---

📄前言

TCP三次握手、四次揮手，相信許多計算機網絡初學者們都對這些問題感到困擾，TCP協議作為考試、面試的大常客，如果不真正了解它們的原理，那么等待你的很可能是掛科、回去等通知吧（大悲）。為了避免悲劇的再度發生，學習TCP協議不容刻緩，從現在開始！！！

Tcp基礎

概念

TCP(Transfer Control Protocol) ，是一種可靠的、面向連接的網絡通信協議，常用與那些對數據完整性有嚴格要求的場景，如聊天、文件傳輸、Web瀏覽等場景。

Tcp能夠實現對數據的流量控制、重發控制、擁塞控制等功能，如果只是在應用層中使用TCP協議，那么肯定是無法體會得到其內部機制的精細，讓我們從理論開始入手Tcp協議吧。

Tcp的優缺點：

• 優點：

  • 保障數據傳輸的可靠性
  • 擁有流量控制功能
  • 擁有擁塞控制功能

• 缺點：

  • 實現復雜，性能較低（相比UDP）
  • 延遲較高，Tcp偏重于數據的可靠傳輸

Tcp 的報文格式

要了解Tcp的工作機制，就得先從它的報文格式開始談起，下圖為Tcp的報文格式。

		 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|          源端口號            |          目的端口號              |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                        序列號                                 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                        確認號                                 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|   4位     | 保留  |     |U|A|P|R|S|F|   |                     ||   首部    | (6位) |     |R|C|S|S|Y|I|   |      16位窗口大小     ||   大小    |       |     |G|K|H|T|N|N|   |                     |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|           16位校驗和         |           16位緊急指針            |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                       選項及填充（若有）                         |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|                          數據                                 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• 端口號：Tcp使用4字節（32bit）來表示源端口和目的端口號，系統會根據端口號的不同來區分連接。
• 序列號：數據的序列號，因為接收的數據順序可能不一致，所以需要序列號來進行排序。
• 確認號：用于告知發送端已經下一次要收的數據序列。
• 首部大小：用于確定Tcp的報頭長度，計算方式為 首部大小 * 4，也就是說報文頭部大小最大為60字節。
• 標志位：類似于一種信號，使用bit位來標志使用到的標志位。
  • URG (Urgent)：確定緊急指針是否有效，一般很少用緊急指針的內容。
  • ACK (Acknowledge)：表明數據已經收到。
  • PSH (Push)： 告訴系統趕緊把數據取走
  • RST (Rest)： 用于重置連接，在服務器客戶端連接認知不一致的情況使用。
  • FIN (Finish)：用于4次揮手，表明要結束連接。
• 窗口大小：流量控制機制，用于表明接受方的緩沖區大小。
• 校驗和：用于校驗數據是否完整。
• 緊急指針：用于標識一個字節的緊急數據的地址（很少用到）。
• 選項：常見的選項有MSS(Maximum Segment Size)——擁塞窗口大小。

三次握手

三次握手是TCP協議進行網絡通信時必須要做的一件事情，所有的連接都的要進行三次握手后才能開始傳輸數據。這是為了確定通信雙方能夠建立可靠的連接，并且交換雙方的信息。

三次握手的過程

1. 第一次握手由客戶端開始發起，用于確定服務器是否存在。
2. 第二次握手是服務器應答請求并發起連接請求，當客戶端收到后則客戶端對服務器的連接就已經建立完畢。
3. 第三次握手是客戶端通知服務器建立連接。

連接丟失的情況：

• 第一、二次握手連接丟失：客戶端因為沒有收到服務器的消息，所以會重新發送報文給服務器。
• 第三次握手連接丟失：這種情況便是雙方連接認知不一致，因為客戶端會認為服務器端已經收到了報文并且建立了連接。客戶端在這種情況下發送數據給服務器端的話，服務器會發送一個帶有RESET標志的報文給客戶端，重新進行三次握手。

四次揮手

四次揮手是用于安全斷開連接的措施。當客戶端選擇斷開連接的時候，服務器端可能還有數據沒有傳輸完畢，所以需要將連接稍微延長，直到數據被完全傳輸完畢。

1. 第一次揮手：表明本地已經沒有需要發送的數據，告訴遠端準備好斷開連接。
2. 第二次揮手：遠端已經收到FIN信號，返回應答，并繼續處理未處理完的數據。
3. 第三次揮手：遠端已經處理完所有數據，告訴本地已經關閉連接（FIN）。
4. 第四次揮手：本地進行應答，然后進入TIME_WAIT狀態，一段時間后結束（CLOSED）。

四次揮手的小細節：

• 四次揮手不像三次握手一樣，會造成認知不一致狀態。
• 四次揮手有極小概率會變成三次揮手（即當FIN信號到了的時候，數據早已經處理完畢）。
• TIME_WAIT狀態的時間是2 * MSL(最大報文生存時間)，而這個時間也是Tcp報文在網絡的最大生存時間，從而確保網絡的延遲報文能夠正確接收，避免影響下次復用該端口號時收到未知的報文。

Tcp的滑動窗口機制

概念

Tcp的三次握手中報文的交換是一個接一個的，但如果數據的傳輸也是如此，勢必會讓傳輸的效率遭到大幅度地下降，于是Tcp協議使用了滑動窗口這種機制來讓數據高效傳輸。

滑動窗口傳輸的細節：

1. 滑動窗口通過序列號來將收到的報文規范排列。
2. 滑動窗口使用確定序列號來通知遠端下一個要接收到報文。
3. 確定序列號代表該序列號之前的報文已經全部接收。
4. 滑動窗口允許一定的確定報文丟失，因為確定序列號代表之前的報文已經全部接收，只要最后到確定報文到達即可。

超時重傳機制

當Tcp發送報文長時間沒有得到應答，則會進行超時重連，沒有收到應答的原因可能是發送的報文數據在網絡傳輸過程中丟失了，也可能是對端發送的ACK消失了。無論是哪一種情況，發送方都會重新發送數據給接受端，接受端再根據Tcp報文中的序列號來確定該數據是否已經接收過。

高速重傳

我們已經知道滑動窗口是用于提高數據傳輸的效率的，如果有任意一個報文沒收到都要等待這么長時間才能重新接受，那么不就是本末倒置了嗎？于是TCP又設置了高速重傳機制——當連續三個ACK報文的確認序列號都相同時，發送端將重發該序列段的數據。

TCP傳輸控制機制

流量控制

設想一下，如果你正在下載某個文件，下載速度非常地快，以至于你的硬盤都來不及去讀取你下載的內容，而服務器又不停地高速給你發送數據，那么你的系統也只能丟棄這些數據，但這樣會造成非常大的網絡資源浪費。有沒有什么辦法能夠阻止這種浪費呢？

你是否還記得Tcp報頭中有一個窗口大小呢？其實Tcp在進行三次握手和傳輸數據期間，都會根據雙方緩沖區的大小動態更新窗口大小，從而實現流量的控制。

流量控制的小細節：

1. 接收端通過接收緩沖區的大小更新滑動窗口大小，然后通過ACK報文通知發送端。

2. 窗口大小也是反映網絡吞吐量的標準。

3. 當接收端窗口大小為0，發送端將停止發送數據一段時間并定時發送窗口探測，直到接收端有能力接受數據。

擁堵控制

慢啟動

我們已經知道TCP擁有流量控制功能，滑動窗口能夠根據對方的緩沖區（窗口大小）動態調整，但網絡環境是復雜的，我們還需要考慮客戶端與服務器之間的網絡情況。如果一次發送大量的數據給對方，可能會對網絡造成癱瘓。為了防止這種情況的發生，TCP使用了慢啟動算法。

1. 慢啟動：其實在Tcp協議的內部，還定義了一個叫做擁塞窗口的變量（非窗口），當數據開始進行傳輸時，這個值被設為1，發送端每收到一個來至接收端的ACK時，擁塞窗口都會呈指數增長。

2. 擁堵避免：一旦擁堵窗口達到一定大小（閾值）時便會進入線性增長模式，即每接受一個ACK，擁塞窗口就+1。

3. 動態調整： 因為網絡的狀態總是不穩定的，所以擁塞窗口的閾值會隨著網絡的丟包/持續傳輸而動態變化。

滑動窗口大小實際為：min( 窗口大小，擁塞窗口 )。

Tcp的性能優化機制

延遲應答

在文章上方的介紹中，我們都是以發送端每發送一個報文，接收端就返回一個報文來進行通信的，但實際的通信過程中，接收端并不會立刻應答，而是選擇等待一段時間，接受多個報文后再回復對方，從而減少網絡的壓力。

延遲應答的小細節：

1. 根據操作系統的不同，可能會在接受到兩個報文后直接回復。
2. 根據操作系統的不同，延遲發送的時間也會不同，時間越長觸發超時重傳的概率也就越高，一般操作系統將延遲應答時間設置為0.2秒。

捎帶應答

捎帶應答其實我們在三次握手中已經見到過了，其實也就是在發送其他數據的時候同時帶著應答報文，從而減少應答報文在網絡的傳輸，降低網絡壓力。

📓總結

TCP協議的設計不僅考慮了連接的可靠性，還考慮到了流量控制、擁堵控制、性能優化等各種方法，相信學習了本文了你，被問到TCP協議的特點時，肯定能侃侃而談，給對方一個好影響吧。

參考書籍：《圖解TCP/IP》

📜博客主頁：主頁
📫我的專欄：C++
📱我的github：github