1 網絡協議背景概念html
4層網絡傳輸是基於udp基於端口算法
7層網絡協議傳輸是基於tcp基於端口（tcp的複雜度很高很高..），並在tcp之上添加了會話層表示層應用層緩存
upd協議面向報文，tcp協議 面上字節流。網絡
啥是面向字節流呢？tcp
2 TCP傳輸通訊過程url
tcp面向字節流，udp面向報文。那tcp的字節流是怎樣的呢？spa
tcp是點到點的通訊，創建tcp連接的兩個端點，傳輸的數據不是報文，是一段數據中的一部分，並不知道一次讀的數據是多少和發送次數。.net
數據交給tcp層，由tcp決定一次發送多少數據，判斷條件有不少，發送窗口、擁塞窗口、路徑上的最大傳輸單元（MTU），輸出隊列數據總量等。3d
如圖在tcp發送數據以前，應用程序和tcp協議之間有一個tcp緩存隊列，這個隊列不固定字節大小，tcp要發送的數據也不固定字節大小，htm
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也不能徹底相信：
若是有接收端會將數據保存直到失敗的分組重傳，就會有接受方內存擁擠把收到的數據丟棄了，可能有。