无需persistent connection即可实现Signaling的技术及相关应用咨询

可行技术方案 #

不需要业务端与信令服务器维持*persistent connection（即常驻open socket）*就能实现信令收发的方案已经非常成熟，主流实现包括以下几类：

• HTTP短轮询：实现逻辑最简单，客户端按固定周期发起普通HTTP请求拉取待处理信令，服务端收到请求后返回当前积压的信令，没有信令就返回空响应，请求完成后立刻释放连接，全程没有常驻的socket连接。缺点是信令延迟和轮询间隔强绑定，轮询间隔过短会拉高服务端请求压力，间隔过长则实时性不足。
• HTTP长轮询：是短轮询的优化版本，客户端发起HTTP请求后，如果服务端暂时没有待下发信令，不会立刻返回空响应，而是将请求挂起——这个挂起阶段不会持续做数据传输，和传统持久连接的常驻socket逻辑完全不同，挂起到超时阈值后服务端会主动断开连接，客户端再重新发起新的请求；一旦挂起阶段有需要下发的信令，服务端会立刻通过当前请求返回响应，完成后马上释放连接。这种方案实时性远好于短轮询，也不需要维持常驻连接，是很多场景下长连接不可用时的标准降级方案。
• 系统级推送通道承载信令：核心逻辑是把信令的推送能力交给操作系统层面维护的统一长连接，App自身不需要和业务服务器维持open socket。当有信令需要下发时，服务端先把信令唤醒消息发给系统推送服务，由系统通道推送到端上，App收到唤醒消息后再临时发起短连接拉取完整信令、执行业务逻辑。
• 基于UDP/QUIC的无状态信令：依托HTTP3/QUIC的无连接特性，不需要像TCP那样做端到端的连接保活，客户端和服务端都可以按需发送UDP报文传输信令，不需要提前维持常驻的socket连接，配合QUIC的连接迁移能力，还能适配网络切换场景下的信令投递需求。

已落地的商用场景 #

这类方案早就不是实验室技术，已经在大量产品的实际业务中大规模应用：

• 主流IM、音视频App的后台/离线信令场景：微信、QQ、抖音这类国民级App，在退到后台、被系统限制进程权限、甚至进程被杀死的状态下，根本不可能自己维持和业务服务器的persistent connection，全靠各手机厂商的系统推送通道、iOS的APNs下发信令唤醒通知，用户点击通知拉起App时才会临时建立连接拉取完整消息、接通话路。
• 低功耗IoT设备的信令交互：智能门锁、低功耗温湿度传感器、电池供电的智能摄像头这类设备，为了延长续航不可能一直维持WiFi/蜂窝网的常驻连接，基本都是定时唤醒发起短请求拉取信令，或者靠短信、低功耗无线广播触发唤醒后，再临时建连完成信令交互，华为、小米的智能家居生态里大量低功耗设备都用这套逻辑。
• 轻量WebRTC应用的信令交换：很多低并发的网页端实时音视频、远程控制应用，根本不会专门建WebSocket长连接做信令，直接用HTTP长轮询完成SDP、ICE候选信息的交换，对等端连接建立完成后，信令通道直接释放，不需要一直保持连接。
• 在线文档、协作文档的低活跃状态降级：腾讯文档、石墨文档这类产品，当检测到用户超过一定时间没有操作时，会主动断开WebSocket长连接，切换到HTTP长轮询拉取协作变更信令，减少不必要的连接资源占用，等用户重新产生操作时再切回长连接模式。

内容的提问来源于stack exchange，提问作者Kris