對於 iPhone 客戶端在 3G 等移動網路上命中的服務，有哪些 TCP 調整技巧？
我是一名開發人員，在設計網路服務方面有好有壞，這將受到 iPhone 客戶端的嚴重打擊。iPhone 應用程序在過去一年的下載量超過了 10MM，現在我讓使用者線上進行互動。
我想為將託管我的基於 TCP 的網路服務的伺服器調整 TCP 實現。發送的每個請求大小將是“小”（例如 < 256 字節）。好吧，你明白了，它是一個遊戲伺服器（令人震驚！）。
僅供參考，我對這種特定服務的 UDP（或在 ENet 和 RakNet 中看到的 UDP 上的可靠層）不感興趣，因為遊戲不像 Quake；必須可靠地接收所有數據包，這就是 TCP 的設計目的。因此，iPhone 客戶端和服務之間的連接將是“長期存在的”（盡可能多地——該死的隧道和電梯！）。
僅供參考，我在執行 Linux 2.6.18-164.9.1.el5 的伺服器上以 100Mbps 上行鏈路執行該服務。
我的目標是同時：
- 保持盡可能低的延遲；和
- 最小化每個連接的客戶端使用的記憶體量。
有大量與 TCP 相關的旋鈕需要調整！經過一些基礎研究後，似乎大多數人建議保持原樣。但是，有許多設置似乎應該針對特定情況進行調整。我知道這有點模糊，這就是我尋求幫助的原因。
考慮調整片狀網路上的小請求/響應同時盡可能減少記憶體的事情可能是：
- TCP/IP 實現可用的記憶體
- 設置“nodelay”選項（禁用 Nagle 算法，因為這是一個半實時遊戲伺服器）
- 擁塞控制算法
- 等等（還有什麼？）
考慮 TCP擁塞控制算法：
- reno：幾乎所有其他作業系統都使用的傳統 TCP
- 立方：CUBIC-TCP
- bic：BIC-TCP
- htcp：漢密爾頓 TCP
- 維加斯：TCP 維加斯
- westwood：針對有損網路進行了優化
我的伺服器預設使用bic，其“目標是設計一種協議，該協議可以在高速長距離網路上將其性能擴展到每秒數十吉比特，同時保持強大的公平性、穩定性和 TCP 友好性。”
僅從微小的描述來看，Westwood聽起來更貼切，因為它“旨在更好地處理大頻寬延遲產品路徑（大管道），由於傳輸或其他錯誤（洩漏管道）而導致潛在的封包遺失，以及動態負載（動態管道）”。
我是不是太深入了，還是這門課程的標準桿？
你們通常為哪些類型的東西調整 TCP/IP？如何？有哪些經驗法則需要了解？
對於我的具體情況，你有什麼智慧之言？
非常感謝！
因此，正如您所發現的，TCP 擁塞控制是一個相當複雜的領域。
對於這種特殊情況，由於請求很小，您將希望盡可能多地保持連接打開，因為每個請求的一個連接每個請求將佔用五個數據包，而您可以將平均值降至如果您保持連接，則多於兩個數據包。
NODELAY 是遊戲伺服器的正確選擇；您希望立即傳遞 256 字節，這不是一個完整的段，因此除非您使用 NODELAY，否則 Nagle 將暫停。
如果您的伺服器有大量記憶體，那麼記憶體選項沒什麼大不了的，新核心就可以了。
至於擁塞控制算法，您發現了 Westwood。另一種選擇是立方。您可以只選擇一個，也可以進行一些研究並對其進行基準測試。這可能是一項相當大的工作，但對於 1000 萬客戶來說，這是值得的。所以，我打算在一台或三台 Mac 上使用流量生成器執行模擬（因為它們與手機具有相同的 TCP 實現），中間有一個 Linux 機器充當路由器（稍後會詳細介紹）和你的一台伺服器，看看它是怎麼回事。
現在，中間的 Linux 機器應該執行ns-3，這樣您就可以模擬一個比乙太網交換機更複雜的路徑。然後，您在 TCP 連接的發送端擷取一些數據包跟踪，並使用tcptrace或wireshark 的 tcptrace 圖形模式對其進行分析。tcptrace 文件很好地介紹了分析 TCP 擁塞行為。