案例：TCP Window Full 是導(dǎo)致異地拷貝速度低的原因嗎？也是在公有云服務(wù)的時候，有個客戶有這么一個需求，就是要把文件從北京機(jī)房拷貝到上海機(jī)房。但是他們發(fā)現(xiàn)傳輸速度比較慢，就做了抓包。在查看抓包文件的時候，發(fā)現(xiàn) Wireshark 有很多 TCP Window Full 這樣的提示，不明白這些是否跟速度慢有關(guān)系，于是找我們來協(xié)助分析。

解讀 Expert Information 我們先要了解一下抓包文件的整體狀況。怎么看呢？當(dāng)然是看 Expert Information 了：

它確實提醒我們，有 69 個 Warning 級別報文，它們的問題是 TCP Window specified by the receiver is now completely Full。在展開進(jìn)一步排查之前，我們先對這個信息做一下解讀。

TCP Window：前面我介紹了 TCP 的三種窗口，分別是發(fā)送窗口、接收窗口、擁塞窗口。那么這里說的是哪個窗口呢？一般說到 TCP Window，如果沒有特別指明，就是指接收窗口。specified by the receiver：這也很明確，這個窗口是接收方的，其實就是佐證了這個窗口就是接收窗口。is now completely Full：窗口滿了，這又怎么理解呢？你還記得在上節(jié)課里學(xué)過的在途數(shù)據(jù)，也就是 Bytes in flight 嗎？當(dāng)在途數(shù)據(jù)的大小等于接收窗口的大小時，這個窗口就是“滿了”。好了，這個信息解讀完畢，一句話說就是：發(fā)生了 69 次在途數(shù)據(jù)等于接收窗口的情況。

接下來我們看看 TCP Window Full 具體是個什么樣子。比如我們選中 224 號報文，主界面也自動定位到了這個報文：

我們可以看到，除了 224 報文，也確實有很多其他報文也報了 TCP Window Full 的警告信息。

解讀 TCP Window Full

TCP Window Full 這個信息非常直接明了，就是說“接收窗口滿了”。不過，你可別以為這個信息是 TCP 報文里的某個字段。其實，它只是 Wireshark 通過分析得出的信息。你有沒有注意到，TCP Window Full 前后是有方括號的。一般來說，Wireshark 自己分析得到的信息，都會用方括號括起來，而 TCP 報文本身的字段，是不會帶這種方括號的。我們來看一個截圖：

上面是 224 號報文的 TCP 詳情，里面有不少信息也帶上了方括號，比如其中的 [Bytes in flight: 112000]，這也是解讀出來的，而且它跟 Window Full 關(guān)系很大。

前面提到過，在途數(shù)據(jù)（或者叫在途字節(jié)數(shù)，Bytes in flight）等于接收窗口大小的時候，Wireshark 就會解讀為 TCP Window Full 了。不過，如果你在上圖中找一下 Window size，會發(fā)現(xiàn)它是 19200，而不是 Bytes in flight 的 112000，這又是為什么呢？

這是因為，我們把發(fā)送方和接收方的接收窗口搞混啦。這里你需要搞清楚：如果說在途數(shù)據(jù)的發(fā)送方是 A，接收方是 B，那么這里 Window Full 的窗口，是 B 的接收窗口，而不是 A 的接收窗口。上圖是 A 的報文，自然沒有我們要找的 B 的接收窗口信息了，那怎么找到 B 的接收窗口呢？

因為這次通信是 SCP 文件傳輸，那么 A 就是客戶端，它的端口是 38979；B 就是服務(wù)端，它的端口是 22。我們的具體做法是：在抓包文件里，找到 B（也就是源端口為 22）的報文，而且應(yīng)該是這個 TCP Window Full 報文之前的最近的一個，在這個報文里就有 B 的最近的接收窗口值。

單純用文字，可能未必容易理解，我給你畫了一張示意圖：

上圖中，我還是用 A 指代發(fā)送端，用 B 指代接收端。當(dāng) A 的在途數(shù)據(jù)跟 B 的接收窗口大小相等時，Wireshark 就會判斷出，這個接收窗口滿了，這意味著：A 無法再從自己的發(fā)送緩沖區(qū)把數(shù)據(jù)發(fā)送出來了。只有當(dāng) B 回復(fù) ACK，確認(rèn)了 n 字節(jié)的數(shù)據(jù)后，A 才有可能發(fā)送最多 n 字節(jié)的數(shù)據(jù)（如果緩沖區(qū)有足夠多的待發(fā)數(shù)據(jù)的話）。

讓我們回到 Wireshark 窗口，找到離這個 TCP Window Full 最近的，從源端口 22 發(fā)送來的報文。我們發(fā)現(xiàn)，它就是下圖這個 222 號報文：

可以看到，這個報文的接收窗口就是 112000，正好等于前面 224 號報文的 Bytes in flight 的 112000 字節(jié)。所以，我把前面的示意圖改進(jìn)一下供你參考。這里面的信息比較多，建議你耐心多花幾分鐘時間來充分理解其中的機(jī)制：

整個過程是這樣的：

B 發(fā)送了報文 222 給 A，其中帶有 B 自己的接收窗口 112000 字節(jié)。由于這是一個純的確認(rèn)報文，所以沒有 TCP 載荷，也沒有在途數(shù)據(jù)。

報文抵達(dá) A 端，進(jìn)入 A 的接收緩沖區(qū)。

A 從 222 號報文中得知，B 現(xiàn)在的接收窗口是 112000 字節(jié)，由于發(fā)送緩沖區(qū)有足夠多的待發(fā)的數(shù)據(jù)，A 選擇用滿這個接收窗口，也就是連續(xù)發(fā)送 112000 字節(jié)。

A 把這 112000 字節(jié)的數(shù)據(jù)發(fā)送出來，成為報文 224，其中還帶有 A 自己的接收窗口值 19200 字節(jié)，不過，由于這次主要是 A 向 B 傳送數(shù)據(jù)，所以 B 發(fā)給 A 的基本都是純確認(rèn)報文，這些報文的載荷都是 0。極端情況下，即使 A 的接收窗口為 0，只要 B 回復(fù)的報文沒有載荷，它們也是可以持續(xù)通信的。

224 報文抵達(dá) B 端，正好填滿 B 的接收窗口 112000 字節(jié)。Wireshark 分別從 222 報文中讀取到 B 的接收窗口值，從 224 報文中讀取到在途字節(jié)數(shù)，由于兩者相等，所以 Wiresahrk 提示 TCP Window Full。而這個信息是被 Wiresahrk 展示在 224 報文中的。

自己驗證 TCP Window Full

對于在途數(shù)據(jù)，既然 Wireshark 可以解讀出來，那只要理解了 TCP 的原理，我們同樣可以自己來計算，這不僅可以考查我們對 TCP 知識的掌握程度，同時對日常排查也有幫助。有這么多好處，你是不是躍躍欲試了呢？不過在開始之前，我們要先理解一個新的概念。

下個序列號

下個序列號，也就是 Next Sequence Number，縮寫是 NextSeq。它是指當(dāng)前 TCP 段的結(jié)尾字節(jié)的位置，但不包含這個結(jié)尾字節(jié)本身。很顯然，下個序列號的值就是當(dāng)前序列號加上當(dāng)前 TCP 段的長度，也就是 NextSeq = Seq + Len。

這也不難理解，因為 TCP 字節(jié)流是連續(xù)的，那么既然 Seq + Len 是這個報文的數(shù)據(jù)截止點(diǎn)，自然也是下一個報文的起始點(diǎn)，你可以參考這個示意圖：

在 Wireshark 里，我們也可以找到 NextSeq 這個解讀值，比如下圖這樣：

明白了 NextSeq，我們來看如何手工驗證 TCP Window Full。比如，還是分析 224 號報文的這次 TCP Window Full，我們可以這么做，來驗證一下在途數(shù)據(jù)是否真的是 112000 字節(jié)。

首先，跟上面的步驟類似，我們要找到 222 號報文。在這個報文里，服務(wù)端（源端口 22）告訴客戶端：“我確認(rèn)你發(fā)送來的 198854 字節(jié)的數(shù)據(jù)”。我們先把這個數(shù)字記為 X。

然后，我們查看 224 號報文里，客戶端發(fā)送的數(shù)據(jù)到了哪個位置：

我們可以在 224 號報文的 TCP 詳情頁，看到 Next sequence number: 310854，而這個數(shù)字，就是客戶端發(fā)送的數(shù)據(jù)的最新的位置。我們把這個數(shù)字記為 Y。當(dāng)然，你也可以像前面說的那樣，把 Seq 和 Len 加起來，也就是 308054 + 2800，得到的自然也是 310854。

最后，我們做一個最簡單的減法：Y - X = 310854 - 198854 = 112000！這正是前面說的在途數(shù)據(jù)的大小。

恭喜你，你已經(jīng)學(xué)會了如何手工計算在途數(shù)據(jù)的方法，這也意味著你對 TCP 的了解又更深入了一點(diǎn)。你可以這么來總結(jié)計算在途數(shù)據(jù)的方法：

Bytes_in_flight = latest_nextSeq - latest_ack_from_receiver

不過，你會不會覺得，雖然這個計算方法對理解窗口有幫助，但是既然 Wireshark 會給我們提示，那這種計算也主要是自我練習(xí)而已，應(yīng)該不會真的用得上吧？

這還真不好說。因為，Wireshark 在不少場景下并不會給你提示。比如，在接收窗口接近滿但又不是完全滿的時候，哪怕是離窗口滿只差 1 個字節(jié)，Wireshark 也不會提示 TCP Window Full 了。但是，在途數(shù)據(jù)都已經(jīng)逼近接收窗口的 99.9% 了，你還覺得這個肯定沒有問題，或者一定沒有隱患嗎？

要知道，這種臨界狀況也很可能跟問題根因有關(guān)。那么你掌握了這個方法，就可以把排查做得更徹底了?；蛘?，如果你想預(yù)防性能瓶頸，那么提前找到這種窗口臨界滿的狀況，也是有益的。

到這里，我們可以回答開始時候的問題了：為什么上節(jié)課里，沒有看到 TCP Window Full 這種提示呢？我們看一下當(dāng)時的報文狀況吧。

在 2239.067477，接收端的確認(rèn)號為 7105632：

然后在 2239.209712，接收端的確認(rèn)號為 7169872：

這兩個報文的時間跨度正好是 141ms 左右，也就是這次傳輸里面的往返時間。在這個往返時間里，接收端確認(rèn)了多少數(shù)據(jù)呢？是 7169872-7105632=64240，也就是 64KB。這個就是 99.9% 逼近 TCP Window Full 了，但是因為還差小幾十個字節(jié)，所以 Wireshark 并沒有提示 TCP Window Full！

你可能還想追問：那為什么不把這剩余的 0.1% 的窗口“榨干”，非要留一點(diǎn)呢？我們看一下當(dāng)時的接收窗口和在途數(shù)據(jù)的具體情況，就以上面選擇的 5864 報文附近為例：

接收端（源端口為 22）的接收窗口為 65728，發(fā)送端（源端口為 59159）的在途數(shù)據(jù)為 65700，兩者相差只有 28 字節(jié)。對于發(fā)送端來說，沒有必要為了這區(qū)區(qū) 28 字節(jié)再發(fā)送一個小報文了，等接收窗口空余出多一點(diǎn)的空間后再動身不遲。

如果你還沒看過我前面的《TCP SEGMENT》，可能會對上面這些信息感到疑惑，建議先去看完，再來看這一篇，效果更好。

TCP Window Full 對傳輸?shù)挠绊?/p>

好了，現(xiàn)在我們已經(jīng)對 TCP Window Full 做了充分的分析，而且也明白了：這就是接收端的接收窗口小于發(fā)送端的發(fā)送能力而出現(xiàn)的狀況。我們也很容易得出推論：瓶頸在接收端，TCP Window Full 也確實會影響傳輸速度。

春節(jié)剛過，你可能對高速公路上的狀況也感受深刻吧！很多路段出現(xiàn)了堵車，這就相當(dāng)于 TCP Window Full，更多的車輛上不了高速了，只好堵在外面。如果高速公路的路更寬、車速更快，那么就相當(dāng)于接收窗口變得更大，車輛就能進(jìn)更多，也就相當(dāng)于 Bytes in flight 更大了。這么說來，TCP 流量控制和高速車流控制這兩個領(lǐng)域也有不少共通之處，說不定雙方都互有借鑒呢。

回到客戶這次的案例。我們看看，這次的傳輸速度是多少呢？在上節(jié)課里，我介紹了在 Wireshark 里查看 TCP 傳輸速度的兩種方法。比如，我們現(xiàn)在用 I/O Graph 來看一下：

補(bǔ)充：如果你的 I/O Graph 顯示的不是這種圖，那需要像圖中這樣：選中 All Bytes 指標(biāo)；Y 軸的單位選為 Bytes。

這個圖不能說不對，但柱子比較粗，看起來不是很精確。這是因為，它默認(rèn)是以 1 秒為間隔而計算的速度。但是 TCP 傳輸中途，很可能每過幾毫秒都有所變化，所以，如果我們要看更加精細(xì)的圖，可以調(diào)整一下粒度，把 Interval 從 1sec 改為 100ms，看看會怎么樣：

這樣看起來精確了很多。

補(bǔ)充：如果你用 Wireshark 查看到的 I/O Graph 跟我這里的不同，那可以對比一下 Interval 和 SMA period 這兩個配置是否跟圖中的一致。

這里有個小的注意點(diǎn)：因為我們選擇的間隔是 100ms，所以 Y 軸的數(shù)字就是 Bytes/100ms，換算成 Bytes/s 的話，要把 Y 軸的數(shù)字再乘以 10。從圖上看，在一開始的 8 秒幾乎沒有數(shù)據(jù)傳輸發(fā)生，從第 8 秒開始速度上到了 400KB/s（就是圖上的 40K*10）左右，一直到結(jié)束都大致維持在 300~400KB/s 這個區(qū)間里。

繼續(xù)深挖窗口

一般來說，接收窗口、擁塞窗口、發(fā)送窗口，這些都不是一上來就是一個很大的值的，而是跟汽車起步階段類似，逐步跑起來的。那么這就產(chǎn)生了一個很有意思的話題：這些窗口之間都是怎么協(xié)調(diào)的呢？直觀上感覺，無論哪個更快了，另外兩個就要受影響。

我們很容易理解，假設(shè)起始值相同，如果接收窗口增長的速度小于擁塞窗口的增長速度，那么接收窗口就成了瓶頸；反過來說，擁塞窗口增速更小，那么它就成了瓶頸。

當(dāng)接收窗口成為瓶頸的時候，很容易就出現(xiàn)這里的 TCP Window Full 的現(xiàn)象。不過，我們這么多討論都是基于文字，如果有更加直觀的方式，讓我們理解這個現(xiàn)象就更好了。這里，我們就可以再學(xué)一個 Wireshark 的小工具：TCP Stream Graphs 里面的 Window Scaling。

我們還是打開 Wireshark 的 Statistics 下拉菜單，找到 TCP Stream Graphs，在二級菜單中，選擇 Window Scaling：

這時候就能看到 Windows Scaling 的趨勢圖了：

我就直接給你把關(guān)鍵信息標(biāo)注出來了。這里主要是兩個關(guān)鍵點(diǎn)。

數(shù)據(jù)流的方向要找對：比如這次傳輸是從客戶端向 SSH 服務(wù)端發(fā)送數(shù)據(jù)，所以要確認(rèn)這是從一個高端口向 22 端口發(fā)送數(shù)據(jù)的流向。如果搞反了，那圖就變成了 SSH 服務(wù)端回復(fù)的 ACK 報文了，不是你要分析的傳輸速度了。定位 TCP Window Full：在這里，Receive Window 是“階梯”式的，每次變化后會保持在一個“平臺”一小段時間，那么這時候 Bytes Out（發(fā)送的數(shù)據(jù)，也就是 Bytes in flight）就有可能觸及這個“平臺”，每次真的碰上的時候，就是一次 TCP Window Full。我們可以看一個例子。圖中的藍(lán)線代表 Bytes Out，綠線代表 Receive Window。你可以像我這樣，在這幾個“平臺”區(qū)域，找到藍(lán)線和綠線的匯合點(diǎn)，然后在這些點(diǎn)上點(diǎn)擊鼠標(biāo)左鍵，就能定位到 TCP Window Full 事件了。

上圖中，我用鼠標(biāo)放大了一個“平臺”，然后選中了一個 Receive Window 和 Bytes Out 重合的點(diǎn)，它是 1200 號報文，主窗口也自動定位到了這個報文，果然它也是一次 TCP Window Full。

驗證傳輸公式

前面我們推導(dǎo)出了 TCP 傳輸?shù)暮诵墓剑核俣?= 窗口 / 往返時間。既然當(dāng)前案例里 TCP Window Full 的時候，Bytes in flight 跟接收窗口相等，那么在這個公式里的窗口，是否就是 Bytes in flight 呢？我們來驗證一下。

還是在 Wireshark 窗口里，我們要添加這么幾個自定義列，以便進(jìn)行數(shù)據(jù)比對：

Acknowledgement Number：確認(rèn)號 Next Sequence Number：下個序列號 Caculated Window Size：計算后的接收窗口 Bytes in flight：在途字節(jié)數(shù) 另外，因為我們要集中檢查發(fā)送端的 Bytes in flight，就需要把源端口 38979 的報文過濾出來，這樣就不會被另一個方向的報文給干擾了。

在這里，我們看到的 Bytes in flight 是 112000 字節(jié)左右。從右邊滾動條的位置來看，這是在傳輸過程的初期。讓我們滾動到中間和后期，看看這些在途字節(jié)數(shù)是多少：

中期這里的 Calculated Window Size 明顯增大了，到了 445312 字節(jié)。再看看后半程：

最后階段已經(jīng)達(dá)到 863800 字節(jié)。綜合這三個階段來看，折中值差不多在 400KB 左右，我們把它除以 RTT 0.029 秒，得到的是 400KB/0.029s=13790KB/s。顯然，這個數(shù)值遠(yuǎn)超過前面 I/O Graph 里看到的 300~400KB/s。這是怎么回事呢？難道我們的核心公式是錯的嗎？

不知道你有沒有考慮到這個問題：Bytes in flight 是指真的一直在網(wǎng)絡(luò)上兩頭不著嗎？一般來說，數(shù)據(jù)到了接收端，接收端就發(fā)送 ACK 確認(rèn)這部分?jǐn)?shù)據(jù)，然后 TCP Window 就往下降了。比如 ACK 300 字節(jié)，那么 TCP Window 就又空出來 300 字節(jié)，也就是發(fā)送端又可以新發(fā)送 300 字節(jié)了。

像圖上這種情況：

B 通知 A：“我的接收窗口是 1000”；A 向 B 發(fā)送了 1000 字節(jié)，此時 B 的接收窗口滿；B 向 A 確認(rèn)了 300 字節(jié)的數(shù)據(jù)，自身的接收窗口也擴(kuò)大為 300 字節(jié)；A 的在途字節(jié)數(shù)也從 1000 字節(jié)變成 700 字節(jié)，因為剛剛有 300 字節(jié)被 B 確認(rèn)了。圖中的 t1 到 t4 表示時間點(diǎn)。t2 到 t4 就是一次往返的時間，在這個往返時間內(nèi)，被傳輸?shù)臄?shù)據(jù)是 1000 字節(jié)嗎？不是。因為被確認(rèn)的只有 300 字節(jié)，所以傳輸完的也只有這 300 字節(jié)，速度也就不是 1000/RTT，而是 300/RTT！我們可以把核心公式做一下改進(jìn)，變成下面這個：

velocity = acked_data/RTT

我們再用改進(jìn)后的公式來計算這次的速度。我們可以選擇傳輸中間偏后面一點(diǎn)的報文來做分析。比如下圖中，我們選擇 1337 號和 1357 號報文為起始和截止點(diǎn)，計算 NextSeq 的差值，還有時間的差值，然后兩個差值相除。

33600/0.094 = 357KB/s。是不是很接近 I/O Graph 的值了？看來這樣計算才是正確的！

那為什么在前面文章里我們就可以用 窗口 / 往返時間 來計算速度，而且數(shù)值也很準(zhǔn)呢？而這種方法用到這里就完全不對呢？

這是因為前面文章的案例，在途數(shù)據(jù)一旦到了接收端，都被及時確認(rèn)了。而當(dāng)前這個案例里面并沒有這樣。也就是說，這次的案例，出現(xiàn)了“滯留”現(xiàn)象。

還是 1337 到 1357 號報文，我們?nèi)サ袅诉^濾器 tcp.srcport eq 38979，這樣就展示了雙向報文?？梢钥吹?，服務(wù)端（B 端）在這段時間內(nèi)，只確認(rèn)了 22400 字節(jié)（1495254 - 1472854），而同樣時刻的在途數(shù)據(jù)，卻一直維持在一個比較高的數(shù)字，在 660KB 上下。所以，真正完成了傳輸?shù)臄?shù)據(jù)量，是前者 22400B，而不是“虛浮”的 660KB。

那你可能又要問了：既然已經(jīng)確認(rèn)了 22400 字節(jié)，為什么客戶端的在途字節(jié)數(shù)還是沒有變化呢？

這是因為，客戶端被確認(rèn)了 22400 字節(jié)的數(shù)據(jù)，馬上又把這個尺寸的數(shù)據(jù)發(fā)送出去了，事實上就維持了這個在途字節(jié)數(shù)的尺寸。

我可以再做一個比喻幫助你理解這個現(xiàn)象。我們?nèi)绻ャy行的一個窗口（這可不是 TCP 窗口）排隊辦業(yè)務(wù)，現(xiàn)在排隊人數(shù)為 10 人，相當(dāng)于 Bytes in flight 為 10。每分鐘都有一個人能完成業(yè)務(wù)辦理，原以為隊列會減小為 9 人，結(jié)果每當(dāng)有一個人出來，保安就喊：“下一個！”于是就立刻又補(bǔ)進(jìn)來一個人，所以隊伍還是維持在 10 人這么長。

那么，窗口的業(yè)務(wù)員的辦理速度是多少呢？顯然不是 10 人 / 分鐘，而是 1 人 / 分鐘了。這樣是不是理解起來容易多了？而前面文章的情況，相當(dāng)于這里的“每次就處理一個人”，所以處理速度就是 1 人 / 分鐘，也就可以用“速度 = 窗口 / 往返時間”來計算了。

審核編輯：湯梓紅