淺談TCP的窗口字段

該撣撣這裏的灰塵了，寫一篇關於TCP的文章吧。今天的主題是TCP的滑動窗口。在開始這個話題以前，我想先提幾個關於TCP協議的常見誤區。

誤區1：TCP協議三次握手過程當中後兩個包都是[ACK]包。

解釋:這種說法並不錯，只是不嚴謹。首先，第一個包是[SYN]，SYN位在TCP報頭flag字段中，見上圖TCP報頭結構。第二個包更確切地說應該叫[SYN,ACK]包，由於除了ACK位被置位之外，SYN位也被置位了。第三個包纔是單純的ACK包，由於只有ACK位被置位。因此三次握手的過程爲:

客戶端----[SYN]------------------>>>服務器

客戶端<<<-------------[SYN,ACK]---服務器

客戶端----[ACK]------------------>>>服務器

有一種很是經典的***叫SYN Flood***，是DDOS***的一種，方法是客戶端發送多個SYN包請求可是不回覆第三個ACK包以佔用服務器有限的資源。

 

誤區2：TCP數據傳輸過程當中，序列號增加的單元是包的個數。

解釋：這是初學者最常犯的一個錯誤，緣由是絕大多數老師爲了方便學生理解，剛開始舉例子時序列號都是+1地往上增。其實否則。序列號增加的單元是包應用層數據(也叫Payload)的字節數。

舉個栗子：

假如某一個數據包序列號：1000，Payload長度500。那麼下一個包的序列號就是1500。

 

誤區3：對於TCP鏈接的雙方，序列號都會增加。

解釋：對於多數應用(HTTP，Telnet)，雙方都存在數據的發送，那麼雙方的序列號都會增加，而對於FTP這樣的應用，在數據通道中，只是某一方在傳輸數據(上傳或下載)，那麼另外一方只是在扮演簡單確認的角色，在這種狀況下，另外一方的序列號並不會增加。

 

說了這麼多，如今開始進入正題，來聊聊TCP的窗口機制，這是理解TCP協議的一個關鍵點。

1. 你們都知道TCP和UDP的區別是，TCP是基於鏈接的(三次握手)，並且TCP數據的傳輸是可靠的，所謂可靠是依託序列號及確認號機制讓TCP的傳輸過程當中即便出現丟包也會重傳。

 

2. 可是TCP的確認機制也讓TCP鏈接雙方的數據傳輸速度變慢，也就是說，一方發送數據須要等待對方的確認才繼續發送後續數據。這就體現的窗口機制的做用，所謂窗口，也就是充分利用雙方的帶寬及緩衝區(Buffer)。舉個栗子，發送方沒必要等待對方的確認，能夠連續發送多個數據包給對方，而對方能夠暫時把這些數據存放在緩衝區，並給對方一個確認。這樣，能夠大大增長數據傳輸的速度。

 

3. 這樣作的問題是一旦當接收方的緩衝區填滿或即將填滿時，就會產生不堪重負的狀況，那麼這就須要TCP窗口的實時更新機制，舉個栗子，接收方窗口大小設置的是50000，也就是說發送方能夠沒必要等待確認而一次性發送50000字節的數據，一旦接收方意識到不堪重負的狀況，能夠發送窗口更新通知告訴發送方，如今的窗口大小是30000，請減小一次性發送數據的字節數。某些極端狀況，接收方的Buffer徹底填滿，這時，會發送ZeroWindowSize通知，讓發送方暫時中止數據傳輸，並等待下一個確認通知。

 

下面咱們來看看抓包中是如何體現窗口的特徵的：

上圖是抓包工具抓到的一個ACK包的頭部信息，能夠看出其windowsize的值是最大值，由於16bit的字段最大取值就是65535。紅框中下面那一行可能會讓你們疑惑。爲何會有一個Calculated window size呢？下面咱們就來看一個TCP的選項：TCP Window Size Scaling。

 

1. 既然是選項，那麼毫無疑問須要體如今上圖TCP報頭的選項（Options）字段。

2. 接下來咱們再看一張抓包的截圖：

 

這張圖中咱們能夠看到，windows size的值是114，可是Calculated Windows Size的值倒是14592，這是怎麼回事呢？

 

3. 在TCP三次握手過程當中，能夠經過SYN包開啓TCP選項Window Size Scaling，設計出這個選項是由於現在的帶寬已經大規模提高，千兆到桌面也是一件常事兒，所以，65535長度的窗口大小已經顯得有些小了，爲了突破這個限制，便有了Window Size Scaling選項，看下圖SYN包截圖：

能夠看到這個字段的值爲7，也就是要將Window Size的值左移七位，即乘以128，所以，上圖中咱們看到window size值是114，可是真正選用的值倒是14592(114*128)。