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