websocket和tcp区别,websocket服务器要多大

本文引用自“ 豆米博客”的《JS实时通信三把斧》系列文章，有优化和改动。

有关Web端即时通讯技术的文章我已整理过很多篇，阅读过的读者可能都很熟悉，早期的Web端即时通讯方案，受限于Web客户端的技术限制，想实现真正的“即时”通信，难度相当大。

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

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

本文将专门介绍WebSocket、socket.io、SSE这几种现代的Web端即时通讯技术，从适用场景到技术原理，通俗又不失深度的文字，特别适合对Web端即时通讯技术有一定了解，且想深入学习WebSocket等现代Web端“实时”通信技术，却又不想花时间去深读枯燥的IETF技术手册的读者。

“豆米”：现居杭州，热爱前端，热爱互联网，豆米是“洋芋(土豆-豆)”和“米喳(米)”的简称。

作者博客：https://blog.5udou.cn/

作者Github：https://github.com/linxiaowu66/

如果你对Web端即时通讯技术的前世今生不曾了解，建议先读以下文章：

1. 《新手入门贴：史上最全Web端即时通讯技术原理详解》
2. 《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
3. 《详解Web端通信方式的演进：从ajax、JSONP 到 SSE、Websocket》
4. 《网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket》

如果你对本文将要介绍的技术已有了解，建议进行专项学习，以便深入掌握：

1. 《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
2. 《SSE技术详解：一种全新的HTML5服务器推送事件技术》
3. 《WebSocket详解（三）：深入WebSocket通信协议细节》
4. 《理论联系实际：从零理解Websocket的通信原理、协议格式、安全性》
5. 《WebSocket从入门到精通，半小时就够！》

在这里不打算详细介绍整个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')

.update(req.headers['sec-websocket-key'] constants.GUID, 'binary')

.digest('base64')

至于为什么需要这么一个步骤，可以参考《理论联系实际：从零理解WebSocket的通信原理、协议格式、安全性》一文。

引用如下：

Sec-WebSocket-Key/Sec-WebSocket-Accept在主要作用在于提供基础的防护，减少恶意连接、意外连接。

作用大致归纳如下：

• 1）避免服务端收到非法的websocket连接（比如http客户端不小心请求连接websocket服务，此时服务端可以直接拒绝连接）；
• 2）确保服务端理解websocket连接。因为ws握手阶段采用的是http协议，因此可能ws连接是被一个http服务器处理并返回的，此时客户端可以通过Sec-WebSocket-Key来确保服务端认识ws协议。（并非百分百保险，比如总是存在那么些无聊的http服务器，光处理Sec-WebSocket-Key，但并没有实现ws协议。。。）；
• 3）用浏览器里发起ajax请求，设置header时，Sec-WebSocket-Key以及其他相关的header是被禁止的。这样可以避免客户端发送ajax请求时，意外请求协议升级（websocket upgrade）；
• 4）可以防止反向代理（不理解ws协议）返回错误的数据。比如反向代理前后收到两次ws连接的升级请求，反向代理把第一次请求的返回给cache住，然后第二次请求到来时直接把cache住的请求给返回（无意义的返回）；
• 5）Sec-WebSocket-Key主要目的并不是确保数据的安全性，因为Sec-WebSocket-Key、Sec-WebSocket-Accept的转换计算公式是公开的，而且非常简单，最主要的作用是预防一些常见的意外情况（非故意的）。

强调：Sec-WebSocket-Key/Sec-WebSocket-Accept 的换算，只能带来基本的保障，但连接是否安全、数据是否安全、客户端/服务端是否合法的 ws客户端、ws服务端，其实并没有实际性的保证。

帧格式定义的格式如下：