表白失敗后，我明白了TCP實現(xiàn)原理

作者：sullivan06 2020-08-19 07:54:40

網(wǎng)絡(luò) 通信技術(shù)

前幾天發(fā)了一個朋友圈，發(fā)現(xiàn)暗戀已久的女生給我點了個贊，于是我當(dāng)晚輾轉(zhuǎn)反側(cè)、徹夜未眠!想著妹子是不是對我有感覺呢?不然怎么會突然給我點贊呢?要不趁機表個白?

[[338439]]
圖片來自 Pexels

于是第二天我在心中模擬了多次表白的話語，連呼吸都反復(fù)練習(xí)。

到了晚上，我撥通了妹子的微信語音，還沒等對方開口我就按捺不住內(nèi)心的想法，開始自說自話，一陣狂亂的表達…

足足五分鐘一氣呵成，一切都是那么自然!可是在我說完之后卻半天都沒有等到妹子的回應(yīng)…

過了好一會兒才聽到對方的聲音：“喂!喂!我這邊信號不好，你剛剛在說啥我一句都沒聽到，我在跟我男朋友逛街呢…”。

我掛斷了電話，我也對我這次失敗的表白進行了深度的總結(jié)!原因就是因為我沒有學(xué)好 TCP!

如果我懂 TCP，那我在表白之前至少要先問一句“在嗎?”!先建立可靠的連接，確保連接正常才能開始表白!

如果我懂 TCP，那我在我說話的過程中需要對方不斷的確認，這樣才能保證我說的每一句話對方都能聽到!這樣我才能表白成功!

所以一切都是因為我沒有學(xué)好 TCP，于是我走進了圖書館…

我們先來看下 TCP 的定義：

TCP 全稱為 Transmission Control Protocol(傳輸控制協(xié)議)，是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。TCP 是為了在不可靠的互聯(lián)網(wǎng)絡(luò)上提供可靠的端到端字節(jié)流而專門設(shè)計的一個傳輸協(xié)議。

這里面每一個字我們都認識，但是連在一塊就不是那么好理解了!那我們就提煉一些關(guān)鍵的詞，也就是我上面高亮的那些：面向連接、可靠、基于字節(jié)流、傳輸層、協(xié)議、端到端!

理解了這些關(guān)鍵字也就理解了 TCP 的實現(xiàn)原理，那我們就來從這些關(guān)鍵字開始進行分析!

傳輸層

我們先講傳輸層，因為可以從比較高的層面去看 TCP，我們先看下經(jīng)典的 OSI 七層網(wǎng)絡(luò)參考模型：

當(dāng)我們需要在網(wǎng)絡(luò)上進行數(shù)據(jù)交換的時候，就需要經(jīng)過這么幾層。每一層都有相關(guān)落地的實現(xiàn)，我們今天要講的 TCP 就是傳輸層的一種落地實現(xiàn)。

可能我們平時在說到傳輸層的時候自然而然的就想到的 TCP，但是 TCP 只是傳輸層的一種實現(xiàn)，其他比較常見的傳輸層協(xié)議還有 UDP 等!

我知道干巴巴的文字對你來說太抽象，那我就抓個包來看看，讓這幾層更加具象!

本文中所有的包都是通過 postman 發(fā)送請求，然后用 wireShark 來抓的!如果對這兩款軟件還不了解的盆友可以先去了解下哈，這里不過多說明。

我們在 postman 中輸入 www.17coding.info 的域名，然后發(fā)送請求，wireshark 就能抓到數(shù)據(jù)包了。

圖上已經(jīng)標(biāo)明每一層與抓到的數(shù)據(jù)包對應(yīng)的關(guān)系了!咦!我們上面不是說的 7 層網(wǎng)絡(luò)參考模型么?為什么數(shù)據(jù)包只有 5 層呢?

注意參考二字，7 層模型是一個理論模型，實際的網(wǎng)絡(luò)中往往都把應(yīng)用層、會話層、表示層統(tǒng)為應(yīng)用層!

什么是協(xié)議?

說到協(xié)議，就是雙方共同遵守的一種約定!比如我寫的這篇文章里，你能夠看懂我寫的每一個字并明白我的意思，那就是因為我們都遵循了漢語的語法，這本身也就是一種協(xié)議。

還有比如我們寫代碼就必須按照規(guī)定的語法進行編寫，這樣編譯器才能進行正確編譯。

在計算機網(wǎng)絡(luò)中也有很多協(xié)議，比如常見的應(yīng)用層協(xié)議 http、ftp、dns 協(xié)議等等。

常見的傳輸層協(xié)議有 TCP、UDP 等等，其實這些協(xié)議都是發(fā)送方和接收方都在遵循的一種規(guī)范。

如果我們遵循了其規(guī)范，也能成為協(xié)議的實現(xiàn)者，比如自己寫一個 web 服務(wù)器處理用戶請求。甚至我們還能自己規(guī)定一套協(xié)議，供別人使用!

TCP 頭部格式

我們前面說了協(xié)議的定義，那 TCP 協(xié)議肯定也有一定的規(guī)范咯!這樣通信雙方才能識別對方的數(shù)據(jù)報文，進行數(shù)據(jù)交換。

我們先看下 TCP 的報文格式：

TCP 報文包含數(shù)據(jù)頭和數(shù)據(jù)體，頭部有 5 行的固定長度以及 1 行可變長度!圖上前面 5 行就是固定長度!

固定長度的每一行占有 4 個字節(jié)(32 位)。因此頭部固定長度就為 5*4=20 個字節(jié)!

到這里我們可以抓個包來看下加深印象，我們依然向 www.17coding.info 發(fā)送一個請求，然后看看其 TCP 部分的數(shù)據(jù)包：

接下來那我們就一行一行的來分析 TCP 的頭部：

第一行：

1、源端口：發(fā)送方端口

2、目標(biāo)端口：接收方端口

前面我們說到 TCP 是端到端的，這里就能很好的體現(xiàn)了!每個數(shù)據(jù)包中都有發(fā)送方和接收方的端口。這里每個端口占用 2 個字節(jié)(16 位)。

第二行、第三行：

1、序號：TCP 是面向字節(jié)流的，數(shù)據(jù)分塊在緩存存放及發(fā)送，序號用來標(biāo)記某個數(shù)據(jù)包最開始的字節(jié)是整個數(shù)據(jù)的第多少個字節(jié)。

2、確認號：每次收到請求后，接收方都會回復(fù)發(fā)送方，告訴對方自己已經(jīng)接收了多少字節(jié)，下一個數(shù)據(jù)包需要從第多少字節(jié)開始發(fā)送。這里的值一般等于接收到的序號+接收到的數(shù)據(jù)包數(shù)據(jù)部分長度。

這里的序號和確認號是保證 TCP 可靠特性所不可或缺的，我們后面會通過抓包來詳細分析!序號和確認號分別都占用了 4 個字節(jié)(32 位)!

第四行：

1、數(shù)據(jù)偏移：這里叫頭部長度更為合適。前面說過 TCP 頭部長度有部分是可變的，所以需要標(biāo)識數(shù)據(jù)包數(shù)據(jù)部分從哪里開始。這個值占用了 4 位。

2、保留：未使用，供擴展使用。這個值占了 3 位。

3、標(biāo)志：標(biāo)志一共有 9 個，每個標(biāo)識占 1 位，共占 9 位。上面的抓包截圖就能看到這 9 個標(biāo)識位!

3.1、NS：Nonce，與 ECN 顯式擁塞通知相關(guān)。

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

3.3、ECE：ECN-Echo，若設(shè)置了該標(biāo)識，則會通知對方，從對方到這邊的網(wǎng)絡(luò)有阻塞。

3.4、URG：Urgent，用于在發(fā)送方加塞。比如在下載文件的時候，下到一半了需要停止下載，就需要發(fā)送一個緊急的請求告訴對方停止發(fā)送數(shù)據(jù)。數(shù)據(jù)包不排隊。

3.5、ACK：Acknowledgment，標(biāo)記為一個確認。

3.6、PSH：Push，與 URG 對應(yīng)的，用于接收方加塞。

3.7、RST：Reset，表示出現(xiàn)嚴(yán)重差錯，可能需要重新創(chuàng)建 TCP 連接。如果我們打開某個網(wǎng)站一直沒刷出來，我們F5進行刷新，那之前的數(shù)據(jù)包就要拒絕。

3.8、SYN：用于同步，建立請求的時候用。在握手時候會帶這個標(biāo)記!

3.9、FIN：通信結(jié)束，釋放連接的時候用。在揮手時候會帶這個標(biāo)記!

4、窗口：不管是發(fā)送方還是接收方，都有對應(yīng)的發(fā)送窗口和接收窗口。在通信之前，通信雙方會協(xié)商窗口的大小。

發(fā)送方按照接收方的接收窗口設(shè)置自己的發(fā)送窗口，同時發(fā)送窗口還受擁塞窗口的限制，這個在擁塞控制部分會提到!

在發(fā)送過程中窗口會根據(jù)接收方的處理能力調(diào)整。這個值對 TCP 的可靠傳輸及流量控制起了很大的作用!這個值占了 16 位。

第五行：

1、校驗和：用于校驗數(shù)據(jù)包是否完整或者被修改。這個值占了 16 位。

2、緊急指針：用來標(biāo)記本報文段中緊急數(shù)據(jù)的指針，也就是指明了從數(shù)據(jù)包數(shù)據(jù)部分的頭部到指定位置的數(shù)據(jù)為緊急數(shù)據(jù)，只有在設(shè)置了標(biāo)志位 URG 的時候才起作用。這個值占了 16 位。

第六行：

1、選項：選項里面也有些重要的數(shù)據(jù)，我們挑幾個講一下。

1.1、MSS：MSS 的全稱為 Maximum segment size，雙方協(xié)商的每一個報文段所能承載的最大數(shù)據(jù)長度(不包括文段頭)。

1.2、WS：WS 的全稱為 Window scale，也叫窗口因子!是用來調(diào)整窗口大小的。前面我們說到過窗口大小的字段，那這個窗口因子又是做什么用的呢?

早期的網(wǎng)絡(luò)帶寬、硬件配置都比較差，所以窗口大小最大只預(yù)留了 16 個 bit，也就是最大能設(shè)置的值為 65535。

隨著硬件和網(wǎng)絡(luò)的發(fā)展，65535 已經(jīng)不能滿足。所以就增加了一個 WS 的選項來擴展!如果設(shè)置了 WS，那實際的窗口大小就等于窗口大小乘以窗口因子。

1.3、SACK：SACK 的全稱為 Selective ACK，選擇性確認是建立在累計確認(后面講) 的基礎(chǔ)上的!

只有收到失序的分組時才會可能會發(fā)送 SACK，如果接收方接收到了后面的數(shù)據(jù)包，而發(fā)現(xiàn)前面的數(shù)據(jù)包丟失，則會通知發(fā)送方哪些報文段丟失，需要重發(fā)!

2、填充：這個字段是為了讓整個頭部為 4 個字節(jié)的倍數(shù)。Java 中也有很多類似的用法!

我們找到一個數(shù)據(jù)包，看看其詳細的頭部數(shù)據(jù)：

紅色部分顯示了 TCP 頭部的長度為 32byte，以及選項部分為 12byte。前面我們說了 TCP 首部固定長度為 20byte，所以 20+12=32。
黃線部分的窗口大小為 259byte，窗口因子為 256。所以實際的窗口大小為 259*256=66304!

面向連接怎么理解

從我表白失敗的例子就能看到，我還未確保連接的正常就開始表白，導(dǎo)致我說完了對方卻因為信號不好沒有聽到。

如果我事先確保連接正常，就不會出現(xiàn)這樣的情況了!我們前面說了 TCP 是面向連接的，那 TCP 是怎么面向連接的呢?

三次握手交代了什么?

沒錯，都是從握手開始!我們都知道，TCP 建立連接需要經(jīng)過三次握手，那每次握手都交代了什么呢?如果只進行兩次握手行不行?

我們先看一個電話接通的場景：

A：你好，你能聽到嗎? B：我能聽到，你能聽到嗎? A：我也能聽到。 …….

在正式通話之前，為了確保通話的可靠，往往都需要經(jīng)過上面的三次對話進行確認。

那這三次對話是必須的嗎?每一次對話的必要性又是什么呢?

A：你好，你能聽到嗎?(讓B知道A能說話) B：我能聽到，你能聽到嗎?(讓A知道B能聽到，且能說話) A：我也能聽到。(讓B知道A能聽到) …….

只有經(jīng)過三次的對話，才能確認自己的聲音能被對方聽到且能聽到對方的聲音。這也才能開展后續(xù)的對話。

這里我們就不得不祭出經(jīng)典的三次握手圖了：

我們分析三次握手過程及每次握手后的狀態(tài)如下：

A 主機發(fā)送標(biāo)識 SYN=1(SYN 表示 A 請求跟 B 建立連接，前面在講 TCP 頭部時候有說到過)，序號 Seq=x，第一次握手請求發(fā)送后 A 的狀態(tài)為 SYN_SENT，B 在接收到請求后狀態(tài)由 LISTEN 變?yōu)?SYN_RCVD!
B 主機收到連接請求后向 A 主機發(fā)送標(biāo)識 SYN=1，ACK=1(SYN 表示 B 請求跟 A 建立連接，ACK 表示對 A 的連接請求進行應(yīng)答)，序號 Seq=y，確認號 Ack=(x+1)，A 接收到 B 的確認后，狀態(tài)變?yōu)?ESTABLISHED，B 的狀態(tài)依然為 SYN_RCVD!
主機 A 收到后檢查 ACK 是否正確，若正確，則發(fā)送標(biāo)識 ACK=1(表示對 B 的連接請求進行應(yīng)答)，序號 Seq=(x+1)，確認號 Ack=(y+1)。B 接收到 A 的確認后，A 和 B 的狀態(tài)都變?yōu)?ESTABLISHED!

這里我們要注意的幾點是：

圖中的發(fā)送請求中中括號里面的 SYN、ACK 就是前面說 TCP 頭部中的那幾個標(biāo)志位!而 Seq 和 ACK 分別代表序號和確認號。
接收方在接收到發(fā)送方發(fā)送的 Seq 后，應(yīng)答一個 ACK，ACK 的值等于 Seq+1，表示已要發(fā)送方開始發(fā)送 Seq+1 位置的數(shù)據(jù)。
B 在接收到了 A 的連接請求后回復(fù)中同時發(fā)送了 SYN、ACK 兩個標(biāo)識位，將建立連接的請求和對 A 的應(yīng)答在同一個包中發(fā)送了，這也是為什么只需要三次握手，就能建立連接。

我們依然向 www.17coding.info 發(fā)送請求，下面為三次握手的包：

在 info 那一欄，我們很明顯的能看到發(fā)送的數(shù)據(jù)包頭部有我們上面說到的那些標(biāo)志位，還有 Seq、ACK 等頭部信息，還有 Win、MSS 等頭部選項數(shù)據(jù)!因此三次握手不僅僅是單純建立連接，還會協(xié)商一些參數(shù)!

當(dāng)我鼠標(biāo)選擇某一行時，如果這個數(shù)據(jù)包包含了對某個數(shù)據(jù)包的確認(也就是有 ACK 的標(biāo)記)，就能在對應(yīng)的數(shù)據(jù)包的 No 列上面看到一個小勾勾，比如上面圖中我鼠標(biāo)選擇的是第三次握手的數(shù)據(jù)包，在第二次握手的數(shù)據(jù)包前面就有個小勾勾。

為什么握手只需要三次而揮手需要四次?

通過三次握手，雙方就建立了一個可靠的連接，就能進行數(shù)據(jù)的傳輸了!當(dāng)數(shù)據(jù)傳輸完成，就得將連接關(guān)閉，因為連接也是一種資源!連接的關(guān)閉需要經(jīng)過四次揮手!

為什么握手可以三次完成，但是揮手卻需要四次呢?我偏要三次行不行?其實也沒啥不可以的!

比如下面的對話場景：

A：我說完了，你說完就掛電話吧! B：好嘞，我也說完了，可以掛電話了! A：好嘞，拜拜。掛斷……

這樣三次對話就可以實現(xiàn)揮手了，但是在實際的網(wǎng)絡(luò)中，當(dāng)我發(fā)出一個請求的時候，可能服務(wù)器的響應(yīng)體比較大，需要較長時間的傳輸!

所以當(dāng)客戶端主動發(fā)起斷開請求的時候，服務(wù)器先回應(yīng)一個確認，等所有數(shù)據(jù)傳輸完畢后再發(fā)送服務(wù)器斷開的請求。

A：我說完了，你說完就掛電話吧! B：好嘞… B：…… B：我也說完了，可以掛電話了 A：好嘞，拜拜掛斷……

所以大部分情況下都需要進行四次揮手!但是，在我個人的抓包實踐中，也會有三次揮手就能完成斷開連接的情況。

這里我們又不得不祭出經(jīng)典的四次揮手圖了：

我們分析四次揮手過程及每次揮手后的狀態(tài)如下：

主機 A 發(fā)送標(biāo)識 FIN=1(FIN 表示 A 請求關(guān)閉連接)用來關(guān)閉 A 到 B 的數(shù)據(jù)傳輸。此時 A 的狀態(tài)為 FIN_WAIT_1!
主機 B 收到關(guān)閉請求后向 A 發(fā)送 ACK(ACK 表示應(yīng)答 A 的關(guān)閉連接請求)，A 不再向 B 發(fā)送數(shù)據(jù)。此時 A 的狀態(tài)為 FIN_WAIT_2，B 為 CLOSE_WAIT!
主機 B 發(fā)送標(biāo)識 FIN=1 用來關(guān)閉 B 到 A 的數(shù)據(jù)傳輸。此時 A 的狀態(tài)為 TIME_WAIT，B 為 LAST_ACK!
主機 A 收到關(guān)閉請求后向 B 發(fā)送 ACK，此時 B 不再向 A 發(fā)送數(shù)據(jù)。此時 A、B 都關(guān)閉了，狀態(tài)變?yōu)?CLOSED。

在圖中我們能看到，A 的 TIME_WAIT 狀態(tài)會持續(xù) 2MSL 再變成 CLOSED。

MSL(Maximum Segment Lifetime)的中文可以譯為“報文最大生存時間”!他是任何報文在網(wǎng)絡(luò)上存在的最長時間，超過這個時間報文將被丟棄。

那 TIME_WAIT 維持 2MSL 的作用是什么呢?

第 4 次揮手的時候主機 A 發(fā)送 ACK 到主機 B，如果發(fā)送完成后就直接就關(guān)閉連接，那如果由于網(wǎng)絡(luò)原因 B 沒有收到 ACK，那 B 就沒法關(guān)閉連接了!因此 A 在回復(fù)確認后，還需要等待，萬一 B 沒有收到應(yīng)答還會繼續(xù)發(fā)送 FIN 的請求。
如果不等待 2MSL，那客戶端的端口可能會被重用，如果再次用這個端口建立與服務(wù)器的連接，那前后兩個使用相同四元組的的連接之間會形成干擾!

我們看上面向 www.17coding.info 發(fā)送請求的揮手數(shù)據(jù)包：

可能大家在抓包的時候不能立馬看到四次揮手的數(shù)據(jù)包!那是因為在 HTTP 1.1 及之后，默認都開啟了長連接!

也就是在一次請求之后，建立的連接并不會立馬關(guān)閉，而是供后續(xù)的其他請求繼續(xù)使用，以減少每次重新建立連接的資源消耗!

如果想發(fā)出請求后立馬能抓到四次揮手的數(shù)據(jù)包，可以設(shè)置 HTTP 的頭部 Connection:close。

這樣每次發(fā)送請求都能看到完整的三次握手四次揮手的過程啦!

TCP 是怎么保證可靠傳輸?shù)?

保證傳輸?shù)目煽课覀兦懊嬉呀?jīng)說到了面向連接，建立連接是保證數(shù)據(jù)傳輸?shù)牡谝徊健Ｄ窃谶B接建立之后的數(shù)據(jù)傳輸怎么保證可靠呢?

我們再次回到我們打電話的場景，一般在對話的過程中，都是得雙方都有互動，給與對方回應(yīng)。而不是一個人一個勁的說而另一方?jīng)]有任何回應(yīng)!

比如下面場景：

A：跟你講哦，我上周網(wǎng)上認識了一個妹子 B：嚯，牛逼啊! A：然后我昨天約出來見面了 B：666啊!然后呢? A：然后我們@#￥%……& B：臥槽，你剛剛說啥我沒聽清，你再說一遍?...

這樣的確認和應(yīng)答就確保了雙方的通信能夠完整可靠。TCP 也采用了這種 y 應(yīng)答和確認重傳的機制，保證在不可靠的網(wǎng)絡(luò)上實現(xiàn)可靠的傳輸。只要我沒有收到確認，我就認為沒有發(fā)送成功，就會重發(fā)。

停止等待協(xié)議

停止等待協(xié)議就是每次給對方發(fā)送數(shù)據(jù)包后，需要等待對方的回應(yīng)然后再發(fā)送下一個數(shù)據(jù)包!

停止等待協(xié)議會出現(xiàn)如下幾種情況：

①無差錯情況：A 發(fā)送 M1 包到 B，B 收到后會給 A 一個確認，當(dāng) A 收到 B 的確認后再發(fā)送包 M2。

②超時重傳：A 發(fā)送 M1 包到 B，如果發(fā)送過程中包丟失，A 會重新發(fā)送。A 等待重發(fā)的時間是比一個報文的往返時間(RTT)稍微多一點。

③確認丟失：如果 B 在給 A 發(fā)送確認的時候丟失，A 會重新發(fā)送 M1 包給 B，由于 B 已經(jīng)處理過 M1 的數(shù)據(jù)包所以 B 會丟棄報文，然后重傳確認 M1 給 A。

④確認遲到：如果 A 發(fā)送數(shù)據(jù)包 M1 給 B，B 回復(fù)確認的時候延遲了。這時 A 又會重新發(fā)送包 M1 給 B，B 收到后丟棄數(shù)據(jù)包，然后重傳確認 M1 給 A。這時 A 會收到多次確認，當(dāng)?shù)诙问盏竭t到的確認后 A 也會丟棄該確認。

我們從上面能看到，停止等待協(xié)議每次都是等到收到確認后再發(fā)下一個數(shù)據(jù)包。

只要我沒收到你給我的確認，我就認為你沒有收到我發(fā)的數(shù)據(jù)包，我就會進行重發(fā)!這樣雖然可靠，但是會導(dǎo)致信道利用率較低!

流水線傳輸

流水線傳輸就是每次發(fā)送多組數(shù)據(jù)包，不必每次發(fā)完一組就停下來等待對方的確認。由于信道上一直有數(shù)據(jù)不間斷的傳輸，因此可以獲得較高的信道利用率!

流水線傳輸如何保證可靠的呢?需要發(fā)送方維持發(fā)送窗口，假如發(fā)送窗口是 5，那 5 個數(shù)據(jù)包會同時發(fā)送，然后等確認!

如果有收到接收方的確認，窗口就會滑動，進行第 6 個數(shù)據(jù)包的發(fā)送。如果都是單個確認，可能效率會比較低，所以有了累計確認!

也就是說假如發(fā)送方發(fā)送了數(shù)據(jù)包 1、2、3、4，接收方只需要回復(fù)對數(shù)據(jù)包 4 的確認，那表示 1234 數(shù)據(jù)包都已經(jīng)收到了，就可以進行第五個數(shù)據(jù)包的發(fā)送了!

假如發(fā)送了數(shù)據(jù)包 1、2、3、4，其中第三個數(shù)據(jù)包丟失，那該怎么確認呢?

TCP 只會回復(fù)對數(shù)據(jù)包 2 的確認，并且對數(shù)據(jù)包 4 進行選擇性確認(TCP 頭部選項講到過的 SACK)，這樣發(fā)送方就知道數(shù)據(jù)包 4 已經(jīng)成功發(fā)送，只需要重發(fā)數(shù)據(jù)包 3。

繼續(xù)前面抓包的例子，接收方并不是對每個數(shù)據(jù)包都進行確認，而是對多個數(shù)據(jù)包進行累計確認：

這里我們能看到服務(wù)器發(fā)送多個數(shù)據(jù)包后，客戶端才進行了一次確認。

流量控制和擁塞控制

通過前面我們知道了，通過建立可靠的連接和確認機制，保證了 TCP 的連接的可靠!

但是每個人使用的計算機的處理能力都是不一樣的，我發(fā)送太快了對方處理不過來怎么辦呢?通信雙方怎么去協(xié)調(diào)發(fā)送和接收數(shù)據(jù)的頻率呢?

以字節(jié)為單位的滑動窗口技術(shù)

在介紹 TCP 頭部的時候，我們已經(jīng)提到過滑動窗口，并且介紹了相關(guān)的控制參數(shù) Win!也說到了接收窗口和發(fā)送窗口!那他們的關(guān)系是怎么樣的呢?

假設(shè)現(xiàn)在 A 需要傳輸數(shù)據(jù)給 B，B 就先要告訴 A 自己的接收窗口有多大。A 根據(jù) B 的接收窗口設(shè)置自己的發(fā)送窗口!A 的發(fā)送窗口時不能大于 B 的接收窗口的!

在開始傳輸數(shù)據(jù)之前，初始的窗口設(shè)置如下圖：

如上圖我們能否看到，B 的接收窗口設(shè)置為 10 個字節(jié)，那 A 的發(fā)送窗口設(shè)置不能超過 10 個字節(jié)!

如果開始傳送數(shù)據(jù)，A 會將數(shù)據(jù)封裝成多個數(shù)據(jù)包進行傳輸，如下圖：

在沒有收到 B 的確認之前，A 的窗口不會滑動，也就是說最多能發(fā) 10 個字節(jié)的數(shù)據(jù)。

如果 B 接受到數(shù)據(jù)且回復(fù)確認給了 A，那 A 的窗口則進行滑動，如下圖：

這樣，A 又可以進行第 11、12 個字節(jié)的發(fā)送啦!如果 B 的處理能力變?nèi)趿耍部梢酝ㄖ?A 將發(fā)送窗口調(diào)小!

這樣也也就很好的協(xié)調(diào)了雙方的接收和發(fā)送能力!這也就很好的實現(xiàn)了 TCP 的可靠傳輸和流量控制!

上面的數(shù)據(jù)包繼續(xù)發(fā)送，如果在發(fā)送過程中，3、4、5 這三個字節(jié)組成的數(shù)據(jù)包丟了，但是后面的數(shù)據(jù)卻收到了，這時候 A 的發(fā)送窗口會移動么?

如果是這種情況，A 的發(fā)送窗口是不會移動的。B 在接收到后面數(shù)據(jù)包的時候回復(fù)給 A 的 ACK 會設(shè)置為 3，且在選項中設(shè)置一個 SACK(在 TCP 頭部選項里面有描述)，告訴 A 哪部分數(shù)據(jù)收到了，而哪部分數(shù)據(jù)需要進行重發(fā)!

擁塞控制

利用滑動窗口技術(shù)，可以很好的協(xié)調(diào)雙方的收發(fā)能力。但是，網(wǎng)絡(luò)狀況是非常復(fù)雜的，且在同一個網(wǎng)絡(luò)上可能有千千萬萬個發(fā)送方和接收方!

如果大家都需要傳輸數(shù)據(jù)都需要占用網(wǎng)絡(luò)，不做好控制措施，就會導(dǎo)致整個網(wǎng)絡(luò)會堵塞甚至癱瘓。

如果我要從深圳開車去廣州，我就會走高速。如果只有我一個人開車，那肯定能暢通無阻!但是高速公路不是我家的，大家都能通行!

所以一到了節(jié)假日，大家都蜂擁而上，而高速的承運能力不會因為節(jié)假日而調(diào)整!

這時候往往就需要交通管制、限流等措施去舒緩交通!

綠線代表理想狀況下，如果高速公路的吞吐量為 100!當(dāng)需要通過的車輛不超過 100 時，所有車輛都能順利通過!當(dāng)需要通過的車輛超過 100，那每次通行的車輛為 100，能提供的負載比較穩(wěn)定。
紅色代表沒有任何交通管制情況下，如果高速公路的吞吐量為 100!當(dāng)需要通過的車輛不超過 100 時，會出現(xiàn)輕微的塞車現(xiàn)象!但是隨著車輛的增多，就會出現(xiàn)嚴(yán)重的阻塞，甚至癱瘓!
藍色代表在交通管制下，如果高速公路的吞吐量為 100!當(dāng)需要通過的車輛不超過 100 時，會出現(xiàn)輕微的塞車現(xiàn)象!但是隨著車輛的增多，交通一直保存較高的負載，不會出現(xiàn)癱瘓的情況!

網(wǎng)絡(luò)就好比高速公路，傳輸?shù)臄?shù)據(jù)包就好比要通過的車輛，而 TCP 則就更像一個交警，維護著數(shù)據(jù)傳輸?shù)闹刃?那 TCP 是怎么做的呢?

慢開始與擁塞避免

發(fā)送方維持一個 cwnd(擁塞窗口，注意這里的擁塞窗口不能大于前面說到的發(fā)送窗口!)，剛開始擁塞窗口設(shè)置為 1。

如果發(fā)現(xiàn)這個包沒有丟失，則調(diào)整擁塞窗口為 2!如果又沒有丟包，則調(diào)整擁塞窗口為 4!

這樣每次以 2 倍的速度一直增長到 16!然后 17、18、19 這樣一個一個的增加，直到大小與發(fā)送窗口一致。

這就是所謂的慢開始和擁塞避免，16 就是慢開始門限……

有沒有得寸進尺的感覺!

我就蹭蹭不進去… … 我就進去不動… … 我就..

如果在發(fā)送的過程中發(fā)現(xiàn)有丟包現(xiàn)象，則會調(diào)整擁塞窗口大小為 1，并且設(shè)置新的慢開始門限為出現(xiàn)擁塞時的二分之一，也就是說當(dāng)擁塞窗口為 24 的時候出現(xiàn)丟包現(xiàn)象，那新的慢開始門限就調(diào)整為 12!

如果理解了上面的文字描述，下面的圖就不難理解了：