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。