1.UDP

用戶數據報協議 UDP（User Datagram Protocol）： 是無連接的，盡最大可能交付，沒有擁塞控制，面向報文（對于應用程序傳下來的報文不合并也不拆分，只是添加 UDP 首部） ，支持一對一、一對多、多對一和多對多的交互通信。

1.1 UDP首部格式

首部字段只有 8 個字節，包括源端口、目的端口、長度、檢驗和。

12 字節的偽首部是為了計算檢驗和臨時添加的。

2.TCP

傳輸控制協議 TCP（Transmission Control Protocol）： 是面向連接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通信，面向字節流（把應用層傳下來的報文看成字節流，把字節流組織成大小不等的數據塊） ，每一條 TCP連接只能是點對點的（一對一）。

2.1 TCP首部格式

• 序號 ：用于對字節流進行編號，例如序號為 301，表示第一個字節的編號為301，如果攜帶的數據長度為 100 字節，那么下一個報文段的序號應為 401。
• 確認號 ：期望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段，序號為 501，攜帶的數據長度為 200 字節，因此 B 期望下一個報文段的序號為 701，B 發送給 A 的確認報文段中確認號就為 701。
• 數據偏移 ：指的是數據部分距離報文段起始處的偏移量，實際上指的是首部的長度。
• 確認 ACK ：當 ACK=1 時確認號字段有效，否則無效。TCP 規定，在連接建立后所有傳送的報文段都必須把 ACK 置 1。
• 同步 SYN ：在連接建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連接請求報文段。若對方同意建立連接，則響應報文中 SYN=1，ACK=1。
• 終止 FIN ：用來釋放一個連接，當 FIN=1 時，表示此報文段的發送方的數據已發送完畢，并要求釋放連接。
• 窗口 ：窗口值作為接收方讓發送方設置其發送窗口的依據。之所以要有這個限制，是因為接收方的數據緩存空間是有限的。

2.2?TCP 的三次握手

假設 A 為客戶端，B 為服務器端。

首先 B 處于 LISTEN（監聽） 狀態，等待客戶的連接請求。

A 向 B 發送連接請求報文，SYN=1，ACK=0，選擇一個初始的序號 x。

B 收到連接請求報文，如果同意建立連接，則向 A 發送連接確認報文，SYN=1，ACK=1，確認號為 x+1，同時也選擇一個初始的序號 y。

A 收到 B 的連接確認報文后，還要向 B 發出確認，確認號為 y+1，序號為x+1。

B 收到 A 的確認后，連接建立。

2.2.1?三次握手的原因

第三次握手是為了防止失效的連接請求到達服務器，讓服務器錯誤打開連接。

• 客戶端發送的連接請求如果在網絡中滯留，那么就會隔很長一段時間才能收到服務器端發回的連接確認。
• 客戶端等待一個超時重傳時間之后，就會重新請求連接。
• 但是這個滯留的連接請求最后還是會到達服務器，如果不進行三次握手，那么服務器就會打開兩個連接。
• 如果有第三次握手，客戶端會忽略服務器之后發送的對滯留連接請求的連接確認，不進行第三次握手，因此就不會再次打開連接。

2.3?TCP 的四次揮手

以下描述不討論序號和確認號，因為序號和確認號的規則比較簡單。并且不討論ACK，因為 ACK 在連接建立之后都為 1。

A 發送連接釋放報文，FIN=1。

B 收到之后發出確認，此時 TCP 屬于半關閉狀態，B 能向 A 發送數據但是 A不能向 B 發送數據。

當 B 不再需要連接時，發送連接釋放報文，FIN=1。

A 收到后發出確認，進入 TIME-WAIT 狀態，等待 2 MSL（最大報文存活時間） 后釋放連接。

B 收到 A 的確認后釋放連接。

2.3.1?四次揮手的原因

客戶端發送了 FIN 連接釋放報文之后，服務器收到了這個報文，就進入了 CLOSEWAIT 狀態。

這個狀態是為了讓服務器端發送還未傳送畢的數據，傳送完畢之后，服務器會發送 FIN 連接釋放報文。

2.3.2?TIME_WAIT

客戶端接收到服務器端的 FIN 報文后進入此狀態，此時并不是直接進入 CLOSED狀態，還需要等待一個時間計時器設置的時間 2MSL。這么做有兩個理由：

• 確保最后一個確認報文能夠到達。如果 B 沒收到 A 發送來的確認報文，那么就會重新發送連接釋放請求報文，A 等待一段時間就是為了處理這種情況的發生。
• 等待一段時間是為了讓本連接持續時間內所產生的所有報文都從網絡中消失，使得下一個新的連接不會出現舊的連接請求報文。

2.4 TCP 可靠傳輸

TCP 使用超時重傳來實現可靠傳輸：如果一個已經發送的報文段在超時時間（具體時間的確定）內沒有收到確認，那么就重傳這個報文段。

2.5?TCP 滑動窗口

窗口是緩存的一部分，用來暫時存放字節流。

發送方和接收方各有一個窗口：

• 接收方通過 TCP 報文段中的窗口字段告訴發送方自己的窗口大小；
• 發送方根據這個值和其它信息設置自己的窗口大小。

發送窗口內的字節都允許被發送，接收窗口內的字節都允許被接收。

如果發送窗口左部的字節已經發送并且收到了確認，那么就將發送窗口向右滑動一定距離，直到左部第一個字節不是已發送并且已確認的狀態；

接收窗口的滑動類似，接收窗口左部字節已經發送確認并交付主機，就向右滑動接收窗口。

接收窗口只會對窗口內最后一個按序到達的字節進行確認。

例如接收窗口已經收到的字節為 {31, 34, 35}，其中 {31} 按序到達，而 {34, 35} 就不是，因此只對字節 31進行確認。發送方得到一個字節的確認之后，就知道這個字節之前的所有字節都已經被接收。

2.6?TCP 流量控制

流量控制是為了控制發送方發送速率，保證接收方來得及接收。

接收方發送的確認報文中的窗口字段可以用來控制發送方窗口大小，從而影響發送方的發送速率。

將窗口字段設置為 0，則發送方不能發送數據。

2.7 TCP 擁塞控制

如果網絡出現擁塞，分組將會丟失，此時發送方會繼續重傳，從而導致網絡擁塞程度更高。

因此當出現擁塞時，應當控制發送方的速率。這一點和流量控制很像，但是出發點不同。

• 流量控制是為了讓接收方能來得及接收，
• 擁塞控制是為了降低整個網絡的擁塞程度。

2.8 TCP擁塞控制方法

TCP 主要通過四種算法來進行擁塞控制：慢開始、擁塞避免、快重傳、快恢復。

發送方需要維護一個叫做擁塞窗口（cwnd） 的狀態變量。

注意擁塞窗口與發送方窗口的區別：

• 擁塞窗口只是一個狀態變量
• 實際決定發送方能發送多少數據的是發送方窗口

為了便于討論，做如下假設：

• 接收方有足夠大的接收緩存，因此不會發生流量控制；
• 雖然 TCP 的窗口基于字節，但是這里設窗口的大小單位為報文段。

2.8.1?慢開始與擁塞避免

發送的最初執行慢開始，令 cwnd=1，發送方只能發送 1 個報文段；

當收到確認后，將 cwnd 加倍，因此之后發送方能夠發送的報文段數量為：2、4、8 ...

注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得發送方發送的速度增長速度過快，網絡擁塞的可能也就更高。

設置一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。

如果出現了超時，則令 ssthresh = cwnd/2，然后重新執行慢開始。

2.8.2 快重傳與快恢復

在接收方，要求每次接收到報文段都應該對最后一個已收到的有序報文段進行確認。

• 例如已經接收到 M1 和 M2 ，此時收到 M 4，應當發送對 M2 的確認。

在發送方，如果收到三個重復確認，那么可以知道下一個報文段丟失，此時執行快重傳，立即重傳下一個報文段。

• 例如收到三個 M2 ，則 M 3丟失，立即重傳 M 3。

在這種情況下，只是丟失個別報文段，而不是網絡擁塞。因此執行快恢復，令ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免。

慢開始和快恢復的快慢指的是 cwnd 的設定值，而不是 cwnd 的增長速率。

• 慢開始cwnd 設定為 1，
• 快恢復 cwnd 設定為 ssthresh。

?

總結

以上是生活随笔為你收集整理的UDP（首部）和TCP（首部、三次握手、四次挥手、可靠传输、滑动窗口、流量控制、拥塞控制（慢开始、拥塞避免、快重传、快恢复））的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。