如何使用IIS通过HTTP隧道传输多玩家游戏数据以最大限度地减少延迟？

Question

我想创建一个基于浏览器的网络游戏。为了确保尽可能多的人使用它，我想将所有流量嵌入标准HTTP包中。

假设我使用IIS作为我的后端，我应该如何对此进行编码以最大限度地减少延迟？

从内存中的共享状态开始使用某种ASP应用程序（可能是ASP.NET MVC）是否合理？或者我应该从一开始就计划编写自己的某种IIS插件？或者我应该放弃IIS并编写自定义服务器吗？

从每个客户端重复查询开始是否合理，比如说每秒十次，或者我应该以某种方式使数据更像流（如果是这样的话）？

Answer 1

这可以很好地工作，但你不得不做一些不那么“传统”的事情。

要做到这一点，不要做单独的请求，保持请求打开，然后用打开的连接传输数据。

你可以尝试使用像Bayeux这样的协议，但这里没有规则。

Here's an example with ASP.NET using COMET

Answer 2

将应用设计为每秒10次点击Web服务器并不是一个好主意。 Web服务器专为较低频率的客户端请求而设计，可能需要比您的游戏使用的更大的处理时间和响应大小。这并不是说Web服务器无法应对它不会是一个有效的客户端 - 服务器匹配。

对于每秒需要多个数据包的任何类型的应用程序，你真的应该考虑比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实现。