即时通讯消息是如何从发送者到达接收者的？企业IM基本通信链路

在聊天窗口按下发送，消息并不会直接"飞"到对方手机上。它走的是一条固定链路：先上传到服务器，由服务器接收、保存，再找到接收方当前在线的连接推送过去。这套"客户端—服务器—客户端"的接力，就是企业 IM 的基本通信链路。本文只讲通用原理，不猜测具体产品的内部实现。

一、链路上有三个角色

一次消息通信里，实际参与的是三方：发送端负责把消息交出去，服务器负责接住并转交，接收端负责收下并确认。消息不是从 A 直接到 B，而是 A → 服务器 → B。

因为这条链路是所有功能的前提，企业 IM 通常把它当作平台底座来做——BeeWorks 就把即时通讯与消息中心作为平台底座的一部分，而不是一个孤立的聊天工具。

二、一条消息的旅程：六个环节

1. 建立连接。 客户端启动时会与服务器建立一条保持着的通道，之后发消息直接走它，不必每次重连。
2. 消息上行。 点发送后，客户端把消息内容、收件人、时间等信息提交给服务器。
3. 接收与保存。 服务器收到后，通常先把消息落下来存住，这样即使对方此刻不在线，消息也不会消失。
4. 查找接收方。 服务器要知道这条消息该送到哪条通道——对方可能在手机，也可能在电脑。
5. 消息下行。 通过找到的通道推送过去；多端在线时各送一份，这就是多端同步的来源。
6. 送达与回执。 收件端回一个确认，发送方才出现"已送达"；对方打开会话，再产生"已读"。

三、为什么要用服务器中转，而不是两点直连

两点直连听起来更短，在真实网络里却做不成：

• 网络阻隔。 公网设备大多在路由器和防火墙后面，彼此看不见。
• 对方不一定在线。 设备关闭或断网时，必须有人把消息存下来。
• 一个人有多台设备。 手机、电脑、网页端要看到同一份记录，需要共同的汇聚点。
• 企业要留痕与审计。 谁能看、能否追溯，都要在可管理的节点上完成。

四、几个容易被忽略的细节

• 离线消息。 对方不在线时先存在服务器，上线后补发。"发出去没回音"不等于"消息丢了"。
• 顺序与去重。 消息要有先后，重复投递要能剔除，否则多端之间会打架。
• 加密的两段。 一段是传递时的保护，一段是存储时的保护，企业 IM 通常两段都要管。
• 多端一致。 一台设备读过的消息，其他设备也该同步成已读。

五、BeeWorks 在这条链路上提供什么

落到具体产品，可以对照已公开的能力来看，而不必去推测内部怎么写代码。

BeeWorks 支持私有化部署；客户端覆盖 Windows、macOS、Linux、iOS、Android 及 Web，用户可在不同设备间同步消息、文件和会话记录。平台提供统一消息推送引擎，业务系统可向指定成员、部门或群组投递审批提醒、待办、告警、工单等消息，并统一进入应用会话。链路的保护上，公开能力包括通信加密、国密算法、数据本地存储、消息留痕。

以上都在产品对外披露的范围内。连接如何维护、消息如何路由这类内部实现，BeeWorks 未公开架构细节，本文不做推测。

六、验收时关注什么

1. 断网、切换网络后，消息能否自动补上；
2. 手机和电脑同时在线，两端记录是否一致；
3. 离线期间的消息，上线后是否完整；
4. 多端同时收消息，会不会重复；
5. 传输和存储两段是否都有加密说明。

FAQ

Q1：消息会丢吗？

正常情况下不会。服务器接收后先保存，对方不在线也会在上线后补发；风险多出在网络中断且未做重传的场景。

Q2：断网时发的消息会怎样？

多数客户端先暂存在本地，网络恢复后再提交；具体行为以各产品为准。

Q3：多台设备同时在线，消息会重复吗？

客户端一般会做去重，让每个终端只显示一条；若明显重复，通常是同步逻辑问题。

Q4：业务通知和聊天消息走同一条链路吗？

企业 IM 里二者通常复用同一套投递机制，只是发起方不同——一个来自人，一个来自业务系统。