TCP協(xié)議詳解_動力節(jié)點Java學院整理

2024-07-21 02:02:55

字體：大中小

供稿：網(wǎng)友

本文描述了TCP協(xié)議，首先簡單介紹了TCP完成了一些什么功能；介紹了TCP報文格式，以及典型報文的數(shù)據(jù)格式；接著從鏈路控制和數(shù)據(jù)傳輸兩個方面進行了介紹，在TCP中鏈路控制和數(shù)據(jù)傳輸是通過同一個通道進行的，并沒有區(qū)分控制通道和數(shù)據(jù)通道；在網(wǎng)絡中傳輸數(shù)據(jù)（控制或真實數(shù)據(jù)），網(wǎng)絡可能發(fā)生擁堵，因此接下來簡單描述了主機端進行擁塞控制所采取的方法，也簡單提及了中間路由器/交換機進行擁塞避免所采取的主動措施；最后介紹了在TCP中性能分析的一些基本概念點，在開發(fā)網(wǎng)絡應用程序的時候，需要對應用的網(wǎng)絡需求進行一個估計。

本文不是TCP的入門資料，閱讀之前需要對TCP有一些基本認識，如三次握手、四次揮手、滑動窗口等。

TCP概述

通常說到TCP，我們都會很自然的想到其為上層提供了一個面向連接、可靠的、端到端的數(shù)據(jù)流服務，也通常用電話線路來類比一個TCP連接。但這種類比對剛接觸到TCP的人來說極易造成誤會，我們需要仔細審視這些概念，你將會發(fā)現(xiàn)TCP并不是那么面向連接的、也不是那么可靠的、數(shù)據(jù)也仍然是通過報文的方式進行傳輸?shù)?。實際上TCP是提供了一種“盡力而為”的數(shù)據(jù)傳輸模型；同時，它也提供了防止網(wǎng)絡擁塞的主機端擁塞控制，試圖去了解整個網(wǎng)絡的狀況，并采取合適的策略（貌似不是TCP應該干的事？）。

TCP的連接并不是指一條實際的或虛擬的鏈路存在于數(shù)據(jù)交換的兩端，而是指連接的雙方都維護了一些資源（如輸入輸出緩沖區(qū)、多種定時器）以及鏈路狀態(tài)的信息，并通過雙方的控制報文交互管理狀態(tài)、向用戶提供接口修改這些資源的分配。在“連接控制”小節(jié)，我們將會仔細審視資源和狀態(tài)（包括控制狀態(tài)的報文），若控制報文丟失，那么連接就會處于一種不一致狀態(tài)，TCP通過一些手段去試圖解決這些問題（如持活定時器、保持定時器等等）。

TCP提供了可靠的數(shù)據(jù)傳輸服務，其采取的措施是對控制報文和數(shù)據(jù)報文進行確認、并在超時之后進行重傳；并利用滑動窗口協(xié)議解決數(shù)據(jù)數(shù)傳亂序、收發(fā)雙方進行流量控制。具體來說就是，對于發(fā)送方，TCP按照其認為最合適的長度發(fā)送數(shù)據(jù)報文，并在發(fā)出報文之后，啟動一個定時器，等待數(shù)據(jù)的確認報文，若定時器超時后仍沒有收到確認報文，則重傳該報文；對于接收方，收到數(shù)據(jù)后，首先檢查報文校驗和，錯誤則直接丟棄該報文，不確認（發(fā)送端會注意到這個事實，從而重傳）；收到重復報文，丟棄，不確認；通過雙方維護的滑動窗口，TCP會將亂序報文排好序后才提交給上層應用程序。需要注意的是，流量控制與擁塞控制并不是同一回事，流量控制的目的在于防止發(fā)送端發(fā)送大量數(shù)據(jù)，超過接收端的處理能力，從而導致丟包等；擁塞控制則在于防止網(wǎng)絡中發(fā)生擁堵，中間路由器或交換機丟棄報文的情況。

TCP提供數(shù)據(jù)流服務，上層應用傳給TCP的數(shù)據(jù)，TCP并不加以區(qū)分，僅僅是按照自己的需求組合、拆分數(shù)據(jù)，然后傳送給對端，對端TCP協(xié)議棧再將數(shù)據(jù)以發(fā)送的順序遞交給上層應用。TCP的數(shù)據(jù)傳送仍然是以IP報文的方式發(fā)送到對端的，每次盡力發(fā)送MSS大小的報文，在“數(shù)據(jù)傳輸”小節(jié)我們會看到諸如Nagle算法、TCP_CORK等對流中報文的控制。

TCP本身并不提供報文邊界之類的東西，但提供了緊急數(shù)據(jù)、PUSH標志（并沒有提供對外接口）等方式可以模擬報文。通常，TCP數(shù)據(jù)流的劃分是應用程序的事，應用程序定義好格式，并自己解析，常見的方案有：

先傳輸固定大小的報文長度字段；
按行進行分割（或其他分隔符）；
固定長度記錄；
各種編碼方案，如xml、json、ASN.1、tlv等。

TCP報文

TCP報文格式

TCP報文最終是由IP層發(fā)送出去的，封裝報文如下：

TCP報文格式如下：

通常使用一個四元組唯一的表示一個TCP連接(client-ip, client-port, server-ip, server-port)，但需要注意以下事實：

監(jiān)聽服務器在server-port窗口接受來自客戶端的連接，并fork一個子進程處理連接，此時，該四元組卻在服務器對應了兩個進程（監(jiān)聽進程只處理SYN報文，而子進程卻只能處理數(shù)據(jù)報文和FIN等）；
連接的化身，這在后面會詳細描述。

在TCP首部的圖中，我們主要關(guān)注以下幾個字段：序號、首部長度、6個標志位、選項，窗口大小、緊急指針都是以字節(jié)單位，這里并不關(guān)注。

不含選項的TCP首部為20字節(jié)，在首部選項中指明了首部有多少個4字節(jié)，由于其占了4位，因此首部最多為60字節(jié)。

序號字段用來標識TCP數(shù)據(jù)流中的數(shù)據(jù)字節(jié)流，在建立連接時會以一個ISN進行初始化，每個SYN、FIN等都會消耗掉一個序號。我們并不用太關(guān)心這個字段，只是需要知道序號為32位，在長肥管道（容量較大的網(wǎng)絡中）序號可能會出現(xiàn)回繞，TCP需要識別。TCP對該字段也進行了相應的擴充（增加選項）。

TCP選項是以1字節(jié)類型、1字節(jié)長度（可選）、內(nèi)容（可選）來表示的，可以只有類型，長度字段包含類型和長度本身。常見選項如下圖所示，無操作選項通常用來作為填充以滿足選項對齊的要求，tcpdump連接建立的輸出中通常會包含這些選項：

TCP首部中定義了6個字段，在一個報文中，通常只會出現(xiàn)一個標志，但也允許多個標志同時出現(xiàn)。

URG，緊急指針標志位。
ACK，確認序號標志位，關(guān)于ACK有幾點需要注意：a) ACK是累積的，表示接收方已經(jīng)正確收到了一直到確認序號減一的所有字節(jié)；b) TCP通常并不會對每個數(shù)據(jù)包進行確認，而是采用了捎帶確認和延遲確認的技術(shù)，捎帶確認是指將ACK報文合并到數(shù)據(jù)報文中去，而延遲確認是TCP維持了一個200ms的定時器，在定時器過期前，若有多個數(shù)據(jù)需要確認，則一塊進行確認，通常是兩個報文確認一次，若200ms到了，仍沒有新數(shù)據(jù)需要確認，則不再等待，直接確認該報文；c) ACK報文本身并不會被確認，當ACK丟失時，需要依靠對端超時機制發(fā)現(xiàn)（后文詳述）。
PSH，該標志由TCP自動設置（曾經(jīng)允許通過接口進行設置，當前多數(shù)實現(xiàn)不提供），多數(shù)實現(xiàn)在發(fā)送者將清空發(fā)送緩沖區(qū)時設置該標志，即發(fā)送者一次將當前發(fā)送緩沖區(qū)的數(shù)據(jù)都發(fā)送出去了。
RST，連接重置標志位。
SYN，同步標志位，用來發(fā)起一個新建連接。
FIN，發(fā)送端已經(jīng)完成了所有的數(shù)據(jù)發(fā)送，不會再發(fā)送新的數(shù)據(jù)，關(guān)閉了其發(fā)送端，若對端也發(fā)送該標志，則完全關(guān)閉連接。

常見報文

TCP中除了通常的數(shù)據(jù)交換報文（數(shù)據(jù)報文詳見后文“數(shù)據(jù)傳輸”小節(jié)），還有以下一些特殊的控制報文：SYN報文、ACK報文、FIN報文、RST報文、窗口探測報文、持活報文。這里將常見報文列出來，一是為了強調(diào)一個事實，TCP的狀態(tài)變更大部分是通過報文交互進行的；二是對各種控制報文的使用場景進行簡單歸納。

SYN報文，用于發(fā)起一個新連接，只包含TCP首部，沒有數(shù)據(jù)。一個典型報文輸出如下：

10:23:17.543837 IP 192.168.47.1.55366 > krt.9876: Flags [S], seq 2289863414, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0

ACK報文，用于對控制報文（不包括RST）和數(shù)據(jù)報文進行確認，參考上一小節(jié)關(guān)于ACK的一些注意點。該報文可以與其他報文結(jié)合在一起，如SYN、數(shù)據(jù)報文、FIN報文等。單獨的ACK本身不含任何數(shù)據(jù)，只有首部，典型報文輸出如下：

10:23:17.544135 IP 192.168.47.1.55366 > krt.9876: Flags [.], ack 1, win 16425, length 0

FIN報文，用于通知對端已經(jīng)發(fā)送完了所有數(shù)據(jù)，將發(fā)送緩沖區(qū)中數(shù)據(jù)發(fā)送完成后，可以關(guān)閉連接。詳細參考后文“連接控制”，用于有序釋放連接或者連接半打開。

RST報文，當向一個出現(xiàn)錯誤的連接發(fā)送一個報文的時候，就收到RST報文。以下是幾種典型情況（詳細情景在后文“連接控制”小節(jié)表述）：

對端的相應端口上沒有監(jiān)聽程序
異常終止連接，SO_LINGER。使用異常方式終止連接，而不是正常的有序終止連接orderly release，可以迫使連接直接丟失未發(fā)送的數(shù)據(jù)；而接收方收到RST報文后，read返回reset錯誤，從而終止該連接，同時不會進行ACK。
檢測半打開連接，一方已經(jīng)關(guān)閉或異常終止連接而另一方還不知道。造成這種狀況的原因在于通信的一方?jīng)]有正確將相應的狀態(tài)報文成功發(fā)送給對端，如主機突然掉電導致FIN報文沒有發(fā)出去，此時再寫該socket，則會得到RST報文。

窗口探測報文（持久探測報文），TCP并不會對不包含數(shù)據(jù)的ACK報文進行確認，因此可能出現(xiàn)ACK丟失，從而導致窗口通告失敗。TCP使用persist定時器，定期的發(fā)送一個字節(jié)的窗口探測報文。探測報文總是在5~60s之間，也是采用指數(shù)后退算法，但不超過60s，該探測報文會一直持續(xù)。實現(xiàn)時，使用500ms的定時器。

持活報文，用于查看連接是否仍然存活的控制報文。報文只帶有ACK標志，且序號字段為將要發(fā)送的序號減一，這樣引起對端進行一個ACK，表示接收到重復序號，對端期望的序號為下一個值。

連接控制

TCP是面向連接的協(xié)議，正如前面所描述的，并不存在真實的物理或虛擬的鏈路，TCP的連接是指在通信的雙方分配了資源和維護了狀態(tài)，并通過控制報文控制連接，通過API協(xié)調(diào)資源。本小節(jié)將詳細描述實現(xiàn)中對TCP的連接控制。需要注意的是，連接的擁塞控制在本小節(jié)不過多涉及，后面單獨小節(jié)描述。

4個定時器：重傳定時器、2MSL定時器、persist定時器、keepalive定時器

連接雙方通過以下一些事件來維持連接的狀態(tài)，發(fā)送方：發(fā)送緩沖區(qū)、4個定時器、發(fā)送窗口、擁塞狀態(tài)計數(shù)器接收方：接收緩沖區(qū)、4個定時器、接收窗口、擁塞狀態(tài)計數(shù)器

TCP連接更詳細的描述通信雙方通過一些內(nèi)部狀態(tài)保持了彼此的信息，連接關(guān)系始終保持，并通過報文交換來進行連接狀態(tài)的變更。由于是通過報文進行連接狀態(tài)的維護，所以報文沒有正確發(fā)出或被接收到時，連接狀態(tài)就會變成意料之外了；除確認報文本身不被確認，其他報文都會有確認報文進行確認；報文（包括確認報文）可能超時、需要重傳。下面是通信過程中一些重要報文的交互序列。

發(fā)送方網(wǎng)絡（中間路由器等組成）接收方

發(fā)送方為Windows，接收方為Linux，操作如下

krt@krt:~$ perl ksock.pl --sleep-before-listen=1
Windows下
C:Userwin-krtDesktop>telnet 192.168.47.120 9876 krt@krt:~$ sudo tcpdump -n -i eth0 tcp port 9876 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 13:59:16.575626 IP 192.168.47.1.65281 > 192.168.47.120.9876: Flags [S], seq 2588085696, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 13:59:16.575678 IP 192.168.47.120.9876 > 192.168.47.1.65281: Flags [S.], seq 3751549776, ack 2588085697, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 13:59:16.577107 IP 192.168.47.1.65281 > 192.168.47.120.9876: Flags [.], ack 1, win 16425, length 0 13:59:19.564526 IP 192.168.47.1.65281 > 192.168.47.120.9876: Flags [P.], seq 1:2, ack 1, win 16425, length 1 13:59:19.564747 IP 192.168.47.120.9876 > 192.168.47.1.65281: Flags [.], ack 2, win 229, length 0 13:59:19.565023 IP 192.168.47.120.9876 > 192.168.47.1.65281: Flags [P.], seq 1:13, ack 2, win 229, length 12 13:59:19.763747 IP 192.168.47.120.9876 > 192.168.47.1.65281: Flags [P.], seq 1:13, ack 2, win 229, length 12 13:59:19.763849 IP 192.168.47.1.65281 > 192.168.47.120.9876: Flags [.], ack 13, win 16422, length 0 13:59:19.764023 IP 192.168.47.1.65281 > 192.168.47.120.9876: Flags [.], ack 13, win 16422, options [nop,nop,sack 1 {1:13}], length 0 13:59:23.688209 IP 192.168.47.1.65281 > 192.168.47.120.9876: Flags [F.], seq 2, ack 13, win 16422, length 0 13:59:23.688372 IP 192.168.47.120.9876 > 192.168.47.1.65281: Flags [F.], seq 13, ack 3, win 229, length 0 13:59:23.689053 IP 192.168.47.1.65281 > 192.168.47.120.9876: Flags [.], ack 14, win 16422, length 0

連接建立

連接建立過程中會經(jīng)歷被稱為“三次握手”的報文交互。