?

TCP是TCP/IP協(xié)議族中一個最核心的協(xié)議，它向下使用網(wǎng)絡(luò)層IP協(xié)議，向上為應(yīng)用層HTTP、FTP、SMTP、POP3、SSH、Telnet等協(xié)議提供支持。本文給出TCP報文格式的詳細說明，介紹網(wǎng)絡(luò)數(shù)據(jù)包傳遞中如何進行地址解析、建立TCP連接的三次握手過程以及斷開TCP連接的四次揮手過程。

1.? 簡介

傳輸控制協(xié)議（英語：Transmission?Control?Protocol，縮寫：TCP）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由國際互聯(lián)網(wǎng)工程任務(wù)組(The Internet Engineering Task Force, IETF)的 RFC793 定義。在簡化的計算機網(wǎng)絡(luò) OSI 模型中，它完成傳輸層所指定的功能。

在TCP定義中，有以下3點需要特別說明：

(1)什么是面向連接？

面向連接是相對于另一個傳輸層協(xié)議UDP(User Datagram Protocol,?用戶數(shù)據(jù)報協(xié)議)而言的。TCP在開始傳輸數(shù)據(jù)前要先經(jīng)歷三次握手建立連接，并通過連接一對一發(fā)送消息，傳輸結(jié)束后通過四次揮手斷開連接。

而UDP是無連接的，發(fā)送方在發(fā)送數(shù)據(jù)之前不需要與接收方建立連接，即刻可以傳輸數(shù)據(jù)，每個UDP數(shù)據(jù)包都是獨立的，相互之間沒有關(guān)聯(lián)，因此UDP可以一對一、一對多或多對多發(fā)送消息。

(2)什么是可靠的通信協(xié)議？

是否可靠也是相對于UDP而言的。TCP自身有三次握手和超時重傳等機制確保數(shù)據(jù)的可靠傳輸，發(fā)送方在發(fā)送數(shù)據(jù)包后會等待接收方發(fā)送確認(ACK)消息。如果發(fā)送方在一定時間內(nèi)未收到確認消息，它將假定數(shù)據(jù)丟失，并重新發(fā)送數(shù)據(jù)。接收方收到重復(fù)的數(shù)據(jù)包時會發(fā)送冗余的ACK消息來通知發(fā)送方，以避免數(shù)據(jù)丟失。同時TCP還提供流量控制和擁塞控制，以保持網(wǎng)絡(luò)的穩(wěn)定性和性能。因此無論網(wǎng)絡(luò)如何變化，只要不是主機宕機等原因都可以保證一個報文可以到達目標主機。

相對于TCP的可靠傳輸，UDP是不可靠的。UDP數(shù)據(jù)包的傳輸過程中不提供確認、重傳、流量控制和擁塞控制等機制，因此UDP數(shù)據(jù)包可能丟失、重復(fù)、亂序或損壞。

(3)什么是面向字節(jié)流的？

TCP是面向字節(jié)流的傳輸，雖然應(yīng)用程序和TCP的交互是一次一個數(shù)據(jù)塊(大小不等)，但TCP把應(yīng)用程序看成是一連串的無結(jié)構(gòu)的字節(jié)流。TCP有一個緩沖，當應(yīng)用程序傳送的數(shù)據(jù)塊太長，TCP就可以把它劃分短一些再傳送。如果應(yīng)用程序一次只發(fā)送一個字節(jié)，TCP也可以等待積累有足夠多的字節(jié)后再構(gòu)成報文段發(fā)送出去。

與面向字節(jié)流相對的是UDP的面向報文。UDP對應(yīng)用層交下來的報文，既不合并也不拆分，而是保留這些報文的邊界，即應(yīng)用層交給UDP多長的報文，UDP就照樣發(fā)送，一次發(fā)送一個報文。因此，應(yīng)用程序必須選擇合適大小的報文。若報文太長，則IP層需要分片，降低效率。若太短，會使IP報文太小。

2.TCP報文格式

了解報文格式是搞懂一個通信協(xié)議的必經(jīng)之路。TCP報文由TCP首部(報頭)和應(yīng)用數(shù)據(jù)構(gòu)成，其中TCP首部是TCP?協(xié)議的核心所在，應(yīng)用數(shù)據(jù)部分是TCP報文的負載，如下圖所示。

以下詳細介紹各字段含義：

源端口(Source Port)和目的端口(Destination Port)：長度各為16位，即2個字節(jié)，分別指示發(fā)送端的應(yīng)用程序使用的端口號以及接收端的應(yīng)用程序期望接收的端口號。它們的長度說明為什么計算機端口的范圍是1-65535 (0不使用，2^16=65536，最大位65536不使用)。有了源端口和目標端口，加上IP首部里的源IP和目標IP，就可以唯一確定一個連接。

序列號(Sequence Number)：長度為32位，說明序列號的范圍是[0, 2^32-1]，也就是[0, 4294967295]。當序號增加到4294967295后，下一個序號將回到0重新開始。在建立連接時由計算機生成的隨機數(shù)作為其初始值(ISN，即Initial Sequence Number，初始序列號)，通過 SYN 包傳給接收端主機，每發(fā)送一次數(shù)據(jù)，就累加一次該“數(shù)據(jù)字節(jié)數(shù)”的大小。序列號用來解決網(wǎng)絡(luò)包亂序問題，實現(xiàn)可靠的數(shù)據(jù)傳輸和流量控制。

確認號(Acknowledgment Number)：長度為32位，只有在ACK標志位被設(shè)置時才有效。它指示期望接收的下一個字節(jié)的序列號(所以該字段一般都是上次接收成功的數(shù)據(jù)字節(jié)序號加1)，用于確認已經(jīng)成功接收的數(shù)據(jù)。在TCP連接建立后，確認號的范圍通常是相對于初始序號(ISN)的相對偏移量。如果ISN的初始值為X，那么確認號的范圍就是[X+1, X+1+N-1]，其中N表示已經(jīng)成功接收的字節(jié)數(shù)。發(fā)送端收到這個確認應(yīng)答以后可以認為在這個序號以前的數(shù)據(jù)都已經(jīng)被正常接收。確認號的范圍是[0, 2^32-1]，也就是[0, 4294967295]。

數(shù)據(jù)偏移(Data Offset)：長度為4位，指示TCP報文的“數(shù)據(jù)”起始處距離TCP報文起始處的距離有多遠，以4字節(jié)為單位計算出的數(shù)據(jù)段開始地址的偏移值。沒有選項時該值為5，即20字節(jié)；4位能表示的最大整數(shù)是15，也就說明TCP報文里數(shù)據(jù)開始的位置距離報文起點是60個字節(jié)(4*15)。這意味著TCP的首部長度是20-60個字節(jié)。

保留(Reserved)：長度為3位，保留供將來使用，目前應(yīng)設(shè)置為零。

控制標志(Flags)：長度為9位，用于控制和管理TCP連接。各控制標志位說明如下：

NS(Nonce Sum)：用于支持一種稱為ECN-nonce的TCP擴展機制，該機制用于增加擁塞控制的安全性，防止擁塞控制信息被惡意篡改。

CWR(Congestion Window Reduced)：用于指示發(fā)送方減小擁塞窗口(Congestion Window)的大小。CWR標志位通常與擁塞控制機制一起使用，以應(yīng)對網(wǎng)絡(luò)擁塞的情況。

ECE(ECN-Echo)：ECE標志被設(shè)置表示發(fā)送方支持顯式擁塞通知(Explicit Congestion Notification,?ECN)機制，并請求接收方通知其關(guān)于網(wǎng)絡(luò)擁塞的情況。接收方在收到設(shè)置了ECE標志的TCP報文段后，如果網(wǎng)絡(luò)出現(xiàn)擁塞，則可以在回復(fù)的TCP報文段中設(shè)置ECN-Echo標志作為響應(yīng)。通過使用ECE標志和ECN-Echo回復(fù)，TCP連接的發(fā)送方和接收方可以共同協(xié)調(diào)擁塞控制，以提高網(wǎng)絡(luò)的性能和穩(wěn)定性。

URG(Urgent)：指示報文段中包含緊急數(shù)據(jù)。當URG=1時，表明開啟了urgent mode，通知接收方在處理數(shù)據(jù)時要特別注意緊急數(shù)據(jù)的處理。URG標志位的設(shè)置與緊急指針字段(Urgent Pointer)一起使用。

ACK(Acknowledgment)：指示確認號字段有效。僅當ACK=1時確認號字段才有效，當ACK=0時確認號無效。TCP規(guī)定，在連接建立后所有的傳送的報文段都必須把ACK置為1。

PSH(Push)：指示接收方應(yīng)立即將數(shù)據(jù)推送給應(yīng)用程序，而不是等待緩沖區(qū)填滿。當兩個應(yīng)用進程進行交互式的通信時，有時一端的應(yīng)用進程希望在鍵入一個命令后立即就能收到對方的響應(yīng)。在這種情況下，TCP就可以使用推送(push)操作。這時，發(fā)送方TCP把PSH置為1，并立即創(chuàng)建一個報文段發(fā)送出去。接收方TCP收到PSH=1的報文段，就盡快地(即“推送”向前)交付接收應(yīng)用進程。而不用再等到整個緩存都填滿了后再向上交付。

RST(Reset)：用于復(fù)位連接，中斷當前的通信。當?RST=1?時，表示?TCP?連接中出現(xiàn)異常(如主機崩潰或其他原因)必須強制斷開連接，然后再重新建立連接進行傳輸。RST置為1還用來拒絕一個非法的報文段或拒絕打開一個連接。

SYN(Synchronize)：用于建立連接，發(fā)起連接請求。在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文段。對方若同意建立連接，則應(yīng)在響應(yīng)的報文段中使SYN=1和ACK=1，因此SYN置為1就表示這是一個連接請求或連接接受報文。

FIN(Finish)：用于關(guān)閉連接，請求終止連接。當FIN=1時，表示發(fā)送方?jīng)]有數(shù)據(jù)要傳輸了，要求釋放連接。

窗口大小(Window Size)：長度為16位，指示接收方的接收窗口大小，用于流量控制，最大的窗口大小為2^16-1=65535=64k。這是早期的設(shè)計，對于現(xiàn)在的網(wǎng)絡(luò)應(yīng)用，可能會不太夠，因此可以在選項里加一個 窗口擴大選項，來傳輸更多的數(shù)據(jù)。窗口指的是發(fā)送本報文段一方的接受窗口(而不是自己的發(fā)送窗口)。窗口值告訴對方：從本報文段首部中的確認號算起，接收方目前允許對方發(fā)送的數(shù)據(jù)量(以字節(jié)為單位)。之所以要有這個限制，是因為接收方的數(shù)據(jù)緩存空間是有限的。總之，窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。

校驗和(Checksum)：長度為16位，用于檢測TCP報文段是否在傳輸過程中發(fā)生了錯誤。校驗和計算包括報頭和數(shù)據(jù)。

緊急指針(Urgent Pointer)：長度為16位，只有在URG標志位被設(shè)置時才有效。它指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)(緊急數(shù)據(jù)結(jié)束后就是普通數(shù)據(jù))。因此，在緊急指針指出了緊急數(shù)據(jù)的末尾在報文段中的位置。當所有緊急數(shù)據(jù)都處理完時，TCP就告訴應(yīng)用程序恢復(fù)到正常操作。值得注意的是，即使窗口為0時也可以發(fā)送緊急數(shù)據(jù)。

選項(Options)：可選字段，長度可變，最長可達40個字節(jié)。當沒有使用“選項”時，TCP的首部長度是20字節(jié)。選項字段用于提供額外的功能和控制，每個選項的開始是 1 字節(jié)的kind字段，說明選項的類型。一些常見的選項舉例如下：

最大報文段長度(Maximum Segment Size,?MSS)：占用4字節(jié)，通常在創(chuàng)建連接而設(shè)置SYN標志的數(shù)據(jù)包中指明這個選項，指明本端所能接收的最大長度的報文段。通常將MSS設(shè)置為(MTU-40)字節(jié)，攜帶TCP報文段的IP數(shù)據(jù)報的長度就不會超過MTU(MTU最大長度為1518字節(jié)，最短為64字節(jié))，從而避免本機發(fā)生IP分片。只能出現(xiàn)在同步報文段中，否則將被忽略。

窗口擴大因子(Window Scale Factor)：占用3字節(jié)，取值0-14。用來把TCP的窗口的值左移的位數(shù)，使窗口值乘倍。只能出現(xiàn)在同步報文段中，否則將被忽略。這是因為現(xiàn)在的TCP接收數(shù)據(jù)緩沖區(qū)(接收窗口)的長度通常大于65535字節(jié)。

時間戳選項(TCP Timestamps Option,?TSopt)：占用10字節(jié)，其中最主要的字段是時間戳字段(Timestamp Value field,?TSval,?4字節(jié))和時間戳回送回答字段(Timestamp Echo Reply field,?TSecr,?4字節(jié))。時間戳選項允許通信的兩端在TCP報文段中包含時間戳值，以便進行一些時間相關(guān)的操作和計算。

安全摘要選項(TCP Authentication Option,?TCP Option)：用于提供數(shù)據(jù)完整性和身份驗證的功能。該選項用于對TCP報文段進行保護，防止數(shù)據(jù)篡改和未經(jīng)授權(quán)的訪問。

3.數(shù)據(jù)包傳遞的地址解析

我們在“IP協(xié)議詳細解析”一文中介紹了IP報頭中“源地址”和“目的地址”，與本文TCP報頭中的“源端口”和“目的端口”共同確定了數(shù)據(jù)包傳遞過程中需要的地址，如下圖所示。

類比日常工作中郵寄信件，我們裝在信封里的信件相當于要傳遞的數(shù)據(jù)，標準的信件格式是要在信封上寫“收信人地址”和“寄信人地址”，相當于IP地址，其中，“收信人地址”對應(yīng)數(shù)據(jù)包里IP報頭中的“目的IP地址”，“寄信人地址”對應(yīng)數(shù)據(jù)包里IP報頭中的“源IP地址”，寫上寄信、收信兩個地址就可以保證信件可以郵寄到目的地了。

但信件郵寄到目的地址后由誰來收？從上面這封信的收件人地址檢索到這個地址是位于上海市浦東新區(qū)張江“A公司B部門”的，這個部門可能有成百上千人，收件人不明確，即使把信件送到這個地址，也沒辦法投遞到具體的收信人。

因此，郵件信件需要填寫“收件人姓名”、“收件人地址”和“寄件人姓名”、“寄件人地址”的組合，才能保證信件能準確投遞到具體的收件人手中。這里的收信人姓名相當于TCP報頭的目的端口，寄信人姓名相當于TCP報頭的源端口。

對比傳遞信件，我們來看網(wǎng)絡(luò)數(shù)據(jù)包傳遞過程的例子。位于北京的李四(電腦IP地址: 106.54.28.25)給上海的張三(電腦IP地址: 114.92.67.193)通過QQ(端口: 80)發(fā)送一條消息，如下圖所示：

首先，李四電腦將消息打包成TCP數(shù)據(jù)報后，添加IP報頭和以太網(wǎng)報頭形成網(wǎng)絡(luò)數(shù)據(jù)包，發(fā)送到計算機網(wǎng)絡(luò)中。計算機網(wǎng)絡(luò)通過數(shù)據(jù)包中IP報頭的目的IP地址(114.92.67.193)把該數(shù)據(jù)包準確傳遞到張三電腦。

張三電腦收到了李四電腦發(fā)送過來的數(shù)據(jù)包后，由于張三電腦上同時運行有多個程序(例如圖中的QQ、微信、Foxmail等)，雖然張三電腦知道這個數(shù)據(jù)包是傳輸給它的，但是它不知道該把這個數(shù)據(jù)包中的數(shù)據(jù)交給哪個程序。

針對這個問題，使用數(shù)據(jù)包中TCP報頭的源端口和目的端口，根據(jù)不同的程序使用不同端口號來確定應(yīng)用程序并發(fā)送和接受數(shù)據(jù)，這樣數(shù)據(jù)包就能像郵寄信件一樣準確投遞到具體電腦上指定的程序了。例如我們指定張三電腦上QQ、微信、Foxmail使用的端口分別是80、8900和110，那么當收到數(shù)據(jù)包里目的端口80就是傳輸給QQ的。

上述例子還可以引申出數(shù)據(jù)包結(jié)構(gòu)中的其他字段的作用，例如我們收到信后可以簡單地通過信封是否完整，來檢查該信件是否被別人在傳輸途中拆開并篡改過信件內(nèi)容。對于網(wǎng)絡(luò)數(shù)據(jù)包，TCP報頭的“校驗和”(Checksum)可以驗證收到數(shù)據(jù)包數(shù)據(jù)是否在途被別人拆開修改過。

4.TCP連接

為什么需要建立TCP連接？首先，IP協(xié)議是無連接的，IP并不維護任何關(guān)于后續(xù)數(shù)據(jù)報的狀態(tài)信息，每個數(shù)據(jù)報的處理相互獨立。這種無連接的優(yōu)點是不占用線路，降低了對網(wǎng)絡(luò)線路的要求；此外，IP協(xié)議是不可靠的，不能保證IP數(shù)據(jù)報能成功到達目的地，是一種盡力而為的傳輸服務(wù)，路由器對IP報文出現(xiàn)錯誤的處理方式是丟包，并發(fā)送ICMP(Internet Control Message Protocol，互聯(lián)網(wǎng)控制協(xié)議)控制消息給源地址。因為IP協(xié)議是無連接、不可靠的，因此，需要上層TCP來建立連接和差錯重傳，實現(xiàn)面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。 ?

4.1 三次握手過程詳解

由于建立TCP連接的過程需要來回3次，所以將這個過程形象的叫做三次握手(Three-Way Handshake)，一旦建立連接，兩臺主機就可以進行全雙工的通信。

下面是三次握手的詳細過程，包括發(fā)送的報文段內(nèi)容：

(1)第一次握手

首先客戶端發(fā)起連接請求，向服務(wù)器發(fā)送一個SYN(同步)報文段，段中包含了目的端口和本機端口，設(shè)置SYN?標志位為1，即SYN=1，并設(shè)置序號字段(Sequence Number)為一個隨機選擇的x，即seq=x，也就是初始序號(Initial Sequence Number,?ISN)，如果是第一個連接，很可能是0。此時服務(wù)器對應(yīng)的端口要處于監(jiān)聽狀態(tài)，客戶端發(fā)起請求后進入?SYN_SENT?狀態(tài)，等待服務(wù)器的確認。

(2)第二次握手

服務(wù)端收到客戶端發(fā)來的?SYN?報文段，對這個SYN報文段進行確認。服務(wù)器向客戶端發(fā)送一個SYN-ACK報文段作為回應(yīng)，報文段中的標志位設(shè)置為SYN=1和ACK=1，表示同時作為確認和同步；序號字段設(shè)置為服務(wù)器的隨機選擇的初始序號y(服務(wù)端的TCP段序號)，即seq=y；確認號字段(Acknowledgment Number)設(shè)置為客戶端的初始序號加1，即ack=x+1。服務(wù)器端將上述所有信息放到一個TCP段(即SYN+ACK段)中，一并發(fā)送給客戶端，此時服務(wù)器進入SYN_RECV狀態(tài)。

(3)第三次握手

客戶端接收到服務(wù)端發(fā)來的?SYN+ACK?報文段后，要向服務(wù)端發(fā)送一個ACK(確認)報文段，對連接請求的確認進行確認。報文段中的標志位設(shè)置為ACK=1，確認號字段設(shè)置為服務(wù)器的初始序號加1，即ack=y+1，序號字段設(shè)置為客戶端的初始序號加1，即seq=x+1。此時客戶端進入?ESTABLISHED(已連接)狀態(tài)，服務(wù)端接收到此?TCP段，也將進入?ESTABLISHED?狀態(tài)，也就標志著三次握手結(jié)束，連接成功建立。

三次握手完成之后，TCP連接就正式建立起來了，雙方可以開始進行數(shù)據(jù)的可靠傳輸。三次握手的目的是確保雙方的初始序號和確認號的同步，并驗證雙方的可達性。通過這個過程，TCP可以建立一個可靠的雙向通信通道，在后續(xù)的數(shù)據(jù)傳輸中保證數(shù)據(jù)的可靠性和順序性。

4.2四次揮手

四次揮手是TCP斷開連接的過程。

(1)第一次揮手

客戶端數(shù)據(jù)發(fā)送完成，則向服務(wù)端發(fā)送連接釋放請求的FIN報文(請求連接終止：FIN=1)，主動關(guān)閉TCP連接。報文中會指定一個序列號seq=u，并停止再發(fā)送數(shù)據(jù)，但依然能夠接收數(shù)據(jù)。此時客戶端處于?FIN_WAIT_1?狀態(tài)，等待服務(wù)端確認。TCP規(guī)定，F(xiàn)IN報文即使不攜帶數(shù)據(jù)，也要消耗一個序號。

(2)第二次揮手

服務(wù)端收到FIN報文之后，通知相應(yīng)的高層應(yīng)用進程，告訴它客戶端向服務(wù)端這個方向的連接已經(jīng)釋放了。此時服務(wù)端向客戶端發(fā)出連接釋放的應(yīng)答ACK報文，并進入了CLOSE_WAIT(關(guān)閉等待)狀態(tài)。ACK報文頭包含：ACK=1，ack=u+1，并且?guī)献约旱男蛄刑?strong>seq=v。這里ack=u+1是第一次揮手的序列值+1，表示希望收到從第u+1個字節(jié)開始的報文段，并且已經(jīng)成功接收了前u個字節(jié)。

客戶端收到服務(wù)端的確認后，進入?FIN_WAIT_2?狀態(tài)，等待服務(wù)端發(fā)出的連接釋放報文段。

前兩次揮手既讓服務(wù)端知道了客戶端想釋放連接，也讓客戶端知道了服務(wù)端已了解自己想要釋放連接的請求。

(3)第三次揮手

如果服務(wù)端也想斷開連接，就向客戶端發(fā)送連接釋放報文。由于在CLOS_WAIT狀態(tài)，服務(wù)端很可能又發(fā)送了一些數(shù)據(jù)，假定此時連接釋放報文的序列號為seq=w，ack也是取第一次揮手的seq +1，即ack=u+1，這和第二次揮手時是一樣的。

此時服務(wù)端就進入了LAST_ACK(最后確認)狀態(tài)，等待客戶端的確認，并停止向客戶端發(fā)送數(shù)據(jù)，但服務(wù)端仍能夠接收從客戶端傳輸過來的數(shù)據(jù)。

(4)第四次揮手

客戶端收到服務(wù)器的連接釋放報文后，一樣發(fā)送一個?ACK?報文作為應(yīng)答(ack=w+1，seq=u+1)， 此時客戶端處于TIME_WAIT(時間等待)狀態(tài)，并在這個狀態(tài)等待?2MSL(Two Maximum Segment Lifetime,?最大報文生存時間)。

服務(wù)端收到從客戶端發(fā)出的?TCP?報文之后結(jié)束?LAST-ACK?階段，進入?CLOSED?階段。客戶端等待完?2MSL之后，結(jié)束?TIME-WAIT?階段，進入?CLOSED?階段，由此完成四次揮手。

為什么客戶端在TIME_WAIT階段要等?2MSL？?主要有以下兩點：

一是為了保證客戶端發(fā)送的最后一個ACK報文段能夠到達服務(wù)器端，確保服務(wù)端能正常進入CLOSED狀態(tài)。服務(wù)端在?1MSL?內(nèi)沒有收到客戶端發(fā)出的?ACK?確認報文，就會再次向客戶端發(fā)出?FIN?報文。

二是為了避免新舊連接混淆。由于網(wǎng)絡(luò)滯留，客戶端可能發(fā)送了多次請求建立連接的請求，經(jīng)過時間2MSL，就可以使本鏈接持續(xù)時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失，這樣就可以使下一個新的連接中不會出現(xiàn)這種舊的連接請求報文段。

編輯：黃飛