目錄
- TCP如何實現可靠傳輸？
- TCP如何實現流量控制？（滑動窗口）
- TCP如何實現擁塞控制？（慢開始、擁塞避免、快重傳、快恢復）
引申：
1.UDP能否也實現可靠傳輸？
2.TCP為什么要三次握手、四次揮手？兩次握手、3次揮手行不行？
3.什么情況使用UDP好、什么情況使用TCP好？
1. TCP如何實現可靠傳輸
TCP的可靠傳輸是基于連續ARQ協議的，ARQ協議中有兩個重要的概念：滑動窗口和累計確認。但是我認為TCP能實現可靠傳輸不僅僅是靠連續ARQ協議，還依靠了：
1.通過三次握手、四次揮手來保證信道的可連接性 ；
2.采用停止等待協議、連續ARQ協議（自動重傳）來保證數據的正確性；
3.序列號和確認應答號保證了數據的有序性，
4.校驗和：如果收到字節的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。
1.1 TCP三次握手的必要性
TCP通過三次握手來確定這是一個可靠的連接，三次握手的目的是為了確定客戶端和服務端都有正常的【收發】能力，即客戶端可以發送和接收消息，服務器也可以發送和接收消息。
- 第一次：客戶端 → 發送請求 （ SYN = 1，syn = x ）→ 服務端，服務端知道【客戶端】可以【發送】消息；
- 第二次：服務端 → 應答+請求 （ ACK = 1 , SYN = 1，syn = y , ack = x + 1）→ 服務端，客戶端知道【服務端】可以【接收】自己的消息，并且知道它能【發送】消息；
- 第三次：客戶端 → 應答 （ ACK = 1，syn = x + 1 , ack = y + 1 ）→ 服務端，服務端也確認【客戶端】能【接收】消息。
那么如果只有兩次握手，則【客戶端】的【接收】能力并沒有得到確認，不能確定這是一個可靠的連接。同時，為了實現可靠數據傳輸， TCP 協議的通信雙方， 都必須維護一個序列號， 以標識發送出去的數據包中， 哪些是已經被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值， 并確認對方已經收到了序列號起始值的必經步驟，如果只是兩次握手， 至多只有連接發起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認。
1.2 TCP為什么要4次揮手？
- 因為TCP是一個全雙工的鏈接，即客戶端可以向服務器傳送數據，服務器也可以向客戶端傳送數據。當客戶端【請求】斷開連接時，代表客戶端需要向服務器發送的數據已經完畢，服務器【確認】收到斷開連接，此時進行了兩次揮手。 如果和建立TCP鏈接時一樣立刻進行第三次揮手會出現一個問題：服務器需要向客戶端發送的數據此時不一定全部發送完畢，這時需要等待服務器發送完送有的數據，才能進行下面的操作。
- 當服務器也發送完所有的數據給客戶端，才能進行后兩次揮手。服務器向客戶端發送一條斷開連接的【請求】，客戶端【確認】應答后，服務器立刻進入了CLOSED模式。
- 此時客戶端還不能立刻進入CLOSED模式，需要等待2MSL。原因：由于客戶端最后一個ACK可能會丟失，這樣B就無法正常進入CLOSED狀態。于是B會重傳請求釋放的報文，而此時A如果已經關閉了，那就收不到B的重傳請求，就會導致B不能正常釋放。而如果A還在等待時間內，就會收到B的重傳，然后進行應答，這樣B就可以進入CLOSED狀態了。
1.3 停止等待協議、連續ARQ協議、選擇重傳
這三個協議的目的，都是為了保證了客戶端和服務器的數據，能確保傳送到對面。如果數據在中途丟失或者延遲，則需要重新發送，一直到對面接收到為止。
停止等待協議：
A每發送完一個報文M，就等候B對其確認；如果沒收到確認，則不能繼續發送，收到確認后再繼續發送。缺點是一個個字節發送效率太低。
數組分組在傳輸過程中發生錯誤時有兩種情況：
1、當接收方收到錯誤數據分組時，會直接丟棄分組。
2、如果數組分組在傳輸的過程中丟失。
在這兩種情況下，接收方都不會發送任何信息。發送方在一定時間內沒有收到確認，就認為分組丟失，然后重傳該數據分組，這就叫超時重傳。
停止等待ARQ協議就是通過這種確認和重傳的機制，在不可靠的網絡上實現可靠通信。
連續ARQ協議：
顯然，每次只發送一個報文然后等待確認效率太低。連續 ARQ 協議可提高信道利用率。發送方維持一個發送窗口，凡位于發送窗口內的分組可以連續發送出去，而不需要等待對方確認。接收方一般采用累計確認，對按序到達的最后一個分組發送確認，表明到這個分組為止的所有分組都已經正確收到了。如果中間發生丟失包的情況，A需要回退到確認的報文重新發送。
A的發送窗口大小是根據B接受窗口設置的。也就是說A發送的報文速度不能超過B處理報文的速度。
TCP中對于超時重傳時間的選擇是根據平均往返時間RTT來計算的。也就是說，如果A超過一個報文平均往返時間沒有收到確認，就會重新發送報文。
選擇重傳：
選擇重傳ARQ協議是指在接收方收到未按序排列的數據流時，通知發送方重傳缺失的數據，而不是重傳全部數據。TCP數據段首部中添加選擇確認選項SACK可以實現該目的。
如圖所示，假設上述分組都在發送窗口中，收到三個不連續的分組。三個分組的邊界分別為：[4000,5001]、[6000,7001]、[8000,9001]。在建立TCP連接時，連接雙方先商定好，在首部選項中加入“允許SACK”的選項。在之后的TCP報文段中增加SACk選項，以便接收方向發送方報告不連續的字節塊的邊界。
因為序號是32位，因此指明一個邊界需要4個字節，說明一個字節塊的邊界需要8個字節。另外需要一個字節指明是SACK選項，一個字節指明這個選項的大小。TCP報文段首部選項最大為40個字節，因此最多指明4個字節塊的邊界信息。
TCP標準并未指明發送方應該如何響應SACK，因此大多數實現還是重傳所有未被確認的數據分組。
2. TCP的流量控制
利用滑動窗口機制可以實現對發送方的流量控制。在TCP連接建立時，接收方會在確認報文段中給出自己接收窗口的大小。在每次發送確認報文時能夠根據情況動態調整接收窗口的大小，并將告知發送方。如下圖所示：
??發送方發送序號從1開始的100字節的數據，接收方在確認報文中聲明自身的接收窗口大小為300字節。之后發送方發送300字節數據，接收方在確認報文中聲明自身接收窗口大小調整為50字節。發送方再發送50字節數據之后，收到接收方傳來的確認報文，在該報文中聲明接收窗口為0。
??在接收方接收窗口為0時，發送方不再發送數據，直到接收方發送確認報文表明窗口大小發生改變。可是這個確認報文不一定能夠被發送方接收到，如果一旦該確認報文丟失，雙方都將處于等待中，形成死鎖。為防止這種情況出現，TCP規定在收到對方接受窗口為0時，啟動一個堅持定時器周期性的發送探測報文，以確定對方接收窗口為0的狀態是否改變。
??另外，TCP標準規定：接收方接收窗口為0時，不再接收正常數據，但是可以接收零窗口探測報文段、確認報文段、攜帶緊急數據的報文段。
3. TCP的擁塞控制
- 擁塞控制是指防止過多的數據注入網絡中，這樣可以使網絡中路由器或者鏈路不致過載。現在通信線路的傳輸質量一般都很好，因傳輸出現差錯丟棄分組的概率很小。因此，判斷網絡擁塞的依據就是出現了超時。
- TCP進行擁塞控制常用的算法有四種：慢啟動、擁塞避免、快重傳、快恢復。
3.1 慢啟動
當主機開始發送數據時，如果立即將較大的發送窗口的全部數據注入網路中，那么由于不清楚網絡的情況，有可能引起擁塞。比較好的方式是試探一下，即從小到大逐漸增大發送端的擁塞控制窗口數值。cwnd以指數增長的形式增長。
3.2 擁塞避免
- 當窗口值逐漸增大時，為了防止cwnd的增長導致網絡擁塞，還需要一個變量——慢開始門限ssthresh。當cwnd以指數增長的形式增長到大于或等于ssthresh時，就不再采用慢啟動算法，而是采用擁塞避免算法來進行擁塞控制。
- 擁塞避免算法規定：每次收到一個確認時將cwnd增加1/cwnd個SMSS。即不再是像慢啟動算法那樣經過一輪傳輸cwnd翻倍了，而是經過一輪傳輸增加一個SMSS。這是一種加性增長的關系。
??當擁塞發生時（超時或收到重復確認），cwnd被設置為1個SMSS。ssthresh被設置為當前窗口大小的一半，但最少為 2個報文段。
3.3 快重傳
- 如果個別報文段在網絡中丟失，網絡并沒有發生擁塞，這種情況下發送方收不到確認報文，在超時之后會重傳該報文。發送方誤以為網絡發生擁塞，錯誤的啟動慢開始算法，降低了傳輸效率。
- 采用快重傳算法可以讓發送方盡早知道個別報文段的丟失。快重傳算法要求接收方不要延時發送確認，即使收到失序的報文段也要立刻發送對已收到報文的重復確認。如下圖所示：
接收方收到M1之后發送對M1的確認報文，M2報文丟失，之后接收方收到M3、M4、M5時每次都發送對M1報文的重復確認。快重傳算法規定當收到三次重復確認后，發送方就認為M2報文段丟失，立即重傳M2報文段。
- 快重傳算法并非取消了重傳機制，只是在某些情況下更早的重傳丟失的報文段（如果當發送端接收到三個重復的確認ACK時，則斷定分組丟失，立即重傳丟失的報文段，而不必等待重傳計時器超時）。
3.4 快恢復
- 當發送方連續收到接收方發來的三個重復確認時，就執行“乘法減小”算法，把慢開始門限減半，這是為了預防網絡發生擁塞。
- 由于發送方現在認為網絡很可能沒有發生擁塞，因此現在不執行慢開始算法，而是把cwnd(擁塞窗口)值設置為慢開始門限減半后的值，然后開始執行擁塞避免算法，使擁塞窗口的線性增大。
作者：白馬笑西風
鏈接：https://juejin.cn/post/6844903799253909512
