UDP 和 TCP 的特點（區(qū)別）

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

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

UDP 首部格式

image.png

首部字段只有 8 個字節(jié)，包括源端口、目的端口、長度、檢驗和。12 字節(jié)的偽首部是為了計算檢驗和臨時添加的。

TCP 首部格式

image.png

序號 ：用于對字節(jié)流進行編號，例如序號為 301，表示第一個字節(jié)的編號為 301，如果攜帶的數(shù)據(jù)長度為 100 字節(jié)，那么下一個報文段的序號應(yīng)為 401。

確認(rèn)號 ：期望收到的下一個報文段的序號。例如 B 正確收到 A 發(fā)送來的一個報文段，序號為 501，攜帶的數(shù)據(jù)長度為 200 字節(jié)，因此 B 期望下一個報文段的序號為 701，B 發(fā)送給 A 的確認(rèn)報文段中確認(rèn)號就為 701。

數(shù)據(jù)偏移 ：指的是數(shù)據(jù)部分距離報文段起始處的偏移量，實際上指的是首部的長度。

確認(rèn) ACK ：當(dāng) ACK=1 時確認(rèn)號字段有效，否則無效。TCP 規(guī)定，在連接建立后所有傳送的報文段都必須把 ACK 置 1。

同步 SYN ：在連接建立時用來同步序號。當(dāng) SYN=1，ACK=0 時表示這是一個連接請求報文段。若對方同意建立連接，則響應(yīng)報文中 SYN=1，ACK=1。

終止 FIN ：用來釋放一個連接，當(dāng) FIN=1 時，表示此報文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢，并要求釋放連接。

窗口 ：窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。之所以要有這個限制，是因為接收方的數(shù)據(jù)緩存空間是有限的。

TCP 的三次握手

image.png

假設(shè) A 為客戶端，B 為服務(wù)器端。

1. 首先 B 處于 LISTEN（監(jiān)聽）狀態(tài)，等待客戶的連接請求。

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

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

4. A 收到 B 的連接確認(rèn)報文后，還要向 B 發(fā)出確認(rèn)，確認(rèn)號為 y+1，序號為 x+1。

5. B 收到 A 的確認(rèn)后，連接建立。

三次握手的原因

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

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

TCP 的四次揮手

image.png

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

1. A 發(fā)送連接釋放報文，F(xiàn)IN=1。

2. B 收到之后發(fā)出確認(rèn)，此時 TCP 屬于半關(guān)閉狀態(tài)，B 能向 A 發(fā)送數(shù)據(jù)但是 A 不能向 B 發(fā)送數(shù)據(jù)。

3. 當(dāng) B 不再需要連接時，發(fā)送連接釋放報文，F(xiàn)IN=1。

4. A 收到后發(fā)出確認(rèn)，進入 TIME-WAIT 狀態(tài)，等待 2 MSL（最大報文存活時間）后釋放連接。

5. B 收到 A 的確認(rèn)后釋放連接。

四次揮手的原因

客戶端發(fā)送了 FIN連接釋放報文之后，服務(wù)器收到了這個報文，就進入了 CLOSE-WAIT 狀態(tài)。這個狀態(tài)是為了讓服務(wù)器端發(fā)送還未傳送完畢的數(shù)據(jù)，傳送完畢之后，服務(wù)器會發(fā)送 FIN 連接釋放報文。也就是說為了==防止數(shù)據(jù)丟失==。

TIME_WAIT作用

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

• 確保最后一個確認(rèn)報文能夠到達(dá)。如果 B 沒收到 A 發(fā)送來的確認(rèn)報文，那么就會重新發(fā)送連接釋放請求報文，A 等待一段時間就是為了處理這種情況的發(fā)生。

• 等待一段時間是為了讓本連接持續(xù)時間內(nèi)所產(chǎn)生的所有報文都從網(wǎng)絡(luò)中消失，使得下一個新的連接不會出現(xiàn)舊的連接請求報文。

TCP 可靠傳輸

TCP 使用超時重傳來實現(xiàn)可靠傳輸：如果一個已經(jīng)發(fā)送的報文段在超時時間內(nèi)沒有收到確認(rèn)，那么就重傳這個報文段。

一個報文段從發(fā)送再到接收到確認(rèn)所經(jīng)過的時間稱為往返時間 RTT，加權(quán)平均往返時間 RTTs 計算如下：

image.png

其中，0 ≤ a ＜ 1，RTTs 隨著 a 的增加更容易受到 RTT 的影響。
超時時間 RTO 應(yīng)該略大于 RTTs，TCP 使用的超時時間計算如下：

image.png

其中 RTTd 為偏差的加權(quán)平均值。

TCP 滑動窗口

窗口是緩存的一部分，用來暫時存放字節(jié)流。發(fā)送方和接收方各有一個窗口，接收方通過 TCP 報文段中的窗口字段告訴發(fā)送方自己的窗口大小，發(fā)送方根據(jù)這個值和其它信息設(shè)置自己的窗口大小。

發(fā)送窗口內(nèi)的字節(jié)都允許被發(fā)送，接收窗口內(nèi)的字節(jié)都允許被接收。如果發(fā)送窗口左部的字節(jié)已經(jīng)發(fā)送并且收到了確認(rèn)，那么就將發(fā)送窗口向右滑動一定距離，直到左部第一個字節(jié)不是已發(fā)送并且已確認(rèn)的狀態(tài)；接收窗口的滑動類似，接收窗口左部字節(jié)已經(jīng)發(fā)送確認(rèn)并交付主機，就向右滑動接收窗口。

接收窗口只會對窗口內(nèi)最后一個==按序到達(dá)==的字節(jié)進行確認(rèn)，例如接收窗口已經(jīng)收到的字節(jié)為 {31, 34, 35}，其中 {31} 按序到達(dá)，而 {34, 35} 就不是，因此只對字節(jié) 31 進行確認(rèn)。發(fā)送方得到一個字節(jié)的確認(rèn)之后，就知道這個字節(jié)之前的所有字節(jié)都已經(jīng)被接收。

image.png

TCP 流量控制

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

接收方發(fā)送的確認(rèn)報文中的窗口字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。
也就是說是通過滑動窗口實現(xiàn)的。

TCP 擁塞控制

如果網(wǎng)絡(luò)出現(xiàn)擁塞，分組將會丟失，此時發(fā)送方會繼續(xù)重傳，從而導(dǎo)致網(wǎng)絡(luò)擁塞程度更高。因此當(dāng)出現(xiàn)擁塞時，應(yīng)當(dāng)控制發(fā)送方的速率。這一點和流量控制很像，但是出發(fā)點不同。流量控制是為了讓接收方能來得及接收，而擁塞控制是為了降低整個網(wǎng)絡(luò)的擁塞程度。

image.png

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

發(fā)送方需要維護一個叫做擁塞窗口（cwnd）的狀態(tài)變量，注意擁塞窗口與發(fā)送方窗口的區(qū)別：擁塞窗口只是一個狀態(tài)變量，實際決定發(fā)送方能發(fā)送多少數(shù)據(jù)的是發(fā)送方窗口。

為了便于討論，做如下假設(shè)：

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

image.png

1. 慢開始與擁塞避免

發(fā)送的最初執(zhí)行慢開始，令 cwnd = 1，發(fā)送方只能發(fā)送 1 個報文段；當(dāng)收到確認(rèn)后，將 cwnd 加倍，因此之后發(fā)送方能夠發(fā)送的報文段數(shù)量為：2、4、8 ...

注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得發(fā)送方發(fā)送的速度增長速度過快，網(wǎng)絡(luò)擁塞的可能性也就更高。設(shè)置一個慢開始門限 ssthresh，當(dāng) cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。

如果出現(xiàn)了超時，則令 ssthresh = cwnd / 2，然后重新執(zhí)行慢開始。

2. 快重傳與快恢復(fù)

在接收方，要求每次接收到報文段都應(yīng)該對最后一個已收到的有序報文段進行確認(rèn)。例如已經(jīng)接收到 M1 和 M2，此時收到 M4，應(yīng)當(dāng)發(fā)送對 M2 的確認(rèn)。

在發(fā)送方，如果收到三個重復(fù)確認(rèn)，那么可以知道下一個報文段丟失，此時執(zhí)行快重傳，立即重傳下一個報文段。例如收到三個 M2，則 M3 丟失，立即重傳 M3。

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

慢開始和快恢復(fù)的快慢指的是 cwnd 的設(shè)定值，而不是 cwnd 的增長速率。慢開始 cwnd 設(shè)定為 1，而快恢復(fù) cwnd 設(shè)定為 ssthresh。

image.png

參考鏈接：

https://github.com/CyC2018/CS-Notes/blob/master/notes/計算機網(wǎng)絡(luò)%20-%20傳輸層.md