[[317204]]

本文轉(zhuǎn)載自微信公眾號「herongwei」，轉(zhuǎn)載本文請聯(lián)系herongwei公眾號。

找工作面試，經(jīng)常會被問到 UDP 和 TCP，今天給大家總結(jié)其中的核心高頻面試題，再有面試官問你相關(guān)的知識點，看這篇就夠了!

PS：文章有點長，請耐心閱讀。

目錄：

1、UDP 和 TCP 的特點與區(qū)別

2、UDP 、TCP 首部格式

3、TCP 的三次握手和四次揮手

4、TCP 的三次握手(為什么三次?)

5、TCP 的四次揮手(為什么四次?)

6、TCP 長連接和短連接的區(qū)別

7、TCP粘包、拆包及解決辦法

8、TCP 可靠傳輸

9、TCP 滑動窗口

10、TCP 流量控制

11、TCP 擁塞控制

12、提供網(wǎng)絡(luò)利用率

前言

網(wǎng)絡(luò)層只把分組發(fā)送到目的主機，但是真正通信的并不是主機而是主機中的進程。傳輸層提供了進程間的邏輯通信，傳輸層向高層用戶屏蔽了下面網(wǎng)絡(luò)層的核心細節(jié)，使應(yīng)用程序看起來像是在兩個傳輸層實體之間有一條端到端的邏輯通信信道。

1、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 連接只能是點對點的(一對一)。

2、UDP 、TCP 首部格式

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

TCP 首部格式比 UDP 復雜。

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

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

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

控制位：八位從左到右分別是 CWR，ECE，URG，ACK，PSH，RST，SYN，F(xiàn)IN。

CWR：CWR 標志與后面的 ECE 標志都用于 IP 首部的 ECN 字段，ECE 標志為 1 時，則通知對方已將擁塞窗口縮小;

ECE：若其值為 1 則會通知對方，從對方到這邊的網(wǎng)絡(luò)有阻塞。在收到數(shù)據(jù)包的 IP 首部中 ECN 為 1 時將 TCP 首部中的 ECE 設(shè)為 1;

URG：該位設(shè)為 1，表示包中有需要緊急處理的數(shù)據(jù)，對于需要緊急處理的數(shù)據(jù)，與后面的緊急指針有關(guān);

ACK：該位設(shè)為 1，確認應(yīng)答的字段有效，TCP規(guī)定除了最初建立連接時的 SYN 包之外該位必須設(shè)為 1;

PSH：該位設(shè)為 1，表示需要將收到的數(shù)據(jù)立刻傳給上層應(yīng)用協(xié)議，若設(shè)為 0，則先將數(shù)據(jù)進行緩存;

RST：該位設(shè)為 1，表示 TCP 連接出現(xiàn)異常必須強制斷開連接;

SYN：用于建立連接，該位設(shè)為 1，表示希望建立連接，并在其序列號的字段進行序列號初值設(shè)定;

FIN：該位設(shè)為 1，表示今后不再有數(shù)據(jù)發(fā)送，希望斷開連接。當通信結(jié)束希望斷開連接時，通信雙方的主機之間就可以相互交換 FIN 位置為 1 的 TCP 段。

每個主機又對對方的 FIN 包進行確認應(yīng)答之后可以斷開連接。不過，主機收到 FIN 設(shè)置為 1 的 TCP 段之后不必馬上回復一個 FIN 包，而是可以等到緩沖區(qū)中的所有數(shù)據(jù)都因為已成功發(fā)送而被自動刪除之后再發(fā) FIN 包;

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

3、什么是 TCP 的三次握手和四次揮手?

TCP 是一種面向連接的單播協(xié)議，在發(fā)送數(shù)據(jù)前，通信雙方必須在彼此間建立一條連接。所謂的“連接”，其實是客戶端和服務(wù)器的內(nèi)存里保存的一份關(guān)于對方的信息，如 IP 地址、端口號等。

TCP 可以看成是一種字節(jié)流，它會處理 IP 層或以下的層的丟包、重復以及錯誤問題。在連接的建立過程中，雙方需要交換一些連接的參數(shù)。這些參數(shù)可以放在 TCP 頭部。

TCP 提供了一種可靠、面向連接、字節(jié)流、傳輸層的服務(wù)，采用三次握手建立一個連接;采用四次揮手來關(guān)閉一個連接。

一個 TCP 連接由一個 4 元組構(gòu)成，分別是兩個 IP 地址和兩個端口號。一個TCP連接通常分為三個階段：啟動、數(shù)據(jù)傳輸、退出(關(guān)閉)。

當 TCP 接收到另一端的數(shù)據(jù)時，它會發(fā)送一個確認，但這個確認不會立即發(fā)送，一般會延遲一會(提供網(wǎng)絡(luò)利用率這部分有講到)。

ACK 是累積的，一個確認字節(jié)號 N 的 ACK 表示所有直到 N 的字節(jié)(不包括 N)已經(jīng)成功被接收了。這樣的好處是如果一個 ACK 丟失，很可能后續(xù)的 ACK 就足以確認前面的報文段了。

一個完整的 TCP 連接是雙向和對稱的，數(shù)據(jù)可以在兩個方向上平等地流動。給上層應(yīng)用程序提供一種雙工服務(wù)。一旦建立了一個連接，這個連接的一個方向上的每個 TCP 報文段都包含了相反方向上的報文段的一個 ACK。

序列號的作用是使得一個 TCP 接收端可丟棄重復的報文段，記錄以雜亂次序到達的報文段。因為 TCP 使用 IP 來傳輸報文段，而IP 不提供重復消除或者保證次序正確的功能。

另一方面，TCP 是一個字節(jié)流協(xié)議，絕不會以雜亂的次序給上層程序發(fā)送數(shù)據(jù)。因此 TCP 接收端會被迫先保持大序列號的數(shù)據(jù)不交給應(yīng)用程序，直到缺失的小序列號的報文段被填滿。

4、TCP 的三次握手(為什么三次?)

三次握手：

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

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

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

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

為什么三次?

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

（2）換個易于理解的視角來看為什么要 3 次握手。

客戶端和服務(wù)端通信前要進行連接，“3次握手”的作用就是雙方都能明確自己和對方的收、發(fā)能力是正常的。

第一次握手：客戶端發(fā)送網(wǎng)絡(luò)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的。

第二次握手：服務(wù)端發(fā)包，客戶端收到了。這樣客戶端就能得出結(jié)論：服務(wù)端的接收、發(fā)送能力，客戶端的接收、發(fā)送能力是正常的。從客戶端的視角來看，我接到了服務(wù)端發(fā)送過來的響應(yīng)數(shù)據(jù)包，說明服務(wù)端接收到了我在第一次握手時發(fā)送的網(wǎng)絡(luò)包，并且成功發(fā)送了響應(yīng)數(shù)據(jù)包，這就說明，服務(wù)端的接收、發(fā)送能力正常。而另一方面，我收到了服務(wù)端的響應(yīng)數(shù)據(jù)包，說明我第一次發(fā)送的網(wǎng)絡(luò)包成功到達服務(wù)端，這樣，我自己的發(fā)送和接收能力也是正常的。

第三次握手：客戶端發(fā)包，服務(wù)端收到了。這樣服務(wù)端就能得出結(jié)論：客戶端的接收、發(fā)送能力，服務(wù)端的發(fā)送、接收能力是正常的。第一、二次握手后，服務(wù)端并不知道客戶端的接收能力以及自己的發(fā)送能力是否正常。

而在第三次握手時，服務(wù)端收到了客戶端對第二次握手作的回應(yīng)。從服務(wù)端的角度，我在第二次握手時的響應(yīng)數(shù)據(jù)發(fā)送出去了，客戶端接收到了。所以，我的發(fā)送能力是正常的。而客戶端的接收能力也是正常的。

經(jīng)歷了上面的三次握手過程，客戶端和服務(wù)端都確認了自己的接收、發(fā)送能力是正常的。之后就可以正常通信了。

每次都是接收到數(shù)據(jù)包的一方可以得到一些結(jié)論，發(fā)送的一方其實沒有任何頭緒。我雖然有發(fā)包的動作，但是我怎么知道我有沒有發(fā)出去，而對方有沒有接收到呢?

而從上面的過程可以看到，最少是需要三次握手過程的。兩次達不到讓雙方都得出自己、對方的接收、發(fā)送能力都正常的結(jié)論。

其實每次收到網(wǎng)絡(luò)包的一方至少是可以得到：對方的發(fā)送、我方的接收是正常的。而每一步都是有關(guān)聯(lián)的，下一次的“響應(yīng)”是由于第一次的“請求”觸發(fā)，因此每次握手其實是可以得到額外的結(jié)論的。

比如第三次握手時，服務(wù)端收到數(shù)據(jù)包，表明看服務(wù)端只能得到客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的，但是結(jié)合第二次，說明服務(wù)端在第二次發(fā)送的響應(yīng)包，客戶端接收到了，并且作出了響應(yīng)，從而得到額外的結(jié)論：客戶端的接收、服務(wù)端的發(fā)送是正常的。

5、TCP 的四次揮手(為什么四次?)

四次揮手：

• 客戶端發(fā)送一個 FIN 段，并包含一個希望接收者看到的自己當前的序列號 K. 同時還包含一個 ACK 表示確認對方最近一次發(fā)過來的數(shù)據(jù)。
• 服務(wù)端將 K 值加 1 作為 ACK 序號值，表明收到了上一個包。這時上層的應(yīng)用程序會被告知另一端發(fā)起了關(guān)閉操作，通常這將引起應(yīng)用程序發(fā)起自己的關(guān)閉操作。
• 服務(wù)端發(fā)起自己的 FIN 段，ACK=K+1, Seq=L。
• 客戶端確認。進入 TIME-WAIT 狀態(tài)，等待 2 MSL(最大報文存活時間)后釋放連接。ACK=L+1。

為什么建立連接是三次握手，而關(guān)閉連接卻是四次揮手呢?

（1）TCP連接是雙向傳輸?shù)膶Φ鹊哪Ｊ?，就是說雙方都可以同時向?qū)Ψ桨l(fā)送或接收數(shù)據(jù)。當有一方要關(guān)閉連接時，會發(fā)送指令告知對方，我要關(guān)閉連接了。

（2）這時對方會回一個ACK，此時一個方向的連接關(guān)閉。但是另一個方向仍然可以繼續(xù)傳輸數(shù)據(jù)，也就是說，服務(wù)端收到客戶端的 FIN 標志，知道客戶端想要斷開這次連接了，但是，我服務(wù)端，我還想發(fā)數(shù)據(jù)呢?我等到發(fā)送完了所有的數(shù)據(jù)后，會發(fā)送一個 FIN 段來關(guān)閉此方向上的連接。接收方發(fā)送 ACK確認關(guān)閉連接。

注意，接收到FIN報文的一方只能回復一個ACK, 它是無法馬上返回對方一個FIN報文段的，因為結(jié)束數(shù)據(jù)傳輸?shù)?ldquo;指令”是上層應(yīng)用層給出的，我只是一個“搬運工”，我無法了解“上層的意志”。

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

（4）因為服務(wù)端在 LISTEN 狀態(tài)下，收到建立連接請求的 SYN 報文后，把 ACK 和 SYN 放在一個報文里發(fā)送給客戶端。而關(guān)閉連接時，當收到對方的 FIN 報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，己方是否現(xiàn)在關(guān)閉發(fā)送數(shù)據(jù)通道，需要上層應(yīng)用來決定，因此，己方 ACK 和 FIN 一般都會分開發(fā)。

TIME_WAIT

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

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

6、TCP 短連接和長連接的區(qū)別

短連接：Client 向 Server 發(fā)送消息，Server 回應(yīng) Client，然后一次讀寫就完成了，這時候雙方任何一個都可以發(fā)起 close 操作，不過一般都是 Client 先發(fā)起 close 操作。短連接一般只會在 Client/Server 間傳遞一次讀寫操作。

短連接的優(yōu)點：管理起來比較簡單，建立存在的連接都是有用的連接，不需要額外的控制手段。

長連接：Client 與 Server 完成一次讀寫之后，它們之間的連接并不會主動關(guān)閉，后續(xù)的讀寫操作會繼續(xù)使用這個連接。

在長連接的應(yīng)用場景下，Client 端一般不會主動關(guān)閉它們之間的連接，Client 與 Server 之間的連接如果一直不關(guān)閉的話，隨著客戶端連接越來越多，Server 壓力也越來越大，這時候 Server 端需要采取一些策略，如關(guān)閉一些長時間沒有讀寫事件發(fā)生的連接，這樣可以避免一些惡意連接導致 Server 端服務(wù)受損;如果條件再允許可以以客戶端為顆粒度，限制每個客戶端的最大長連接數(shù)，從而避免某個客戶端連累后端的服務(wù)。

長連接和短連接的產(chǎn)生在于 Client 和 Server 采取的關(guān)閉策略，具體的應(yīng)用場景采用具體的策略。

7、TCP粘包、拆包及解決辦法

為什么常說 TCP 有粘包和拆包的問題而不說 UDP ?

由前兩節(jié)可知，UDP 是基于報文發(fā)送的，UDP首部采用了 16bit 來指示 UDP 數(shù)據(jù)報文的長度，因此在應(yīng)用層能很好的將不同的數(shù)據(jù)報文區(qū)分開，從而避免粘包和拆包的問題。

而 TCP 是基于字節(jié)流的，雖然應(yīng)用層和 TCP 傳輸層之間的數(shù)據(jù)交互是大小不等的數(shù)據(jù)塊，但是 TCP 并沒有把這些數(shù)據(jù)塊區(qū)分邊界，僅僅是一連串沒有結(jié)構(gòu)的字節(jié)流;另外從 TCP 的幀結(jié)構(gòu)也可以看出，在 TCP 的首部沒有表示數(shù)據(jù)長度的字段，基于上面兩點，在使用 TCP 傳輸數(shù)據(jù)時，才有粘包或者拆包現(xiàn)象發(fā)生的可能。

什么是粘包、拆包?

假設(shè) Client 向 Server 連續(xù)發(fā)送了兩個數(shù)據(jù)包，用 packet1 和 packet2 來表示，那么服務(wù)端收到的數(shù)據(jù)可以分為三種情況，現(xiàn)列舉如下：

第一種情況，接收端正常收到兩個數(shù)據(jù)包，即沒有發(fā)生拆包和粘包的現(xiàn)象。

第二種情況，接收端只收到一個數(shù)據(jù)包，但是這一個數(shù)據(jù)包中包含了發(fā)送端發(fā)送的兩個數(shù)據(jù)包的信息，這種現(xiàn)象即為粘包。這種情況由于接收端不知道這兩個數(shù)據(jù)包的界限，所以對于接收端來說很難處理。

第三種情況，這種情況有兩種表現(xiàn)形式，如下圖。接收端收到了兩個數(shù)據(jù)包，但是這兩個數(shù)據(jù)包要么是不完整的，要么就是多出來一塊，這種情況即發(fā)生了拆包和粘包。這兩種情況如果不加特殊處理，對于接收端同樣是不好處理的。

為什么會發(fā)生 TCP 粘包、拆包?

• 要發(fā)送的數(shù)據(jù)大于 TCP 發(fā)送緩沖區(qū)剩余空間大小，將會發(fā)生拆包。
• 待發(fā)送數(shù)據(jù)大于 MSS(最大報文長度)，TCP 在傳輸前將進行拆包。
• 要發(fā)送的數(shù)據(jù)小于 TCP 發(fā)送緩沖區(qū)的大小，TCP 將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會發(fā)生粘包。
• 接收數(shù)據(jù)端的應(yīng)用層沒有及時讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包。

粘包、拆包解決辦法

由于 TCP 本身是面向字節(jié)流的，無法理解上層的業(yè)務(wù)數(shù)據(jù)，所以在底層是無法保證數(shù)據(jù)包不被拆分和重組的，這個問題只能通過上層的應(yīng)用協(xié)議棧設(shè)計來解決，根據(jù)業(yè)界的主流協(xié)議的解決方案，歸納如下：

• 消息定長：發(fā)送端將每個數(shù)據(jù)包封裝為固定長度(不夠的可以通過補 0 填充)，這樣接收端每次接收緩沖區(qū)中讀取固定長度的數(shù)據(jù)就自然而然的把每個數(shù)據(jù)包拆分開來。
• 設(shè)置消息邊界：服務(wù)端從網(wǎng)絡(luò)流中按消息邊界分離出消息內(nèi)容。在包尾增加回車換行符進行分割，例如 FTP 協(xié)議。
• 將消息分為消息頭和消息體：消息頭中包含表示消息總長度(或者消息體長度)的字段。
• 更復雜的應(yīng)用層協(xié)議比如 Netty 中實現(xiàn)的一些協(xié)議都對粘包、拆包做了很好的處理。

8、TCP 可靠傳輸

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

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

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

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

9、TCP 滑動窗口

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

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

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

10、TCP 流量控制

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

接收方發(fā)送的確認報文中的窗口字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

實際上，為了避免此問題的產(chǎn)生，發(fā)送端主機會時不時的發(fā)送一個叫做窗口探測的數(shù)據(jù)段，此數(shù)據(jù)段僅包含一個字節(jié)來獲取最新的窗口大小信息。

11、TCP 擁塞控制

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

TCP 主要通過四個算法來進行擁塞控制：

慢開始、擁塞避免、快重傳、快恢復。

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

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

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

慢開始與擁塞避免

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

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

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

快重傳與快恢復

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

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

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

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

12、提供網(wǎng)絡(luò)利用率

（1）Nagle 算法

發(fā)送端即使還有應(yīng)該發(fā)送的數(shù)據(jù)，但如果這部分數(shù)據(jù)很少的話，則進行延遲發(fā)送的一種處理機制。具體來說，就是僅在下列任意一種條件下才能發(fā)送數(shù)據(jù)。如果兩個條件都不滿足，那么暫時等待一段時間以后再進行數(shù)據(jù)發(fā)送。

• 已發(fā)送的數(shù)據(jù)都已經(jīng)收到確認應(yīng)答。
• 可以發(fā)送最大段長度的數(shù)據(jù)時。

（2）延遲確認應(yīng)答

接收方收到數(shù)據(jù)之后可以并不立即返回確認應(yīng)答，而是延遲一段時間的機制。

• 在沒有收到 2*最大段長度的數(shù)據(jù)為止不做確認應(yīng)答。
• 其他情況下，最大延遲 0.5秒 發(fā)送確認應(yīng)答。
• TCP 文件傳輸中，大多數(shù)是每兩個數(shù)據(jù)段返回一次確認應(yīng)答。

（3）捎帶應(yīng)答

在一個 TCP 包中既發(fā)送數(shù)據(jù)又發(fā)送確認應(yīng)答的一種機制，由此，網(wǎng)絡(luò)利用率會提高，計算機的負荷也會減輕，但是這種應(yīng)答必須等到應(yīng)用處理完數(shù)據(jù)并將作為回執(zhí)的數(shù)據(jù)返回為止。

今天的知識點掌握了嗎?不要忘了學而時習之，不亦可乎。

歡迎留言和我交流！

參考：

www.cnblogs.com/panchanggui/p/9518735.html

www.cnblogs.com/qcrao-2018/p/10182185.html