页面上要展示实时数据，用轮询达不到时效性要求，改用 websocket 或者 sse 方式长连接，这样服务端就被 socket 的长连接监听阻塞了，正常 http 请求就不能返回，而且前端的负载均衡，和 http 混在一起也不好搞。

这种 http 服务中，加入 websocket 是不是一般都单独用一个子域名，起单独的服务处理长链接问题？
你放到别的端口不就好了嘛?不阻塞 80 和 443 就好了啊。

你后端怎么实现的？不会是 fpm 吧

新开个端口，和开个子域名没区别呀
后端开始是线程池和消息队列的方式，后来发现前端负载均衡不好搞。不行的化，就用个子域名，配置一下跨域估计能行。


不说实现方式怎么讨论？

#新开个端口，和开个子域名没区别呀
怎么会没区别呢

我这 node 的服务器没事 http 和 websocket 共存 不过没有 LB 量也不大

其实如果只是简单使用还是轮询比较好弄，服务器别立刻返回，有数据再返回，否则一分钟超时一次，配合协程啥的很快就搞定了，还心跳啥啥的网络问题都不用管，又简单又稳定，等其他给数据也好实现，队列、redis 的 subpub 或者啥分布式锁什么的都可以，几分钟就搞出来了

时效性也妥妥的毫无问题

有多少并发啊，一台 linux 服务器能提供 6 万多个 socket 连接，剩下的就是每个连接消耗的内存。如果 ws 长连接的并发已经到了万这个量级，那最好是用一个新域名专门处理

同一个域名，不同路径，nginx 映射到不同 upstream, ws 的 header 要 upgrade 的

弄个服务专门保持连接，只负责转发消息不处理，自己内部用 mq 之类的东西与负责处理消息的服务交换数据，彻底解偶

阻塞 80/433 也没问题，你的服务器端不要直接用 webserver 监听 80/433 就行了，单独再写一个转发工具，判断是 http 就给 80/433，如果是 websocket，就转给你的 websocker server....

js 不都是协程吗？奇怪了你这用的什么框架？难道自己处理 socket ？

我看标题以为是浏览器对单一域名的最大连接数限制了你，结果点进来一看是服务端限制。咋说呢，你不懂计网，就别为难自己了，HTTP 挺好的，那么多成熟方案你随便抄一个就行了。
还有这位五更琉璃的老公，服务端程序进行 accept 不受 65535 最大端口数的限制。所以也不存在什么六万多的连接限制。

是的，这块我记错了，服务端没有端口数量限制，只取决于 CPU 内存资源