WebSocket 和 HTTP 相似,只是一个应用层协议,对下层透明,所以不涉及 TCP/IP。
由于浏览器支持了 WebSocket,所以在用 JS 写客户端的时候,是无需考虑数据的编码解码的。
以下主要针对服务器端而言。
[ 接收数据,需要做的是解码,即 decode ]
要接收WebSocket数据,一个端点(endpoint)要监听底层网络连接。
进来的数据必须作为WebSocket帧(frame)解析。https://tools.ietf.org/html/rfc6455#section-5.2
如果接收到控制帧(control frame),这个帧必须被处理。https://tools.ietf.org/html/rfc6455#section-5.5
接收到数据帧的时候,https://tools.ietf.org/html/rfc6455#section-5.6
端点(endpoint)必须把数据的 /type/ 作为已定义的 opcode(frame-opcode) 解释。https://tools.ietf.org/html/rfc6455#section-5.2
帧中的应用层数据(Application data)在消息的 /data/ 中定义。
如果帧包含一个未拆分的消息(unfragmented message),https://tools.ietf.org/html/rfc6455#section-5.4
它是在说一个包含类型 /type/ 和数据 /data/ 的WebSocket消息已被接收。
如果帧是被拆分消息(fragmented message)的一部分,应用层数据(Application data)随后的数据帧被连接起来而形成数据。
当最后一个片段(fragment)作为 FIN 比特(frame-fin)标示被接收,
说明WebSocket消息已经接收了数据 /data/(包括由片段组成的应用层数据)和类型 /type/ (碎片消息的第一帧)。
后来的数据帧必须被作为新的WebSocket解释。
扩展(extensions)可能改变数据如何读取的语义,https://tools.ietf.org/html/rfc6455#section-9
特别是包括 - 什么构成消息的边界。
在一个有效载荷(payload)中,扩展(extensions)为了在应用层数据前面添加扩展数据(extension data),可能也修改应用层数据(通过压缩它)。
服务器必须移除从客户端接收数据帧的掩码(masking)。https://tools.ietf.org/html/rfc6455#section-5.3
[ 发送数据,需要做的是编码,即 encode ]
要在一个WebSocket连接上发送包含 /data/ 的WebSocket消息,端点(endpoint)必须执行如下步骤。
1.端点(endpoint)必须保证WebSocket连接是 OPEN 状态(握手操作之后)。如果在任何端点上,WebSocket连接状态改变了,端点必须终止以下步骤。
2.端点必须封装 /data/ 到WebSocket帧中。https://tools.ietf.org/html/rfc6455#section-5.2
3.第一个数据帧的 opcode(frame-opcode)包含的数据必须 针对数据被接收者解释为文本数据或二进制数据 来设置为合适的值。https://tools.ietf.org/html/rfc6455#section-5.2
4.包含数据的最后帧FIN比特(frame-fin),必须被设置为1。https://tools.ietf.org/html/rfc6455#section-5.2
5.如果数据正在被客户端发送,帧必须被掩码。https://tools.ietf.org/html/rfc6455#section-5.3
6.如果针对WebSocket连接的扩展已经议定,额外的考虑因素可以按照这些扩展的定义来应用。https://tools.ietf.org/html/rfc6455#section-9
7.已形成的帧必须在底层网络连接上传输。
相信你也看明白了,这个过程是一个交互和阐述,实现需要遵照 section-5 的解释来 coding,而且只要实现功能,方式没有限制。