文章目錄

TCP協議段格式TCP原理確認應答機制超時重傳機制連接管理機制三次握手：四次揮手： 滑動窗口如果出現丟包，如何進行重傳？ 流量控制擁塞控制延遲應答捎帶應答 粘包問題TCP異常情況 TCP，即Transmission Control Protocol，傳輸控制協議，對數據的傳輸進行詳細的控制。

【資料圖】

TCP協議段格式

源/目的端口號：表示數據從哪個進程來，到那個進程去。 源端口號表示報文的發送端口，源端口號和源IP地址組合起來可以表示報文的發送地址。 目的端口表示報文的接收端口，目的端口和目的IP地址組合起來可以表示報文的接收地址。 TCP協議就是根據IP協議的基礎上傳輸的，TCP報文中的源端口號+源IP，與TCP報文中的目的端口號+目的IP一起，組合起來唯一性的確定一條TCP連接。 序號（Sequence Number）：TCP傳輸過程中，在發送端出的字節流中，傳輸報文中的數據部分的每一個字節都有它的編號。序號（Sequence Number）占32位，發起方發送數據時，都需要標記序號。 在數據傳輸過程中，TCP協議通過序號（Sequence Number）對上層提供有序的數據流。發送端可以用序號來跟蹤發送的數據量；接收端可以用序號識別出重復接收到的TCP包，從而丟棄重復包；對于亂序的數據包，接收端也可以依靠序號對其進行排序。 序號會根據SYN是否為1，表示不同的意思： 當SYN為1時，當前為建立連接階段； 當SYN為0是，數據傳輸正式開始。 確認序號（Acknowledgment Number）：確認序號標識了報文接收端期望接收的字節序列。如果設置了ACK控制位，確認序號的值表示一個準備接收的包的序列號，注意，它所指向的是準備接收的包，也就是下一個期望接收的包的序列號。 4位TCP報頭長度：表示TCP頭部有多少個32位bit（4字節）；所以TCP頭部最大長度為 15 * 4 = 60字節。 6位標志位：

URG：緊急指針是否有效；ACK：確認號是否有效，ACK置 1 ，代表起到了確認作用，需要填寫確認序列號（下一次期望收到第一個字節的序列號）；PSH：提示接收端應用程序立刻從TCP緩沖區把數據讀走；RST：對方要求重新建立連接，我們把攜帶RST標識的稱為復位報文段；SYN：請求建立連接，我們把攜帶SYN標識的成為同步報文段；FIN：通知對方，本端要關閉了，我們稱攜帶FIN標識的為結束報文段。

窗口大小：長度為16位，共2個字節。此字段用來進行流量控制。流量控制的單位為字節數，這個值是本端期望一次接收的字節數。 １６位校驗和：發送端填充，CRC校驗。接收端校驗不通過，則認為數據有問題，此處的檢驗和不光包含TCP首部，也包含TCP數據部分。 16位緊急指針：標識那部分數據是緊急數據。

TCP原理

TCP對數據傳輸提供的管控機制，主要體現在兩個方面：安全、效率。 這些機制和多線程的設計原則類似：保證數據傳輸的安全前提下，盡可能地提高傳續效率。

確認應答機制

TCP將每個字節的數據進行了編號，即序列號。 每一個ACK都帶有對應的確認序列號，意思是告訴發送者，我已經收到了那些數據，下一次你從哪里開始給我發。

超時重傳機制

主機A給主機B發送了數據之后，可能會因為網絡擁堵等原因，數據無法發送到B，如果A在一個特定的時間間隔內沒有收到B發來的確認應答，就會重新發送。 當然，A沒有收到確認應答，也可能是ACK丟了。因此，主機B會收到很多重復數據，可以利用序列號做到去重的效果。 那么超時時間如何確定？

TCP為了保證無論在任何環境下都能比較高效地通信，因此會動態計算這個最大超時時間。

連接管理機制

在正常情況下，TCP要經過三次握手建立連接，四次揮手斷開連接

三次握手：

第一次握手：客戶端進入SYN_SENT狀態，發送一個SYN幀來主動打開傳輸通道，該幀的SYN標志位被設置為1，同時會帶上Client分配好的SN序列號，該SN是根據時間產生的一個隨機值。第二次握手：服務端在收到SYN幀之后，會進入SYN_RCVD狀態，同時返回SYN+ACK幀給客戶端，主要目的在于通知客戶端，服務端已經收到SYN消息，現在需要進行確認。 服務端發出的SYN+ACK幀的ACK標志位被設置為1，其確認序號ASN值被設置為客戶端的SN+1；SYN+ACK幀的SYN標志位被設置為1，SN值為服務端生成的SN序號。第三次握手：客戶端在收到服務端的第二次握手的SYN+ACK確認幀之后，首先將自己的狀態會從SYN_SENT變成ESTABLISHED，表示自己方向的連接通道已經建立成功，客戶端可以發送數據給服務端了。然后，客戶端發ACK幀給服務端，該ACK幀的ACK標志位被設置為1，其確認序號ASN值被設置為服務端的SN序列號+1。服務端收到客戶端的ACK之后，會從SYN_RCVD狀態變成ESTABLISHED狀態，至此，TCP全雙工連接建立完成。

四次揮手：

第一次揮手：主動斷開方向對方發送一個FIN結束請求報文，此報文的FIN位被設置為1，發送完成后，主動斷開方進入FIN_WAIT_1狀態，這表示主動斷開方沒有業務數據要發送給對方，準備關閉SOCKET連接了。第二次揮手：正常情況下，在收到了主動斷開方發送的FIN斷開請求報文后，被動斷開方會發送一個ACK響應報文，之后，被動斷開方就進入了CLOSE-WAIT（關閉等待）狀態，TCP協議服務會通知高層的應用進程，對方向本地方向的連接已經關閉，對方已經沒有數據要發送了，若本地還要發送數據給對方，對方依然會接受。被動斷開方的CLOSE-WAIT（關閉等待）還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。第三次揮手：在發送完成ACK報文后，被動斷開方還可以繼續完成業務數據的發送，待剩余數據發送完成后，或者CLOSE-WAIT（關閉等待）截止后，被動斷開方會向主動斷開方發送一個FIN+ACK結束響應報文，表示被動斷開方的數據都發送完了，然后，被動斷開方進入LAST_ACK狀態。第四次揮手：主動斷開方收在到FIN+ACK斷開響應報文后，還需要進行最后的確認，向被動斷開方發送一個ACK確認報文，然后，自己就進入TIME_WAIT狀態，等待超時后最終關閉連接。處于TIME_WAIT狀態的主動斷開方，在等待完成2MSL的時間后，如果期間沒有收到其他報文，則證明對方已正常關閉，主動斷開方的連接最終關閉。 被動斷開方在收到主動斷開方的最后的ACK報文以后，最終關閉了連接。

TCP狀態轉換匯總：

滑動窗口

剛才我們討論了確認應答策略，對每一個發送的數據段，都要給一個ACK確認應答。收到ACK后再發送下一個數據段。這樣做有一個比較大的缺點，就是性能較差。尤其是數據往返的時間較長的時候。 既然這樣一發一收的方式性能較低，那么我們一次發送多條數據，就可以大大的提高性能（其實是將多個段的等待時間重疊在一起了）。

如果出現丟包，如何進行重傳？

情況一：數據包已經抵達，ACK被丟了

情況二：數據包就直接丟了

流量控制

接收端處理數據的速度是有限的。如果發送端發的太快，導致接收端的緩沖區被打滿，這個時候如果發送端繼續發送，就會造成丟包，繼而引起丟包重傳等等一系列連鎖反應。 因此TCP支持根據接收端的處理能力，來決定發送端的發送速度。這個機制就叫做流量控制（Flow Control）。

接收端如何把窗口大小告訴發送端呢？回憶我們的TCP首部中，有一個16位窗口字段，就是存放了窗口大小信息。

擁塞控制

TCP引入 慢啟動 機制，先發少量的數據，探探路，摸清當前的網絡擁堵狀態，再決定按照多大的速度傳輸數據。慢啟動，只是初始時慢，增長的很快

少量的丟包，我們僅僅是觸發超時重傳；大量的丟包，我們就認為網絡擁塞; 當TCP通信開始后，網絡吞吐量會逐漸上升；隨著網絡發生擁堵，吞吐量會立刻下降; 擁塞控制，歸根結底是TCP協議想盡可能快的把數據傳輸給對方，但是又要避免給網絡造成太大壓力的折中方案。

延遲應答

如果接收數據的主機立刻返回ACK應答，這時候返回的窗口可能比較小。

每隔N個包就要應答一次，或者超過最大應答時間也要應答一次。 N一般取2，超時時間取200ms。 窗口越大，網絡吞吐量就越大，傳輸效率就越高。我們的目標是在保證網絡不擁塞的情況下盡量提高傳輸效率。

捎帶應答

粘包問題

對于定長的包，保證每次都按固定大小讀取即可；例如上面的Request結構，是固定大小的，那么就從緩沖區從頭開始按sizeof（Request）依次讀取即可；對于變長的包，可以在包頭的位置，約定一個包總長度的字段，從而就知道了包的結束位置；對于變長的包，還可以在包和包之間使用明確的分隔符。

TCP異常情況

進程終止：進程終止會釋放文件描述符，仍然可以發送FIN。和正常關閉沒有什么區別。 機器重啟：和進程終止的情況相同。 機器掉電/網線斷開：接收端認為連接還在，一旦接收端有寫入操作，接收端發現連接已經不在了，就會進行reset。即使沒有寫入操作，TCP自己也內置了一個保活定時器，會定期詢問對方是否還在。如果對 方不在，也會把連接釋放。

另外，應用層的某些協議，也有一些這樣的檢測機制。例如HTTP長連接中，也會定期檢測對方的狀態。 例如QQ，在QQ斷線之后，也會定期嘗試重新連接。

TCP ： 可靠、有連接、面向字節流