TCP傳輸小數據包效率問題(譯自MSDN）
http://www.ftpff.com/blog/?q=node/16
摘要：當使用TCP傳輸小型數據包時，程序的設計是相當重要的。如果在設計方案中不對TCP數據包的
延遲應答，Nagle算法，Winsock緩沖作用引起重視，將會嚴重影響程序的性能。這篇文章討論了這些
問題，列舉了兩個案例，給出了一些傳輸小數據包的優化設計方案。
背景：當Microsoft TCP棧接收到一個數據包時，會啟動一個200毫秒的計時器。當ACK確認數據包
發出之後，計時器會復位，接收到下一個數據包時，會再次啟動200毫秒的計時器。為了提升應用程序
在內部網和Internet上的傳輸性能，Microsoft TCP棧使用了下面的策略來決定在接收到數據包後
什麼時候發送ACK確認數據包：
1、如果在200毫秒的計時器超時之前，接收到下一個數據包，則立即發送ACK確認數據包。
2、如果當前恰好有數據包需要發給ACK確認信息的接收端，則把ACK確認信息附帶在數據包上立即發送。
3、當計時器超時，ACK確認信息立即發送。
為了避免小數據包擁塞網絡，Microsoft TCP棧默認啟用了Nagle算法，這個算法能夠將應用程序多次
調用Send發送的數據拼接起來，當收到前一個數據包的ACK確認信息時，一起發送出去。下面是Nagle
算法的例外情況：
1、如果Microsoft TCP棧拼接起來的數據包超過了MTU值，這個數據會立即發送，而不等待前一個數據
包的ACK確認信息。在以太網中，TCP的MTU(Maximum Transmission Unit)值是1460字節。
2、如果設置了TCP_NODELAY選項，就會禁用Nagle算法，應用程序調用Send發送的數據包會立即被
投遞到網絡，而沒有延遲。
為了在應用層優化性能，Winsock把應用程序調用Send發送的數據從應用程序的緩沖區復制到Winsock
內核緩沖區。Microsoft TCP棧利用類似Nagle算法的方法，決定什麼時候才實際地把數據投遞到網絡。
內核緩沖區的默認大小是8K，使用SO_SNDBUF選項，可以改變Winsock內核緩沖區的大小。如果有必要的話，
Winsock能緩沖大於SO_SNDBUF緩沖區大小的數據。在絕大多數情況下，應用程序完成Send調用僅僅表明數據
被復制到了Winsock內核緩沖區，並不能說明數據就實際地被投遞到了網絡上。唯一一種例外的情況是：
通過設置SO_SNDBUT為0禁用了Winsock內核緩沖區。
Winsock使用下面的規則來向應用程序表明一個Send調用的完成：
1、如果socket仍然在SO_SNDBUF限額內，Winsock復制應用程序要發送的數據到內核緩沖區，完成Send調用。
2、如果Socket超過了SO_SNDBUF限額並且先前只有一個被緩沖的發送數據在內核緩沖區，Winsock復制要發送
的數據到內核緩沖區，完成Send調用。
3、如果Socket超過了SO_SNDBUF限額並且內核緩沖區有不只一個被緩沖的發送數據，Winsock復制要發送的數據
到內核緩沖區，然後投遞數據到網絡，直到Socket降到SO_SNDBUF限額內或者只剩余一個要發送的數據，才
完成Send調用。
案例1
一個Winsock TCP客戶端需要發送10000個記錄到Winsock TCP服務端，保存到數據庫。記錄大小從20字節到100
字節不等。對於簡單的應用程序邏輯，可能的設計方案如下：
1、客戶端以阻塞方式發送，服務端以阻塞方式接收。
2、客戶端設置SO_SNDBUF為0，禁用Nagle算法，讓每個數據包單獨的發送。
3、服務端在一個循環中調用Recv接收數據包。給Recv傳遞200字節的緩沖區以便讓每個記錄在一次Recv調用中
被獲取到。
性能：
在測試中發現，客戶端每秒只能發送5條數據到服務段，總共10000條記錄，976K字節左右，用了半個多小時
才全部傳到服務器。
分析：
因為客戶端沒有設置TCP_NODELAY選項，Nagle算法強制TCP棧在發送數據包之前等待前一個數據包的ACK確認
信息。然而，客戶端設置SO_SNDBUF為0，禁用了內核緩沖區。因此，10000個Send調用只能一個數據包一個數據
包的發送和確認，由於下列原因，每個ACK確認信息被延遲200毫秒：
1、當服務器獲取到一個數據包，啟動一個200毫秒的計時器。
2、服務端不需要向客戶端發送任何數據，所以，ACK確認信息不能被發回的數據包順路攜帶。
3、客戶端在沒有收到前一個數據包的確認信息前，不能發送數據包。
4、服務端的計時器超時後，ACK確認信息被發送到客戶端。
如何提高性能：
在這個設計中存在兩個問題。第一，存在延時問題。客戶端需要能夠在200毫秒內發送兩個數據包到服務端。
因為客戶端默認情況下使用Nagle算法，應該使用默認的內核緩沖區，不應該設置SO_SNDBUF為0。一旦TCP
棧拼接起來的數據包超過MTU值，這個數據包會立即被發送，不用等待前一個ACK確認信息。第二，這個設計
方案對每一個如此小的的數據包都調用一次Send。發送這麼小的數據包是不很有效率的。在這種情況下，應該
把每個記錄補充到100字節並且每次調用Send發送80個記錄。為了讓服務端知道一次總共發送了多少個記錄，
客戶端可以在記錄前面帶一個頭信息。
案例二：
一個Winsock TCP客戶端程序打開兩個連接和一個提供股票報價服務的Winsock TCP服務端通信。第一個連接
作為命令通道用來傳輸股票編號到服務端。第二個連接作為數據通道用來接收股票報價。兩個連接被建立後，
客戶端通過命令通道發送股票編號到服務端，然後在數據通道上等待返回的股票報價信息。客戶端在接收到第一
個股票報價信息後發送下一個股票編號請求到服務端。客戶端和服務端都沒有設置SO_SNDBUF和TCP_NODELAY
選項。
性能：
測試中發現，客戶端每秒只能獲取到5條報價信息。
分析：
這個設計方案一次只允許獲取一條股票信息。第一個股票編號信息通過命令通道發送到服務端，立即接收到
服務端通過數據通道返回的股票報價信息。然後，客戶端立即發送第二條請求信息，send調用立即返回，
發送的數據被復制到內核緩沖區。然而，TCP棧不能立即投遞這個數據包到網絡，因為沒有收到前一個數據包的
ACK確認信息。200毫秒後，服務端的計時器超時，第一個請求數據包的ACK確認信息被發送回客戶端，客戶端
的第二個請求包才被投遞到網絡。第二個請求的報價信息立即從數據通道返回到客戶端，因為此時，客戶端的
計時器已經超時，第一個報價信息的ACK確認信息已經被發送到服務端。這個過程循環發生。
如何提高性能：
在這裡，兩個連接的設計是沒有必要的。如果使用一個連接來請求和接收報價信息，股票請求的ACK確認信息會
被返回的報價信息立即順路攜帶回來。要進一步的提高性能，客戶端應該一次調用Send發送多個股票請求，服務端
一次返回多個報價信息。如果由於某些特殊原因必須要使用兩個單向的連接，客戶端和服務端都應該設置TCP_NODELAY
選項，讓小數據包立即發送而不用等待前一個數據包的ACK確認信息。
提高性能的建議：
上面兩個案例說明了一些最壞的情況。當設計一個方案解決大量的小數據包發送和接收時，應該遵循以下的建議：
1、如果數據片段不需要緊急傳輸的話，應用程序應該將他們拼接成更大的數據塊，再調用Send。因為發送緩沖區
很可能被復制到內核緩沖區，所以緩沖區不應該太大，通常比8K小一點點是很有效率的。只要Winsock內核緩沖區
得到一個大於MTU值的數據塊，就會發送若干個數據包，剩下最後一個數據包。發送方除了最後一個數據包，都不會
被200毫秒的計時器觸發。
2、如果可能的話，避免單向的Socket數據流接連。
3、不要設置SO_SNDBUF為0，除非想確保數據包在調用Send完成之後立即被投遞到網絡。事實上，8K的緩沖區適合大多數
情況，不需要重新改變，除非新設置的緩沖區經過測試的確比默認大小更高效。
4、如果數據傳輸不用保證可靠性，使用UDP。
