1. 滑動窗口（效率機(jī)制）

TCP 使用 確認(rèn)應(yīng)答 策略，對每一個(gè)發(fā)送的數(shù)據(jù)段，都要給一個(gè) ACK 確認(rèn)應(yīng)答。收到 ACK 后再發(fā)送下一個(gè)數(shù)據(jù)段。這樣做有一個(gè)比較大的缺點(diǎn)，就是性能較差。尤其是數(shù)據(jù)往返的時(shí)間較長的時(shí)候。

既然這樣一發(fā)一收的方式性能較低，那么我們一次發(fā)送多條數(shù)據(jù)，使用滑動窗口，就可以大大的提高性能（其實(shí)是將多個(gè)段的等待時(shí)間重疊在一起了）。
滑動窗口存在的意義就是在保證可靠性的前提下，盡量提高效率。

• 窗口大小指的是無需等待確認(rèn)應(yīng)答而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。上圖的窗口大小就是 4000 個(gè)字節(jié)（四個(gè)段）。
• 發(fā)送前四個(gè)段的時(shí)候，不需要等待任何 ACK，直接發(fā)送；
• 收到第一個(gè) ACK 后，滑動窗口向后移動，繼續(xù)發(fā)送第五個(gè)段的數(shù)據(jù)；依次類推；
  （相當(dāng)于一份等待時(shí)間等待多份 ACK， 當(dāng)然不能不等，可靠傳輸?shù)撵`魂就是確認(rèn)應(yīng)答， 若沒有 ACK，可靠傳輸就形同虛設(shè)。）
• 操作系統(tǒng)內(nèi)核為了維護(hù)這個(gè)滑動窗口，需要開辟 發(fā)送緩沖區(qū) 來記錄當(dāng)前還有哪些數(shù)據(jù)沒有應(yīng)答；只有確認(rèn)應(yīng)答過的數(shù)據(jù)，才能從緩沖區(qū)刪掉；
• 在一定范圍內(nèi)，窗口越大，傳輸速率就越快，網(wǎng)絡(luò)的吞吐率就越高

那么如果出現(xiàn)了丟包，如何進(jìn)行重傳？這里分兩種情況討論。

• 情況一：數(shù)據(jù)包已經(jīng)抵達(dá)，ACK 被丟了。

這種情況下，部分 ACK 丟了并不要緊，因?yàn)榭梢酝ㄟ^后續(xù)的ACK進(jìn)行確認(rèn).
ACK 的確認(rèn)號有特定含義，保證后一條 ACK 覆蓋前一條，
比如并沒有收到 1001 ACK, 但是收到了 2001 ACK 就說明 2001 之前的數(shù)據(jù)全部已經(jīng)收到了。
若發(fā)送 4001 ~ 5000 之前，只收到了 4001, 但是它的意思是，4001 之前的都收到了，窗口就可以一次往下挪動 4 個(gè)。

• 情況二：數(shù)據(jù)包就直接丟了。

• 當(dāng)某一段報(bào)文段丟失之后，發(fā)送端會一直收到 1001 這樣的 ACK，就像是在提醒發(fā)送端 “我想要的是 1001” 一樣；
• 如果發(fā)送端主機(jī)連續(xù)三次收到了同樣一個(gè) “1001” 這樣的應(yīng)答，就會將對應(yīng)的數(shù)據(jù) 1001 - 2000 重新發(fā)送；
• 這個(gè)時(shí)候接收端收到了 1001 之后，再次返回的 ACK 就是 7001 了（因?yàn)?001 - 7000）接收端其實(shí)之前就已經(jīng)收到了，被放到了接收端操作系統(tǒng)內(nèi)核的接收緩沖區(qū)中；
  （重傳只需要把丟的數(shù)據(jù)重傳就行了，后面已經(jīng)傳過的數(shù)據(jù)不用再傳了。）

這種機(jī)制被稱為 “高速重發(fā)控制”（也叫 “快重傳”）。
（為什么說是 “快” 重傳，因?yàn)榭赡苁盏饺齻€(gè)連續(xù)相同的 ACK 的時(shí)間內(nèi)還沒有觸發(fā)超時(shí)機(jī)制，也就是還沒超時(shí)呢，但是不等觸發(fā)超時(shí)，直接就重傳了。）

2. 流量控制（安全機(jī)制）

流量控制是滑動窗口的延伸，目的是為了保證可靠性。

• 在一定范圍內(nèi)，滑動窗口越大傳輸效率就越高，但是不能只考慮發(fā)送方，不考慮接收方，
• 接收端處理數(shù)據(jù)的速度是有限的。如果發(fā)送端發(fā)的太快，導(dǎo)致接收端的緩沖區(qū)被打滿，這個(gè)時(shí)候如果發(fā)送端繼續(xù)發(fā)送，就會造成丟包，繼而引起丟包重傳等等一系列連鎖反應(yīng)。

因此 TCP 支持根據(jù)接收端的處理能力，來決定發(fā)送端的發(fā)送速度。這個(gè)機(jī)制就叫做流量控制（Flow Control）；

• 接收端將自己可以接收的緩沖區(qū)大小放入 TCP 首部中的 “窗口大小” 字段，通過 ACK 端通知發(fā)送端；
• 發(fā)送方接收到這個(gè)這個(gè)數(shù)據(jù)后，就會靈活的調(diào)整發(fā)送速度，調(diào)整窗口大小
• 窗口大小字段越大，說明網(wǎng)絡(luò)的吞吐量越高；
• 接收端一旦發(fā)現(xiàn)自己的緩沖區(qū)快滿了，就會將窗口大小設(shè)置成一個(gè)更小的值通知給發(fā)送端；
• 發(fā)送端接受到這個(gè)窗口之后，就會減慢自己的發(fā)送速度；
• 如果接收端緩沖區(qū)滿了，就會將窗口置為 0；
• 這時(shí)發(fā)送方不再發(fā)送數(shù)據(jù)，但是需要定期發(fā)送一個(gè)窗口探測數(shù)據(jù)段，使接收端把窗口大小告訴發(fā)送端。

• 接收端如何把窗口大小告訴發(fā)送端呢？
  回憶我們的 TCP 首部中，有一個(gè)16 位窗口字段，就是存放了窗口大小信息；

• 那么問題來了，16 位數(shù)字最大表示 65535，那么 TCP 窗口最大就是 65535 字節(jié)么？
  實(shí)際上，TCP 首部40字節(jié)選項(xiàng)中還包含了一個(gè)窗口擴(kuò)大因子 M，實(shí)際窗口大小是 窗口字段的值左移 M 位即 65535 * 2 ^M

3. 擁塞控制（安全機(jī)制）

擁塞控制，也是滑動窗口的延伸，限制滑動窗口的發(fā)送速率。
擁塞控制描述的是發(fā)送方到接收方整個(gè)鏈路直接的擁堵情況。

• 最終的滑動窗口的大小 = Min (流量控制窗口，擁塞控制窗口)

雖然TCP有了滑動窗口這個(gè)大殺器，能夠高效可靠的發(fā)送大量的數(shù)據(jù)。
但是如果在剛開始階段就發(fā)送大量的數(shù)據(jù)，仍然可能引發(fā)問題。
因?yàn)榫W(wǎng)絡(luò)上有很多的計(jì)算機(jī)，可能當(dāng)前的網(wǎng)絡(luò)狀態(tài)就已經(jīng)比較擁堵。在不清楚當(dāng)前網(wǎng)絡(luò)狀態(tài)下，貿(mào)然發(fā)送大量的數(shù)據(jù)，是很有可能引起雪上加霜的。

• 發(fā)送方開始時(shí)以一個(gè)較小的窗口來發(fā)送數(shù)據(jù)，
• 若數(shù)據(jù)很流暢到達(dá)，就逐漸加大窗口大小，
• 若加大到一定程度出現(xiàn)丟包，就減小窗口，
• 通過反復(fù)的增大/減小過程，逐漸找到一個(gè)合適的范圍，擁塞窗口就在這個(gè)范圍中不斷變化，達(dá)到一個(gè) “動態(tài)平衡”。

具體擁塞窗口是怎么變化的呢 ？

1. 慢開始
   初始值 窗口大小為 1， 然后以指數(shù)級別增長，“慢開始” 只是指初使時(shí)慢，但是增長速度非?？?。
2. 擁塞避免
   窗口值到達(dá) ssthresh 時(shí)，從指數(shù)增長變?yōu)?線性增長。
3. 網(wǎng)絡(luò)擁塞
   出現(xiàn)大量丟包情況，說明網(wǎng)絡(luò)擁塞了，擁塞窗口大小直接變?yōu)?1 。ssthresh 閾值變?yōu)榇藭r(shí)擁塞窗口大小的一半，圖中就是從 變?yōu)?24 的一半 12 。
   （少量的丟包，我們僅僅是觸發(fā)超時(shí)重傳；大量的丟包，我們就認(rèn)為網(wǎng)絡(luò)擁塞；）
4. 然后重新慢開始，循環(huán)這個(gè)過程。

當(dāng)TCP通信開始后，網(wǎng)絡(luò)吞吐量會逐漸上升；隨著網(wǎng)絡(luò)發(fā)生擁堵，吞吐量會立刻下降；

• 為什么使用指數(shù)級別的增長速度 ？
  因?yàn)橄Ｍ芸焖俳咏?ssthresh 閾值, 既希望速度快，又希望不大量丟包，如果初始情況給的窗口大小很小，可能合適的值是個(gè)很大的值，那么使用指數(shù)增長的話，能夠很快的接近這個(gè)值。

• ssthresh 的意義 ？
  決定了什么時(shí)候從指數(shù)增長變?yōu)榫€性增長

• 擁塞窗口最理想的大小 ？
  ssthresh 值與 出現(xiàn)擁塞的這個(gè)值之間是最理想的效果，這個(gè)范圍之間傳輸速率較快，并且沒有大量丟包。

• 為什么出現(xiàn)擁塞時(shí)，直接讓窗口變?yōu)槌跏贾?1 ？
  因?yàn)榫W(wǎng)絡(luò)的情況很復(fù)雜，不穩(wěn)定，如果出現(xiàn)大量丟包，很可能速度降下來一點(diǎn)是不能解決問題的，速度降得太慢還會有可能出現(xiàn)持續(xù)丟包，就會對網(wǎng)絡(luò)質(zhì)量帶來很大影響，一下讓窗口變得很小，就是期望這次傳輸一定能成功。

擁塞控制，歸根結(jié)底是TCP協(xié)議想盡可能快的把數(shù)據(jù)傳輸給對方，但是又要避免給網(wǎng)絡(luò)造成太大壓力的折中方案。

常見面試題：

1. UDP 本身是無連接，不可靠，面向數(shù)據(jù)報(bào)的協(xié)議，如果要基于傳輸層UDP協(xié)議，來實(shí)現(xiàn)一個(gè)可靠傳輸，應(yīng)該如何設(shè)計(jì)？
2. UDP 大小是受限的，如果要基于傳輸層UDP協(xié)議，傳輸超過64K的數(shù)據(jù)，應(yīng)該如何設(shè)計(jì)？

以上兩個(gè)問題答案類似，都可以參考TCP的可靠性機(jī)制然后在應(yīng)用層實(shí)現(xiàn)類似的邏輯：
如：

• 引入序列號，保證數(shù)據(jù)順序；
• 引入確認(rèn)應(yīng)答，確保對端收到了數(shù)據(jù)，保證可靠傳輸；
• 引入超時(shí)重傳，如果隔一段時(shí)間沒有應(yīng)答，就重發(fā)數(shù)據(jù)；
• 引入滑動窗口；
• 引入窗口擴(kuò)大選項(xiàng)；
• 引入流量控制
• 引入擁塞控制
• ……

好啦！ 以上就是對 TCP 滑動窗口、流量控制 以及擁塞控制的講解，希望能幫到你 ！
評論區(qū)歡迎指正 !