浅析现代Web端im即时通讯开发技术

传统的Web端即时通讯技术从短轮询到长连询，再到Comet技术，在如此原始的HTML标准之下，为了实现所谓的“即时”通信，技术上可谓绞尽脑汁，极尽所能。

自从HTML5标准发布之后，WebSocket这类技术横空出世，实现Web端即时通讯技术的便利性大大提前，以往想都不敢想的真正全双工实时通信，如此早已成为可能。

 

在这里不打算详细介绍整个WebSocket协议的内容，根据我本人以前协议的学习思路，我挑重点使用问答方式来介绍该协议，这样读起来就不那么枯燥。

协议运行在OSI的哪层？

应用层，WebSocket协议是一个独立的基于TCP的协议。 它与HTTP唯一的关系是它的握手是由HTTP服务器解释为一个Upgrade请求。

协议运行的标准端口号是多少？

默认情况下，WebSocket协议使用端口80用于常规的WebSocket连接、端口443用于WebSocket连接的在传输层安全（TLS）RFC2818之上的隧道化口。

协议是如何工作的?

其中帧的一些重要字段需要解释一下：

    1）Upgrade：`upgrade`是HTTP1.1中用于定义转换协议的`header`域。它表示，如果服务器支持的话，客户端希望使用现有的「网络层」已经建立好的这个「连接（此处是 TCP 连接）」，切换到另外一个「应用层」（此处是 WebSocket）协议；

    2）Connection：`Upgrade`固定字段。Connection还有其他字段，可以自己给自己科普一下；

    3）Sec-WebSocket-Key：用来发送给服务器使用（服务器会使用此字段组装成另一个key值放在握手返回信息里发送客户端）；

    4）Sec-WebSocket-Protocol：标识了客户端支持的子协议的列表；

    5）Sec-WebSocket-Version：标识了客户端支持的WS协议的版本列表，如果服务器不支持这个版本，必须回应自己支持的版本；

    6）Origin：作安全使用，防止跨站攻击，浏览器一般会使用这个来标识原始域；

    7）Sec-WebSocket-Accept：服务器响应，包含Sec-WebSocket-Key 的签名值，证明它支持请求的协议版本。

关于Sec-WebSocket-Key和Sec-WebSocket-Accept的计算是这样的：

    所有兼容RFC 6455 的WebSocket 服务器都使用相同的算法计算客户端挑战的答案：将Sec-WebSocket-Key 的内容与标准定义的唯一GUID字符(258EAFA5-E914-47DA-95CA-C5AB0DC85B11)串拼接起来，计算出SHA1散列值，结果是一个base-64编码的字符串，把这个字符串发给客户端即可。

用代码就是实现如下：

    const key = crypto.createHash('sha1')

&nbs