几种常见的长连接实现方案
一、什么是长连接？长连接可以指 HTTP 持久连接 (persistent connection)，也可以指基于 TCP / UDP / QUIC / WebSocket 等一个或多个协议建立后可以持续收发消息的数据通路。本文主要介绍的是后者，其中以微信 2017 年初开源的 Mars 被大家熟知。从 Mars 的 issue 中我们可以看到 Longlink 这个国内长连接的直译，目前还没有特别好的英文术语。实际上 Mars 只是长链接架构中的客户端，还需要一个服务端来配合。
二、国内长连接现状
目前国内的大厂基本上都有自己的网关团队，长连接服务是网关中的子服务，客户端团队负责端上的网络库（如 Mars），网关相关的公开资料可以查询到的如阿里的 ACCS ，美团的 Shark 等
提供了诸如 消息推送，消息广播，多协议切换，HTTP 代理，多接入点容灾等功能。可覆盖 即时通讯，弹幕，互动游戏，竞拍等多个业务。
三、长连接解决的问题
总的来说主要解决的数据实效性的问题：
1、数据推送
最常见的案例就是消息通知。
最简单的做法是启动一个计时器，周期性轮询（polling ）一个接口。这种方案常见于早期基于浏览器的项目。坏处是间隔设置的太长用户体验不好，设置间隔太短后端服务会进行大量的无效查询。
稍好一点的做法是使用长轮询（long polling）, 发送 HTTP 请求后，如果没有新数据，服务端就一直不返回 HTTP 的 response。这种方式减少了大量无效的查询，但是如果新数据频繁，会进行大量的连接建立和关闭。常见于早期浏览器 WebSocket 协议支持不完整的时候。
目前主流的方案是浏览器基于 WebSocket，移动端基于 TCP / UDP/ QUIC 的全双工数据通道的方案。一次连接建立，服务端维护连接和业务的对应关系（如用户 id），当用户有新数据时，找到对应的连接，将数据发送出去，浏览器或者移动端就可以立刻收到消息，返回给上层。
可以推测手机厂商给 APP 提供的离线消息推送的通道，如果想做到最好的实时性，也需要维护一个手机和厂商服务的连接，在 APP 后端发送推送后，厂商转发给手机，展示给用户。
— 现在都有WebTransport了罢:lol
页:
[1]