目錄：

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

2、UDP 、TCP 首部格式

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

4、TCP 的三次握手（為什么三次？）

5、TCP 的四次揮手（為什么四次？）

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

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

8、TCP 可靠傳輸

9、TCP 滑動(dòng)窗口

10、TCP 流量控制

11、TCP 擁塞控制

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

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

（1）TCP：傳輸控制協(xié)議（Transmission Control Protocol)（類似打電話）

是面向連接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通信，面向字節(jié)流（把應(yīng)用層傳下來(lái)的報(bào)文看成字節(jié)流，把字節(jié)流組織成大小不等的數(shù)據(jù)塊），每一條 TCP 連接只能是點(diǎn)對(duì)點(diǎn)的（一對(duì)一）。

（2）UDP：用戶數(shù)據(jù)報(bào)協(xié)議 （User Datagram Protocol）（類似發(fā)短信）

是無(wú)連接的，盡最大可能交付，沒(méi)有擁塞控制，面向報(bào)文（對(duì)于應(yīng)用程序傳下來(lái)的報(bào)文不合并也不拆分，只是添加 UDP 首部），支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的交互通信。

2、UDP 、TCP 首部格式

（1）UDP 的格式：

UDP首部字段只有 8 個(gè)字節(jié)，包括源端口、目的端口、長(zhǎng)度、檢驗(yàn)和。12 字節(jié)的偽首部是為了計(jì)算檢驗(yàn)和臨時(shí)添加的。

（2）TCP 首部格式比 UDP 復(fù)雜。

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

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

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

控制位：八位從左到右分別是 CWR，ECE，URG，ACK，PSH，RST，SYN，FIN。

CWR：CWR 標(biāo)志與后面的 ECE 標(biāo)志都用于 IP 首部的 ECN 字段，ECE 標(biāo)志為 1 時(shí)，則通知對(duì)方已將擁塞窗口縮小；

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

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

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

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

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

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

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

每個(gè)主機(jī)又對(duì)對(duì)方的 FIN 包進(jìn)行確認(rèn)應(yīng)答之后可以斷開連接。不過(guò)，主機(jī)收到 FIN 設(shè)置為 1 的 TCP 段之后不必馬上回復(fù)一個(gè) FIN 包，而是可以等到緩沖區(qū)中的所有數(shù)據(jù)都因?yàn)橐殉晒Πl(fā)送而被自動(dòng)刪除之后再發(fā) FIN 包；

窗口：窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。之所以要有這個(gè)限制，是因?yàn)榻邮辗降臄?shù)據(jù)緩存空間是有限的。

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

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

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

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

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

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

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

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

（8）序列號(hào)的作用是使得一個(gè) TCP 接收端可丟棄重復(fù)的報(bào)文段，記錄以雜亂次序到達(dá)的報(bào)文段。因?yàn)?TCP 使用 IP 來(lái)傳輸報(bào)文段，而IP 不提供重復(fù)消除或者保證次序正確的功能。

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

4、TCP 的三次握手（為什么三次？）

三次握手：

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

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

• A 向 B 發(fā)送連接請(qǐng)求報(bào)文，SYN=1，ACK=0，選擇一個(gè)初始的序號(hào) x。

• B 收到連接請(qǐng)求報(bào)文，如果同意建立連接，則向 A 發(fā)送連接確認(rèn)報(bào)文，SYN=1，ACK=1，確認(rèn)號(hào)為 x+1，同時(shí)也選擇一個(gè)初始的序號(hào) y。

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

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

為什么三次？

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

2、換個(gè)易于理解的視角來(lái)看為什么要 3 次握手。

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

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

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

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

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

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

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

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

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

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

（1）【SYN】SEQ:1000，ACK：-

SEQ為1000, ACK為空：現(xiàn)在傳遞數(shù)據(jù)包序號(hào)為1000，如果接收無(wú)誤，請(qǐng)通知我向您傳遞1001號(hào)數(shù)據(jù)包；（首次請(qǐng)求連接時(shí)使用的消息，稱為SYN：表示收發(fā)數(shù)據(jù)前傳遞的同步消息）

（2）【SYN+ACK】：SEQ:2000，ACK：1001

SEQ為2000：現(xiàn)在傳遞數(shù)據(jù)包序號(hào)為2000，如果接收無(wú)誤，請(qǐng)通知我向您傳遞2001號(hào)數(shù)據(jù)包；

ACK為1001：剛才傳輸?shù)腟EQ為1000的數(shù)據(jù)包接收無(wú)誤，現(xiàn)在請(qǐng)傳遞SEQ為1001的數(shù)據(jù)包；

（3）【ACK】：SEQ:1001，ACK：2001

SEQ為1001：已正確收到傳輸?shù)腟EQ為2000的數(shù)據(jù)包，現(xiàn)在請(qǐng)傳遞SEQ為2001的數(shù)據(jù)包；

5、TCP 的四次揮手（為什么四次？）

四次揮手：

• 客戶端發(fā)送一個(gè) FIN 段，并包含一個(gè)希望接收者看到的自己當(dāng)前的序列號(hào) K. 同時(shí)還包含一個(gè) ACK 表示確認(rèn)對(duì)方最近一次發(fā)過(guò)來(lái)的數(shù)據(jù)。

• 服務(wù)端將 K 值加 1 作為 ACK 序號(hào)值，表明收到了上一個(gè)包。這時(shí)上層的應(yīng)用程序會(huì)被告知另一端發(fā)起了關(guān)閉操作，通常這將引起應(yīng)用程序發(fā)起自己的關(guān)閉操作。

• 服務(wù)端發(fā)起自己的 FIN 段，ACK=K+1, Seq=L。

• 客戶端確認(rèn)。進(jìn)入 TIME-WAIT 狀態(tài)，等待 2 MSL（最大報(bào)文存活時(shí)間）后釋放連接。ACK=L+1。

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

1、TCP連接是雙向傳輸?shù)膶?duì)等的模式，就是說(shuō)雙方都可以同時(shí)向?qū)Ψ桨l(fā)送或接收數(shù)據(jù)。當(dāng)有一方要關(guān)閉連接時(shí)，會(huì)發(fā)送指令告知對(duì)方，我要關(guān)閉連接了。

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

注意，接收到FIN報(bào)文的一方只能回復(fù)一個(gè)ACK, 它是無(wú)法馬上返回對(duì)方一個(gè)FIN報(bào)文段的，因?yàn)榻Y(jié)束數(shù)據(jù)傳輸?shù)摹爸噶睢笔巧蠈討?yīng)用層給出的，我只是一個(gè)“搬運(yùn)工”，我無(wú)法了解“上層的意志”。

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

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

TIME_WAIT

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

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

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

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

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

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

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

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

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

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

（1）為什么常說(shuō) TCP 有粘包和拆包的問(wèn)題而不說(shuō) UDP ？

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

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

（2）什么是粘包、拆包？

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

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

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

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

（3）為什么會(huì)發(fā)生 TCP 粘包、拆包？

• 要發(fā)送的數(shù)據(jù)大于 TCP 發(fā)送緩沖區(qū)剩余空間大小，將會(huì)發(fā)生拆包。

• 待發(fā)送數(shù)據(jù)大于 MSS（最大報(bào)文長(zhǎng)度），TCP 在傳輸前將進(jìn)行拆包。

• 要發(fā)送的數(shù)據(jù)小于 TCP 發(fā)送緩沖區(qū)的大小，TCP 將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會(huì)發(fā)生粘包。

• 接收數(shù)據(jù)端的應(yīng)用層沒(méi)有及時(shí)讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包。

（4）粘包、拆包解決辦法

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

• 消息定長(zhǎng)：發(fā)送端將每個(gè)數(shù)據(jù)包封裝為固定長(zhǎng)度（不夠的可以通過(guò)補(bǔ) 0 填充），這樣接收端每次接收緩沖區(qū)中讀取固定長(zhǎng)度的數(shù)據(jù)就自然而然的把每個(gè)數(shù)據(jù)包拆分開來(lái)。

• 設(shè)置消息邊界：服務(wù)端從網(wǎng)絡(luò)流中按消息邊界分離出消息內(nèi)容。在包尾增加回車換行符進(jìn)行分割，例如 FTP 協(xié)議。

• 將消息分為消息頭和消息體：消息頭中包含表示消息總長(zhǎng)度（或者消息體長(zhǎng)度）的字段。

• 更復(fù)雜的應(yīng)用層協(xié)議比如 Netty 中實(shí)現(xiàn)的一些協(xié)議都對(duì)粘包、拆包做了很好的處理。

8、TCP 可靠傳輸

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

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

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

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

9、TCP 滑動(dòng)窗口

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

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

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

10、TCP 流量控制

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

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

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

11、TCP 擁塞控制

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

TCP 主要通過(guò)四個(gè)算法來(lái)進(jìn)行擁塞控制：

慢開始、擁塞避免、快重傳、快恢復(fù)。

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

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

• 接收方有足夠大的接收緩存，因此不會(huì)發(fā)生流量控制；

• 雖然 TCP 的窗口基于字節(jié)，但是這里設(shè)窗口的大小單位為報(bào)文段。

慢開始與擁塞避免

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

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

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

快重傳與快恢復(fù)

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

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

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

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

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

1、Nagle 算法

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

• 已發(fā)送的數(shù)據(jù)都已經(jīng)收到確認(rèn)應(yīng)答。

• 可以發(fā)送最大段長(zhǎng)度的數(shù)據(jù)時(shí)。

2、延遲確認(rèn)應(yīng)答

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

• 在沒(méi)有收到 2*最大段長(zhǎng)度的數(shù)據(jù)為止不做確認(rèn)應(yīng)答。

• 其他情況下，最大延遲 0.5秒 發(fā)送確認(rèn)應(yīng)答。

• TCP 文件傳輸中，大多數(shù)是每?jī)蓚€(gè)數(shù)據(jù)段返回一次確認(rèn)應(yīng)答。

3、捎帶應(yīng)答

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