TCP 如何處理失敗重傳呢？

1  網絡協議背景概念

4層網絡傳輸是基於udp基於端口

7層網絡協議傳輸是基於tcp基於端口（tcp的複雜度很高很高..），並在tcp之上添加了會話層表示層應用層

upd協議面向報文，tcp協議 面上字節流。

 

啥是面向字節流呢？

 

2  TCP傳輸通訊過程

tcp面向字節流，udp面向報文。那tcp的字節流是怎樣的呢？

tcp是點到點的通訊，創建tcp連接的兩個端點，傳輸的數據不是報文，是一段數據中的一部分，並不知道一次讀的數據是多少和發送次數。

數據交給tcp層，由tcp決定一次發送多少數據，判斷條件有不少，發送窗口、擁塞窗口、路徑上的最大傳輸單元（MTU），輸出隊列數據總量等。

 

如圖在tcp發送數據以前，應用程序和tcp協議之間有一個tcp緩存隊列，這個隊列不固定字節大小，tcp要發送的數據也不固定字節大小，

tcp是去發送數據的一部分字節流，

並在這個傳輸中一直單向的進行。 ？？？？？？？

因此在網絡傳輸中能夠看到的是數據片斷，而後是一組一組的數據交付給接收方。

 

3  傳輸報錯重傳機制

若是發送方發送 1 2 3 4 接收方只收到 1 2 回覆確認 ack 3，而後發送方發來了 4，不能回覆確認ack 5，由於不能跳躍確認。

因而，採用重傳機制，有2種：

3.1  超時重傳

發送方不知道3 4 5 的接收狀況，接收方一直在等 3，這中方式會有比較嚴重的問題。

發送方有兩種選擇：

  a ,  默認 3 發送失敗，從新發送3 

  b ，默認 3 4 5 發送失敗，重傳 3 4 5 

a的方式，只傳 3可能會慢，b的方式傳 3 4 5 很快可是佔用帶寬，timeout也可能很長，這兩個都不是最後的方法。

3.2  快速重傳

tcp還有一種 快速重傳 的算法，Fast-Retransmit，是以數據驅動重傳，不是timeout時間驅動。

怎麼是以數據驅動呢？

就是 若是隻收到 1 2 ，回覆ack 3 ，隨後收到了 4 5 可是還沒收到 3， 4 5的ack也回覆 3 3，這樣發送方會收到3個同樣的ack，會知道傳輸出了問題

這就是大部分tcp數據驅動重傳機制（什麼？大部分tcp，總共是有幾個版本的..）。

這種方式還不是最好的，只是解決了timeout的問題，回傳的個數仍是沒解決，好比一次發了20條，就不知道是哪3個發的ack了，須要回傳這20條。。

3.3  sack 重傳

選擇性重傳，Selective Acknowledgement（sack），tcp的頭會多一個SACK，快速重傳的ACK還在。

sack只回復已經到達的碎片，這樣發送端就能準確知道是重傳那部分字節流。在Linux能夠用tcp_sack這個字段開啓這個功能，2.4版以後的Linux默認開啓。

 

參考：https://tools.ietf.org/html/rfc2018  https://www.jianshu.com/p/69695f332a71

 

遺留問題

tcp重傳還有一些問題，sack也不能徹底相信：

若是有接收端會將數據保存直到失敗的分組重傳，就會有接受方內存擁擠把收到的數據丟棄了，可能有。