其余相關(guān)文章： JavaEE 網(wǎng)絡(luò)原理——TCP的工作機(jī)制(中篇 三次握手和四次揮手)

本篇文章銜接的是前面兩篇文章的內(nèi)容，在這里繼續(xù)解釋 TCP 的內(nèi)部原理。

一、滑動(dòng)窗口

我們知道，可靠性和傳輸效率是相互矛盾的。
對(duì)此，我們就需要在保證可靠性的基礎(chǔ)上，來(lái)盡可能的提高傳輸效率。(盡量降低效率的折損)

如圖所示：對(duì)于基本的確認(rèn)應(yīng)答的情況來(lái)講，每次發(fā)送一個(gè)數(shù)據(jù)，都需要進(jìn)行等待，再到 ack 到達(dá)后才會(huì)發(fā)送下一個(gè)。

因此，為了解決上述的問題，滑動(dòng)窗口就此誕生。如圖：

滑動(dòng)窗口的本質(zhì)是：不等待的批量發(fā)送一組數(shù)據(jù)，然后使用一份時(shí)間來(lái)等待著數(shù)組和多個(gè) ACK。
窗口大小： 將不需要等待，就直接可以發(fā)送的數(shù)據(jù)的最大的量，稱之為 “窗口大小”。

• 問題1
  當(dāng)批量發(fā)送窗口大小這些數(shù)據(jù)后，發(fā)送方就要等待 ack 了。
  呢么，問題來(lái)了，什么時(shí)候繼續(xù)向下發(fā)送？等待什么時(shí)候結(jié)束？

不是說(shuō)，等待到所有的 ack 到達(dá)，才能繼續(xù)向下發(fā)送，而是到一個(gè) ack ，就會(huì)繼續(xù)向下發(fā)送下一條。(此處的等待的 ack 始終是 4 條)
這里簡(jiǎn)單舉出一個(gè)例子：
假設(shè)本人當(dāng)前是一個(gè)客服的工作人員，需要對(duì)用戶的問題進(jìn)行逐一的回答。(本人只能一次和 4 個(gè)用戶進(jìn)行溝通)
簡(jiǎn)單分析：
此處，這里的 4 就是窗口大小。
是將這里的 4 個(gè)客戶都解決完畢后，才繼續(xù)后面的 4 個(gè)客戶嗎？ 很顯然這里不是這樣的！！！
而是在這 4 個(gè)客戶中，只要有一個(gè)客戶的問題解決后，就可以開啟和下一個(gè)客戶交流了。(始終是同時(shí)在和 4 個(gè)客戶聊天)

具體情況如圖：

如上圖所示，本來(lái)等待 ack 是 1001 - 5000.
接下來(lái)，收到了 2001 這個(gè) ack，此時(shí)說(shuō)明 2001 之前的數(shù)據(jù) (1001 - 2000) 已經(jīng)被確認(rèn)了。
此時(shí)就可以立即發(fā)送 5001 - 6000 的數(shù)據(jù)，此時(shí)意味著等待 ack 的范圍就是 2001 - 6000。

• 問題 2
  在滑動(dòng)窗口的情況下，此時(shí)，出現(xiàn)丟包的情況該怎么辦？

情況1：返回的 ack 丟失了。

其實(shí)，對(duì)于這樣的情況，不需要去做任何的處理，問題不大。
關(guān)鍵需要理解的要點(diǎn)在于 確認(rèn)序號(hào) 的含義。
這里的 “確認(rèn)序號(hào)” 所表示的是該序號(hào)向前的所有數(shù)據(jù)都已經(jīng)確認(rèn)送達(dá)了。
也就是說(shuō)，這里的 1001 返回的 ack 雖然丟失，但是后面的 2001 處返回的 ack 實(shí)際上涵蓋了前面從 1 - 1001 處的 ack 信息。

情況2：數(shù)據(jù)丟失

如上圖所示，1001 - 2000 在傳輸時(shí)出現(xiàn)丟包情況。在接下來(lái)的 2001 - 3000 到達(dá)主機(jī) B 之后，由 B 給 A 返回的 ACK 確認(rèn)序號(hào)仍然是 1001. (此時(shí)和你發(fā)送過來(lái)的這個(gè)數(shù)據(jù)號(hào)是什么，關(guān)系已經(jīng)不大了。)

這里的意思就是在索要 1001 開頭的數(shù)據(jù)。

在這里，對(duì)此處的丟包重傳方式起了一個(gè)新的名字，叫做 “快速重傳”(重傳操作只是重傳了丟失的數(shù)據(jù))。
這里的重傳機(jī)制可以視為是超時(shí)重傳機(jī)制在滑動(dòng)窗口下的變形。
注：如果此處的傳輸數(shù)據(jù)比較密集，就按照滑動(dòng)窗口的方式來(lái)傳輸。
如果此處的傳輸數(shù)據(jù)比較稀疏，就不在按照滑動(dòng)窗口的方式了，此時(shí)就還按照之前的超時(shí)重傳的形式來(lái)處理丟包。

快速重傳中的問題

1. 有關(guān)補(bǔ)發(fā)數(shù)據(jù)是否會(huì)出現(xiàn)數(shù)據(jù)順序混亂的情況。
   解釋： 這個(gè)問題并不復(fù)雜，TCP 中有一個(gè)接收緩沖區(qū)，在緩沖區(qū)中會(huì)對(duì)數(shù)據(jù)按照序號(hào)進(jìn)行重新排隊(duì)。
2. 以上面圖片中的情況為例，假設(shè)此時(shí)在 2001 - 7001 之間有丟失了一組，此時(shí)的情況該是怎樣？
   解釋： 這里其實(shí)也不難理解，當(dāng) 主機(jī) B 接受到 1001 - 2000 后，就會(huì)再次按順序向后索取缺少的其他范圍的數(shù)據(jù)。

二、流量控制

流量控制作用： 這是一種干預(yù)發(fā)送窗口大小的機(jī)制。
在上面的一個(gè)要點(diǎn)中，我向大家講解了 滑動(dòng)窗口。對(duì)于滑動(dòng)窗口，窗口越大，傳輸?shù)男示蜁?huì)越高。(也就是說(shuō)，在一份時(shí)間中，等待的 ACK 就越多)。
但是，窗口的大小也不能無(wú)限大！！！

可能出現(xiàn)的問題如下：

1. 完全不等待 ack ，在可靠性能否保障畫上問號(hào)。
2. 窗口太大，也會(huì)消耗大量的系統(tǒng)資源。
3. 發(fā)送的速度太快，接受方處理不過來(lái)，發(fā)了也沒什么用。。。

其實(shí)，綜上所述，接受方的處理能力，就是一個(gè)很重要的約束依據(jù)。發(fā)送方的速度，不能超出接受方的處理能力！

流量控制，要做的工作就是這個(gè)。根據(jù)接受方的處理能力，協(xié)調(diào)發(fā)送方的發(fā)送速率。

所以，如何衡量接收方的處理能力 就是這里的關(guān)鍵所在。

解釋： 如何衡量接受方的處理能力。

這里有一個(gè)最簡(jiǎn)單直接的方法，直接觀察接收方的緩沖區(qū)剩余大小。

如上圖所示，每次 A 給 B 發(fā)送個(gè)數(shù)據(jù)。
B 就需要計(jì)算下一個(gè)水池中的剩余空間，然后將這個(gè)值通過 ack 報(bào)文返回給 A
A 此時(shí)就根據(jù)這個(gè)值來(lái)決定接下來(lái)發(fā)送的速率是多少。(窗口大小是多少)

通過上圖所示，窗口大小就指的是 16 位窗口大小。
但是，這里是否就意味著，窗口大小最大是 64kb？答案顯然不是這樣的！TCP 為了讓窗口更大，在選項(xiàng)部分，引入了窗口拓展因子。

解釋： 窗口拓展因子如何作用。

假設(shè)： 此時(shí)，窗口大小已經(jīng)是 64kb。在拓展因子中寫入 2.
這里的意思就是讓 64kb << 2 ——> 256 kb

所以，通過上面的分析我們可以知道，接受緩沖區(qū)一直是在動(dòng)態(tài)變化的，所以，對(duì)應(yīng)的每次返回的 ack 攜帶的窗口大小也在變化。對(duì)此，發(fā)送方也是在不斷的動(dòng)態(tài)調(diào)整的！！！

特殊情況： 當(dāng)窗口的大小為 0 時(shí)。
此時(shí)，發(fā)送方就會(huì)暫停發(fā)送，在暫停發(fā)送的等待過程中，會(huì)給 B 定期發(fā)送窗口探測(cè)報(bào)文。這個(gè)報(bào)文不會(huì)攜帶任何的具體業(yè)務(wù)數(shù)據(jù)，只是為了觸發(fā) ack 查詢窗口大小。

三、擁堵控制

這里的擁堵控制，與前面向大家解釋的流量控制共同決定發(fā)送方的窗口大小的多少。

這里描述的 “發(fā)送發(fā)窗口大小” 是通過 接收方 的 ack 報(bào)文中的 窗口大小字段。是從 接收方 告訴給 發(fā)送方 的！

流量控制： 考慮的是接收方的處理能力。
擁塞控制： 考慮的是傳輸過程中，中間節(jié)點(diǎn)的處理能力。

形如上圖所示，對(duì)于兩臺(tái)主機(jī) A，B 兩者之間傳遞數(shù)據(jù)，是需要在中間經(jīng)過多臺(tái)設(shè)備的。

對(duì)于接受方的處理能力，是比較好量化衡量的。但是 中間節(jié)點(diǎn) ，不好衡量。

因此，為了解決這個(gè)問題，設(shè)計(jì) TCP 的大佬們想出了一個(gè)非常天才的方法。
既然不好直接量化，呢么就可以通過 “實(shí)驗(yàn)” 的方式來(lái)測(cè)試出一個(gè)合適的值。

解釋： 如何通過測(cè)試獲取合適的值。

如上圖所示，這里的 “擁塞窗口” 表述的是，不斷嘗試要以多大的窗口進(jìn)行發(fā)送。
初始階段： 由于初始窗口比較小(從1開始)，此時(shí)每一輪的不丟包，都會(huì)使窗口大小擴(kuò)大一倍(指數(shù)增長(zhǎng))。
中間階段： 當(dāng)增長(zhǎng)率到達(dá)閾值時(shí)，此時(shí)的指數(shù)增長(zhǎng)就會(huì)變成線性增長(zhǎng)。(注意，這里增長(zhǎng)的前提是不丟包)
調(diào)整階段： 當(dāng)傳輸過程中一但產(chǎn)生丟包，呢么說(shuō)明此時(shí)，發(fā)送的速率已經(jīng)接近網(wǎng)絡(luò)的極限。此時(shí)，一下子就會(huì)把窗口大小縮成很小的值。(并且重復(fù)前面的指數(shù)增長(zhǎng)和線性增長(zhǎng)的過程)
通過上面的分析，可以的出一個(gè)結(jié)論：
擁塞窗口不是一個(gè)固定的數(shù)值，而是一直動(dòng)態(tài)變化的。隨著時(shí)間的推移，逐漸達(dá)到一個(gè)平衡的過程。

上面的動(dòng)態(tài)處理，即可以把問題解決，同時(shí)也可以隨著網(wǎng)絡(luò)情況的變化而變化。

四、延時(shí)應(yīng)答

延時(shí)應(yīng)答，在這里也是一個(gè)為了提高效率的機(jī)制。
這個(gè)機(jī)制，也就是對(duì)滑動(dòng)窗口進(jìn)行補(bǔ)充。

滑動(dòng)窗口的關(guān)鍵，就是讓窗口的大小大一點(diǎn)，傳輸?shù)乃俣染涂煲稽c(diǎn)。
因此，需要做的就是，在接收方能夠處理的了的前提下，盡可能將窗口的大小放大。

延時(shí)應(yīng)答，就是在接受數(shù)據(jù)后，不是立即返回 ACK 而是稍等一會(huì)在返回。
在這個(gè)等待的時(shí)間中，接受方的應(yīng)用程序，就可以將緩沖區(qū)的數(shù)據(jù)進(jìn)行一波消費(fèi)，此時(shí)剩余的空間不就變大了一點(diǎn)。。。
如圖：

這里表現(xiàn)出的延時(shí)應(yīng)答方式，就是在滑動(dòng)窗口下。ACK 不在對(duì)每一條數(shù)據(jù)進(jìn)行返回，比如隔一個(gè)返回一次。

五、捎帶應(yīng)答

捎帶應(yīng)答也是提高效率的一種方式。
捎帶應(yīng)答的引入，是在延時(shí)應(yīng)答的基礎(chǔ)之上的。

我們已經(jīng)知道，服務(wù)器客戶端程序，最典型的模型就是 “一問一答”。
如圖：

從上圖可以看出，這兩個(gè)信息根本就是不同時(shí)機(jī)產(chǎn)生，不同時(shí)機(jī)發(fā)送。

捎帶應(yīng)答，就是在這兩條信息中進(jìn)行動(dòng)作的。
在之前的延時(shí)應(yīng)答機(jī)制中，因?yàn)橐却彌_區(qū)中的數(shù)據(jù)消費(fèi)。所以，就會(huì)導(dǎo)致在等待 ACK 的過程中，B 就要向 A 發(fā)送業(yè)務(wù)數(shù)據(jù)了。呢么此時(shí)，就可以讓這個(gè)業(yè)務(wù)數(shù)據(jù) 捎帶著 ACK 一并發(fā)送過去 即可。
如圖：

注意：
這里要說(shuō)的是，“合并發(fā)送” 這個(gè)事情是成立的，并不是說(shuō)有了 “捎帶應(yīng)答” 就一定會(huì)合并。
而 “延時(shí)應(yīng)答” 則是提高了合并的概率。

六、面向字節(jié)流

當(dāng)數(shù)據(jù)面向字節(jié)流時(shí)，此時(shí)，在這里就引入了一個(gè)比較麻煩的事—— 粘包問題。

在前面的說(shuō)明中，我們已經(jīng)知道了一個(gè)名詞 “接收緩沖區(qū)”。
在上圖中的多次交互中，其實(shí)所有的交互信息都會(huì)被存入到 接受緩沖區(qū) 中，這里的多個(gè)數(shù)據(jù)都會(huì)被放到一起。
呢么，問題來(lái)了。
此時(shí)應(yīng)用程序在 read 讀取的時(shí)候，讀取到哪里才算是一個(gè)完整的應(yīng)用層數(shù)據(jù)報(bào)呢？

如上圖所示，我們大家都知道，糯米團(tuán)子的粘度是很大的。想要單獨(dú)拿出來(lái)一個(gè)，很容易就會(huì)出現(xiàn)粘連的情況。

TCP 是字節(jié)流的。
一次讀取一個(gè)字節(jié)，讀取 N 個(gè)字節(jié)，都是可以的。
在這樣的情況下，一次讀取的是半個(gè)數(shù)據(jù)報(bào)，或整個(gè)數(shù)據(jù)報(bào)，或多個(gè)數(shù)據(jù)報(bào)的情況都是存在的！

解釋： 描述 “粘包” 具體情況。

以上圖的情況為例，應(yīng)用程序調(diào)用 read
如果 read 的是 7 個(gè)字節(jié)，此時(shí)正好讀出的是 aaaaaaa ，這就是一個(gè)完整的數(shù)據(jù)報(bào)。
如果 read 的是 8 個(gè)字節(jié)，此時(shí)讀到的就是 aaaaaaab ，讀到的就是 “一個(gè)半” 數(shù)據(jù)。
如果 read 的是 6 個(gè)字節(jié)，此時(shí)讀到的是 aaaaaa ，讀到的就是 半個(gè)數(shù)據(jù)報(bào)。

綜上所述，粘包問題的影響還是比較大的。
但是，還有一個(gè)更令人悲傷的故事。。。
在 TCP 層次，沒有在 socket api 中告訴我們應(yīng)該讀取幾個(gè)字節(jié)。具體要怎么讀，完全是程序員自己負(fù)責(zé)。

我們肯定是想讀到的是一個(gè)完整的一個(gè)數(shù)據(jù)報(bào)。
解決問題的方法其實(shí)也非常簡(jiǎn)單，只需要在應(yīng)用層中約定好應(yīng)用層協(xié)議即可。
尤其是要明確應(yīng)用層數(shù)據(jù)報(bào)之間的邊界就好。

約定的條件有下面的兩條：
1.約定好分隔符。
2.約定好每個(gè)包的長(zhǎng)度。

七、異常情況

對(duì)于異常情況，直接說(shuō)明就是在傳輸過程中出現(xiàn)了不可抗力。

對(duì)于不可抗力大概有下面幾點(diǎn)情況：

1 進(jìn)程崩潰
2.主機(jī)關(guān)機(jī)(按照正常流程關(guān)機(jī))
3.主機(jī)斷電
4.網(wǎng)線斷開

這里我們將上述情況分為下面兩部分：

• 情況 1 和 2
  針對(duì)這兩種情況，直接對(duì)應(yīng)的是進(jìn)程沒了。
  （1）在 進(jìn)程崩潰 情況下，對(duì)應(yīng)的 PCB 也就沒了，對(duì)應(yīng)的文件描述符表也就釋放了。相當(dāng)于 socket.close()。 此時(shí)內(nèi)核會(huì)繼續(xù)完成四次揮手。其實(shí)仍然是一個(gè)正常斷開的流程。
  （2）對(duì)于 主機(jī)關(guān)機(jī) 主機(jī)關(guān)機(jī)要先殺進(jìn)程，然后才會(huì)正常關(guān)機(jī)。(在殺死進(jìn)程的過程中，也和上面一樣會(huì)觸發(fā)四次揮手)。

• 情況 3 和 4
  針對(duì)這兩個(gè)情況顯然是來(lái)不及揮手了
  （3）對(duì)于 主機(jī)掉電 在這里可以分為兩類情況。
  假設(shè) 接受方 掉電
  發(fā)送方 仍然在繼續(xù)發(fā)送數(shù)據(jù)，發(fā)送完需要等待 ack ，但是 ack 始終等不到。。。
  超時(shí)重傳在怎么重傳，也收不到 ack。。。
  在重傳幾次后，仍然沒有應(yīng)答，此時(shí)嘗試嘗試重置 TCP 的連接。但是很顯然這個(gè)重置也會(huì)失敗。
  最終只能放棄連接(單方面放棄)。
  如果是 發(fā)送方 掉電
  接受方 發(fā)現(xiàn)，沒數(shù)據(jù)了。此時(shí)接受方還不知道發(fā)送方是一個(gè)什么情況。(此時(shí)，接收方能做的事就只有一件，等待！)
  在等待一段時(shí)間后，接收方 會(huì)周期性的向 發(fā)送方 發(fā)送一個(gè)消息。來(lái)確認(rèn)對(duì)方是否還在正常工作。

接受方周期性的發(fā)送信息，在這里有一個(gè)更加形象的名字 心跳包。
1.心跳，是一個(gè)周期性的。
2.如果心跳無(wú)了，呢么就說(shuō)明掛了
在這里也就是通過心跳包來(lái)確認(rèn)通信雙方是否處在一個(gè)正常的工作狀態(tài)中。。

八、總結(jié)

到此，本人使用了長(zhǎng)達(dá)三篇文章對(duì) TCP 中最重要的十個(gè)特性進(jìn)行了描述。但是這里的學(xué)習(xí)仍然任重道遠(yuǎn)。還需要反復(fù)的思考琢磨來(lái)達(dá)到更清晰的理解。

碼子不易，您小小的點(diǎn)贊是對(duì)我最大的鼓勵(lì)！！！