我是一名開發人員，設計的網路服務會受到 iPhone 用戶端的嚴重打擊，這種情況有好有壞。去年，iPhone 應用程式的下載量超過 10 百萬次，現在我正在讓用戶在線上互動。
我想調整將託管基於 TCP 的網路服務的伺服器的 TCP 實作。發送的每個請求大小將是“小”（例如 < 256 位元組）。好吧，你已經明白了，它是一個遊戲伺服器（令人震驚！）。
僅供參考，我對這個特定服務的 UDP（或 UDP 之上的可靠層，例如 ENet 和 RakNet 中看到的）不感興趣，因為遊戲不像 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：針對有損網路進行最佳化
我的伺服器預設為比克其“目標是設計一種協議，能夠在高速長距離網絡上將性能擴展至每秒數十吉比特，同時保持強大的公平性、穩定性和 TCP 友好性。”
僅從微小的描述來看，韋斯特伍德聽起來更合適，因為它「旨在更好地處理大頻寬延遲產品路徑（大管道），由於傳輸或其他錯誤（洩漏管道）而導致潛在的資料包丟失，以及動態負載（動態管道）」。
我在這裡是否陷得太深了，還是這符合課程的標準？
你們通常會為哪些類型的事情調整 TCP/IP？如何？有哪些經驗法則需要了解？
對於我的具體情況，您有哪些至理名言？
多謝！
答案1
因此，正如您所發現的，TCP 擁塞控制是一個相當複雜的領域。
對於這種特殊情況，由於請求較小，您將希望盡可能保持連接打開，因為每個請求一個連接將佔用五個資料包，而您可以將平均值降至如果您保持連接，則多於兩個數據包。
NODELAY 對於遊戲伺服器來說是正確的選擇；您希望立即傳送 256 字節，但這不是一個完整的段，因此 Nagle 將暫停，除非您使用 NODELAY。
如果您的伺服器有大量內存，那麼內存選項沒什麼大不了的，新核心有它們。
至於擁塞控制演算法，您發現了 Westwood。另一個選項是 CUBIC。您可以只選擇一個，也可以做一些研究並對它們進行基準測試。這可能是一項相當大的工作，但對於 1000 萬客戶來說這是值得的。因此，我希望在一台或三台 Mac 上使用流量產生器（因為它們具有與手機相同的 TCP 實作）、一個充當路由器（稍後會詳細介紹）和您的一台伺服器，看看情況如何。
現在，中間的 Linux 機器應該運行了ns-3因此您可以模擬比乙太網路交換器更複雜的路徑。然後，您可以捕獲 TCP 連線發送端的一些資料包跟踪，並使用以下命令進行分析：tcptrace或wireshark 的tcptrace 繪圖模式。 tcptrace 文件很好地介紹了分析 TCP 擁塞行為。