簡述TCP可靠性傳輸設計

概念掃盲

TCP 全稱 Transmission Control Protocol（傳輸控制協議），是傳輸層協議的一種。 傳輸層位於網絡層之上，用於處理網絡層（IP路由）尋址成功後端對端的傳輸過程控制，它的發展過程以下：

1. 客戶端、服務端尋址成功後，如何肯定當前網絡鏈接是須要哪一個進程去處理呢？綁定一個進程端口，綁定端口後咱們就基本實現了UDP（User Datagram Protocol，用戶數據報協議）；
2. 傳輸過程當中數據丟失問題如何解決？在UDP的基礎上補充可靠性設計，這就是TCP。

TCP要解決的4個可靠性問題

其實TCP要處理的問題很是多，這裏說的4個問題只是大框架的問題。

1. 鏈接問題

問題引入場景：尋址成功後，客戶端開始發送數據了，結果服務端進程都沒啓動，尷尬了。。

那如何解決：三次握手、四次揮手

爲何揮手比握手多一次呢？創建鏈接的時候讀寫是一塊兒開啓的，可是關閉鏈接時讀寫要分開關閉

1. client:FIN
2. server:ACK(server關閉讀，client關閉寫)
     。。間隔一段時間等待server寫完。。
3. server：FIN
4. client：ACK（server關閉寫，client關閉讀）
複製代碼

2. 丟包問題

問題引入場景：A向B發送了10個數據包，結果由於各類緣由B只收到了8個，可是B不知道A發送了10個，A也不知道B只收到了8個

如何解決：ACK確認，超時重傳

ACK確認策略的優化手段

1. 批量確認：再也不等待接收到上一個消息ACK以後再發送下一個消息，而是一次性批量發送多個數據包，後續慢慢接受ACK；
2. 批量確認如何判斷ACK與Packet的對應關係？給每一個數據包添加seq序號（Sequence Number序列號），ACK回覆seq+1；
3. 累計確認：若是A收到ACK爲10，代表前9個seq所有收到，這樣的話能夠必定程度上緩解ACK丟包問題。

3. 發送/接收數據處理速度同步問題

問題引入場景：client發送很是快，一秒鐘發了一個G，server一天才能處理完一個G的數據，那server要麼溢出，要麼數據就全丟了。

如何解決：滑動窗口。

4. 解決網絡擁塞問題

問題引入場景：server很強，給多少我都能處理，可是網絡不大行，發送5個數據能發過去，發送10個數據確定會丟掉幾個，怎麼辦？

如何解決：與速度滑動窗口相結合的網絡擁塞窗口，先發5個試試發現都收到ACK了，再發10個試試發現有丟的，再發7個發現沒問題，大概網絡擁塞窗口就是7吧。

最終窗口大小 = min(網絡擁塞窗口cwnd, 流速窗口rwnd)