TCP 和 UDP 協議簡介

JMCui發表於2021-04-14

一、TCP

TCP(Transmission Control Protocol),傳輸控制協議,對“傳輸、傳送、通訊”進行“控制”的協議,它充分地實現了資料傳輸時的各種控制功能,可以進行丟包時的重發控制,還可以對次序亂掉的分包進行順序控制。此外,TCP 是面向有連線的協議,只有在確認通訊端存在時才會傳送資料。

TCP 複雜控制連線的建立、斷開、保持等管理工作,保證了在 IP 這種無連線的網路上也能夠實現高可靠性的通訊。

1. 資料傳送

在 TCP 中,當傳送端的資料到達接收主機時,接收端主機會返回一個已收到訊息的通知,這個訊息叫做確認應答(ACK)。如果在一定時間內沒有收到 ACK,傳送端就可以認為資料已經丟失,並進行重發。

在 TCP 中,會在傳送資料的每一個位元組都標上序號,接收端查詢接收資料 TCP 首部中的序列號和資料的長度,將自己下一步應該接收的序號作為 ACK 返送回去。序列號機制使傳送端可以根據序列號分批次傳送,使接收端可以處理訊息亂序和重複問題。

在 TCP 中,會在每次發包時計算往返時間及其偏差(方差),將這個往返時間和偏差(方差)相加就是 重發超時時間。當然,最初的資料包還不知道往返時間,其重發超時一般設定為 6 秒左右。若資料被重發之後還是收不到 ACK,則進行再次傳送,此時,重發超時時間會以 2 倍、4 倍的指數函式延長。

當資料達到一定的重發次數之後,如果仍沒有任何 ACK 返回,就會判斷為網路或對端主機發生了異常,強制關閉連線。

2. 連線管理

TCP 連線過程就是我們再熟悉不過的三次握手和四次揮手過程。

TCP 和 UDP 協議簡介

3. 段和視窗控制

TCP 以段(Segment)為單位傳送資料,段的大小(MSS:Maximum Segment Size)是在三次握手的時候,在兩端主機之間被計算得出。兩端的主機在發出建立連線的請求時,會在 TCP 首部中寫入 MSS 選項,告訴對方自己的介面能夠適應的 MSS 的大小,然後 TCP 會在兩者之間選擇一個較小的值投入使用。

TCP 以段為單位,每發一個段進行一次 ACK 的處理,這樣的傳輸方式有一個缺點 —— 包的往返時間越長通訊效能就越低。為解決這個問題,TCP 引入了 視窗 這個概念,視窗是比段更大的單位,在視窗內傳送了一個段以後不必要一直等待 ACK,而是繼續傳送。如下圖,視窗大小為 4 個段。

TCP 和 UDP 協議簡介

在使用視窗控制中,如果出現段丟失該怎麼辦?這個問題可以分為兩種情況,第一種情況是接收端接收到了資料,但是回覆 ACK 失敗,這種情況是不需要再進行重發的,接收端會在下一次的 ACK 中告知資料接收成功了;第二種情況是接收端未收到資料,接收端會一直 ACK 該資料的序列號,當傳送端連續 3 次接收同一序列號的 ACK,就會將其對應的資料進行重發,該機制稱為 高效重發機制

TCP 和 UDP 協議簡介

4. 流控制

流控制體現為可以讓傳送端根據接收端的實際接收能力控制傳送的資料量。它的具體操作是,接收端主機向傳送端主機通知自己可以接收資料的大小,於是傳送端會傳送不超過這個限度的資料,該大小限度就被稱為視窗大小。

接收端的資料緩衝區一旦面臨溢位時,視窗大小的值也會被隨之設定為一個更小的值通知給傳送端。傳送端再根據該值,對傳送資料的量進行控制。這就形成了一個完整的 TCP 流控制。

5. 擁塞控制

擁塞控制是為了解決網路擁堵的問題,在網路出現擁堵時,如果突然傳送一個較大量的資料,極有可能會導致整個網路的癱瘓。前面提到的流控制,視窗大小是由接收端決定的,傳送端無法自我調節要傳送的資料量。

為了在傳送端調節所要傳送資料的量,定義了一個叫做 擁塞視窗 的概念。在通訊一開始時,通過一個叫做慢啟動的演算法計算出擁塞視窗的初始閾值,之後每收到一次 ACK,擁塞視窗按照一定的比例放大擁塞視窗。在傳送資料包時,將擁塞視窗的大小與接收端主動通知的視窗大小做比較,然後按照它們當中較小的那個值,傳送比其還要小的資料量。

當 TCP 通訊開始以後,網路吞吐量會逐漸上升,但是隨著網路擁堵的發生(體現為資料重發)吞吐量也會急速下降。於是會再次進入吞吐量慢慢上升的過程。因此所謂 TCP 的吞吐量的特點就好像是在逐步佔領網路頻寬的感覺。

TCP 和 UDP 協議簡介

6. Nagle 演算法

Nagle 演算法是指傳送端即使還有應該傳送的資料,但如果這部分資料很少的話,則進行延遲傳送的一種處理機制。具體來說,就是僅在下列任意一種條件下才能傳送資料。

  • 已傳送的資料都已經收到 ACK
  • 已傳送最大段長度(MSS)的資料

7. 延遲確認應答

前面提到,TCP 採用滑動視窗的控制機制,因此通常確認應答少一些也無妨。為此,引入了一個方法,那就是收到資料以後並不立即返回 ACK,而是延遲一段時間的機制。

  • 在沒有收到 2x最大段長度(MSS)的資料為止不做 ACK,體現為每兩個資料段返回一個 ACK。
  • 其他情況下,最大延遲 0.5s 傳送 ACK(很多作業系統設定為 0.2s 左右)

二、UDP

UDP(User Datagram Protocol),使用者資料包協議,不提供複雜的控制協議,利用 IP 提供面向無連線的通訊服務。即使是出現網路擁堵的情況下,UDP 也無法進行流量控制等避免網路擁塞的行為。此外,傳輸途中即使出現丟包,UDP 也不負責重發。甚至當出現包的到達順序亂掉時也沒有糾正的功能。如果需要這些細節控制,那麼不得不交由採用 UDP 的應用程式去處理。

UDP 是一種沒有複雜控制,提供面向無連線通訊服務的一種協議。換句話說,它將部分控制轉移給應用程式去處理,自己卻只提供作為傳輸層協議的最基本功能,本身處理既簡單又高效,因此經常用於以下幾個方面:

  • 包總量較少的通訊(DNS、SNMP 等)
  • 視訊、音訊等多媒體通訊(即時通訊)
  • 限定於 LAN 等特定網路中的應用通訊
  • 廣播通訊(廣播、多播)

三、總結

TCP 是一種面向有連線的傳輸層協議。它可以保證兩端通訊主機之間的通訊可達。TCP 能夠正確處理在傳輸過程中丟包、傳輸順序亂掉等異常情況。此外,TCP 還能夠有效利用頻寬,緩解網路擁堵。然而,為了建立與斷開連線,有時它需要至少 7 次的發包丟包,導致網路流量的浪費。此外,為了提高網路的利用率,TCP 協議中定義了各種各樣複雜的規範,因此不利於視訊會議(音訊、視訊的資料量既定)等場合使用。

UDP 有別於 TCP,它是一種面向無連線的傳輸層協議。UDP 不會關注對端是否真的收到了傳送過去的資料,如果需要檢查對端是否收到分組資料包,或者對端是否連線到網路,則需要在應用程式中實現。UDP 常用於分組資料較少或多播、廣播通訊以及視訊通訊等多媒體領域。

相關文章