为什么Web端IM一定要用WebSocket，客户端用http发、用SSE收不行？

目前看到的一些开源项目，客户端和服务端交互的时候，都是使用websocket


想法
1，客户端发送消息给服务端的时候，可以改为http，一般情况下http自带ACK，可以保证消息可达性
2，服务端推送消息给客户端，可以不用websocket，可以使用EventSource。


但是没有仔细研究过EventSource，容我去研究一下，不知道EventSource有什么不好的地方么。

引用：特级西红柿 发表于 2023-08-18 14:37
大佬，http2在协议层面上已经提供了 server push的能力，也就是说其实推送能力应该是具备的吧。可能在分 ...

每项技术总有个最适合的场景，如果哪天websocket被w3c明确废弃了，那你说的这些肯定会成为主流用法

引用：JackJiang 发表于 2023-07-19 14:25
所谓的长连接，最大的作用是提供服务端主动“推”的能力，http的标准里没有这种能力

大佬，http2在协议层面上已经提供了 server push的能力，也就是说其实推送能力应该是具备的吧。可能在分布式系统里面，需要存一个连接在哪台机器的路由关系？ 而且对于基于quic协议的http3来说，已经可以做到0rtt，拿出来本身http的keepalive能力，0rtt在一定程度上也可以缓解您说的握手问题？

引用：特级西红柿 发表于 2023-07-19 14:19
大佬，请加一下，http不是有长连接吗？我理解这样不行主要冗余信息比较多，而且server不能直接推送

所谓的长连接，最大的作用是提供服务端主动“推”的能力，http的标准里没有这种能力

引用：JackJiang 发表于 2023-06-29 16:35
你只看到了http好的一面。http对于im不好的一面，就是它是短连接，用完就断，也意味着每条消息都得连接、 ...

大佬，请加一下，http不是有长连接吗？我理解这样不行主要冗余信息比较多，而且server不能直接推送

引用：WarriorFromLong 发表于 2023-06-29 14:58
其实有一个问题，，客户端给服务端发送消息，要保证ack。

感觉使用http发送消息也是ok的额。http自带a ...

你只看到了http好的一面。http对于im不好的一面，就是它是短连接，用完就断，也意味着每条消息都得连接、断开，走完全程，如果开启了SSL/TLS加密，那更要命，延迟不说，频繁的连接和断开，手机耗电量会很感人。

另外，http冗余信息太多，哪怕一个字节的消息，那Http头同样是一大堆。

总之一句话，跟着主流作法走，总归是没错的

引用：JackJiang 发表于 2023-06-28 12:22
你说的是SSE吧，这两篇你可以看看：

其实有一个问题，，客户端给服务端发送消息，要保证ack。

感觉使用http发送消息也是ok的额。http自带ack。

你说的是SSE吧，这两篇你可以看看：

• 《网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket》
• 《搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、SSE》
  

你这种方法用来搞IM是野路子，但搞类似于股票客户端那种场景，倒是可以考虑