WebSocket是一种在单个TCP连接上进行全双工通信的协议，与传统的HTTP轮询相比，它能让服务端主动向客户端推送消息，延迟低、开销小，是即时通讯、实时推送、在线协作等场景的首选方案。本文将以云服务器为例，完整讲解WebSocket长连接从环境准备到上线运行的配置过程。
一、WebSocket与HTTP轮询的本质区别
在理解WebSocket之前，先看看传统方案的问题。HTTP是无状态的请求响应协议，客户端想知道有没有新消息，只能不停地发请求去问服务端，这就是所谓的轮询。轮询频率低了消息延迟高，频率高了又浪费带宽和服务器资源，连接频繁建立销毁，开销非常大。
WebSocket通过一次HTTP握手完成协议升级，之后这条连接就保持打开状态，客户端和服务端都可以随时向对方发送数据。一次握手、长期使用，消息推送几乎实时到达，头部开销也只有几个字节。对于聊天室、在线客服、行情推送、游戏状态同步这类需要高频通信的应用，WebSocket的优势是压倒性的。
二、云服务器环境准备
搭建之前需要做好几项基础工作。首先是云服务器的选购与系统安装，推荐使用CentOS或Ubuntu系统，配置方面2核4G起步即可满足中小规模的即时通讯需求。如果服务部署在国内，域名需要进行备案，WebSocket服务同样受此约束。
其次是安全组与防火墙配置，这是新手最容易忽略的环节。登录云服务商控制台，在安全组规则中放行WebSocket服务监听的端口，比如常用的8080或自定义端口。同时在服务器内部执行以下命令开放防火墙：
以Ubuntu的ufw为例：sudo ufw allow 8080/tcp
以CentOS的firewalld为例：sudo firewall-cmd --permanent --add-port=8080/tcp && sudo firewall-cmd --reload
最后安装运行环境。WebSocket服务可以用Node.js、Java、Go、Python等多种语言实现，以Node.js为例，执行sudo apt install nodejs npm完成安装，再通过npm安装ws库即可快速搭建服务端。
三、编写WebSocket服务端代码
下面用Node.js和ws库写一个最小可用的服务端示例，实现连接管理、消息广播和心跳检测：
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', function connection(ws) {
console.log('新客户端接入');
ws.on('message', function incoming(data) {
wss.clients.forEach(function each(client) {
if (client.readyState === WebSocket.OPEN) client.send(data);
});
});
ws.on('close', () => console.log('客户端断开'));
});
这段代码实现了最基本的群聊广播逻辑：任何一个客户端发来的消息，都会推送给当前所有在线用户。实际项目中还需要在此基础上增加用户鉴权、房间隔离、消息持久化、离线消息补发等功能，建议把连接对象与用户ID建立映射关系，方便定向推送。
四、Nginx反向代理配置
生产环境中通常不会直接把WebSocket端口暴露给外网，而是用Nginx做反向代理，统一走80或443端口。关键在于proxy升级头的配置，否则握手会失败：
location /ws/ {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 300s;
}
需要特别注意proxy_read_timeout这个参数，它决定了Nginx在无数据传输时保持连接的时长。如果WebSocket连接上没有心跳，默认60秒后Nginx会主动断开连接，导致客户端频繁掉线。所以要么调大这个超时时间，要么在应用层实现心跳保活。
五、心跳保活与断线重连
长连接并不是建立之后就一劳永逸。中间的负载均衡器、防火墙、运营商网关都可能把长时间空闲的TCP连接悄悄断掉，客户端却毫不知情，表现为消息收不到但连接状态显示正常，这就是所谓的假在线。
解决办法是心跳机制：客户端每隔30秒左右发送一个ping帧或自定义心跳消息，服务端收到后回复pong，双方据此确认连接存活。如果连续几次心跳没有响应，就判定连接已死，主动关闭并触发重连逻辑。同时建议客户端采用指数退避的重连策略，避免服务端故障重启时所有客户端同时涌入造成雪崩。
| 问题现象 | 可能原因 | 排查方向 |
|---|---|---|
| 握手失败返回400 | Nginx未配置Upgrade头 | 检查proxy_set_header配置 |
| 连接约60秒后断开 | 代理超时或无心跳 | 调大timeout或添加心跳 |
| 外网无法连接 | 安全组未放行端口 | 控制台检查安全组规则 |
| 消息延迟明显 | 使用轮询而非长连接 | 确认客户端协议为wss或ws |
六、上线前的注意事项
正式上线前还有几点必须落实。第一，务必使用wss加密协议，也就是在Nginx上配置SSL证书后通过443端口提供WebSocket服务，否则通信内容明文传输，且很多浏览器环境下https页面不允许连接ws端口。
第二，考虑横向扩展问题。当用户量增长到单机扛不住时，需要部署多个WebSocket节点，此时连接分布在不同机器上，跨节点的消息投递要借助Redis的发布订阅功能或消息队列来完成。第三，做好连接数监控和资源限制，每条长连接都会占用文件描述符和内存，记得调整系统的ulimit限制，并用压测工具验证服务器的承载能力，做到心中有数再放量。