随着最近WebSocket服务器实现的高速增长，对于HTML5 Web Socket如何处理代理服务器，防火墙，以及负载平衡路由器出现了许多疑问。代理服务器是否会自动中断WebSocket连接？HTML5 Web Sockets是否能比Comet更好的处理防火墙与代理服务器问题呢？Web Sockets又是否是实行无缝的代理服务器遍历的银弹呢？在这篇文章中，我将会解释HTML5 Web Sockets是如何与代理服务器，负载平衡路由器以及防火墙进行交互的。此外，我将会解释Kazzing WebSocket网关及其Web Socket模仿功能如何带来额外的价值。
               
关于HTML5 Web Sockets与代理服务器

让我们从一些基本概念开始：HTML5 Web Sockets和代理服务器究竟是什么？

HTML5 Web Sockets

HTML5 Web Sockets规范定义了Web Sockets API，支持页面使用Web Socket协议与远程主机进行全双工的通信。它引入了WebSocket接口并且定义了一个全双工的通信通道，通过一个单一的套接字在Web上进行操作。HTML5 Web Sockets以最小的开销高效地提供了Web连接。相较于经常需要使用推送实时数据到客户端甚至通过维护两个HTTP连接来模拟全双工连接的旧的轮询或长轮询（Comet）来说，这就极大的减少了不必要的网络流量与延迟。

要使用HTML5 Web Sockets从一个Web客户端连接到一个远程端点，你要创建一个新的WebSocket实例并为之提供一个URL来表示你想要连接到的远程端点。该规范定义了ws://以及wss://模式来分别表示WebSocket和安全WebSocket连接。一个WebSocket连接是在客户端与服务器之间HTTP协议的初始握手阶段将其升级到Web Socket协议来建立的，其底层仍是TCP/IP连接。

Proxy Servers

一个代理服务器是作为客户端与另一个服务器之间的一个中介（比如，因特网上的一个web服务器）。代理服务器通常被用作内容缓存，因特网连接，安全，以及企业内容过滤。典型的，一个代理服务器被架设在私有网络与因特网之间。代理服务器可以监控流量并断开连接，如果该连接已打开很久。对于使用长期活跃连接的web应用来说（比如，Comet HTTP流或者HTML5 Web Sockets），代理服务器的问题是明显的：HTTP代理服务器——原本最初设计用来文档转移——可能会选择关闭流或闲置的WebSocket连接，因为它们看起好像是尝试连接一个没有回应的HTTP服务器。这一行为对于长久的连接，比如WebSockets来说，是存在问题的。另外，代理服务器可能会缓冲未加密的HTTP响应，这将会对HTTP响应流带来不可估计的延迟。

HTML5 Web Sockets和代理服务器

让我们看看HTML5 Web Sockets是如何与代理服务器工作的。WebSocket连接使用标准HTTP端口（80和443），这让很多人管它叫做“代理服务器和防火墙友好协议”。因此，HTML5 Web Sockets不需要安装新的硬件，或者要求公司网络开放新的端口——这两件事足以使任何新的协议夭折。在浏览器与WebSocket服务器之间不需要任何中间服务器（代理或反向代理服务器，防火墙，负载平衡路由器等等），只要服务器和客户端双方都理解Web Socket协议，WebSocket连接就可以顺利的建立。然而，在真实的环境中，许多网络流量都被路由到中间服务器。

一图胜千言。图1展示了一个简化的网络拓扑，客户端使用浏览器来访问后端基于TCP的服务，这里使用了全双工的HTML5 WebSocket连接。一些客户端位于公司网络内部，受到公司防火墙的保护，并被配置为通过显式的或者已知的代理服务器来访问因特网，这些代理服务器会提供内容缓存和安全；而其它的客户端则直接在因特网上访问WebSocket。两种情况中，客户端的请求都可能被路由到透明的，或者未知的代理服务器（例如，一个数据中心的代理服务器或者远程服务器前端的一个反向代理服务器）。代理服务器甚至还有可能有它们自己的显式的代理服务器，这又增加了WebSocket传输需要的中继数。

附件:
图1——有着显式和透明的代理服务器的Web Sockets架构

跟常规的使用请求/响应协议的HTTP传输不一样，WebSocket连接可以长时间保持打开。代理服务器也许可以支持这点并优雅地处理，但它们同时也可能带来破坏因素。