用Rust实现的长连接方案

在上一篇文章，我们讲到了长连接常见的实现方案，相信大家对长连接已经有一定的了解了，这篇文章我们会讲 FeatureProbe 的长连接实现方案。

一、为什么FeatureProbe需要长连接

Feature Toggle 在部分场景下，客户端对实时性有较高的要求，如紧急情况，希望配置立刻下发生效。有的 Feature 在 Web 端加载或 App 启动的时候就要读取到开关的值，虽然缓存能解决一部分问题，但是最快拿到最新的值，会更符合用户的预期。我们在上篇有提到过，长连接可以解决数据推送和请求优化这两个场景。

1、可选协议

• SSE ：Server Send Event 能满足服务端向客户端发送数据的需求，协议简单，但因为不是双工的数据通路后期无法实现 HTTP 的请求优化。
• TCP ：目前最主流的长连接协议，配合 TLS 1.3 可以做到很好的使用效果。
• QUIC ：本身握手和 TLS1.3 融合，还支持连接恢复，多Stream避免包头阻塞问题，有很多优势，因为基于UDP，可能会有部分特殊网络环境被禁止。
• UDP ：需要自己实现丢包重传，部分网络环境有可能被限制。
• WebSocket ：对浏览器友好，小程序唯一支持的双向收发 (全双工) 协议，很难做连接优化。

2、设计目标

• 尽可能支持更多的端，小程序，移动端，多种语言服务端；
• 尽量降低 SDK 的实现复杂度，方便后期社区贡献；
• 尽可能使开关快速生效；
• 尽可能低的数据传输量。

二、FeatureProbe长连接方案

1、协议选择 WebSocket

小程序是我们一期要优先支持的平台，所以所有不支持