Websocket 有哪些限制？
简单来说，Websocket 是什么？
Websocket 是一种通信协议，可在两个系统之间保持持久连接。在初始连接建立后，双方无需反复发起新请求即可相互发送消息。在实际应用中，这种机制可用于从市场数据提供商或交易平台向客户端持续推送更新（例如报价或市场事件）。
有必要区分两个概念：
- 协议机制：消息如何通过持久连接发送和接收。
- 市场实用性：你接收到的消息是否及时、完整，并符合特定应用的需求。
主要限制在于，Websocket 仅解决 消息传输方式，而不保证这些消息是否代表稳定、实时或未来可用的信息。
Websocket 如何工作？哪些假设可能失效？
使用 Websocket 时，消息通过持久通道传输。在典型的流式传输设置中，客户端订阅特定数据（按交易品种、工具或主题），服务器则在数据更新时立即推送。
“它运行良好”这一预期背后的常见假设包括：
- 连接保持健康，足以支持应用程序持续运行。
- 消息以可用的顺序和频率 到达，满足你的逻辑处理需求。
- 服务器确实按预期发布更新（针对所选订阅内容和时间）。
- 你的客户端能足够快地处理消息，以跟上更新速度。
一旦这些假设中的任何一个失效，就可能出现更新丢失、延迟增加、积压或反复尝试重连等问题。
可观察的故障模式示例（无需假设实时行为）
即使不假设实时市场数据，你仍可从系统设计角度评估故障模式：
- 重连断口：如果连接中断，客户端可能稍后重连。在此期间，可能错过部分更新。
- 背压与缓冲：如果消息处理速度或网络吞吐量低于更新到达速率，消息将排队，导致延迟增加。
- 排序与去重需求：系统通常需要处理重复消息（重连后的重试）以及跨重连的乱序到达问题。
一个常见误解是将持久套接字上的消息传递等同于完美的及时性或完整性。Websocket 可减少通信开销，但无法免除对断口处理、去重和时间对齐的需求。
局限性与风险：Websocket 不适用的场景
当 Websocket 与可变的外部条件交互时，其局限性尤为明显：
- 网络与基础设施波动：延迟、丢包或间歇性连接仍会影响消息到达的时间和方式。
- 提供商/服务器行为变化：更新频率、可用订阅或限流策略可能因提供商和条件而异。
- 执行与数据时序不匹配：即使你快速收到数据，下游操作（如计算、订单处理或系统调度）仍可能滞后。
- 成本与运维开销：持久连接、重连策略和监控增加了系统复杂性；复杂性越高，边缘情况故障的可能性越大。
- “实时准确性”的不确定性：消息时序与结果之间的历史关系，并不能保证未来仍保持相同关系。
由于这些因素在不同系统和司法管辖区之间存在差异，你应将 Websocket 视为一种传输机制，并在实际条件下验证所接收数据的有效性。
如何独立验证 Websocket 的限制
要验证限制而不依赖承诺，请为你的设置定义可衡量的检查项。例如：
- 跟踪 连接/断开事件，并记录重连断口的持续时间。
- 测量 端到端消息延迟，即从接收到消息到应用程序使用该数据的时间。
- 确认系统在重连后是否能正确处理 重复和丢失的消息。
- 评估高活动期间的 消息量 是否导致处理积压。
如果你的需求包含严格的时效性或完整性要求，请考虑设计中是否包含监控、对账以及对不确定性的稳健处理机制。总体而言，Websocket 的限制不在于协议本身，而在于对消息传递、时序和数据质量的假设是否在真实环境中得到验证（或未验证）。