可靠傳輸，是TCP最核心的特性
可靠傳輸不是說數據100%傳輸給接收方了
1）發送方發出數據后，能過知道接收方是否收到數據
2）一旦發現對方沒收到，可以通過一定的方法”補救”
1. 確認應答
發送方，把數據已發給接收方后，接收方收到數據就會給發送方返回一個 應答報文（acknowlrdge，ack）
發送方，如果接收到這個應答報文，就知道自己的數據是否發送成功了
發送數據的時候可能會出現“后發先至”的情況——>
一個數據包在進行傳輸的過程中，走的路徑非常復雜，不同的數據包，可能走不通的路線
TCP 此事要完成兩個工作：
1. 確保應答報文和發出去的數據，不要出現歧義?
2. 確保在出現先發后至的情況下，能夠讓應用程序這邊仍然按照正確的順序來理解數據
序號就是一個整數，大小關系描述了數據的先后順序
序號是按照字節編號的——>TCP是面向字節流的
TCP報頭記錄的序號，是這一次傳輸的載荷數據中第一個字節的序號，剩下的序號，都需要一次推出
如圖可知，第一次序號為1，第二次為1001，
相當于是1001之前的數據都被接收到了，接下來對端開始索要1001開始的數據
此處通過特殊的ack數據包，里面攜帶的“確認序號”告訴對方，那些數據已經被確認了
此時發送方，就知道了自己發送的數據到沒到
可靠傳輸——>達成的最核心機制是? 確認應答
區分一個數據包是普通的數據，還是ack應答數據報
? 第二位? ACK
為1，當前數據包是一個應答報文，里面的“確認序號字段”生效
為0，當前數據寶是一個普通報文，里面的“確認序號字段”不生效
2. 超時重傳
如果數據包太多了，就會阻塞在一些交換機/路由器上，其中大部分的數據包就被直接丟棄了
確認應答是一個理想的情況，如果網絡傳輸過程中，出現丟包，發送方就無法收到ack
——>使用超時重傳，針對確認應答，進行補充
由于丟包是一個隨機事件，于是就有兩種情況：
? ? ? ? ? ? 1. 傳輸的數據丟了? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?2. 返回的ack丟了
站在傳輸方的角度，無法區分這兩種情況
無論出現上述那種情況，發送方都會進行“重新傳輸”
此時，發送方何時重傳——>
發送方，在發出數據之后，會先等一段時間，如果這個時間之內，ack來了，就是為數據到達，反之，就會觸發重傳
1. 初始的等待時間，是可配置的，不同系統上的不一定一樣，可以通過修改內核參數來改變
2. 等待是時間，也會動態變化，每多經歷一次超時，等待時間就會變長
等待也不是無限拉長的，重傳若干次，就會放棄TCP連接（觸發TCP重置連接）
等待時間變長，意味著對能正確傳輸數據是悲觀的
如果數據丟了，不會觸發ack；如果ack丟了，返回的是ack發送數據的第一個字節（滑動窗口）
? ? ?
返回的ack丟失時，B會收到兩條一樣的數據——>
TCP會有一個“接收緩沖區”（內存空間），保存當前已經接收到的數據，以及數據的序號
如果接收方發現，當前發送方發來的數據，已經在接收緩沖區中存在（收到重復的數據），接收方就會直接把這個后來的數據丟棄掉，確保應用程序進行read的時候，讀到的是只有一條數據
3. 連接管理
建立連接（三次握手）+斷開連接（四次揮手）? ? ? ? handshake
handshake相當于是打個招呼，沒有實際意義，比較簡短，是為了引起對方注意
TCP的“握手”，也就是給對方傳輸一個簡短的，沒有業務數據的數據包
通過這個數據包，喚起對方注意，從而觸發后續的操作
同步報文段——特殊的TCP數據包，沒有載荷（不攜帶業務數據）——>應用層數據包
? ? ? ? 第五位
為1，表示這個報文是一個同步報文段
為0，則不是
TCP 的三次握手
TCP 在建立連接的過程，需要通信雙方一共“打三次招呼”才能建立連接
? ? ? ? ? syn? 同步報文段? ? ? ack? 應答數據報
此時，A和B記錄了對方的信息（構成“邏輯”上的連接）
通信過程中，通信雙方都要給對方發起syn，也要反饋ack
一共進行四次握手，中間兩次可以合并成一次
TCP是為了實現可靠傳輸
進行確認應答和超時重傳有個前提，當前網絡環境時基本可用的，通暢的
三次握手的作用：
1）確認當前網絡是否暢通
2）要讓發送方和接收方都能確認自己的發送能力和接受能力均正常
3）讓通信雙方在握手過程中，針對一些重要參數進行協商
TCP通信過程中的序號從幾開始，就是雙方協商出來的（一般不是從1開始）
每次建立連接的時候，都會協商出一個比較大的，和上次不一樣得值
有時候網絡不太好，客戶端和服務器可能
在新的連接建立好后，舊的數據又傳輸過來斷開重連，此時應該直接丟棄——>
如果發現收到的數據序號和當前數據序號差異較大，就可以直接丟棄
此處僅對連接管理機制進行初步介紹，下節將詳細介紹連接管理和其他機制?
