TCP/IP 特定問題
某些程式設計技術遇到與 TCP/IP 實作連結的效能問題。 這類效能問題並不表示 TCP/IP 效率不佳或效能瓶頸;相反地，當無法瞭解 TCP/IP 作業時，就會看到這些問題。
下列問題會找出 TCP/IP 作業和網路應用程式開發選擇組合導致效能不佳的常見案例。
大量連線應用程式。
某些應用程式會為每個交易具現化新的 TCP 連線。 TCP 連線建立需要時間、貢獻額外的 RTT，而且受限於慢速啟動。 此外，關閉的連接受限於使用系統資源的 TIME-WAIT。
大量連線應用程式通常很常見，因為它們很容易建立;測試和錯誤處理非常簡單。 在持續性連線上偵測錯誤可能會花費大量程式代碼和精力，因此有時不會完成。
藉由重複使用 TCP 連線來補救這種情況。 除非交易透過多個連線多任務處理，否則這可能會導致透過 TCP 連線進行串行化。 如果採用此方法，連線數目應限制為兩個，而且需要應用層框架和進階錯誤處理。
長度為零的傳送緩衝區和封鎖傳送。
使用 setsockopt 函式關閉緩衝，將傳送緩衝區 （SO_SNDBUF） 設定為零，類似於關閉磁碟快取。 將傳送緩衝區設定為零併發出封鎖傳送時，應用程式有50%的機會達到200毫秒延遲通知。
除非您已考慮所有網路環境的影響，否則請勿關閉傳送緩衝。 其中一個例外狀況：使用重疊 I/O 的串流數據應該將傳送緩衝區設定為零。
Send-Send-Receive 程式設計模型。
建構應用程式以執行 send-send-receives 會增加遇到 Nagle 演算法的機會，這會導致 RTT+200 毫秒的延遲。 如果最後一個傳送小於 TCP 區段大小上限（MSS，單一數據報中的數據上限，則可能會遇到 Nagle 演算法）。 MSS 可以是非常大的值（IPv4 中為 64K，在 IPv6 中甚至更大），因此不要指望通常較小的 MSS。 更好的選項是使用 WSASend 或 memcpy 函式，將這兩個傳送合併成單一傳送。
大量同時連線。
除了特殊用途應用程式中，並行連線不應超過兩個。 超過兩個並行聯機會導致資源浪費。 良好的規則是每個目的地最多有四個短期連線，或兩個持續性連線。
相關主題