WebSocket协议详解：与HTTP协议、定时轮询和长轮询技术的对比
WebSocket协议详解：与HTTP协议、定时轮询和长轮询技术的对比
WebSocket是一种在单个TCP连接上进行全双工通信的协议，它解决了HTTP协议在实时通信方面的一些局限性。本文将详细介绍WebSocket的工作原理，并将其与HTTP协议、定时轮询和长轮询等技术进行对比，帮助读者理解WebSocket的优势和应用场景。
1 为什么需要 WebSocket？
在使用HTTP协议时，用户点击网页上的按钮，客户端发送一次请求，服务器返回一次响应。不难发现，服务器从来都不会主动向客户端发送一次请求。
因此在HTTP协议中，客户端是主动方，服务器是被动方。考虑网页游戏的场景，通常情况下玩家不需要点击鼠标，怪物就能够源源不断地刷新出来。也就是说，在用户不做任何操作的情况下，客户端能够收到消息并发生变更。那么这种看起来像是服务器主动发送消息给客户端的场景是如何实现的呢？
何谓 “看起来像是”？答：在定时轮询和长轮询中，仍然是客户端主动发送请求，只是用户感知不到，误以为是服务器在主动发送数据。
最常见的做法是「HTTP定时轮询」，客户端定时自动发送HTTP请求到服务器，服务器收到请求后对客户端进行响应。这是一种「伪服务器推」的形式，它其实并不是服务器主动发送消息到客户端，而是客户端不断请求服务器，只是用户无感知而已。
使用该方式的场景很多，最常见的就是扫码登录。比如微信的登录平台，前端网页不知道用户是否完成扫码，于是不断向后端服务器询问。一般请求间隔是在1到2秒之间，保证用户在扫码后的1到2秒中能够得到反馈。
以上便是「HTTP定时轮询」，它的缺点在于：
- 每次请求消耗带宽，增加了下游服务器的负担；
- 最快情况下，用户也需要等待1到2秒才能触发下一次HTTP请求，完成页面的跳转。
说明：由于服务器是被动方，即使它知道用户扫码成功了也没办法主动告诉客户端，需要等待客户端的下一次请求，因此用户需要等待1到2秒才能完成页面的跳转。
更好的方案是「HTTP长轮询」，如果增大超时的时间，比如30秒，在这30秒内，只要服务器收到了用户的扫码请求，就可以立马返回给客户端。如果超时，那么客户端就立马发起下一次请求。
说明：HTTP协议的通信模式是一个请求搭配一个响应，即一问一答的模式。在定时轮询中，即使服务器知道了答案，但只要客户端没问，它就不能答。而在长轮询中，客户端提问后服务器并不急着回答，以避免浪费本次提问，从而保证了一旦服务器知道了答案就能立即进行回答。
这样就减少了HTTP请求的个数，并且响应也是及时的。采用该方案的有百度网盘。
2 WebSocket
上述两种解决方案，本质上还是客户端主动取数据，适用于扫码登录这种简单的应用场景。而网页游戏中有大量的数据需要由服务器主动推送到客户端，这就需要使用WebSocket技术了。
2.1 采用 TCP 全双工
维基百科
- 半双工：半双工的系统允许二台设备之间的双向资料传输，但不能同时进行。因此同一时间只允许一设备发送资料，若另一设备要发送资料，需等原来发送资料的设备发送完成后再处理。
- 全双工：全双工的系统允许二台设备间同时进行双向资料传输。
TCP协议支持全双工
虽然目前使用最广泛的HTTP1.1基于TCP协议，但是它规定同一时间内客户端和服务器只能有一方主动发送数据。这是因为HTTP在设计之初，考虑的是在网页中浏览文本的场景，能做到客户端发起请求、服务器进行响应即可。它并未考虑网页游戏这种，客户端和服务器之间需要相互主动发送大量数据的场景。为了更好地支持这样的场景，我们需要一个基于TCP的新协议——WebSocket协议。
注意：Socket和WebSocket的区别就像是雷锋和雷峰塔的区别。
2.2 建立 WebSocket 连接
在浏览网页时，我们一会儿使用HTTP协议看图文，一会儿使用WebSocket协议打游戏，一会儿刷视频。为了兼容这些应用场景，要求客户端和服务器在TCP三次握手建立起连接后，都统一使用HTTP请求先进行一次通信。
如果该请求是普通的HTTP请求，那么双方继续使用HTTP协议进行交互。如果该请求是建立WebSocket的请求，那么请求里会带上一些特殊的头部信息：
Connection: Upgrade # 客户端想升级协议
Upgrade: WebSocket # 客户端想升级成WebSocket协议
Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg # 用于验证的BASE64码
服务器使用公开算法将客户端的BASE64码变成一段字符串，放在HTTP响应里：
HTTP/1.1 101 Switching Protocols # 101协议切换状态码
Sec-WebSocket-Accept: iBJKv/ALlW2DobfoA4dmr3JHBCY= # 字符串
Upgrade: WebSocket
Connection: Upgrade
客户端也使用相同的公开算法将BASE64码变成一段字符串，如果和服务器传回来的字符串一致，那么验证通过。
WebSocket协议（ws协议）和HTTP协议都是基于TCP协议。在完成TCP三次握手之后，可以利用HTTP请求将HTTP协议升级为ws协议，后续双方使用ws协议的数据格式进行通信。
2.3 WebSocket 帧
在ws协议中，数据包被称为帧：
- opcode用于指明帧的数据类型，=1是指text类型，=2是指二进制类型
- payload用于指明所传输的数据的长度，单位是字节
3 WebSocket 解决的问题
这一小节相当于是总结了前文各种解决方案的优缺点。
3.1 HTTP 存在的问题
- HTTP协议是一种无状态协议，其特性决定了在每次会话结束后，服务器端无法识别下一次发起请求的客户端身份。因此，为了确保通信的准确性，每次通信都必须重新确认对方身份，对实时通讯造成了障碍。
- HTTP协议的通信遵循一次请求对应一次响应的模式。每次请求和响应都携带了大量的头部信息，这对于实时通讯而言，解析这些头部信息无疑增加了处理时间，从而降低了通信效率。
- HTTP协议的通信机制是客户端主动发起请求，服务器被动响应。这种模式限制了服务器端的主动性，即服务器无法在没有客户端请求的情况下主动发送信息，从而无法实现实时通讯中的主动推送功能。
3.2 Ajax 轮询存在的问题
Ajax轮询技术是指，客户端定期发起请求，以查询是否有新消息。若有新消息，则立即返回；若无，则等待预设的时间间隔后再次发起查询。该技术弥补了HTTP协议在实时更新方面的不足。
以一个具体场景为例：张三正在等待快递，由于他迫不及待，因此每隔10分钟就打电话给快递站询问快递是否到达。快递站无法主动通知张三，只有等到张三的电话才能告知他快递已到。
从上述例子中，我们可以看出两个问题：
- 假设张三的通话间隔为10分钟，在他收到快递前最后一次通话被告知尚未到达后，如果快递随即入库，那么张三在下一次通话时才能得知快递已到。这种通讯方式并不能算作实时通讯，因为可能存在10分钟的时间差。
- 假设张三所在的小区每天都有大量的快递需要接收，且每个人都采取主动致电的方式，那么快递站的电话占线也成为问题。
综上所述，Ajax轮询技术存在的问题主要包括：
- 推送延迟：即使数据变更，服务器也只能在客户端发来请求时返回响应。
- 服务器压力：频繁的轮询会对服务器造成较大压力。
- 难以平衡推送延迟与服务器压力：减小轮询间隔虽能降低延迟，但会增加压力；增大轮询间隔虽能减轻压力，但会提高延迟。
3.3 长轮询存在的问题
针对上述HTTP协议在实时通讯方面的局限性，出现了一种解决方案——长轮询技术。
长轮询技术是在HTTP协议的基础上，由客户端发起的一种特殊请求。在该机制中，如果服务器的数据没有发生变化，服务器将暂时挂起客户端的请求，直至数据更新或达到设定的超时时间才返回响应。如果超时，那么客户端会在收到响应后立即发起下一次长轮询请求。该技术克服了HTTP协议无法实现实时更新的缺陷，即一旦数据更新，服务器便迅速处理请求并返回响应。
在长轮询机制中，张三主动致电快递站并保持通话直至快递到达。
总体而言，长轮询技术存在以下优点：
- 没有推送延迟：服务器数据变更后，长轮询结束，能够迅速向客户端返回响应。
- 服务器压力小：长轮询的间隔通常较长，如30秒或60秒，且服务器在挂起连接期间并不会消耗过多的资源。
个人理解：虽然长轮询克服了定时轮询的诸多缺点，但是长轮询本质上还是需要客户端主动去发起请求，即需要张三亲自打电话去询问快递站，快递站是不会主动通知张三去取快递的。而WebSocket允许快递站通知张三，以帮助张三及时取到快递，因此它的实时性更好。
3.4 WebSocket 的改进
一旦WebSocket连接得以建立，后续的数据传输均采用帧序列的形式。在客户端主动断开WebSocket连接或服务器终止连接之前，双方无需重新发起连接请求。在处理大量并发连接及客户端与服务器之间交互频繁的场景下，此举显著降低了网络带宽资源的消耗，并展现出卓越的性能优势。客户端与服务器之间的消息发送与接收均在同一持久连接上进行，实现了真正的 “长连接”，其实时性优势尤为突出。