看了下这网站的实时提醒（如有人回复了你）是用延迟 POST 的形式（一二十秒一次？）
WebScoket/WS已经出来那么多年了，为什么还不用呢？
应该更简单也更快吧？
那叫long polling，长轮询
这是写discourse messagebus的作者的回复
2 个赞
我知道啊，刚毕业（8年前）接触的那个项目就用到了，毕竟那时还不太兼容 WebSocket 吧~
个人猜想哈， websocket是基于TCP长连接的，如果实时性要求不是那么高，比如现在的1,20秒一次的查询，就没必要维持个长连接了。
我也这样猜想，是不是现在这情况 ws 比 polling 成本更低~
用第三方服务的话（比如Pusher）都是按connection收费的，WS成本可能更高吧？
好奇问下大家, 相对于一个普通的每个请求都用 fetch/ajax/http 的网页, 把大多服务器数据请求(图片和文件除外)用WebSocket 会更节省服务器成本吗?
不用频繁地断开+连接…
吾好奇的就是, WebSocket会不会因为需要长期连接状态, 比起 HTTP的用完即走, 成本就会更高些?
还是说取决于具体请求的数量和频率? 大多数呢?
吾猜是WebSocket更快, 因为看稍微有点规模的网站都是动不动就几十上百个的请求, HEADER就浪费了一堆流量了(积少成多啊)
我觉得不会，用户打开一个站点下n个页面,但是却不做任何操作，就在那里放着，不知道什么时候想起来了就回来看一下(本坛有浏览器标签页开几百上千个的用户,不记得是那个帖子了)，这个时候WebSocket没必要一直在后台连着服务器占资源,应该断开,用户回来了在连,而WebSocket的特性就是适合一直连着,总是断开在连感觉又不适合
如果要实时通知新的消息是不是就没得选了？
其实有 requestAnimationFrame 可以应对你说的情况，判断到超过一段时间，例如1分钟都没切到页面，就断开socket，再每几分钟轮寻检查一次有没有数据更新或通知，一旦用户切换回页面就立刻更新数据并开启 websocket
“实时通知新的消息”应该是没得选，websocket比长连接更好