每次请求新建后端WebSocket连接的成本与技术选型问询

性能层面 #

• 每次新建WebSocket都要走完TCP三次握手、TLS握手（wss场景）、HTTP升级握手全流程，光网络往返就要几十到上百毫秒，弱网环境下建连耗时甚至能到秒级。老旧SSR架构下用户每跳转一次页面、触发一次常规页面请求就会整页刷新，往往等WebSocket连接刚建好，用户已经跳到下一页，实时通知根本来不及触达，全是无用开销。
• 前端每个页面都要重复编写连接初始化、鉴权、消息绑定、异常处理逻辑，代码冗余度高，后续维护成本陡增。

稳定性层面 #

• Apache本身是面向短连接HTTP请求设计的，传统mod_php模式下每个请求会占用一个工作进程/线程，如果直接用Apache承载WebSocket，频繁创建销毁的连接会快速占满Apache的工作线程池，直接导致正常的PHP业务请求无法被处理，整站随机返回503错误。
• TCP连接频繁断开会产生大量TIME_WAIT状态的套接字，堆积到操作系统阈值之后，新的网络连接根本无法建立，甚至会影响服务器本身的SSH登录、内部服务通信等基础能力。
• 每次建连的几百毫秒空窗期内如果有通知下发，会直接漏推，没有额外补传逻辑的话用户完全感知不到丢失的消息。

可靠性层面 #

• 频繁建连断连很容易出现死连接残留：旧连接没被服务端及时感知断开，新连接已经完成建立，同一个用户会同时挂载多个无效连接，消息可能推到已失效的死连接上导致丢失，也可能顺着多个有效连接重复推送，用户收到多条重复通知。
• 每次新建连接都要走一遍用户鉴权逻辑，高并发场景下很容易打穿缓存，把鉴权依赖的数据库、Redis服务直接拖垮。

服务器负载层面 #

• 同等服务器配置下，频繁创建销毁WebSocket连接能承载的并发用户数只有常驻长连接方案的5%不到，光是TLS握手、TCP连接建立的CPU开销就是维持空闲长连接的几十倍。
• 频繁的连接创建销毁会产生大量硬件中断，快速耗尽文件描述符、临时端口等操作系统底层网络资源，同机器部署的数据库、缓存、定时任务等关联服务都会被牵连出故障。

连接泛滥的本质是SSR页面每次整页刷新时，前端逻辑无判断重复创建连接，和使用什么前端框架没有直接关系。Vue、React这类SPA框架之所以很少出现这个问题，只是因为SPA不会触发整页刷新，应用初始化一次就常驻，只需要建一次连接而已，不存在任何特殊的黑魔法。
针对老旧Apache/PHP SSR架构，完全可以用极低改造成本实现连接复用，不需要重构整个前端技术栈：

• 最省事的方案是实现全局连接单例：把WebSocket实例挂载到window全局对象上，页面加载时先判断实例是否存在、是否处于已连接状态，只要有可用连接就直接复用，绝对不重复新建。页面卸载时不要主动调用连接的close方法，避免无意义的断连。
• 更稳妥的方案是用SharedWorker维护唯一连接：编写一个几十行的SharedWorker脚本，在脚本内部初始化WebSocket连接，所有同域页面加载时都连接这个SharedWorker接收消息，不管用户开多少个标签页、怎么刷新跳转页面，整个浏览器环境只会存在一个活跃的WebSocket连接，从根源上避免重复建连，这套逻辑纯原生JS就能实现，不需要任何框架依赖。
• 如果只是实现系统通知这类服务端单向推送的场景，甚至不用上WebSocket，直接用SSE（Server-Sent Events）即可：SSE原生基于HTTP协议，和老Apache/PHP的兼容性远好于WebSocket，PHP端只要设置响应头为Content-Type: text/event-stream，关掉输出缓冲就能持续推送消息，前端用原生EventSourceAPI即可接入，自带断线重连能力，实现成本比WebSocket低一半还多，完全适配现有架构现状。

内容的提问来源于stack exchange，提问作者David E. Hollow