TCP協議詳解_動力節點Java學院整理

2024-07-21 02:02:55

字體：大中小

來源：轉載

供稿：網友

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

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

TCP概述

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

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

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

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

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

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

TCP報文

TCP報文格式

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

TCP報文格式如下：

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

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

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

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

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

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

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

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

常見報文

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

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

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）和數據報文進行確認，參考上一小節關于ACK的一些注意點。該報文可以與其他報文結合在一起，如SYN、數據報文、FIN報文等。單獨的ACK本身不含任何數據，只有首部，典型報文輸出如下：

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

FIN報文，用于通知對端已經發送完了所有數據，將發送緩沖區中數據發送完成后，可以關閉連接。詳細參考后文“連接控制”，用于有序釋放連接或者連接半打開。

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

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

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

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

連接控制

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

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

連接雙方通過以下一些事件來維持連接的狀態，發送方：發送緩沖區、4個定時器、發送窗口、擁塞狀態計數器接收方：接收緩沖區、4個定時器、接收窗口、擁塞狀態計數器

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

發送方網絡（中間路由器等組成）接收方

發送方為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

連接建立

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