【IT168 技术文档】

    最近关于HTML 5 Web Socket的流言已经满天飞，它通过Web上的一个单一Socket定义了一个全双工通信信道，HTML 5 Web Socket并不是普通HTTP通信的增强版，它代表着一个巨大的进步，特别是针对实时的、事件驱动的Web应用程序。

    Google的工程师Ian Hickson说“数据的字节数急剧减少到2字节，延迟从150毫秒减少到50毫秒，实际上，这两个因素已经足以引起Google的兴趣了”。通过在一个浏览器中模拟全双工连接，HTML 5 Web Socket对Web通信带来了显著的改善。

    让我们与传统的解决方案相比，看看HTML 5 Web Socket是如何减少不必要的网络流量和延迟的。

    当前的Web通信——头疼的轮询(Polling)

    通常，当浏览器访问一个网页时，会向托管该网页的Web服务器发送一个HTTP请求，Web服务器识别这一请求，并返回响应。例如，股票价格，新闻报道，门票销售，流量模式，医疗设备读数等，在浏览器渲染页面时，响应可能会过期，如果你想获得最新的“实时”信息，你可以不断地手动刷新页面，但显然这不是最好的办法。

    目前提供的实时Web程序主要是围绕轮询和其它服务器端推送技术进行的，最著名的是Comnet，它推迟了HTTP响应的结束，基于Comnet的推送通常是使用JavaScript结合长轮询(Long Polling)或流连接策略实现的。

    使用轮询时，浏览器定期发送HTTP请求，并立即收到响应，这种技术是交付实时信息的第一次尝试，显然，如果知道消息传递的时间间隔，这算是一个好办法，因为你可以在服务器上的信息可用时同步客户端请求，但实时数据往往是不可预测的，不可避免会产生一些不必要的请求，导致许多连接处于打开状态，有些不必关闭的连接却被关闭了。

    使用长轮询时，浏览器向服务器发送一个请求，服务器在既定期限内保持请求处于打开状态，如果在此期间收到通知，向客户端发送一个包含消息的响应，如果在此期间没有收到消息，服务器发送一个响应终止打开的请求。最重要的是要理解，当你的信息容量很高时，长轮询与传统的轮询相比不提供任何性能改善。实际上，它可能更糟，因为长轮询可能会失控进入一个死循环。

    使用流时，浏览器发送一个完整的请求，但服务器发送一个响应，并保存打开状态，然后不断更新使其一直保持打开（或在一段时间内保持打开），无论何时消息准备好发送时，响应就更新，但服务器不会发送一个结束的响应，因此连接就一直保持打开状态，后面发送的消息就可以继续使用这个连接。但流仍然是封装在HTTP中的，阻扰了防火墙和代理服务器选择缓冲区中的内容进行响应，因此消息传递的时间就延长了。许多流式Comnet解决方案都转向了长轮询，另外，TLS（SSL）连接可以用来屏蔽来自缓冲区的响应，但在这种情况下，每个连接消耗的服务器资源更多了。

    最终，所有这些方法都提供了实时数据，包含HTTP请求和响应头，其中包含许多额外的，不必要的头数据，最重要的是，全双工连接需要的不仅仅是从服务器到客户端的下行连接。为了模拟基于半双工HTTP上的全双工通信，目前的许多解决方案都使用了两个连接：一个下行连接，一个上行连接。维护和协调这两个连接需要大量的系统开销，并增加了复杂性。简言之，HTTP不是为实时的，全双工通信设计的，如图1所示，它显示了构建一个Comnet Web应用程序的复杂性，它从后端数据源使用发布/订阅模式基于半双工HTTP显示实时数据。
 

图 1：Comnet程序的复杂性

    当你试图向外扩展那些Comet解决方案时，情况变得更糟糕，模拟基于HTTP的双向通信容易出错，即使最终用户感觉某些东西看起来象是一个实时Web应用程序，但这种“实时”体验的代价都是非常高昂的，需要付出更多的延迟等待时间，不必要的网络流量和对CPU性能的拖累。