共用方式為

聯合 TCP/IP 區段的規則

  • 發行項

本節會定義當接收區段聯合 (RSC) 支援的迷你埠驅動程式必須聯合指定 TCP 連線的區段時所指定的規則。 如果違反任何規則，就會產生例外狀況，而迷你埠驅動程式必須中止區段的聯合。

迷你埠驅動程式必須更新單一聯合單位的 IP 和 TCP 標頭， (SCU) 。 迷你埠驅動程式必須透過 SCU 重新計算 TCP 和 IPv4 總和檢查碼，並鏈結 TCP 承載。

下列兩個流程圖的第一個說明聯合區段和更新 TCP 標頭的規則。 此流程圖是指區分有效重複 ACK 和視窗更新的機制。 第二個流程圖描述這些機制。

這些流程圖是以瞭解 RSC 規則的參考方式提供。 只要維護正確性，硬體實作就可以優化流程圖。

流程圖中會使用下列詞彙：

詞彙 描述
Seg。SEQ 傳入區段的序號。
H.SEQ 目前追蹤 SCU 的序號。
Seg。Ack 傳入區段的通知編號。
H.ACK 目前追蹤 SCU 的通知號碼。
Seg。WND 傳入區段所公告的視窗。
H.WND 目前追蹤 SCU 所公告的視窗。
Seg。萊恩 傳入區段的 TCP 承載長度。
H.LEN 目前追蹤 SCU 的 TCP 承載長度。
Seg。Nxt SEG 的總和。SEQ和SEG。LEN。
H.NXT H.SEQ和H.LEN的總和。
H.DupAckCount 已聯合至 SCU 的重複 ACK 數目。 此數字應為零，
Seg。Tsval 目前收到的區段中的 Timestamp 值。 此值的格式定義于 RFC 1323中。
H.Tsval 目前追蹤 SCU 中的 Timestamp 值。
Seg。TSecr 目前收到的區段中的 Timestamp Echo Reply 。
H.TSecr 目前追蹤 SCU 中的 時間戳記回應回復 。

流程圖，顯示聯合區段和更新 TCP 標頭的規則。

顯示區分有效重複 ACK 和視窗更新之機制的流程圖。

流程圖顯示迷你埠驅動程式可能會聯合不同 ACK 號碼的區段。 不過，迷你埠驅動程式必須遵循下列有關 ACK 號碼的規則，如上述第一個流程圖所示：

  • 執行序號檢查之後，如果傳入的純 ACK 符合下列其中一個或兩個條件，可能會聯合到目前追蹤的 SCU：

    • H.ACK == Seg。ACK。

    • 所追蹤聯合區段中的重複 ACK 計數為零。 換句話說， H.DupAckCount == 0。

      換句話說，不是重複 ACK 或視窗更新的任何純 ACK 都會觸發例外狀況，且不得聯合。 所有這類純 ACK 都必須以個別區段表示。 此規則可確保 RSC 不會影響 Windows TCP 壅塞控制演算法的行為或效能。

  • 內送資料區段 (SEG。ACK == H.ACK) 或內送的 piggy 支援 ACK (SEG。如果符合下列兩個條件，ACK >H.ACK) 可能會聯合到目前追蹤的 SCU：

    • 區段與序列空間中的 SCU 連續。 換句話說，SEG。SEQ == H.NXT。
    • 所追蹤聯合區段中的重複 ACK 計數為零。 換句話說， H.DupAckCount == 0。

重複 ACK 聯合的其他注意事項

重複的 ACK 行為

迷你埠驅動程式應該將重複的 ACK 區段視為相當於純 ACK，而不是將其聯合。 在此情況下，如果有任何) 指示，且指出重複的 ACK 區段為個別區段，則必須完成目前的 SCU (。 因為 Windows 用戶端預設會使用選擇性通知 (SACK) ，所以重複的 ACK 區段可能會產生例外狀況。 如需 範例，請參閱接收區段聯合的範例 。 如果指出具有DupAckCount> 0 的區段，NDIS 會在介面上停用 RSC。

追蹤由資料區段組成的 SCU 時處理重複的 ACK

使用H.LEN> 0 (追蹤 SCU 時，如果接下來有重複的 ACK 到達，則追蹤 SCU 應該如下所示完成：包含資料) 的聯合區段：

  1. 應該追蹤新的 SCU，從重複的 ACK 開始。

  2. 新 SCU 的 DupAckCount 應設定為零。

  3. 如果收到其他重複的 ACK，則 DupAckCount 應該遞增。

在此情況下， DupAckCount 會小於重複 ACK 的數目。 主機堆疊會正確處理計數。

追蹤由純累積 ACK 組成的 SCU 時處理重複的 ACK

追蹤包含單一純累積 ACK (規則的 SCU 時，禁止將多個純 ACK 聯合) ，如果接下來出現重複的 ACK，則追蹤 SCU 的 DupAckCount 應該遞增。 如果收到其他重複的 ACK，它也應該遞增。 在此情況下， DupAckCount 會等於聯合的重複 ACK 數目。

當在 DPC 中收到的第一個區段是重複的 ACK 時

在此情況下，NIC 無法判斷接收的區段是否為重複的 ACK，因為它不會維護任何狀態。 因此，區段應該視為純 ACK，如下所示：

  1. 應該從此區段開始追蹤新的 SCU。

  2. 新 SCU 的 DupAckCount 應設定為零。

  3. 針對收到的每個額外重複 ACK， DupAckCount 應該遞增 1。

在此情況下， DupAckCount 會等於 1 小於重複 ACK 的實際數目。 主機堆疊會正確處理計數。

重複的 ACK 豁免

迷你埠驅動程式可能會處理與純 ACK 相等的重複 ACK 區段，而不是將其聯合。 在此情況下，如果有任何) 指示，且指出重複的 ACK 區段為個別區段，則必須完成目前的 SCU (。 因為 Windows 用戶端預設會使用 SACK，所以重複的 ACK 區段可能會產生例外狀況。 如需範例，請參閱 接收區段聯合的範例。 此豁免不適用於視窗更新區段。

使用時間戳選項聯合區段

TCP 時間戳記選項是唯一可合法聯合的選項。 使用此選項聯合區段會保留為實作特定的決策。 如果迷你埠驅動程式使用時間戳選項聯合區段，則必須遵循下列流程圖中所述的規則：

流程圖，描述使用 TCP 時間戳記選項聯合區段的規則。

注意

檢查SEG。TSval= H.TSval> 必須使用模數-232 算術來執行，類似于用於 TCP 序號的算術。 請參閱 RFC 793，第 3.3 節。

指出聯合區段時，下列頻外資訊必須如下所示，設定描述聯合區段之NET_BUFFER_LIST結構的NetBufferListInfo成員：

  • 聯合的區段數目必須儲存到 NetBufferListInfo[TcpRecvSegCoalesceInfo]。CoalescedSegCount 成員。 這個數位只代表已聯合的資料區段。 禁止純 ACK 聯合，且視窗更新區段不得計入此欄位的一部分。

  • 重複的 ACK 計數必須儲存到 NetBufferListInfo[TcpRecvSegCoalesceInfo]。DupAckCount 成員。 上述第一個流程圖說明如何計算此值。

  • 當具有 TCP 時間戳記選項的區段已聯合時， NetBufferListInfo[RscTcpTimestampDelta] 必須填入組成 SCU 之聯合區段序列中最早和最新 TCP 時間戳記值之間的絕對差異。 SCU 本身應該包含聯合區段序列中所見的最新 TCP 時間戳記值。

只有在CoalescedSegCount成員大於零時，才會解譯DupAckCount和RscTcpTimestampDelta成員。 如果 CoalescedSegCount 為零，則會將區段視為非聯合的非 RSC 區段。

如需 NetBufferListInfo 成員內容的相關資訊，請參閱 NDIS_NET_BUFFER_LIST_INFO 和 NDIS_RSC_NBL_INFO。

PSH 位應該是所有聯合區段的 ORed。 換句話說，如果 PSH 位是在任一個別區段中設定，迷你埠驅動程式應該在 SCU 中設定 PSH 位。

完成 SCU 牽涉到：

  • 重新計算 TCP，如果適用的話，IPv4 總和檢查碼。

  • 更新 IP 標頭，如 更新聯合區段的 IP 標頭中所述。

  • 將 TCP 和 IP 標頭中的 ECN 位和 ECN 欄位設定為個別區段中設定的相同值。

處理 TCP/IP IPsec 區段

網路卡可能會報告 RSC 和 IPsec 工作卸載功能。 (請參閱 判斷網路介面卡的 RSC 功能) 不過，如果支援 IPsec 工作卸載，則不得嘗試聯合受 IPsec 保護的區段。