☰

TCP視窗探測

tag-icon • tag-icon tcp
TCP視窗探測

當我最初在 Networking SE 中詢問時，有人提到了這個網站。

我有一些關於 TCP 中的 rwnd 廣告的問題。我已經閱讀了 RFC，但留下了一些未解答的想法（或者也許我錯過了一些事情）。也許有些答案取決於實現 - 在這種情況下，請使用您的經驗回答，因為我想知道一般情況下會發生什麼。

TCP標準規定如下：

即使發送視窗為零，發送 TCP 也必須準備好接受用戶的發送並發送至少一個八位元組的新資料。

我認為原因是視窗探測訊息包含一個八位元組的資料。然而，這讓我想到：

  1. 我還沒有看到標準中規定探測資料包必須包含一個八位元組的新資料。是否有不同的方法來探測視窗大小？

  2. 如果這是唯一的方法，我想知道為什麼重新發送舊的段落（帶有舊的序號）是不夠的。接收方是否必須僅確認某個時刻視窗內的資料（意味著舊資料不一定會被確認），這意味著我們必須將探測資料包視為該規則的例外？

  3. 一般來說，當接收方的視窗變大時，接收方是否會通知發送方？它是否必須這樣做（我知道確認可能會丟失，因此發送者可能必須進行探測）？

  4. 探測包是只在發送時發送window = 0還是可以在之前發送？

答案1

我認為原因是視窗探測訊息包含一個八位元組的資料。

需要明確的是，視窗探測資料包沒有特殊的資料包格式、標頭或其他識別碼。當 TCP 需要探測視窗時，它只是發送一個標準的 TCP 封包。它只是恰好將該 TCP 資料包中的使用者/應用程式資料限制為一個八位元組。

  1. 我沒有看到標準中規定探測資料包必須包含一個八位元組的新資料。

您剛剛引用了標準中的聲明，即探測資料包必須至少包含一個八位元組的新數據，不是嗎？如果您需要其他聲明，您會在 RFC 793 和 RFC 1122 中找到聲明，提醒您沒有新應用程式資料的 Ack 不會可靠傳輸（這意味著您必須傳輸一些新資料才能知道它是否通過了）。

是否有不同的方法來探測視窗大小？

人們可以想像TCP標準的作者可以想出其他方法，但你引用的方法是他們在標準中提供的唯一方法。

  1. 如果這是唯一的方法，我想知道為什麼重新發送舊的段落（帶有舊的序號）是不夠的。

這不是是否足夠的問題，而是什麼是最好的方法的問題。如果您沒有進一步的資料要傳送，則無需探測該視窗。如果你做有更多數據要發送，為什麼不使用那探測窗口，而不是將頻寬浪費在先前發送（並且可能已確認）的資料上？

接收者是否必須僅確認某個時刻視窗內的資料（意味著舊資料不一定會被確認）

接收器應該只確認它收到的最新數據，即與從一開始就收到的所有數據連續的（通過連續，我是說如果它有一個洞，因為它錯過了一個或多個數據包，但收到了一個較晚的資料包，它無法確認後面的資料包；它必須繼續確認第一個洞之前的最後一個序號）。

  1. 一般來說，當接收方的視窗變大時，接收方是否會通知發送方？

是的，一般來說，接收方會在每次 Ack 時通知發送方視窗大小更新。

另外，在第 14 頁的「視窗管理建議」下。 RFC 793 的第 43 條中，作者建議 TCP 接收器「當視窗較大時，發送另一個帶有新視窗資訊的確認」。該 RFC 早於定義了 MAY/SHOULD/MUST 術語標準的 RFC 2119，但該建議似乎在 RFC 2119 的需求等級指導下被視為 SHOULD。

它是否必須這樣做（我知道確認可能會丟失，因此發送者可能必須進行探測）？

我不知道有任何 RFC 更新 RFC 793 會使此行為成為必須。

探測包是只在window = 0時發送還是可以在window = 0之前發送？

如果視窗不為零，則單資料位元組 TCP 段不會真正被視為探測。例如，如果我有一個 telnet 連線向遠端主機發送單獨的擊鍵，則每個擊鍵可能會作為單資料位元組 TCP 段發送。即使視窗大於 0 或 1，這些也可以在 telnet 等情況下發送，但它們不會被視為探測。

答案2

這建立在斯皮夫的回答，但添加的內容超出了評論的範圍。請注意，2022 年 8 月RFC9293最終取代了原始的 TCP 規範，它包含了所有 MUST/SHOULD/MAY 語言。

Q1.我還沒有看到標準中規定探測資料包必須包含一個八位元組的新資料。

最初的 TCP 規範中有以下要求，不限於 1 個八位元組RFC793並被逐字複製到 RFC9293 中：

When the receiving TCP peer has a zero window and a segment arrives, it must
still send an acknowledgment showing its next expected sequence number
and current window (zero).

Q2。我想知道為什麼重新發送舊的片段......還不夠

這不是最有效的方法（如果視窗變得足夠大，仍然需要丟棄八位元組）。但它會起作用，因為 TCP 擁塞控制規範總是這樣說RFC5681現在說：

A TCP receiver SHOULD send an immediate duplicate ACK when an out-of-
order segment arrives.

Q3。一般來說，當接收方的視窗變大時，接收方是否會通知發送方？

我假設您的意思是接收器的視窗增長是因為接收應用程式消耗了接收緩衝區中的一些資料。然後，我相信規範中沒有要求發送 ACK 來通知這一點。因此需要視窗探測來引發 ACK。

Q4。僅當window=0時才傳送探測包

是的，根據定義。因為如果在 window = 0 之前發送一個八位元組的資料包，那麼它只是一個碰巧只有 1 個八位元組大的常規資料包。

相關內容