Comet和HTML 5 Web Socket之间的对决

    人们最关注的是HTML 5 Web Socket如何减少不必要的网络流量和延迟，我们比较一个轮询应用程序和Web Socket应用程序就知道了。

    对于轮询的例子，我创建了一个简单的Web应用程序，一个网页使用传统的发布/订阅模式从RabbitMQ消息代理请求实时的股票数据，它是通过轮询一个托管在Web服务器上的Java Servlet实现的，RabbitMQ消息代理从一个虚构的，不断更新价格的股票价格源接收数据，网页连接并订阅一个特定的股票频道（消息代理上的一个主题），使用XMLHttpRequest每秒更新一次进行轮询。当收到更新时，执行一些计算，然后将股票数据显示在图2所示的表中。

图 2：一个JavaScript股票行情应用程序

    注意：后端的股票源每秒实际上产生了大量的股票价格更新，因此使用每秒一次轮询的方式比使用长轮询方式更好，长轮询会产生许多连续的轮询，轮询会更有效地阻止传入更新。

    这一切看起来还不错，但仔细观察，你就会发现这种应用程序存在严重的问题，例如，使用Firefox的Firebug插件（允许你调试网页和监控页面加载和脚本执行时间），你可以看到每秒都有一个GET请求砸向服务器。打开Live HTTP Headers（另一个Firefox 插件，显示实时的HTTP消息头流量）揭示每个请求关联的消息头开销数量是相当惊人的。下面两个例子显示了一个请求和响应的HTTP消息头数据。

    例2：HTTP请求头

    例3：HTTP响应头

    HTTP请求和响应头信息开销总共包括871字节，而且还不包括任何数据，当然，这只是一个例子，你的消息头数据完全可能低于871字节，但我也看到过消息头数据超过2000字节的情况。在这个例子中，股票主题消息数据大约只有20个字符。

    当你把这样的程序大规模部署给用户时会怎么样？我们使用三个不同的用例观察一下该轮询应用程序关联的HTTP请求和响应头数据需要的网络吞吐量。

    用例A：1000客户端，每秒轮询一次
    网络吞吐量（871x1000）=871000字节=6968000比特/秒（6.6Mbps）

    用例B：10000客户端，每秒轮询一次
    网络吞吐量（871x10000）=8710000字节=69680000比特/秒（66Mbps）

    用例C：100000客户端，每秒轮询一次
    网络吞吐量（871x100000）=87100000字节=696800000比特/秒（665Mbps）

    这是一个不必要的巨大的网络吞吐量，这时我们可以使用HTML 5 Web Socket，我使用HTML 5 Web Socket重构了应用程序，给网页添加了一个事件处理程序，同步监听来自消息代理的股票更新消息。每个消息都是一个Web Socket帧，开销只有2个字节（而不是871字节），再来看看对网络吞吐量的影响。

    用例A：1000客户端，每秒轮询一次
    网络吞吐量（2x1000）=2000字节=16000比特/秒（0.015Mbps）

    用例B：10000客户端，每秒轮询一次
    网络吞吐量（2x10000）=20000字节=160000比特/秒（0.153Mbps）

    用例C：100000客户端，每秒轮询一次
    网络吞吐量（2x100000）=200000字节=1600000比特/秒（1.526Mbps）

    正如你在图3中可以看到的，与轮询解决方案相比，HTML 5 Web Socket减少了不必要的网络流量。
 

图 3：比较轮询和WebSocket应用程序之间的网络吞吐量

    延迟减少怎么样呢？看看图4便知，图中上半部分显示了半双工轮询方案的延迟，这里我们假设消息从服务器传输到浏览器需要50毫秒，轮询方式引入许多额外的延迟，因为当响应完成时，一个新的请求已经发送到服务器了，这个新请求又需要50毫秒，在此期间服务器不能发送任何消息给浏览器，导致额外的服务器内存消耗。

    图4下半部分显示了Web Socket方式产生的延迟，一旦连接升级到Web Socket，消息的传输会更及时，从服务器传输到浏览器仍然需要50毫秒，但Web Socket连接保持打开，之后就再也不用向服务器发送请求了。

图 4：轮询和Web Socket应用程序之间的延迟对比