WebSocket网页和服务器如何保持一条不断线的实时通道

聊天框、弹幕、股票行情、在线客服的消息，这些页面不用刷新就能自己更新，靠的都是 WebSocket。它和普通 HTTP 请求最大的区别是连接不会断：握手一次之后，浏览器和服务器随时能互相发消息。本文讲清它和 HTTP 的差别、工作流程和适用场景，听完就能分清什么时候该用它、什么时候不该用。

你有没有想过，网页聊天时对方的消息是怎么“自己冒出来”的？普通网页的工作方式像寄信：浏览器发一个 HTTP 请求问一句，服务器回一句，通信就结束了。想知道有没有新消息，只能不停地再问——这叫轮询，每隔几秒问一次“有新消息吗”，既费流量，消息还最多迟到好几秒。WebSocket 就是为了解决这个问题诞生的：它让浏览器和服务器之间保持一条不断线的通道，有消息随时推过来。
WebSocket 和 HTTP 是什么关系？它借了 HTTP 的门、走的是自己的路。连接开始时，浏览器先发一个带 Upgrade 标记的 HTTP 请求，相当于跟服务器说“这条线咱别挂断，换成长连接”；服务器同意后回一个确认，这一步叫握手。握手成功，这条 TCP 连接就不再是问答模式了，而是变成一条双向通道：浏览器可以随时给服务器发消息，服务器也可以随时给浏览器推消息，不需要谁先开口。地址写法也成对：ws:// 是明文版，wss:// 是加密版，正好对应 http 和 https，正式网站都该用 wss。
连上之后，消息以“帧”为单位一小段一小段地传，体积比 HTTP 请求小得多——HTTP 每次请求都要带上一大堆头信息，长连接里这些重复的头都省了。所以 WebSocket 不只是“不用等”，还更省。连接保持期间还有一个小心跳机制：双方定时互发一个很小的 ping/pong 包，证明“线还通着”，对方没回应就判定掉线，客户端自动重连。做实时功能时，断线重连和心跳保活是必须配套的两件事，光连上不算完。
它适合什么场景？凡是“服务器要主动告诉浏览器”的事都适合：在线聊天和网站客服（访客发消息、客服回复，都是即时推送）、直播弹幕和评论、股票和币价行情、订单状态变化通知、多人协同编辑、在线游戏。不适合的也很明确：普通页面打开、表单提交、看文章这类一问一答就结束的事，老老实实用 HTTP 就行，没必要为了它们养一条长连接——长连接是占着服务器连接数的，每多一个在线用户就多一份占用。
实际用的时候有两点要心里有数。第一，连接数就是成本：一万人同时在线聊天，就是一万条连接挂在服务器上，内存和端口都要算账，大流量场景通常要配专门的消息推送服务或多台机器分摊。第二，连接断了怎么办要提前设计好：网络一切换（比如手机从 WiFi 切到流量）连接就断，客户端要自动重连，重连期间漏掉的消息要靠“拉取最近记录”补回来，不然用户会看到消息丢失。