【原創】TCP超時重傳機制探索
TCP超時重傳機制探索
作者：tll （360電商技術）
1）通信模型
TCP（Transmission Control Protocol）是一種可靠傳輸協議。在傳輸過程中當發送方（sender）向接收方（receiver）發送的數據丟失時，將引起發送方向接收方重傳丟失的數據包。
其通信模型例如以下：
圖1
2）超時重傳
重傳機制在實現數據可靠傳輸功能的同一時候，也引起了對應的性能問題：何時進行數據重傳？怎樣保證較高的傳輸效率？
重傳時間過短：在網絡因為擁塞引起丟包時。頻繁的重傳會進一步加劇網絡擁塞。引起丟包。惡化網絡傳輸性能。
重傳時間過長：接收方長時間無法完畢數據接收。引起長時間占用連接線路造成資源損耗、傳輸效率較低等問題。
針對上述問題，TCP中設計了超時重傳機制。
該機制規定當發送方A向B發送數據包P1時，開啟一個時長為RTO（Retransmission Timeout）的重傳定時器，假設A在RTO內未收到B對P1的確認報文，則覺得P1在網絡中丟失，此時又一次發送P1。由此，引出RTO大小的設定問題。
對RTO大小的設定，因為的傳輸特性不同將導致發送與接收方完畢一次數據傳輸（發送與應答）的時間不同（例：通常有線網絡的傳輸速率遠高於無線網絡）。因此固定大小的RTO無法滿足不同環境下的傳輸需求。由此TCP採用針對詳細傳輸環境動態測量的方式來確定當前時刻的RTO.
針對上述問題TCP中引入RTT（Round Trip Time），當中RTT為一個數據包從發出去到收到對該包確認的時間差，並依據RTT計算RTO.
因為RTT為單次測量的結果，經常受到網絡拖延等因素的影響，波動較大，便記錄多次的RTT值，通過加權移動的方式計算出一個更加合理的數值即SRTT（Smoothed RTT）。依據SRTT計算RTO.
RTT---->SRTT---->RTO
對於上述數值的計算RFC793做了對應描寫敘述，詳細公式例如以下
SRTT = (α* SRTT ) + ((1-α) * RTT)
RTO = min[UBOUND, max[LBOUND, (β*SRTT)]]
當中 UBOUND 為timeout的上限 (e.g., 1 minute),
LBOUND 為timeout的下限 (e.g., 1 second),
α為平滑因子 (e.g., .8 to .9),
β為時延變化因子 (e.g., 1.3 to 2.0).
由上式能夠看出RTO的計算相對保守。每次新到的RTT對RTO影響較少，如此將導致RTO在RTT變化較大的環境中不能做及時調整。更好的適應當前環境。如此。Van jacobson在Congestion Avoidance and Control 一文中對RTO的計算提出了一種高速算法
當中A為SRTT。M為最新RTT。D為偏差，g=1/2^n ，進一步
如此求得A與D，而RTO=A+4D，完畢對RTO計算。
Linux中詳細實現參考
t=media/appmsg_edit&action=edit&isMul=1&isNew=1&type=10&lang=zh_CN&token=1938686498#L609" _href="#L609">tcp_rtt_estimator
當中而在Linux中RTO的最小值為200ms
#define TCP_RTO_MIN((unsigned)(HZ/5)) /* 200ms */
3）高速重傳
TCP繼續發展。重傳機制得到進一步加強。出現了高速重傳。例如以下圖所看到的：
圖2
高速重傳機制規定：發生丟包時，在重傳定時器被觸發之前，當發送方連續收到3個對丟失數據包的重傳請求時將引起馬上重傳。
如上圖所看到的，數據包2在發送過程中丟失。然而在此時的重傳定時器未到達之前，發送方連續收到4個ACK。當中第一個為對數據包1的確認。後3個ACK在對收到的數據包4，5。6做選擇性應答的同一時候，連續3次告知對方缺少對數據包2的接收。由此觸發高速重傳，數據包10為對丟失數據包2的重傳。
此時假設超時計時未到，將使得發送方能更加及時的發送出待重傳數據包；假設超時計時到達。則相同馬上發送待重傳數據包。
由此可看出，高速重傳機制在一定程度上彌補了超時重傳機制。使得重傳更加及時。
4）選擇性重傳
因為網絡傳輸路徑往往是復雜的。數據包在傳輸中可能發生丟包或者亂序到達，而TCP僅僅對連續的最後一個序列號做應答，使得亂序提前到達的數據包被重傳，導致傳輸性能下降。
為改善此現狀，RFC2018中提出了SACK（Selective Acknowledgement）。通過對ACK選項中加入已經接收的不連續數據塊信息，通過對方不必反復發送對方已經接收的亂序數據塊。
當中TCP首部中SACK選項例如以下所看到的：
圖3
選項中分別用Left Edge of Block 與 Right Edge of Block來表示一個不連續數據塊的第一個數據序號和最後一個數據序號+1。由此Right Edge of Block(n)與Left Edge of Block(n-1) – 1 的間隔表示丟失數據段。
圖4
如上圖所看到的。發送方在發送報文段5，6丟失的情況下，接收方應答報文9完畢對序列號201之前數據的應答，同一時候以SACK 301-401 501-601告知對方已接收數據段。發送方此時僅僅需重傳丟失數據段201-300以及401-500之間的數據就可以。
選擇重傳的出現，在一定程度上大大減少了網絡重傳的數量。提高了網絡吞吐量。
5）定時器的開啟
圖5
a. 重傳計時器對哪些數據包進行計數？
TCP對每個連接採用一個重傳計時器，當定時器已被使用時。當前發送的數據段不被計時。
如上圖所看到的，因為發送數據段3時啟動計時器，所以數據段4在計時器結束之前不再計時。
b. 重傳計時器的起始時間？
如圖發送數據段3，開啟計時器，同一時候記錄此時發送數據包的SEQ（257）。在接收到含有SEQ的ACK時，完畢計時。
如確認段5對SEQ 513之前數據的確認，包括RTT#2 計時起始的SEQ（257），此時RTT#2完畢計時。
同理RTT#3中開啟計時時SEQ（769）此時確認段8中是對SEQ在769之前的確認（不包括769），所以此時RTT3並不結束。
6）重傳次數與時間
圖2描寫敘述了網絡中生成一次丟包與重傳的情景，然而網絡的傳輸場景是復雜的，引起網絡的多次重傳，針對連續的重傳定時TCP採用了指數退讓的方式來減少網絡負載。
圖6
如上圖所看到的，在第12數據包發生丟失時，連續重傳13，14，15。16，17號數據包。其間隔時間分別為6s，12s，24s。48s。96s
1）為什麽不是準確的2倍？
Linux同BSD版TCP採用500ms作為一個滴答的定時器完畢定時功能。例定時6s則須要記錄12次滴答就可以。
例如以下圖所看到的，TCP設置一個6s定時器，則在第0個滴答到來時。完畢計時。因為計時開始發生在12到11的隨意時間，所以此時完畢計時的時間將在5.5～6s之間。
圖7
2）關於默認值
如此可看出，默認重傳次數為3，最高重傳次數為15
3）關於參數的設置與服務的配置
a. 內核中參數的設置
proc文件裏查看當前網絡協議棧等內核信息
sysctl –a 顯示全部系統參數
例查看ipv4一些參數的設置：
圖8
通過echo完畢對內核參數的動態改動。重新啟動失效。
在/etc/sysctl.conf文件裏完畢對參數的改動，使用sysctl –p 使之永久生效。
b. Web server中TCP的參數設置
Apache中對網絡連接的設置：
圖9
c. 應用程序對TCP連接參數的設置
通過setoptsock對socket選項完畢對連接參數的設置，包括擁塞算法、保活時間等參數
setoptsock---> tcp_setsockopt ---> do_tcp_setsockopt
當中do_tcp_setsockopt部分代碼例如以下：
7）小結
TCP是一項復雜的協議，重傳機制作為其保證進行可靠傳輸而存在，致使網絡編程（TCP和UDP）是一個相對復雜的任務，能夠使用默認參數進行傳輸，然而為了提升傳輸性能，往往須要針對詳細的環境做對應的參數設置與細節處理。比如對MTU（Maximum Transmission Unit）的考慮，不同的網絡傳輸環境MTU可能不同。採用同等較大的數據包傳輸層則會引起傳輸效率問題。數據傳輸包過大會引起分片，數據包過小帶塊利用率較低（當中TCP數據字節流傳輸。用戶發送數據時在傳輸層受限與MSS大小完畢數據段切割。UDP為數據報傳輸，IP報文段大小受限於鏈路層MTU的大小。過大的數據包將完畢數據分片並帶來性能損耗，所以應盡量在應用層完畢對報文段大小的確認，避免傳輸過程中不必要的分片過程）。
對保活連接時長和重傳請求次數以及擁塞控制算法的選取都與應用場景有著密切的關系。假設須要進一步提升網絡性能須要對詳細參數做針對性調整。
<完>
-------------------------------------------------------------------------------------
黑夜路人，一個關註開源技術、樂於學習、喜歡分享的程序猿
博客：http://blog.csdn.net/heiyeshuwu
微博：http://weibo.com/heiyeluren
微信：heiyeluren2012
想獲取很多其它IT開源技術相關信息。歡迎關註微信！
微信二維碼掃描高速關註本號碼：
?
【原創】TCP超時重傳機制探索