設計問題-透過 TCP 使用 Winsock 傳送小型資料區段

文章翻譯 文章翻譯
文章編號: 214397 - 檢視此文章適用的產品。
全部展開 | 全部摺疊

在此頁中

結論

需要透過 TCP 傳送小型資料封包時 Winsock 應用程式的設計就會是特別重要。沒有考慮到帳戶之間的延遲的認可,Nagle 演算法和 Winsock 緩衝互動的設計可大幅影響效能。本文將告訴您使用兩種情況下研究這些問題,並衍生一系列的有效地從 Winsock 應用程式傳送小型資料封包的建議。

其他相關資訊

背景

當 Microsoft TCP 堆疊會接收資料封包時,200 毫秒延遲計時器會。當最後傳送的 ACK 時延遲計時器重設,並收到下一個資料封包時,會起始另一個 200 ms 的延遲。 若要增加 [網際網路及內部網路應用程式的效率,Microsoft TCP 堆疊會使用下列準則來決定何時收到的資料封包傳送一個 ACK:
  • 如果延遲計時器逾時前,會收到第二個資料封包,會傳送 「 ACK。
  • 如果是之前收到第二個資料封包,並且延遲計時器逾時,傳送相同的方向為 [ACK 資料 [ACK 是 piggybacked 資料區段,並立即傳送。
  • 當延遲計時器逾時,[ACK 就會傳送。
若要避免必須 congest 網路上的小型資料封包,Microsoft TCP 堆疊會讓聯合來自多個傳送呼叫和延遲傳送接收它直到先前的資料封包的 ACK 傳送到來自遠端主機的小型資料緩衝區的預設 Nagle 演算法。Nagle 演算法的兩個例外狀況如下:
  • 如果堆疊已經聯合大比 「 傳輸單元最大值 (MTU) 的資料緩衝區,而不需等待來自遠端主機 ACK 完整大小的封包會立即傳送。在乙太網路 TCP/IP 的 MTU 為 1460 位元組。
  • TCP_NODELAY 通訊端選項會套用至停用 Nagle 演算法,讓小型資料封包傳給遠端主機沒有延遲。
在應用程式層級的效能最佳化,Winsock 複本資料緩衝區,從應用程式會傳送 Winsock 核心緩衝區的呼叫。然後,堆疊會使用它自己的啟發式 (例如 Nagle 演算法) 來判斷何時實際放在網路傳輸上的 [封包。您可以變更 Winsock 核心緩衝區配置到通訊端使用 SO_SNDBUF 選項 (它將是預設的 8 K) 數量。必要時,Winsock 可以在一個以上的 [SO_SNDBUF 緩衝區大小會大幅緩衝區。在大多數情況下傳送完成應用程式中的只指出應用程式中的資料緩衝區傳送呼叫複製到 Winsock 核心緩衝區和並不表示資料已經達到網路媒體。唯一的例外是當您停用] 設定為 0 的 SO_SNDBUF Winsock 緩衝處理。

Winsock 使用下列規則來指示應用程式的傳送完成 (取決於如何呼叫傳送完成通知可能會從封鎖呼叫,信號的事件或呼叫告知函式傳回的函式等等):
  • 如果通訊端仍內 SO_SNDBUF 配額,Winsock 可複製的應用程式傳送的資料,並指出傳送完成應用程式。
  • 如果通訊端已超出 SO_SNDBUF 配額,且仍在堆疊核心緩衝區中的只有一個先前緩衝的傳送,Winsock 可複製資料的應用程式傳送,並指出傳送完成應用程式。
  • 如果通訊端已超出 SO_SNDBUF 配額,而且沒有堆疊核心緩衝區中一個以上的其中一個先前緩衝傳送 Winsock 會複製從應用程式傳送的資料。Winsock 不表示傳送完成應用程式,直到堆疊完成放回內 SO_SNDBUF 配額或只有一個未完成的傳送條件通訊端不足,無法傳送。

案例研究 1

概觀:

必須將 10000 記錄傳送到 Winsock TCP 伺服器在一個資料庫中儲存 Winsock TCP 用戶端。記錄大小變化從 20 個位元組長 100 個位元組。若要簡化應用程式邏輯,設計是,如下所示:
  • 用戶端會封鎖傳送。伺服器會封鎖接收。
  • 用戶端通訊端,將 [SO_SNDBUF 設定為 0,使每一筆記錄熄滅時,單一的資料區段中。
  • 伺服器會在迴圈中呼叫接收。公佈在接收緩衝區是 200 個位元組,如此一來,每一筆記錄可以接收一個接收呼叫中。

效能:

測試,期間,開發人員會尋找用戶端可能只傳送給伺服器的每秒的五筆記錄。總 10000 記錄,在 976 K 位元組的資料最大 (10000 * 100 / 1024年),採用多個半個小時傳送至伺服器。

分析:

因為用戶端並不會設定 TCP_NODELAY 選項,Nagle 演算法會強迫 TCP 堆疊,它可以在網路上傳送另一個封包前等待的 ACK。不過,用戶端已停用 SO_SNDBUF 選項設定為 0 Winsock 緩衝處理。因此,10000 傳送可呼叫可能會傳送和 ACK'ed 個別。每個 ACK 是延遲的 200 毫秒,因為發生下列情況伺服器的 TCP 堆疊上:
  • 當伺服器取得一個封包時,其 200 毫秒延遲計時器會。
  • 伺服器不需要傳送任何回,所以無法 piggybacked [ACK。
  • 除非經過認可的前一個封包,用戶端將不會傳送另一個封包。
  • 在伺服器上的延遲計時器終止,並在 ACK 傳送回。

如何改善:

有兩個這種設計問題。第一次,是延遲計時器問題。必須要能夠將兩個封包傳送到 200 ms.內伺服器,因為用戶端使用 Nagle 演算法的預設用戶端,它應該只使用預設 Winsock 緩衝,並不將 SO_SNDBUF 設為 0。一旦 TCP 堆疊已經聯合緩衝區大比 「 傳輸單元最大值 (MTU),而不需等待來自遠端主機 ACK 完整大小的封包會立即傳送。

其次,此設計會呼叫一個傳送這類小的大小的每一筆記錄。 傳送此大小的小型不是很有效率。在這種情況下,開發人員可能要填補到 100 個位元組的每一筆記錄,並傳送 80 的資料錄從一部用戶端一次傳送呼叫。若要讓知道多少記錄將會以總計傳送伺服器,在用戶端可能想要開始通訊時和修正程式大小的頁首,其中包含要遵循的記錄數目。

案例研究 2

概觀:

Winsock TCP 用戶端應用程式使用 Winsock TCP 伺服器的應用程式,提供股票報價服務開啟兩個連線。第一個連線作為命令通道,傳送至伺服器的股票符號。第二個連線為資料通道用來接收即時股票報價。建立兩個的連線後用戶端傳送至透過命令通道伺服器的股票符號,並等待 [即時股票報價到回來透過資料通道。只在接收第一個即時股票報價後,它可以傳送至伺服器的下一個股票符號要求。用戶端和伺服器不要設定 [SO_SNDBUF 及 TCP_NODELAY] 選項。

效能:

測試,期間,開發人員會尋找用戶端只取得每秒的五個引號。

分析:

這項設計只允許一個未完成的即時股票報價要求一次。第一個股票符號傳送至伺服器透過命令通道 (連線),且回應立即傳送從伺服器至用戶端透過資料通道 (連線)。然後,用戶端立即傳送第二個股票符號要求並傳送立即傳回要求緩衝區傳送呼叫中的複製到 Winsock 核心緩衝區。不過,用戶端 TCP 堆疊無法傳送要求從其核心緩衝區,請立即因為透過傳送第一個命令通道不認可還。200 毫秒延遲在計時器之後伺服器命令通道過期,第一次符號要求 ACK 回談到用戶端。然後,第二個引號要求是成功傳送至伺服器之後延遲為 200 ms.是第二個股票符號的報價來自回立即透過資料通道因為這次在用戶端資料通道延遲計時器已經過期。伺服器會接收到先前的報價回應的 ACK。(請記住用戶端無法傳送 200-ms 的第二個即時股票報價要求因此給予時間延遲計時器過期,並將一個 ACK 傳送至伺服器用戶端上的)。如此一來用戶端取得第二個引號回應,並可以發出另一個受限於相同的循環的報價要求。

如何改善:

以下兩個連接 (通道) 設計是不必要的。如果為即時股票報價要求和回應中使用只有一個連線報價要求 ACK 可以被 piggybacked 報價回應上,與回來立即。若要進一步改善效能,用戶端可能"multiplex"多個即時股票報價要求至伺服器的一個傳送呼叫,伺服器可能也"multiplex"多個報價回應至用戶端的一個傳送呼叫。如果兩個單向通道設計真的需要基於某些原因,雙方應該設定 TCP_NODELAY 選項,使小的封包可能會立即傳送而不必等待前一個封包的 ACK。

建議:

雖然這些兩個案例研究 fabricated,他們協助說明一些最糟的大小寫案例。牽涉到大量的小型資料區段的應用程式的設計時傳送並 recvs,您應該考慮下列方針:
  • 如果的資料區段都是不時間關鍵,應用程式應該聯合它們到較大的資料區塊,要傳遞至傳送呼叫。因為傳送緩衝區可能會被複製到 Winsock 核心緩衝區所以不應該太大緩衝區。有點少於 8 K 是通常是有效的。只要 Winsock 核心取得區塊大小超過 MTU,將會傳送出多個完整大小的封包,以及與任何項目會保留最後一個封包。傳送] 側邊除了最後一個封包不會叫用由 200 毫秒延遲計時器。最後一個封包如果它剛好是奇數封包將仍然受到延遲的認可演算法。如果傳送端堆疊會取得另一個區塊大於 MTU,它仍然可以略過 Nagle 演算法。
  • 如果可能請避免與單向資料流量的通訊端連線。透過單向通訊端的通訊是更加輕鬆地在 Nagle 受影響,並且延遲認可演算法。如果通訊] 後面的要求及回應流程,您應該使用單一的通訊端進行傳送和 recvs,使 [ACK 可以 piggybacked 上回應。
  • 如果所有小型資料區段有立即傳送,設定在傳送端 TCP_NODELAY 選項。
  • 除非您想要保證當依 Winsock 表示傳送完成時,將會傳送網路上的封包,您不應該將 [SO_SNDBUF 設定為零。在實際上預設 8 K 緩衝區 heuristically 判定工作適用於大多數的情況下而且您應該不變更它除非測試過新的 Winsock 緩衝區設定提供您較佳的效能,比預設值。而且,設定 SO_SNDBUF 為零,是大多是用於執行大量資料傳輸的應用程式很有幫助。甚至然後的最大的效率您應該使用它連同緩衝 (在任何指定時間的多個未完成傳送) 的雙精度浮點數並重疊的 I/O。
  • 如果資料傳遞並不需要保證,使用 UDP。

?考

如需延遲通知和 Nagle 演算法的詳細資訊,請參閱下列:

Braden r 鍵 [1989] RFC 1122、 網際網路主機--通訊圖層網際網路工程任務的需求強制。

屬性

文章編號: 214397 - 上次校閱: 2005年7月11日 - 版次: 3.1
這篇文章中的資訊適用於:
  • Microsoft Platform Software Development Kit-January 2000 Edition
關鍵字:?
kbmt kbdswnet2003swept kbapi kbinfo kbip kbnetwork kbwinsock KB214397 KbMtzh
機器翻譯
重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤,就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本:214397
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。

提供意見

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com