TCP協議詳細解析

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

1. 簡介

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

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

(1)什么是面向連接？

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

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

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

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

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

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

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

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

2.TCP報文格式

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FIN(Finish)：用于關閉連接，請求終止連接。當FIN=1時，表示發送方沒有數據要傳輸了，要求釋放連接。

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

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

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

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

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

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

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

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

3.數據包傳遞的地址解析

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

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

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

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

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

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

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

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

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

4.TCP連接

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

4.1 三次握手過程詳解

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

下面是三次握手的詳細過程，包括發送的報文段內容：

(1)第一次握手

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

(2)第二次握手

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

(3)第三次握手

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

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

4.2四次揮手

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

(1)第一次揮手

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

(2)第二次揮手

服務端收到FIN報文之后，通知相應的高層應用進程，告訴它客戶端向服務端這個方向的連接已經釋放了。此時服務端向客戶端發出連接釋放的應答ACK報文，并進入了CLOSE_WAIT(關閉等待)狀態。ACK報文頭包含：ACK=1，ack=u+1，并且帶上自己的序列號seq=v。這里ack=u+1是第一次揮手的序列值+1，表示希望收到從第u+1個字節開始的報文段，并且已經成功接收了前u個字節。

客戶端收到服務端的確認后，進入FIN_WAIT_2狀態，等待服務端發出的連接釋放報文段。

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

(3)第三次揮手

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

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

(4)第四次揮手

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

服務端收到從客戶端發出的TCP報文之后結束LAST-ACK階段，進入CLOSED階段?？蛻舳说却?MSL之后，結束TIME-WAIT階段，進入CLOSED階段，由此完成四次揮手。

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

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

二是為了避免新舊連接混淆。由于網絡滯留，客戶端可能發送了多次請求建立連接的請求，經過時間2MSL，就可以使本鏈接持續時間內所產生的所有報文段都從網絡中消失，這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段。

審核編輯：湯梓紅