TCP窗口縮放、時間戳和SACK
Linux TCP 協(xié)議棧具有無數(shù)個可以更改其行為的 sysctl 旋鈕。 這包括可用于接收或發(fā)送操作的內(nèi)存量、套接字的最大數(shù)量、可選的特性和協(xié)議擴展。
有很多文章出于各種“性能調(diào)優(yōu)”或“安全性”原因，建議禁用 TCP 擴展，比如時間戳或選擇性確認（SACK）。
本文提供了這些擴展功能的背景，為什么會默認啟用，它們之間是如何關(guān)聯(lián)的，以及為什么通常情況下將它們關(guān)閉是個壞主意。
TCP 窗口縮放
TCP 可以承受的數(shù)據(jù)傳輸速率受到幾個因素的限制。其中包括：
-
往返時間（RTT）。
這是數(shù)據(jù)包到達目的地并返回回復所花費的時間。越低越好。
-
所涉及的網(wǎng)絡(luò)路徑的最低鏈路速度。
-
丟包頻率。
-
新數(shù)據(jù)可用于傳輸?shù)乃俣取?/p>
例如，CPU 需要能夠以足夠快的速度將數(shù)據(jù)傳遞到網(wǎng)絡(luò)適配器。如果 CPU 需要首先加密數(shù)據(jù)，則適配器可能必須等待新數(shù)據(jù)。同樣地，如果磁盤存儲不能足夠快地讀取數(shù)據(jù)，則磁盤存儲可能會成為瓶頸。
-
TCP 接收窗口的最大可能大小。
接收窗口決定了 TCP 在必須等待接收方報告接收到該數(shù)據(jù)之前可以傳輸多少數(shù)據(jù)（以字節(jié)為單位）。這是由接收方宣布的。接收方將在讀取并確認接收到傳入數(shù)據(jù)時不斷更新此值。接收窗口的當前值包含在 TCP 報頭 中，它是 TCP 發(fā)送的每個數(shù)據(jù)段的一部分。因此，只要發(fā)送方接收到來自對等方的確認，它就知道當前的接收窗口。這意味著往返時間（RTT）越長，發(fā)送方獲得接收窗口更新所需的時間就越長。
TCP 的未確認（正在傳輸）數(shù)據(jù)被限制為最多 64KB。在大多數(shù)網(wǎng)絡(luò)場景中，這甚至還不足以維持一個像樣的數(shù)據(jù)速率。讓我們看看一些例子。
理論數(shù)據(jù)速率
在往返時間（RTT）為 100 毫秒的情況下，TCP 每秒最多可以傳輸 640KB。在延遲為 1 秒的情況下，最大理論數(shù)據(jù)速率降至只有 64KB/s。
這是因為接收窗口的原因。一旦發(fā)送了 64KB 的數(shù)據(jù)，接收窗口就已經(jīng)滿了。發(fā)送方必須等待，直到對等方通知它應(yīng)用程序已經(jīng)讀取了至少一部分數(shù)據(jù)。
發(fā)送的第一個段會把 TCP 窗口縮減去該段的大小。在接收窗口值的更新信息可用之前，需要往返一次。當更新以 1 秒的延遲到達時，即使鏈路有足夠的可用帶寬，也會導致 64KB 的限制。
為了充分利用一個具有幾毫秒延遲的快速網(wǎng)絡(luò)，必須有一個比傳統(tǒng) TCP 支持的窗口更大的窗口。“64KB 限制”是協(xié)議規(guī)范的產(chǎn)物：TCP 頭只為接收窗口大小保留了 16 個位。這允許接收窗口最大為 64KB。在 TCP 協(xié)議最初設(shè)計時，這個大小并沒有被視為一個限制。
不幸的是，想通過僅僅更改 TCP 頭來支持更大的最大窗口值是不可能的。如果這樣做就意味著 TCP 的所有實現(xiàn)都必須同時更新，否則它們將無法相互理解。為了解決這個問題，我們改變了對接收窗口值的解釋。
“窗口縮放選項”允許你改變這個解釋，同時保持與現(xiàn)有實現(xiàn)的兼容性。
TCP 選項：向后兼容的協(xié)議擴展
TCP 支持可選擴展。這允許使用新特性增強協(xié)議，而無需立即更新所有實現(xiàn)。當 TCP 發(fā)起方連接到對等方時，它還會發(fā)送一個支持的擴展列表。所有擴展都遵循相同的格式：一個唯一的選項號，后跟選項的長度以及選項數(shù)據(jù)本身。
TCP 響應(yīng)方檢查連接請求中包含的所有選項號。如果它遇到一個不能理解的選項號，則會跳過 該選項號附帶的“長度”字節(jié)的數(shù)據(jù)，并檢查下一個選項號。響應(yīng)方忽略了從答復中無法理解的內(nèi)容。這使發(fā)送方和接收方都夠理解所支持的公共選項集。
使用窗口縮放時，選項數(shù)據(jù)總是由單個數(shù)字組成。
窗口縮放選項
Window Scale option (WSopt): Kind: 3, Length: 3+---------+---------+---------+| Kind=3 |Length=3 |shift.cnt|+---------+---------+---------+1 1 1
窗口縮放 選項告訴對等方，應(yīng)該使用給定的數(shù)字縮放 TCP 標頭中的接收窗口值，以獲取實際大小。
例如，一個宣告窗口縮放因子為 7 的 TCP 發(fā)起方試圖指示響應(yīng)方，任何將來攜帶接收窗口值為 512 的數(shù)據(jù)包實際上都會宣告 65536 字節(jié)的窗口。增加了 128 倍（2^7）。這將允許最大為 8MB 的 TCP 窗口。
不能理解此選項的 TCP 響應(yīng)方將會忽略它，為響應(yīng)連接請求而發(fā)送的 TCP 數(shù)據(jù)包（SYN-ACK）不會包含該窗口縮放選項。在這種情況下，雙方只能使用 64k 的窗口大小。幸運的是，默認情況下，幾乎每個 TCP 棧都支持并默認啟用了此選項，包括 Linux。
響應(yīng)方包括了它自己所需的縮放因子。兩個對等方可以使用不同的因子。宣布縮放因子為 0 也是合法的。這意味著對等方應(yīng)該如實處理它接收到的接收窗口值，但它允許應(yīng)答方向上的縮放值，然后接收方可以使用更大的接收窗口。
與 SACK 或 TCP 時間戳不同，窗口縮放選項僅出現(xiàn)在 TCP 連接的前兩個數(shù)據(jù)包中，之后無法更改。也不可能通過查看不包含初始連接三次握手的連接的數(shù)據(jù)包捕獲來確定縮放因子。
支持的最大縮放因子為 14。這將允許 TCP 窗口的大小高達 1GB。
窗口縮放的缺點
在非常特殊的情況下，它可能導致數(shù)據(jù)損壞。但在你禁用該選項之前，要知道通常情況下是不可能損壞的。還有一種解決方案可以防止這種情況。不幸的是，有些人在沒有意識到它與窗口縮放的關(guān)系的情況下禁用了該解決方案。首先，讓我們看一下需要解決的實際問題。想象以下事件序列：
- 發(fā)送方發(fā)送段：s_1、s_2、s_3、... s_n。
- 接收方看到：s_1、s_3、... s_n，并發(fā)送對 s_1 的確認。
- 發(fā)送方認為 s_2 丟失，然后再次發(fā)送。它還發(fā)送了段 s_n+1 中包含的新數(shù)據(jù)。
- 接收方然后看到：s_2、s_n+1，s_2：數(shù)據(jù)包 s_2 被接收兩次。
當發(fā)送方過早觸發(fā)重新傳輸時，可能會發(fā)生這種情況。在正常情況下，即使使用窗口縮放，這種錯誤的重傳也絕不會成為問題。接收方將只丟棄重復項。
從舊數(shù)據(jù)到新數(shù)據(jù)
TCP 序列號最多可以為 4GB。如果它變得大于此值，則該序列會回繞到 0，然后再次增加。這本身不是問題，但是如果這種問題發(fā)生得足夠快，則上述情況可能會造成歧義。
如果在正確的時刻發(fā)生回繞，則序列號 s_2（重新發(fā)送的數(shù)據(jù)包）可能已經(jīng)大于 s_n+1。因此，在最后的步驟（4）中，接收方可以將其解釋為：s_2、s_n+1、s_n+m，即它可以將 “舊” 數(shù)據(jù)包 s_2 視為包含新數(shù)據(jù)。
通常，這不會發(fā)生，因為即使在高帶寬鏈接上，“回繞”也只會每隔幾秒鐘或幾分鐘發(fā)生一次。原始數(shù)據(jù)包和不需要的重傳的數(shù)據(jù)包之間的間隔將小得多。
例如，對于 50MB/s 的傳輸速度，重復項要遲到一分鐘以上才會成為問題。序列號的回繞速度沒有快到讓小的延遲會導致這個問題。
一旦 TCP 達到 “GB/s” 的吞吐率，序列號的回繞速度就會非常快，以至于即使只有幾毫秒的延遲也可能會造成 TCP 無法檢測出的重復項。通過解決接收窗口太小的問題，TCP 現(xiàn)在可以用于以前無法實現(xiàn)的網(wǎng)絡(luò)速度，這會產(chǎn)生一個新的，盡管很少見的問題。為了在 RTT 非常低的環(huán)境中安全使用 GB/s 的速度，接收方必須能夠檢測到這些舊的重復項，而不必僅依賴序列號。
TCP 時間戳
最佳截止日期
用最簡單的術(shù)語來說，TCP 時間戳只是在數(shù)據(jù)包上添加時間戳，以解決由非常快速的序列號回繞引起的歧義。如果一個段看起來包含新數(shù)據(jù)，但其時間戳早于上一個在接收窗口內(nèi)的數(shù)據(jù)包，則該序列號已被重新回繞，而“新”數(shù)據(jù)包實際上是一個較舊的重復項。這解決了即使在極端情況下重傳的歧義。
但是，該擴展不僅僅是檢測舊數(shù)據(jù)包。TCP 時間戳的另一個主要功能是更精確的往返時間測量（RTTm）。
需要準確的 RTT 估算
當兩個對等方都支持時間戳時，每個 TCP 段都攜帶兩個附加數(shù)字：時間戳值和回顯時間戳。
TCP Timestamp option (TSopt): Kind: 8, Length: 10+-------+----+----------------+-----------------+|Kind=8 | 10 |TS Value (TSval)|EchoReply (TSecr)|+-------+----+----------------+-----------------+1 1 4 4
準確的 RTT 估算對于 TCP 性能至關(guān)重要。TCP 會自動重新發(fā)送未確認的數(shù)據(jù)。重傳由計時器觸發(fā)：如果超時，則 TCP 會將尚未收到確認的一個或多個數(shù)據(jù)包視為丟失。然后再發(fā)送一次。
但是，“尚未得到確認” 并不意味著該段已丟失。也有可能是接收方到目前為止沒有發(fā)送確認，或者確認仍在傳輸中。這就造成了一個兩難的困境：TCP 必須等待足夠長的時間，才能讓這種輕微的延遲變得無關(guān)緊要，但它也不能等待太久。
低網(wǎng)絡(luò)延遲 VS 高網(wǎng)絡(luò)延遲
在延遲較高的網(wǎng)絡(luò)中，如果計時器觸發(fā)過快，TCP 經(jīng)常會將時間和帶寬浪費在不必要的重發(fā)上。
然而，在延遲較低的網(wǎng)絡(luò)中，等待太長時間會導致真正發(fā)生數(shù)據(jù)包丟失時吞吐量降低。因此，在低延遲網(wǎng)絡(luò)中，計時器應(yīng)該比高延遲網(wǎng)絡(luò)中更早到期。所以，TCP 重傳超時不能使用固定常量值作為超時。它需要根據(jù)其在網(wǎng)絡(luò)中所經(jīng)歷的延遲來調(diào)整該值。
往返時間的測量
TCP 選擇基于預期的往返時間（RTT）的重傳超時。RTT 事先是未知的。它是通過測量發(fā)送的段與 TCP 接收到該段所承載數(shù)據(jù)的確認之間的增量來估算的。
由于多種因素使其而變得復雜。
- 出于性能原因，TCP 不會為收到的每個數(shù)據(jù)包生成新的確認。它等待的時間非常短：如果有更多的數(shù)據(jù)段到達，則可以通過單個 ACK 數(shù)據(jù)包確認其接收。這稱為“累積確認”。
- 往返時間并不恒定。這是有多種因素造成的。例如，客戶端可能是一部移動電話，隨其移動而切換到不同的基站。也可能是當鏈路或 CPU 的利用率提高時，數(shù)據(jù)包交換花費了更長的時間。
- 必須重新發(fā)送的數(shù)據(jù)包在計算過程中必須被忽略。這是因為發(fā)送方無法判斷重傳數(shù)據(jù)段的 ACK 是在確認原來的傳輸數(shù)據(jù)（畢竟已到達）還是在確認重傳數(shù)據(jù)。
最后一點很重要：當 TCP 忙于從丟失中恢復時，它可能僅接收到重傳段的 ACK。這樣，它就無法在此恢復階段測量（更新）RTT。所以，它無法調(diào)整重傳超時，然后超時將以指數(shù)級增長。那是一種非常具體的情況（它假設(shè)其他機制，如快速重傳或 SACK 不起作用）。但是，使用 TCP 時間戳，即使在這種情況下也會進行 RTT 評估。
如果使用了擴展，則對等方將從 TCP 段的擴展空間中讀取時間戳值并將其存儲在本地。然后，它將該值作為 “回顯時間戳” 放入發(fā)回的所有數(shù)據(jù)段中。
因此，該選項帶有兩個時間戳：它的發(fā)送方自己的時間戳和它從對等方收到的最新時間戳。原始發(fā)送方使用 “回顯時間戳” 來計算 RTT。它是當前時間戳時鐘與 “回顯時間戳” 中所反映的值之間的增量。
時間戳的其他用途
TCP 時間戳甚至還有除 PAWS（防止序列號回繞） 和 RTT 測量以外的其他用途。例如，可以檢測是否不需要重發(fā)。如果該確認攜帶較舊的回顯時間戳，則該確認針對的是初始數(shù)據(jù)包，而不是重新發(fā)送的數(shù)據(jù)包。
TCP 時間戳的另一個更晦澀的用例與 TCP syn cookie 功能有關(guān)。
在服務(wù)器端建立 TCP 連接
當連接請求到達的速度快于服務(wù)器應(yīng)用程序可以接受新的傳入連接的速度時，連接積壓最終將達到其極限。這可能是由于系統(tǒng)配置錯誤或應(yīng)用程序中的錯誤引起的。當一個或多個客戶端發(fā)送連接請求而不對 “SYN ACK” 響應(yīng)做出反應(yīng)時，也會發(fā)生這種情況。這將用不完整的連接填充連接隊列。這些條目需要幾秒鐘才會超時。這被稱為“同步泛洪攻擊”。
TCP 時間戳和 TCP Syn Cookie
即使隊列已滿，某些 TCP 協(xié)議棧也允許繼續(xù)接受新連接。發(fā)生這種情況時，Linux 內(nèi)核將在系統(tǒng)日志中打印一條突出的消息：
端口 P 上可能發(fā)生 SYN 泛洪。正在發(fā)送 Cookie。檢查 SNMP 計數(shù)器。
此機制將完全繞過連接隊列。通常存儲在連接隊列中的信息被編碼到 SYN/ACK 響應(yīng) TCP 序列號中。當 ACK 返回時，可以根據(jù)序列號重建隊列條目。
序列號只有有限的空間來存儲信息。因此，使用 “TCP Syn Cookie” 機制建立的連接不能支持 TCP 選項。
但是，對兩個對等點都通用的 TCP 選項可以存儲在時間戳中。ACK 數(shù)據(jù)包在回顯時間戳字段中反映了該值，這也允許恢復已達成共識的 TCP 選項。否則，cookie 連接受標準的 64KB 接收窗口限制。
常見誤區(qū) —— 時間戳不利于性能
不幸的是，一些指南建議禁用 TCP 時間戳，以減少內(nèi)核訪問時間戳時鐘來獲取當前時間所需的次數(shù)。這是不正確的。如前所述，RTT 估算是 TCP 的必要部分。因此，內(nèi)核在接收/發(fā)送數(shù)據(jù)包時總是采用微秒級的時間戳。
在包處理步驟的其余部分中，Linux 會重用 RTT 估算所需的時鐘時間戳。這還避免了將時間戳添加到傳出 TCP 數(shù)據(jù)包的額外時鐘訪問。
整個時間戳選項在每個數(shù)據(jù)包中僅需要 10 個字節(jié)的 TCP 選項空間，這不會顯著減少可用于數(shù)據(jù)包有效負載的空間。
常見誤區(qū) —— 時間戳是個安全問題
一些安全審計工具和（較舊的）博客文章建議禁用 TCP 時間戳，因為據(jù)稱它們泄露了系統(tǒng)正常運行時間：這樣一來，便可以估算系統(tǒng)/內(nèi)核的補丁級別。這在過去是正確的：時間戳時鐘基于不斷增加的值，該值在每次系統(tǒng)引導時都以固定值開始。時間戳值可以估計機器已經(jīng)運行了多長時間（正常運行時間 uptime）。
從 Linux 4.12 開始，TCP 時間戳不再顯示正常運行時間。發(fā)送的所有時間戳值都使用對等設(shè)備特定的偏移量。時間戳值也每 49 天回繞一次。
換句話說，從地址 “A” 出發(fā)，或者終到地址 “A” 的連接看到的時間戳與到遠程地址 “B” 的連接看到的時間戳不同。
運行 sysctl net.ipv4.tcp_timeamp=2 以禁用隨機化偏移。這使得分析由諸如 wireshark 或 tcpdump 之類的工具記錄的數(shù)據(jù)包跟蹤變得更容易 —— 從主機發(fā)送的數(shù)據(jù)包在其 TCP 選項時間戳中都具有相同的時鐘基準。因此，對于正常操作，默認設(shè)置應(yīng)保持不變。
選擇性確認
如果同一數(shù)據(jù)窗口中的多個數(shù)據(jù)包丟失了，TCP 將會出現(xiàn)問題。這是因為 TCP 確認是累積的，但僅適用于按順序到達的數(shù)據(jù)包。例如：
- 發(fā)送方發(fā)送段 s_1、s_2、s_3、... s_n
- 發(fā)送方收到 s_2 的 ACK
- 這意味著 s_1 和 s_2 都已收到，并且發(fā)送方不再需要保留這些段。
- s_3 是否應(yīng)該重新發(fā)送？ s_4 呢？ s_n？
發(fā)送方等待 “重傳超時” 或 “重復 ACK” 以使 s_2 到達。如果發(fā)生重傳超時或到達了 s_2 的多個重復 ACK，則發(fā)送方再次發(fā)送 s_3。
如果發(fā)送方收到對 s_n 的確認，則 s_3 是唯一丟失的數(shù)據(jù)包。這是理想的情況。僅發(fā)送單個丟失的數(shù)據(jù)包。
如果發(fā)送方收到的確認段小于 s_n，例如 s_4，則意味著丟失了多個數(shù)據(jù)包。發(fā)送方也需要重傳下一個數(shù)據(jù)段。
重傳策略
可能只是重復相同的序列：重新發(fā)送下一個數(shù)據(jù)包，直到接收方指示它已處理了直至 s_n 的所有數(shù)據(jù)包為止。這種方法的問題在于，它需要一個 RTT，直到發(fā)送方知道接下來必須重新發(fā)送的數(shù)據(jù)包為止。盡管這種策略可以避免不必要的重傳，但要等到 TCP 重新發(fā)送整個數(shù)據(jù)窗口后，它可能要花幾秒鐘甚至更長的時間。
另一種方法是一次重新發(fā)送幾個數(shù)據(jù)包。當丟失了幾個數(shù)據(jù)包時，此方法可使 TCP 恢復更快。在上面的示例中，TCP 重新發(fā)送了 s_3、s_4、s_5、...，但是只能確保已丟失 s_3。
從延遲的角度來看，這兩種策略都不是最佳的。如果只有一個數(shù)據(jù)包需要重新發(fā)送，第一種策略是快速的，但是當多個數(shù)據(jù)包丟失時，它花費的時間太長。
即使必須重新發(fā)送多個數(shù)據(jù)包，第二個也是快速的，但是以浪費帶寬為代價。此外，這樣的 TCP 發(fā)送方在進行不必要的重傳時可能已經(jīng)發(fā)送了新數(shù)據(jù)。
通過可用信息，TCP 無法知道丟失了哪些數(shù)據(jù)包。這就是 TCP 選擇性確認（SACK）的用武之地了。就像窗口縮放和時間戳一樣，它是另一個可選的但非常有用的 TCP 特性。
SACK 選項
TCP Sack-Permitted Option: Kind: 4, Length 2+---------+---------+| Kind=4 | Length=2|+---------+---------+
支持此擴展的發(fā)送方在連接請求中包括 “允許 SACK” 選項。如果兩個端點都支持該擴展，則檢測到數(shù)據(jù)流中丟失數(shù)據(jù)包的對等方可以將此信息通知發(fā)送方。
TCP SACK Option: Kind: 5, Length: Variable+--------+--------+| Kind=5 | Length |+--------+--------+--------+--------+| Left Edge of 1st Block |+--------+--------+--------+--------+| Right Edge of 1st Block |+--------+--------+--------+--------+| |/ . . . /| |+--------+--------+--------+--------+| Left Edge of nth Block |+--------+--------+--------+--------+| Right Edge of nth Block |+--------+--------+--------+--------+
接收方遇到 s_2 后跟 s_5 ... s_n，則在發(fā)送對 s_2 的確認時將包括一個 SACK 塊：
+--------+-------+| Kind=5 | 10 |+--------+------+--------+-------+| Left edge: s_5 |+--------+--------+-------+------+| Right edge: s_n |+--------+-------+-------+-------+
這告訴發(fā)送方到 s_2 的段都是按順序到達的，但也讓發(fā)送方知道段 s_5 至 s_n 也已收到。然后，發(fā)送方可以重新發(fā)送那兩個數(shù)據(jù)包（s_3、s_4），并繼續(xù)發(fā)送新數(shù)據(jù)。
神話般的無損網(wǎng)絡(luò)
從理論上講，如果連接不會丟包，那么 SACK 就沒有任何優(yōu)勢。或者連接具有如此低的延遲，甚至等待一個完整的 RTT 都無關(guān)緊要。
在實踐中，無損行為幾乎是不可能保證的。即使網(wǎng)絡(luò)及其所有交換機和路由器具有足夠的帶寬和緩沖區(qū)空間，數(shù)據(jù)包仍然可能丟失：
- 主機操作系統(tǒng)可能面臨內(nèi)存壓力并丟棄數(shù)據(jù)包。請記住，一臺主機可能同時處理數(shù)萬個數(shù)據(jù)包流。
- CPU 可能無法足夠快地消耗掉來自網(wǎng)絡(luò)接口的傳入數(shù)據(jù)包。這會導致網(wǎng)絡(luò)適配器本身中的數(shù)據(jù)包丟失。
- 如果 TCP 時間戳不可用，即使一個非常小的 RTT 的連接也可能在丟失恢復期間暫時停止。
使用 SACK 不會增加 TCP 數(shù)據(jù)包的大小，除非連接遇到數(shù)據(jù)包丟失。因此，幾乎沒有理由禁用此功能。幾乎所有的 TCP 協(xié)議棧都支持 SACK —— 它通常只在不進行 TCP 批量數(shù)據(jù)傳輸?shù)牡凸?IOT 類的設(shè)備上才不存在。
當 Linux 系統(tǒng)接受來自此類設(shè)備的連接時，TCP 會自動為受影響的連接禁用 SACK。
總結(jié)
本文中研究的三個 TCP 擴展都與 TCP 性能有關(guān)，最好都保留其默認設(shè)置：啟用。
TCP 握手可確保僅使用雙方都可以理解的擴展，因此，永遠不需因為對等方可能不支持而全局禁用該擴展。
關(guān)閉這些擴展會導致嚴重的性能損失，尤其是 TCP 窗口縮放和 SACK。可以禁用 TCP 時間戳而不會立即造成不利影響，但是現(xiàn)在沒有令人信服的理由這樣做了。啟用它們還可以支持 TCP 選項，即使在 SYN cookie 生效時也是如此。
