先來一張全景圖，3 秒快速了解整篇文章的內(nèi)容。

初始傳輸層

前面說過，傳輸層的作用是建立應用程序間的端到端連接，為數(shù)據(jù)傳輸提供可靠或不可靠的通信服務。傳輸層有兩個重要協(xié)議，分別是 TCP 和 UDP。TCP 是面向連接的可靠傳輸協(xié)議，UDP 是無連接的不可靠傳輸協(xié)議。

傳輸層協(xié)議

一個 IP 地址可以標識一臺主機，IP 報文頭部有一個字段，用來標識上層協(xié)議類型。根據(jù)這個字段的協(xié)議號，來識別 IP 傳輸?shù)臄?shù)據(jù)是 TCP 還是 UDP 。IP 用協(xié)議號 6 標識 TCP ，用協(xié)議號 17 標識 UDP 。但一臺主機可能同時有多個程序，傳輸層的 TCP 和 UDP ，為了識別上一層的應用程序類型，使用端口號來識別具體的程序，從而使這些程序可以復用網(wǎng)絡通道。

協(xié)議號和端口號

二層的幀通信和三層的包通信都是無連接的、不可靠的通信方式，四層的 TCP 卻是一種可靠的通信方式。如果幀在傳輸中丟失，通信雙方的二層功能模塊發(fā)現(xiàn)不了;如果包在傳輸中丟失，通信雙方的三層功能模塊發(fā)現(xiàn)不了。燃鵝，一個 TCP 段丟失了，TCP 模塊一定能夠發(fā)現(xiàn)。一個 TCP 段的丟失，意味著一個 IP 包的丟失，因為 TCP 段是封裝在 IP 包里的;同理，一個 IP 包的丟失，意味著一個幀的丟失。因此，二層和三層通信的不可靠性在 TCP 這里得到補償。

數(shù)據(jù)封裝

應用程序其實就是 TCP/IP 的應用協(xié)議，應用協(xié)議大多以客戶端/服務端的形式運行?？蛻舳? Client ，使用服務的一方。)是請求的發(fā)起端。而服務端( Server ，提供服務的程序或主機。)則是請求的處理端。作為服務端的程序有必要提前啟動，隨時準備接收客戶端的請求。否則即使有客戶端的請求發(fā)過來，也無法進行處理。

Client/Server模式

確認一個請求究竟是發(fā)給哪一個服務端，可以通過收到數(shù)據(jù)包的目的端口號輕松識別。當收到 TCP 的建立連接請求時，如果目的端口號是 22 ，則轉(zhuǎn)給 SSH ，如果是 80 則轉(zhuǎn)給 HTTP 。

>TCP

TCP 是面向連接的、可靠的流協(xié)議。流就是不間斷的數(shù)據(jù)，當應用程序采用 TCP 發(fā)送消息時，雖然是按順序發(fā)送，但接收端收到是沒有間隔的數(shù)據(jù)流。比如，在發(fā)送端應用程序發(fā)送了 10 次 100 字節(jié)的數(shù)據(jù)，那么在接收端，應用程序可能會收到一個 1000 字節(jié)連續(xù)不間斷的數(shù)據(jù)。

可靠傳輸

TCP 為提供可靠性傳輸，實行順序控制、重發(fā)控制機制。此外還有流量控制、擁塞控制、提高網(wǎng)絡利用率等眾多功能。

>UDP

**UDP **是不具有可靠性的協(xié)議，可靠性功能交給上層的應用去完成。UDP 雖然可以確保發(fā)送數(shù)據(jù)的大小，比如：發(fā)送端應用程序發(fā)送一個 100 字節(jié)的消息，那么接收端應用程序也會以 100 字節(jié)為長度接收數(shù)據(jù)。但不能保證數(shù)據(jù)一定會到達。因此，應用有時會根據(jù)需要進行重發(fā)處理。

不可靠傳輸

>TCP 和 UDP 的區(qū)別

TCP 是可靠的傳輸協(xié)議，一定會優(yōu)于 UDP 嗎?其實不然，TCP是面向連接的，并且具備順序控制、重發(fā)控制等機制，可以為應用提供可靠傳輸。而 UDP 主要用于對高速傳輸和實時性有較高要求的通信。比如：通過 IP 電話進行通話。如果使用 TCP ，數(shù)據(jù)如果丟失會重發(fā)，這樣就無法流暢地傳輸通話的聲音，導致無法進行正常交流。而采用 UDP ，它不會進行重發(fā)處理。也就不會有聲音大幅度延遲到達的問題。即使有部分數(shù)據(jù)丟失，也只會影響小部分的通話。因此，TCP 和 UDP 需要根據(jù)應用的目的選擇使用。

端口號

數(shù)據(jù)鏈路層和網(wǎng)絡層的地址，分別是 MAC 地址和 IP 地址。MAC 地址用來標識同一網(wǎng)段中不同的設備，IP 地址標識網(wǎng)絡中的主機或路由器。傳輸層的地址就是端口號，端口號用來識別同一臺主機中不同的應用程序，也被稱為程序地址。

一臺主機可以同時運行多個程序，比如 WWW 服務的 Web 瀏覽器、電子郵箱客戶端等程序都可同時運行。傳輸層協(xié)議正是利用這些端口號，識別主機正在進行通信的應用程序，并準確的傳輸數(shù)據(jù)。

端口號

僅僅通過目的端口來識別某一個通信是不準確的。兩臺主機訪問的目的端口號 80 相同，可以根據(jù)源端口號區(qū)分這兩個通信。

目的端口號和源端口號相同，但是兩臺主機的源 IP地址不同;IP 地址和端口號都一樣，只是協(xié)議號不同。這些情況，都會認為是兩個不同的通信。

因此，網(wǎng)絡通信中通常采用 5 個信息來識別一個通信。它們是源 IP 地址、目的 IP 地址、協(xié)議號、源端口號、目的端口號。只要其中一項不同，就會認為是不同的通信。

會話五元素

TCP/UDP 的端口號是一個 16 位二進制數(shù)，端口號范圍為 0 ~ 65535 。在實際進行通信時，要事先確定端口號。確定端口號的方法分為兩種：

1)標準端口號

這種方法也叫靜態(tài)方法。它是指每個應用程序都有指定的端口號。HTTP 、TELNET 、FTP 等常用的應用程序所使用的端口號是固定的，這些端口號又稱為知名端口號。知名端口號范圍是 0 ~ 1023 。

除了知名端口號外，還有一些端口號也被正式注冊，稱為注冊端口。它們分布在 1024 ~ 49151 之間。

標準端口號

2)時序分配法

這種方法也叫動態(tài)分配法。服務端有必要確定監(jiān)聽的端口號，但是接受服務的客戶端不需要確定端口號。

客戶端應用程序不用設置端口號，由操作系統(tǒng)進行分配。操作系統(tǒng)可以為每個應用程序分配不沖突的端口號。比如：每需要一個新的端口號時，就在之前分配號碼的基礎上加 1 。這樣，操作系統(tǒng)就可以動態(tài)管理端口號了。

動態(tài)分配的端口號范圍是 49152 ~ 65535 之間。

UDP

UDP ，全稱 User Datagram Protocol 。UDP 不提供復雜的控制機制，利用 IP 提供面向無連接的、不可靠的通信服務。并且它是將應用程序發(fā)來的數(shù)據(jù)，在收到的那一刻，立即按照原樣發(fā)送到網(wǎng)絡上的一種機制。

即使在網(wǎng)絡出現(xiàn)擁堵的情況下，UDP 也無法進行流量控制。傳輸途中出現(xiàn)丟包，UDP 也不負責重發(fā)。當出現(xiàn)包的到達順序錯誤時也沒有糾正的功能。如果需要這些細節(jié)控制，那么需要交由上層的應用程序去處理。也可以說，是損失信息傳輸?shù)目煽啃詠硖嵘畔鬏數(shù)男省?/p>

UDP 的特點如下：

UDP 是無連接的：UDP 發(fā)送數(shù)據(jù)前不與對方建立連接。

UDP 不對數(shù)據(jù)進行排序：UDP 報文的頭部沒有數(shù)據(jù)順序的信息。

UDP 對數(shù)據(jù)不發(fā)送確認，發(fā)送端不知道數(shù)據(jù)是否被正確接收，也不會重發(fā)數(shù)據(jù)。

UDP 傳送數(shù)據(jù)比 TCP 快，系統(tǒng)開銷也少。

UDP 缺乏擁塞控制機制，不能夠檢測到網(wǎng)絡擁塞。

由于 UDP 面向無連接，它可以隨時發(fā)送數(shù)據(jù)。再加上 UDP 本身的處理既簡單又高效，因此常用于以下幾個方面：

包總量較少的通信( DNS 、SNMP 等)

視頻、音頻等多媒體通信(即時通信)

只在局域網(wǎng)使用的應用通信

廣播通信(廣播、多播)

UDP知名端口號

TCP

UDP 將部分控制轉(zhuǎn)移給應用程序去處理，只提供作為傳輸層協(xié)議的最基本功能。與 UDP 不同，TCP 是對傳輸、發(fā)送、通信進行控制的協(xié)議。

主要特點如下：

三次握手建立連接：確保連接建立的可靠性。

端口號：通過端口號識別上層協(xié)議和服務，實現(xiàn)網(wǎng)絡的多路復用。

完整性校驗：通過計算校驗和，保證接收端能檢測出傳輸過程中可能出現(xiàn)的錯誤。

確認機制：對于正確收到的數(shù)據(jù)，接收端通過確認應答告知發(fā)送方，超出一定時間后，發(fā)送方將重傳沒有被確認的段，確保傳輸?shù)目煽啃浴?/p>

序列號：發(fā)送的數(shù)據(jù)都有唯一的序列號，標識了每一個段。接收端可以利用序列號實現(xiàn)丟失檢測、亂序重排等功能。

窗口機制：通過可調(diào)節(jié)的窗口，TCP 接收端可以告知希望的發(fā)送速度，控制數(shù)據(jù)流量。

TCP 實現(xiàn)了數(shù)據(jù)傳輸時各種控制功能，可以進行丟包時的重發(fā)控制，還可以對次序錯誤的分包進行順序控制。作為一種面向有連接的協(xié)議，只有在確定對端存在時，才會發(fā)送數(shù)據(jù)，從而可以控制通信流量的浪費。由于 UDP 沒有連接控制，即使對端不存在或中途退出網(wǎng)絡，數(shù)據(jù)包還是能夠發(fā)送出去。

1)連接

連接是指網(wǎng)絡中進行通信的兩個應用程序，為了相互傳遞消息而專有的、虛擬的通信線路，也叫做虛擬電路。

一旦建立了連接，進行通信的應用程序只使用這個虛擬線路發(fā)送和接收數(shù)據(jù)，就可以保障信息的傳輸。應用程序可以不用考慮 IP 網(wǎng)絡上可能發(fā)生的各種問題，依然可以轉(zhuǎn)發(fā)數(shù)據(jù)。TCP 則負責連接的建立、斷開、保持等管理工作。

連接

為了在不可靠的 IP 通信實現(xiàn)可靠性傳輸，需要考慮很多事情，數(shù)據(jù)的破壞、丟包、重復以及分片順序混亂等問題。TCP 通過校驗和、序列號、確認應答、重發(fā)控制、連接管理以及窗口控制等機制實現(xiàn)可靠性傳輸。

TCP知名端口號

>序列號和確認應答

在 TCP 中，當發(fā)送端的數(shù)據(jù)到達接收主機時，接收端主機會返回一個已收到的消息。這個消息叫做確認應答( ACK )。

正常數(shù)據(jù)傳輸

TCP 通過確認應答實現(xiàn)可靠的數(shù)據(jù)傳輸。當發(fā)送端將數(shù)據(jù)發(fā)出后，會等待對端的確認應答。如果有確認應答，說明數(shù)據(jù)已經(jīng)成功到達對端。否則，數(shù)據(jù)可能已經(jīng)丟失。

在一定時間內(nèi)沒有等到確認應答，發(fā)送端會認為數(shù)據(jù)已經(jīng)丟失，并進行重發(fā)。這樣，即使有丟包，仍能保證數(shù)據(jù)到達對端，實現(xiàn)可靠傳輸。

數(shù)據(jù)丟失

未收到確認應答，不一定是數(shù)據(jù)丟失。也可能對端已經(jīng)收到數(shù)據(jù)，返回的確認應答在途中丟失，也會導致發(fā)送端重發(fā)。此外，也可能確認應答延遲到達，發(fā)送端重發(fā)數(shù)據(jù)后才收到。

確認應答丟失

每一次傳輸數(shù)據(jù)時，TCP 都會標明段的起始序列號，以便對方確認。在 TCP 中并不直接確認收到哪些段，而是通知發(fā)送方下一次應該發(fā)送哪一個段，表示前面的段已經(jīng)收到。比如：收到的確認應答序列號是 N + 1 時，表示 N 以及 N 之前的數(shù)據(jù)都收到了。

序列號和確認應答

由于每一個段都有唯一的編號，這樣的話，當接收端收到重復的段時容易發(fā)現(xiàn)，數(shù)據(jù)段丟失后也容易定位，亂序后也可以重新排列。

>超時重發(fā)

超時重發(fā)是指在重發(fā)數(shù)據(jù)之前，等待確認應答到來的那個間隔時間。如果超過 RTT(往返時間)，仍未收到確認應答，發(fā)送端將進行數(shù)據(jù)重發(fā)。

往返時間

數(shù)據(jù)被重發(fā)后，若還收不到確認應答，則再次發(fā)送。這時，等待確認應答的時間將會以 2 倍、4 倍的指數(shù)函數(shù)增長。數(shù)據(jù)也不會無限地重發(fā)，達到一定的重發(fā)次數(shù)后，還沒收到確認應答，就會認為網(wǎng)絡或?qū)Χ酥鳈C發(fā)送異常，強制關閉連接，并通知應用通信異常強行終止。

RTT 時間是一個非常重要的參數(shù)。過大的 RTT 會導致 TCP 重傳非常慢，降低傳輸?shù)乃俣?過小的 RTT 會導致 TCP 頻繁重傳，降低資源的使用效率。在實際情況下，通過實時跟蹤數(shù)據(jù)往返的時間間隔來動態(tài)調(diào)整 RTT 的數(shù)值。

>連接管理

TCP 提供面向有連接的通信傳輸，面向有連接是指在數(shù)據(jù)通信前做好通信兩端的準備工作。在數(shù)據(jù)通信前，發(fā)送一個 SYN 包作為建立連接的請求。如果對端發(fā)來確認應答，則認為可以開始數(shù)據(jù)通信。如果對端的確認應答未能到達，就不會進行數(shù)據(jù)通信。在通信結(jié)束時，會使用 FIN 包進行斷開連接的處理。

SYN 包和 FIN 包是通過 TCP 頭部的控制字段來管理 TCP 連接。一個連接的建立與斷開，正常過程至少需要來回發(fā)送 7 個包才能完成。建立一個 TCP 連接需要發(fā)送 3 個包，這個過程叫作三次握手。斷開一個 TCP 連接需要發(fā)送 4 個包，這個過程也稱作四次揮手。創(chuàng)建一個 TCP 連接，會產(chǎn)生一個 32 位隨機序列號，因為每一個新的連接使用一個新的隨機序列號。

連接管理

>三次握手

主機 A 想向主機 B 發(fā)送數(shù)據(jù)，TCP 模塊通過三次握手建立連接 TCP 會話。

三次握手，是指 TCP 會話建立過程中共交換了 3 個 TCP 控制段，它們分布是 SYN 段、SYN + ACK 段、ACK 段。

詳細過程如下：

發(fā)送端主機 A 向接收端主機 B 發(fā)出 SYN 段，表示發(fā)起建立連接請求，同時把自己的狀態(tài)告訴主機 B 。將段的序列號設為 a ，SYN 置位，表示 SYN 管理段。

主機 B 收到連接請求后，回應 SYN + ACK 段，將序列號設為 b ，確認號設為 a + 1 ，同時將 SYN 和 ACK 置位。

主機 A 收到主機 B 的連接確認后，發(fā)送 ACK 段再次進行確認，確認會話的建立，將 ACK 置位。主機 A 收到確認號是 a + 1 、序列號是 b 的段后，發(fā)送序列號為 a + 1 、確認號為 b + 1 的段進行確認。

主機 B 收到確認報文后，連接建立。雙方可以開始傳輸數(shù)據(jù)。

三次握手

經(jīng)過 3 次握手后，A 和 B 之間其實是建立了兩個 TCP 會話，一個是從 A 指向 B 的 TCP 會話，另一個是從 B 指向 A 的 TCP 會話。A 發(fā)送的 SYN 段，表示 A 請求建立一個 從 A 指向 B 的 TCP 會話，目的是控制數(shù)據(jù)能夠正常、可靠的從 A 傳輸?shù)?B 。B 在收到 SYN 段后，會發(fā)送一個 SYN + ACK 段作為回應。SYN + ACK 的含義是：B 一方面同意了 A 的請求，另一方面也請求建立一個從 B 指向 A 的 TCP 會話，這個會話目的是控制數(shù)據(jù)能夠正確、可靠的從 B 傳輸?shù)?A 。A 收到 SYN + ACK 段后，回應一個 ACK ，表示同意 B 的請求。

>四次揮手

當 TCP 數(shù)據(jù)段的傳輸結(jié)束時，雙方都需要發(fā)送 FIN 段和 ACK 段來終止 TCP 會話。這個方式叫做四次揮手，詳細過程如下：

主機 A 想要終止連接，發(fā)送序列號為 p 的段，F(xiàn)IN 置位，表示 FIN 管理段。

主機 B 收到主機 A 發(fā)送的 FIN 段后，發(fā)送 ACK 段，確認號為 p + 1 ，同時關閉連接。

主機 B 發(fā)送序列號為 q的段，F(xiàn)IN 置位，通知連接關閉。

主機 A 收到主機 B 發(fā)送的 FIN 段后，發(fā)送 ACK 段，確認號為 q + 1 ，同時關閉連接。TCP 連接至此結(jié)束。

四次揮手

TCP 會話的終止分為兩個部分。首先 A 發(fā)送 FIN 控制段，請求終止從 A 到 B 的 TCP 會話。B 回應 ACK 段，表示同意 A 的終止會話請求。A 收到 B 的 ACK 段后，才開始終止這個會話。同理，B 也會向 A 發(fā)起請求，終止從 B 到 A 的 TCP 會話。

>單位段

經(jīng)過傳輸層協(xié)議封裝后的數(shù)據(jù)稱為段。在建立 TCP 連接時，可以確定數(shù)據(jù)段的大小，也就是最大消息長度( MSS )。TCP 在傳輸大量數(shù)據(jù)時，是以 MSS 的大小將數(shù)據(jù)進行分割發(fā)送，重發(fā)也是以 MSS 為單位。

MSS分片

MSS 是在三次握手時，由兩端主機計算出來的。兩端主機在發(fā)出建立連接的請求時，會在 TCP 頭部寫入 MSS 值。然后在兩者間選擇較小的值使用。MSS 默認值為 536 字節(jié)，理想值是 1460 字節(jié)，加上 IP 頭部 20 字節(jié)和 TCP 頭部 20字節(jié)，剛好在 IP 層不會被分片。

MSS協(xié)商

>窗口控制

TCP 是以 1 個段為單位，每發(fā)一個段進行一次確認應答。如果包的往返時間越長，通信性能就越低。

按數(shù)據(jù)包確認應答

為解決這個問題，TCP 引入了窗口的概念。確認應答不再是每個分段，而是以窗口的大小進行確認，轉(zhuǎn)發(fā)時間被大幅度的縮短。窗口大小就是指無需等待確認應答，而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。窗口大小是一個 16 位字段，因此窗口最大是 65535 字節(jié)。在 TCP 傳輸過程中，雙方通過交換窗口的大小來表示自己剩余的緩沖區(qū)( Buffer )空間，以及下一次能夠接受的最大數(shù)據(jù)量，避免緩沖區(qū)的溢出。

滑動窗口

發(fā)送數(shù)據(jù)中，窗口內(nèi)的數(shù)據(jù)即使沒有收到確認應答也可以發(fā)送出去。如果窗口中的數(shù)據(jù)在傳輸中丟失，也需要進行重發(fā)。因此，發(fā)送端主機在收到確認應答前，必須在緩沖區(qū)保留這部分數(shù)據(jù)。

收到確認應答后，將窗口滑動到確認應答中的序列號位置。這樣可以按順序?qū)⒍鄠€段同時發(fā)送，這種機制也被稱為滑動窗口控制。

滑動窗口控制

>窗口控制和重發(fā)控制

在使用窗口控制時，如果出現(xiàn)確認應答未能返回的情況，數(shù)據(jù)已經(jīng)到達對端，是不需要再進行重發(fā)的。然而，在沒有使用窗口控制時，沒收到確認應答的數(shù)據(jù)是會重發(fā)的。而使用了窗口控制，某些確認應答即使丟失也無需重發(fā)。

窗口控制重發(fā)

如果某個報文段丟失，接收主機收到序號不連續(xù)的數(shù)據(jù)時，會為已經(jīng)收到的數(shù)據(jù)返回確認應答。即使接收端收到的包序號不是連續(xù)的，也不會將數(shù)據(jù)丟棄，而是暫時保存至緩沖區(qū)。出現(xiàn)報文丟失時，同一個序號的確認應答將會被重復發(fā)送。如果發(fā)送端收到連續(xù) 3 次同一個確認應答，就會將對應的數(shù)據(jù)進行重發(fā)。這種機制比超時管理更高效，也被稱為高速重發(fā)機制。

高速重發(fā)控制

>流控制

接收端處于高負荷狀態(tài)時，可能無法處理接收的數(shù)據(jù)，并丟棄數(shù)據(jù)，就會觸發(fā)重發(fā)機制，導致網(wǎng)絡流量無端浪費。

為了防止這種情況，TCP 提供一種機制可以讓發(fā)送端根據(jù)接收端的實際接收能力控制發(fā)送的數(shù)據(jù)量，這就是流控制。它的具體操作是，接收端主機通知發(fā)送端主機自己可以接收數(shù)據(jù)的大小，于是發(fā)送端會發(fā)送不超過這個限度的數(shù)據(jù)。這個限度的大小就是窗口大小。

TCP 頭部中有一個字段用來通知窗口大小。接收主機將緩沖區(qū)大小放入這個字段發(fā)送給接收端。當接收端的緩存不足或處理能力有限時，窗口大小的值會降低一半，從而控制數(shù)據(jù)發(fā)送量。也就是說，發(fā)送端主機會根據(jù)接收端主機的指示，對發(fā)送數(shù)據(jù)的量進行控制，也就形成了一個完整的 TCP 流控制。

若接收端要求窗口大小為 0 ，表示接收端已經(jīng)接收全部數(shù)據(jù)，或者接收端應用程序沒有時間讀取數(shù)據(jù)，要求暫停發(fā)送。

流控制

如果窗口更新的報文丟失，可能會導致無法繼續(xù)通信。為避免這個問題，發(fā)送端主機會時不時的發(fā)送一個叫窗口探測的數(shù)據(jù)段，此數(shù)據(jù)段僅含一個字節(jié)以獲取最新的窗口大小信息。

>擁塞控制

有了 TCP 的窗口控制，收發(fā)主機之間不再以一個數(shù)據(jù)段為單位發(fā)送確認應答，也能夠連續(xù)發(fā)送大量數(shù)據(jù)包。在網(wǎng)絡出現(xiàn)擁堵時，如果突然發(fā)送一個較大量的數(shù)據(jù)，有可能會導致整個網(wǎng)絡癱瘓。

為了防止這個問題出現(xiàn)，在通信開始時，就會通過一個叫慢啟動的算法得出的數(shù)值，對發(fā)送數(shù)據(jù)量進行控制。

慢啟動

為了在發(fā)送端調(diào)節(jié)發(fā)送數(shù)據(jù)的量，需要使用擁塞窗口。在慢啟動時，將擁塞窗口的大小設置為 1 MSS 發(fā)送數(shù)據(jù)，之后每收到一次確認應答( ACK ),擁塞窗口的值就加 1 。在發(fā)送數(shù)據(jù)包時，將擁塞窗口的大小與接收端主機通知的窗口大小做比較，選擇它們當中較小的值發(fā)送數(shù)據(jù)。這樣可以有效減少通信開始時連續(xù)發(fā)包導致網(wǎng)絡擁堵，還可以避免網(wǎng)絡擁塞的發(fā)生。

TCP 和 UDP 的對比

TCP和UDP對比

UDP 格式

UDP 段由 UDP 頭部和 UDP 數(shù)據(jù)組成。UDP 頭部有源端口號、目的端口號、長度、校驗和組成，UDP 頭部長度為固定的 8 字節(jié)。

UDP報文格式

源端口號：字段長 16 位，表示發(fā)送端 UDP 端口號。

目的端口號：字段長 16 位，表示接收端 UDP 端口號

長度：字段長 16 位，表示 UDP 頭部和 UDP 數(shù)據(jù)的總長度。

校驗和：字段長 16 位，是錯誤檢查的字段，包括 UDP 頭和 UDP 數(shù)據(jù)的內(nèi)容計算得出，用于檢查傳輸過程中出現(xiàn)的錯誤。

TCP 格式

TCP 頭部比 UDP 頭部復雜得多，由一個 20 字節(jié)的固定長度加上可變長的選項字段組成。

TCP報文格式

源端口號：字段長 16 位，表示發(fā)送端 TCP 端口號。

目的端口號：字段長 16 位，表示接收端 TCP 端口號。

序列號：字段長 32 位，是指 TCP 段數(shù)據(jù)的位置序號。根據(jù)序列號來判斷是否存在重收、漏收、亂序等情況。

確認號：字段長 32 位，是指下一次應該收到的數(shù)據(jù)的序列號。收到這個確認號，表示這個確認號之前的數(shù)據(jù)都已經(jīng)正常收到。

數(shù)據(jù)偏移：字段長 4 位，表示 TCP 數(shù)據(jù)從哪一位開始計算，也可以看作 TCP 頭部的長度。

保留：字段長 6 位，保留給以后擴展使用。

控制位：字段長 6 位，每 1 位標志位可以打開一個控制功能，也叫做控制位。從左到右分別是 URG 、ACK 、PSH 、RST 、SYN 、FIN 。

控制位

URG：標志位為 1 時，表示有需要緊急處理的數(shù)據(jù)。

ACK：標志位為 1 時，表示確認應答有效。

PSH：標志位為 1 時，表示將數(shù)據(jù)立即上傳給應用程序，而不是在緩沖區(qū)排隊。

RST：標志位為 1 時，表示 TCP 連接出現(xiàn)異常，必須強制斷開連接。

SYN：標志位為 1 時，表示請求建立連接，并設置序列號的初始值。

FIN：標志位為 1 時，表示數(shù)據(jù)發(fā)送結(jié)束，請求斷開 TCP 連接。

窗口：字段長 16 位，標明滑動窗口的大小，表示自己還能接收多少字節(jié)的數(shù)據(jù)。

校驗和：字段長 16 位，是錯誤檢查的字段，包括 TCP 頭和 TCP 數(shù)據(jù)的內(nèi)容計算得出，用于檢查傳輸過程中出現(xiàn)的錯誤。

緊急指針：字段長 16 位，表示緊急數(shù)據(jù)的長度。當 URG 位為 1 時，這個字段才有效。

選項：字段的長度是可變的。通過添加不同的選項，實現(xiàn) TCP 的一些擴展功能。

填充：如果 TCP 段的頭部不是 4 字節(jié)的整數(shù)倍，就填充一些 0 ，來保證頭部長度是 4 字節(jié)的整數(shù)倍。

數(shù)據(jù)：TCP 段的數(shù)據(jù)部分，不是 TCP 頭部內(nèi)容，字段最大是 MSS 。

審核編輯：湯梓紅