什么是WebSocket?基础知识梳理

聊天应用和实时行情为什么能在不刷新页面的情况下即时更新?

什么是WebSocket

普通的HTTP通信是一种"请求-响应"协议:服务器只有在客户端发出请求后才能响应,因此永远无法主动把新信息告诉客户端。WebSocket突破了这一限制,让连接保持打开状态,服务器和客户端任何一方都可以在需要时随时发送消息,实现真正的双向实时通信。

WebSocket出现之前的方式:轮询

在WebSocket出现之前,网站通过轮询来模拟实时效果——客户端每隔几秒钟就反复向服务器询问"有新消息吗?"。短轮询会用持续不断的请求给服务器和网络带来不必要的压力;长轮询让服务器延迟响应,直到确实有新事件发生,情况有所改善,但每次请求仍然带着完整的HTTP头部开销,而且依然不是真正的双向通信。WebSocket用一条持久连接取代了这种反复请求,解决了这个问题。

握手与协议升级

WebSocket连接一开始只是一个普通的HTTP请求。客户端发送一个带有"Upgrade: websocket"头部的请求,如果服务器接受,就会以HTTP状态码101(Switching Protocols)作出响应。从这一刻起,同一条底层TCP连接不再遵循HTTP的请求-响应方式,而是变成了双方随时都能发送数据帧的WebSocket连接。

"ws://"与"wss://"的区别

ws://是未加密的WebSocket连接,而wss://是经过TLS加密的WebSocket连接——两者的关系就如同HTTP与HTTPS。与普通网站一样,传输任何敏感数据时都应始终使用wss://,以防止传输过程中被窃听或篡改。出于安全考虑,大多数浏览器也会阻止从HTTPS页面发起未加密的ws://连接请求。

实际应用场景

WebSocket(或类似的实时技术)支撑着许多常见体验:聊天应用中消息无需刷新即可即时显示、股票和加密货币行情实时跳动、在线游戏中的状态实时同步,以及多人协作文档中彼此的光标和编辑内容实时可见,都是它在幕后发挥作用的典型例子。

WebSocket与替代技术的比较

如果只需要服务器向客户端推送数据、而不需要反向通信,Server-Sent Events(SSE)可以是更简单的替代方案,它构建在普通HTTP之上,实现简单,也更容易融入现有的HTTP基础设施。而对于聊天或游戏这类客户端也需要频繁发送消息的场景,WebSocket真正的双向通信能力则更为合适。

WebSocket与HTTP之间的关系

人们很容易把WebSocket想象成取代HTTP的东西,但实际上它一开始就是一个HTTP请求,只有在握手成功(状态码101)之后才会切换协议。这意味着WebSocket服务器仍然需要正确处理最初的HTTP请求,而一些只理解普通HTTP的基础设施——比如某些老旧的代理服务器或限制严格的防火墙——有时会干扰这次升级过程。

为什么生产环境中的WebSocket应用需要额外的配套机制

一个基础的WebSocket连接可能会在双方都没有立即察觉的情况下悄然断开——比如手机从Wi-Fi切换到蜂窝网络,或电脑进入休眠状态——因此实际应用通常会加入周期性的ping/pong心跳帧来检测连接是否已经失效,并配备自动重连逻辑来恢复连接。此外,与无状态的HTTP请求不同,每一条WebSocket连接都是长期存在且带状态的,这意味着要把WebSocket服务横向扩展到多台服务器上,还需要额外的处理方式,常见做法是使用会话保持(sticky session)或共享消息代理,确保客户端始终能连接到保存着其连接状态的那台服务器。

常见问题

防火墙会阻止WebSocket连接吗?

会。一些管控严格的企业网络或公共Wi-Fi防火墙,会阻止标准HTTP/HTTPS端口(80和443)之外的连接,或阻止协议升级请求。不过大多数WebSocket服务都会直接使用HTTPS通常使用的443端口来运行,从而将这种风险降到最低。

WebSocket在移动网络环境下也能稳定运行吗?

在Wi-Fi与蜂窝网络之间切换,或者屏幕熄灭、应用转入后台时,连接都可能会断开,因此实际应用中通常会内置自动重连逻辑,专门应对这类中断情况。