如何通過HTTP通過IIS傳輸多人遊戲數據以最大限度地減少延遲？

Question

我想創建一個基於瀏覽器的網絡遊戲。爲確保儘可能多的人使用它，我希望將所有流量都嵌入到標準的HTTP包中。

假設我使用IIS作爲我的後端，我該如何編碼以最小化延遲？

從內存中使用共享狀態的某種ASP應用程序（可能是ASP.NET MVC）開始合理嗎？還是應該從一開始就編寫我自己的某種IIS插件？或者我應該放棄IIS並改寫自定義服務器？

從每個客戶開始反覆查詢，每秒說十次，還是應該使數據更像流（如果是這樣）？

Answer 1

這可以工作得很好，但你將不得不做一些不太「常規」的事情。

爲了做到這一點，不要做單個的請求，請保持請求打開，然後用打開的連接傳輸數據。

你可以嘗試使用像Bayeux這樣的協議，但這裏沒有規則。

Here's an example with ASP.NET using COMET。

Answer 2

設計一個應用程序來每秒擊中一次Web服務器10次並不是一個好主意。 Web服務器專爲較少的客戶端請求而設計，並且可能比您的遊戲將使用的處理時間和響應大小更大。這並不是說一個Web服務器不能應付，它不會是一個有效的客戶端服務器匹配。

對於任何類型的需要每秒多個數據包的應用程序，您應該考慮使用比HTTP更輕鬆的協議，而HTTP相當詳細。例如，如果你的遊戲需要發送4個字節來註冊一個用戶的戰列艦座標，那麼你並不想傳輸額外的幾百字節的HTTP報頭。

我推薦一個像Siverlight of Flash這樣的瀏覽器插件技術。這兩種都支持TCP套接字連接。您將需要編寫自己的服務器來坐在TCP套接字的另一端。通過這種方法，您還可以將數據推送到客戶端，而無需依賴HTTP所需的客戶端輪詢機制。 AJAX。

Answer 3

標準HTTP消息將面臨的一個問題是頭數據的大小（以及缺乏控制）。

我參與了數百萬人玩過的Flash遊戲的設計。我們需要每隔幾秒鐘與服務器通信，並最終使用超輕量級JSON消息來節省帶寬並保持活躍。

JSON消息的大小：16個字節

HTTP標頭的大小：200+字節

HTTP是不是真的爲高流量，低等待時間要求良好的協議。它被設計用於較大的，較不頻繁的請求/響應模型，並且因此具有如304 Not Modified的狀態代碼。

您可能想要下載到自定義的TCP/IP實現。