评估 Websocket 用于外汇交易自动化时应检查的内容

Websocket 定义及其实际含义

Websocket 是一种网络协议，可在客户端与服务器之间保持连接打开，使双方能够以低开销双向交换消息。对于自动化而言，这通常意味着软件系统可以接收频繁更新（例如报价或状态消息），并回传指令，而无需反复建立新连接。

在评估 Websocket 时，应将 稳定机制（协议和客户端的典型行为）与 可变条件（提供商基础设施、网络质量、服务器负载和市场环境）区分开来。稳定机制有助于判断正确性；可变条件则决定其在实际使用中是否有效。

尽职调查清单（控制检查表）

1) AFV：假设、故障、验证

首先列出假设。对于依赖的每条消息，说明：该消息代表什么、如何检测其是否到达，以及未到达时的应对措施。

然后识别故障模式（AFVinkpunten）：

• 丢失或延迟的消息：确认在高负载下的表现，以及是否存在数据缺口。
• 乱序传递或重复事件：定义如何处理重复和排序问题。
• 状态不同步：若构建本地视图，需验证是否可重新同步。

最后，指定 验证方法：记录原始帧、与服务器提供的序列信息（如可用）进行比对，并运行模拟断开连接和限流的测试。

2) 消息语义：类型、模式与顺序

查阅官方文档中的消息 模式 和 消息类型。至少应验证：

• 消息是否包含时间戳和序列号（或等效的排序标记）。
• 服务器是否在增量/更新前发送 初始快照。
• 系统应如何解释“心跳”或“订阅”确认。

一个现成的测试方法是：订阅后，在固定时间段内捕获消息，确认解析器和状态机能够处理每个已记录的字段和事件类型。

3) 可靠性行为：重连、退避与数据缺口

一个关键限制是网络和服务器的可用性无法完全保证。需验证 Websocket 在以下情况下的表现：

• 连接中断，
• 临时中断，
• 速率限制，
• 认证失败，
• 以及服务器重启。

应确认提供商是否提供恢复错失更新的方法（例如重新订阅加快照，或缺口恢复机制）。若无此机制，您的本地状态可能过期，而系统仍在运行。

4) 吞吐量与延迟预期（及测量内容）

不要假设性能，应实际测量。即使在一次测试中看到“快速”更新，吞吐量也可能在高活动或高峰时段下降。

检查文档是否说明了限制，如最大订阅数、消息大小或速率策略。然后在您自己的环境中测量：

• 从接收到处理完成的端到端延迟，
• 解析对 CPU 和内存的影响，
• 以及处理时间如何影响跟上进度的能力。

若无法测量，应假设系统可能落后并开始累积延迟。

5) 安全性与访问控制

从提供商的官方资料中验证认证要求和令牌处理规则。检查：

• 凭据如何发送，
• 令牌是否过期，
• 以及系统对“未授权”错误的响应方式。

同时验证您的实现是否在日志中谨慎处理敏感数据（避免以明文存储密钥）。

6) 正确性证据：日志与可审计性

要求提供可重建事件的证据。实际上，这意味着：

• 存储原始消息捕获（至少用于测试运行），
• 保留与序列/顺序标记关联的结构化日志，
• 并记录重连和重新订阅事件。

这是您的“证据或文档”检查表：通过将预期行为（根据文档）与观察行为（您的测试）进行比对，证明正确性。

预期的限制与风险（至少一个具体故障模式）

一种常见故障模式是 断开连接后的状态过期。示例假设：您的客户端基于增量更新构建订单/报价数据的本地表示。如果连接中断且重新连接时无明确的重新同步机制，您可能继续使用不完整或过时的状态。

其他需规划的风险包括：

• 解析与模式漂移：未记录的字段或变更可能破坏您的解析器。
• 时间假设：不同系统的时钟可能不一致；您的逻辑不应假设完美时钟同步。
• 非预测性历史：即使历史行为看似稳定，也不能证明未来消息的可靠性。