TCP-IP详解：重传机制
參考教材：TCP-IP Guide?
?
超時重傳是TCP保證數(shù)據(jù)傳輸可靠性的又一大措施，本文主要介紹重傳TCP報文的兩大舉措：超時重傳和快速重傳
?
超時重傳機制
超時重傳指的是，發(fā)送數(shù)據(jù)包在一定的時間周期內(nèi)沒有收到相應(yīng)的ACK，等待一定的時間，超時之后就認為這個數(shù)據(jù)包丟失，就會重新發(fā)送。這個等待時間被稱為RTO. ?
檢測丟失segment的方法從概念上講還是比較簡單的，每一次開始發(fā)送一個TCP segment的時候，就啟動重傳定時器，定時器的時間一開始是一個預(yù)設(shè)的值（Linux 規(guī)定為1s），隨著通訊的變化以及時間的推移，這個定時器的溢出值是不斷的在變化的，有相關(guān)算法計算RTO[參考：文章....],如果在ACK收到之前，定時器到期，協(xié)議棧就會認為這個片段被丟失，重新傳送數(shù)據(jù)。
TCP在實現(xiàn)重傳機制的時候，需要保證能夠在同一時刻有效的處理多個沒有被確認的ACK，也保證在合適的時候?qū)γ恳粋€片段進行重傳，有這樣幾點原則：
1 . 這些被發(fā)送的片段放在一個窗口中，等待被確認，沒有確認不會從窗口中移走，定時器在重傳時間到期內(nèi)，每個片段的位置不變，這個地方其實在滑動窗口的時候也有提到過
2 .只有等到ACK收到的時候，變成發(fā)送并ACK的片段，才會被從窗口中移走。
3 .如果定時器到期沒有收到對應(yīng)ACK， 就重傳這個TCP segment
重傳之后也沒有辦法完全保證，數(shù)據(jù)段一定被收到，所以仍然會重置定時器，等待ACK，如果定時器到期還是沒有收到ACK，繼續(xù)重傳，這個過程重傳的TCP segment一直留著隊列之內(nèi)。
舉個重傳的例子：
1. Server 發(fā)送80個字節(jié) Part1，seq = 1?
2. Server 發(fā)送120個字節(jié)Part2，Seq = 81
3. Server發(fā)送160個字節(jié)Part3，Seq = 201，此包由于其他原因丟失
4. Client收到前2個報文段，并發(fā)送ACK = 201
5. Server發(fā)送140個字節(jié)Part4， Seq = 361
7. Server收到Client對于前兩個報文段的ACK，將2個報文從窗口中移除，窗口有200個字節(jié)的余量
8. 報文3的重傳定時器到期，沒有收到ACK，進行重傳
9. 這個時候Client已經(jīng)收到報文4，存放在緩沖區(qū)中，也不會發(fā)送ACK【累計通知，發(fā)送ACK就表示3也收到了】，等待報文3，報文3收到之后，一塊對3,4進行確認
10. Server收到確認之后，將報文3,4移除窗口，所有數(shù)據(jù)發(fā)送完成
這種方式會面臨一個問題：客戶端在等待報文3的時候，服務(wù)器如何處理報文4， 客戶端這個期間內(nèi)并沒有發(fā)送任何報文，服務(wù)器并不知道報文3和報文4的狀態(tài)，報文4可能會丟失，也可能會被客戶端接收，那么如果超時了，我到底值該發(fā)送報文3 ，還是報文3和報文4 呢？
總結(jié)起來就是2中處理
1. 定時器溢出，重傳3
2. 定時器溢出，重傳3,4
對于怎么傳的問題，在RFC2018中已經(jīng)提供了一種方案: SACK, ? ?詳細可參考文章：TCP-IP詳解：SACK選項（Selective Acknowledgment）
對于重傳時間是如何計算的問題，在RFC2988中也提供了一種至今Linux使用的方案，詳細介紹可以參考文章：TCP-IP詳解 RTT and RTO
對于定時器溢出的問題,就來介紹一下 快速重傳機制。
?
快速重傳機制
在超時重傳中，重點是定時器溢出超時了才認為發(fā)送的數(shù)據(jù)包丟失，快速重傳機制，實現(xiàn)了另外的一種丟包評定標準，即如果我連續(xù)收到3次dup ACK，發(fā)送方就認為這個seq的包丟失了，立刻進行重傳，這樣如果接收端回復(fù)及時的話，基本就是在重傳定時器到期之前，提高了重傳的效率。
在傳輸過程中會出現(xiàn)out-of-order的現(xiàn)象，但是在滑動窗口中會有嚴格的順序控制，假設(shè)有4，5，6三個待接收的數(shù)據(jù)包，先收到了5,6，協(xié)議棧是不會回復(fù)對5,6包的確認，而是根據(jù)TCP協(xié)議的規(guī)定，當接收方收到亂序片段時，需要重復(fù)發(fā)送ACK, 在這個地方會發(fā)送報文4 seq的ACK，表明需要報文4沒有被接收到，如果此后收到的是報文7，那么仍然要回報文4 seq的ACK，如果連續(xù)發(fā)送3個 dup ACK，接收端認為這個片段已經(jīng)丟失，進行快速重傳。
看一個簡單的例子：這是下載過程中網(wǎng)絡(luò)不好抓的tcpdump
1. 145/153/170 是3個dup ACK
2. ?171包，快速重傳
不過快速重傳能夠解決超時的問題，但是對于之前討論的究竟重傳哪些包的問題，依然不能有效的解決，這就需要TCP中提供的SACK機制來解決。
?
參考文章
1.http://blog.jobbole.com/71427/
2.http://www.cricode.com/2688.html
3.http://blog.csdn.net/jiqiandong/article/details/39393889
總結(jié)
以上是生活随笔為你收集整理的TCP-IP详解：重传机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 802.11帧聚合技术
- 下一篇： 浅析TCP之SACK（选择性确认）