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

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

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

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

接下來我們看看 TCP Window Full 具體是個(gè)什么樣子。比如我們選中 224 號(hào)報(bào)文，主界面也自動(dòng)定位到了這個(gè)報(bào)文：

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

解讀 TCP Window Full

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

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

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

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

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

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

上圖中，我還是用 A 指代發(fā)送端，用 B 指代接收端。當(dāng) A 的在途數(shù)據(jù)跟 B 的接收窗口大小相等時(shí)，Wireshark 就會(huì)判斷出，這個(gè)接收窗口滿了，這意味著：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 窗口，找到離這個(gè) TCP Window Full 最近的，從源端口 22 發(fā)送來的報(bào)文。我們發(fā)現(xiàn)，它就是下圖這個(gè) 222 號(hào)報(bào)文：

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

整個(gè)過程是這樣的：

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

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

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

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

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

自己驗(yàn)證 TCP Window Full

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

下個(gè)序列號(hào)

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

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

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

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

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

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

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

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

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

Bytes_in_flight = latest_nextSeq - latest_ack_from_receiver

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這樣看起來精確了很多。

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

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

繼續(xù)深挖窗口

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

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

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

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

這時(shí)候就能看到 Windows Scaling 的趨勢(shì)圖了：

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

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

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

驗(yàn)證傳輸公式

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

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

Acknowledgement Number：確認(rèn)號(hào) Next Sequence Number：下個(gè)序列號(hào) Caculated Window Size：計(jì)算后的接收窗口 Bytes in flight：在途字節(jié)數(shù) 另外，因?yàn)槲覀円袡z查發(fā)送端的 Bytes in flight，就需要把源端口 38979 的報(bào)文過濾出來，這樣就不會(huì)被另一個(gè)方向的報(bào)文給干擾了。

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

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

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

不知道你有沒有考慮到這個(gè)問題：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é)，此時(shí) B 的接收窗口滿；B 向 A 確認(rèn)了 300 字節(jié)的數(shù)據(jù)，自身的接收窗口也擴(kuò)大為 300 字節(jié)；A 的在途字節(jié)數(shù)也從 1000 字節(jié)變成 700 字節(jié)，因?yàn)閯倓傆?300 字節(jié)被 B 確認(rèn)了。圖中的 t1 到 t4 表示時(shí)間點(diǎn)。t2 到 t4 就是一次往返的時(shí)間，在這個(gè)往返時(shí)間內(nèi)，被傳輸?shù)臄?shù)據(jù)是 1000 字節(jié)嗎？不是。因?yàn)楸淮_認(rèn)的只有 300 字節(jié)，所以傳輸完的也只有這 300 字節(jié)，速度也就不是 1000/RTT，而是 300/RTT！我們可以把核心公式做一下改進(jìn)，變成下面這個(gè)：

velocity = acked_data/RTT

我們?cè)儆酶倪M(jìn)后的公式來計(jì)算這次的速度。我們可以選擇傳輸中間偏后面一點(diǎn)的報(bào)文來做分析。比如下圖中，我們選擇 1337 號(hào)和 1357 號(hào)報(bào)文為起始和截止點(diǎn)，計(jì)算 NextSeq 的差值，還有時(shí)間的差值，然后兩個(gè)差值相除。

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

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

這是因?yàn)榍懊嫖恼碌陌咐谕緮?shù)據(jù)一旦到了接收端，都被及時(shí)確認(rèn)了。而當(dāng)前這個(gè)案例里面并沒有這樣。也就是說，這次的案例，出現(xiàn)了“滯留”現(xiàn)象。

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

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

這是因?yàn)椋蛻舳吮淮_認(rèn)了 22400 字節(jié)的數(shù)據(jù)，馬上又把這個(gè)尺寸的數(shù)據(jù)發(fā)送出去了，事實(shí)上就維持了這個(gè)在途字節(jié)數(shù)的尺寸。

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

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

審核編輯：湯梓紅