03 | 轮询与长连接：如何解决消息的实时到达问题？
该思维导图由 AI 生成，仅供参考
短轮询场景
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
IM系统中的消息实时到达问题一直是一个重要的挑战。本文介绍了即时消息服务中是如何解决“消息实时性”这个难题。文章从短轮询、长轮询到服务端推送的演进过程中，介绍了不同阶段的技术架构和解决方案。短轮询模式通过高频率的轮询获取消息，但存在网络开销和服务端压力大的问题；长轮询模式通过延长轮询时间减少了无效轮询，但仍未解决服务端资源压力。随着HTML5的出现，WebSocket协议成为了服务端推送的解决方案，实现了双向通信和边缘触发，大幅降低了服务端轮询压力。此外，基于TCP长连接的IM协议如XMPP、MQTT等也被介绍，并指出了它们的优缺点。通过介绍不同阶段的技术演进，文章展示了IM系统中消息实时到达问题的解决方案，为读者提供了对实时性技术发展的全面了解。文章以技术演进的方式，生动地展现了IM系统中消息实时到达问题的解决方案，为读者提供了全面了解实时性技术发展的视角。
《即时消息技术剖析与实战》，新⼈⾸单¥59
全部留言(71)
- 最新
- 精选
王棕生TCP 长连接的方式是怎么实现“当有消息需要发送给某个用户时，能够准确找到这个用户对应的网络连接”？ 答： 首先用户有一个登陆的过程： (1)tcp客户端与服务端通过三次握手建立tcp连接；(2)基于该连接客户端发送登陆请求；(3)服务端对登陆请求进行解析和判断，如果合法，就将当前用户的uid和标识当前tcp连接的socket描述符(也就是fd)建立映射关系； (4)这个映射关系一般是保存在本地缓存或分布式缓存中。 然后，当服务端收到要发送给这个用户的消息时，先从缓存中根据uid查找fd，如果找到，就基于fd将消息推送出去。作者回复: 👍
2019-09-021188
菜菜菜菜菜鸟TCP不是可靠的吗，为什么还需要在应用层实现ack，不应该是消息发出对方就一定可以收到的吗作者回复: 是个好问题。因为很多时候消息由tcp层交给应用层之后还可能出现丢失的情况，比如客户端落本地db失败了，类似这种。
2019-09-02733- 技术带头老师你好，我们也落地了一套im，服务端和本地都有存储，和用websoket。现在存在一个问题。群聊离线推送是将离线后产生的所有消息再用户上线的时候推送，还是客户端分页拉取
作者回复: 可以考虑推拉结合，离线消息太多如果全部都推的话性能和带宽上都不太友好，可以离线推送一页，后续的再由客户端来拉取。
2019-09-0823 
yic客户端发送心跳包，一般多久一次比较合适？ 我看老师有回复国内不超过5分钟，微信用的是4分半。这个时间有什么依据吗？作者回复: 以前有大厂测试过国内各家运营商的NAT超时情况，有的运营商在2/3G网络下NAT超时是5分钟。
2019-09-08218
魏巍服务器端如果突然进程被kill掉，客户端如何及时得到通知并下线？作者回复: 进程kill是会对socket执行close操作的哈，所以客户端是能感知到的。真要是通过拔网线的方式把服务端网络断开，这种情况客户端在发送数据时就会失败，然后短连后重连其他服务器就可以了。
2019-09-03217
飞翔服务器维护一个hashmap key是 userid，value 是socket instance， 这样 用户A 发给用户B的信息里边含有用户B 的id， 用usedBid 到hashmap 里边查到 用户B的socket 就可以用socket 发送信息给用户B了，老师我还有一个问题 就是如果一台机器连接数有限， 如果需要多台机器，如果用户A的socker 和用户B的socket 不在一台机器上，这样怎么解决呀作者回复: 一种做法是用户上线时维护一个全局的 uid->网关机 的映射，下发的时候就能做到精确定位；另一种方式是：下发时把所有消息下发给所有机器，每台机器如果发现当前用户连接在本机就下发，其他的就丢掉，这种会有一定的资源浪费。
2019-09-021316
探索无止境老师你好，为什么说一台服务器可以最多可以支持1000万的连接请求，这个数值是怎么推算出来的？作者回复: 不具备读写操作仅仅只是维护静态连接的话基本上就是个拼内存的活，调整tcp单连接的读写缓冲区大小到4k，优化下其他系统参数比如句柄限制啥的，建连速度稍微慢点，有个200g内存是没问题的。这里其实想说的是，不要光看单机能维护多少连接，每秒收发包数这些才是关键。
2019-10-0112
sam轮询就是前段定时请求，这个比较了解。但长轮询第一次听说，实际开发也没用过，特别是服务器的“悬挂（hang）”怎么理解？ 是HTTP协议的机制吗？作者回复: 和http没关系哈，实现上比如接收到一个请求后，通过while循环判断，如果请求时间和当前时间的时间差没有到达超时阈值，就继续查询后端是否有新消息，直到超时或者查询到新消息。
2019-09-0329- 魏巍一个linux服务器可以接受多少tcp连接，如何量化这个数字？当业务层对持久化层操作响应慢时，为何客户端会频繁掉线？聊天数据的持久化与下发操作查库对数据库的读写压力如何缓解？实时聊天的数据库如果宕机，能否做自动切换数据库服务器的操作？
作者回复: 连接数一般不是问题哈，服务端单机几百万上千万都可以的，受限于分配给每个连接的buffer占用的内存。业务层持久化会慢会导致客户端掉线这个没看懂呀，能具体一点吗？第三个问题可以做db的读写分离，第四个问题应该是说db的自动切主吧，这个是可以的哈，很成熟的方案。
2019-09-039 - zombo老师请教一个区分，长连接是不是 "header: keep-alive" 的连接? 英文对应 persistent HTTP connection，但大家用得不多。而 webSocket 是HTML5才出来的，类似的机制，但各种浏览器支持得比较多。 因为机制和实现上，我好像看不出它们有太大的区别? 还是说 persistent HTTP 仍然是3次握手，websocket是一次?
作者回复: 最大的区别在于websocket是支持全双工的，也就是说是可以由服务端主动进行推送的，http 1.1 的keep alive只是能够多次http请求复用同一个tcp连接，但只能由客户端发起请求。
2020-03-138
