当你在手机上收到即时消息通知时，是否想过背后的技术经历了怎样的进化？从早期网页聊天时的"刷新才能看到新消息"，到如今直播弹幕的毫秒级响应，实时通信技术的发展堪称一部"效率革命史"。
一、轮询：像个心急的快递员不断敲门
2000年代初的网页聊天工具，采用的是最朴素的"轮询"机制。客户端就像个心急的快递员，每隔几秒就给服务器打个电话："有新消息吗？""有新消息吗？"这种被称为"短轮询"的方式，实现起来简单粗暴：
// 短轮询代码示意
function askServer() {
fetch('/new-messages')
.then(response => response.json())
.then(data => {
showMessages(data);
setTimeout(askServer, 3000); // 每3秒问一次
});
}这种方式的问题显而易见：服务器80%的回复都是"暂无新消息"，却要承受潮水般的请求。就像你网购后每5分钟给快递员打电话，双方都不堪其扰。据统计，早期聊天网站的服务器资源，有60%都浪费在处理这些无效请求上。
后来出现的"长轮询"稍微聪明一些：客户端发送请求后，服务器会"按住电话不挂"，直到有新消息才回复。这就像快递员说"有你的快递我再通知你"，而不是让你反复询问。但服务器仍需为每个用户维持一个"挂起的电话"WhatsApp网页版，在高并发时依然力不从心。
二、HTTP长连接：占着电话线不说话的通讯方式
随着HTTP/1.1的普及，"长连接"技术试图解决轮询的痛点。通过在响应头中加入Connection: keep-alive，客户端和服务器可以保持TCP连接不关闭，就像打完电话不挂线，下次直接说话。
这种机制让早期的AJAX应用如虎添翼。比如股票行情网站，原本需要每秒刷新一次页面，现在可以在一个连接里连续获取数据。但本质上，服务器依然只能"被动回答"，无法主动推送。就像你打电话问客服，对方不会主动告诉你"刚刚有新优惠"，必须等你再次提问。
长连接的另一个尴尬是"线头阻塞"——同一连接中WhatsApp网页版，前一个请求没处理完，后面的请求只能排队。这就像超市收银台，一个顾客结账慢了，后面所有人都得等着。
三、WebSocket：双向车道的信息高速公路
2011年，WebSocket协议（RFC 6455）的诞生彻底改变了游戏规则。它通过一次HTTP握手，将连接升级为全双工通道，就像把单向对讲机换成了双向电话。
握手过程堪称技术界的"身份验证"：客户端发送Upgrade: websocket请求，服务器返回101状态码表示"同意升级"，随后双方即可自由收发数据。最妙的是，后续通信不再需要HTTP头，数据帧最小只需2字节，比轮询节省75%的带宽。
// WebSocket连接示例
const socket = new WebSocket('wss://chat.example.com');
socket.onopen = () => socket.send('终于不用反复打电话了！');
socket.onmessage = (event) => showNewMessage(event.data);如今，WebSocket已成为实时应用的标配：股票行情系统用它推送毫秒级报价，在线协作工具靠它实现多人同步编辑，连美团这样的App都基于WebSocket构建了Pike推送服务，支撑每天数十亿条消息的实时投递。
技术进化背后的用户体验革命
从轮询到WebSocket，技术演进的核心驱动力始终是"降低延迟"和"减少浪费"。对比三种技术：
技术
实时性
服务器负载
带宽消耗
典型场景
短轮询
低（秒级延迟）
极高（无效请求多）
早期网页聊天室
长连接
中（秒级延迟）
中（连接挂起耗资源）
股票行情页面
WebSocket
高 (毫秒级)
低（单连接双向通信）
直播弹幕、在线游戏
美团技术团队的实践表明，采用WebSocket后WhatsApp网页版，消息推送延迟从平均3秒降至68毫秒，服务器带宽占用减少62%。这种提升直接转化为用户体验的飞跃——当你在直播间发送弹幕，看到即时显示的那一刻，正是WebSocket在默默工作。
技术的终极目标永远是"消失在用户体验中"。从需要手动刷新的轮询时代，到如今无感的实时交互，WebSocket不仅改变了技术实现，更重塑了我们对"即时"的认知。下一次收到消息通知时，不妨想想这个背后持续了二十年的技术进化故事。
