Skip to content

Congestion and Deployment

b23r0 edited this page Oct 12, 2026 · 1 revision

English · 简体中文

拥塞与部署边界

库控制了什么

可靠交付使用 ACK/NACK、ACK 缺口快速重传和有上限的超时退避。原发送路径有固定可靠在途窗口;可选 SendOptions 提供帧/字节限制、队列预算和 flush 突发量。这些是本地流量/队列控制,不是自适应带宽估计或 TCP/QUIC 式拥塞窗口算法。

RecoveryOptions 可以在重试截止时间唤醒和探测符合条件的尾包,不会增加拥塞识别、速率 pacing 或动态带宽控制。不同交付通道仍共享同一网络路径。

链路突然恶化会怎样

可用带宽从 100 Mbps 降到 2 Mbps、RTT 从 30 ms 升到 800 ms 时,保持原生产速率会使应用、传输、内核及瓶颈队列累积。固定在途窗口限制一部分未确认数据,但不会自行保证瓶颈低延迟,部分队列可能丢包。

队列丢包与随机丢包呈现相同 ACK/NACK 症状。快速重传可能增加送入链路的负载;超时退避延缓重复重传,新的无歧义 RTT 样本更新 SRTT/RTO。实现不会区分随机与拥塞丢包;Karn 排除和反馈到达时间决定适应不是瞬时完成。业务消息还可能等待排序缺口,即使传输 ACK 仍有进展。

不能承诺任意持续过载下都维持低延迟。历史恢复链路阶跃实验只测试特定链路与负载,不代表拥塞公平性保证。README 的随机丢包回环测试不等于拥塞 WAN 测试。

应用侧措施

  1. 发送前限制任务和活跃会话数量,监测应用队列年龄及吞吐。
  2. 可替换状态选择 UnreliableSequenced,应用主动合并过期更新;不可靠消息并不自动拥有全局优先级。
  3. 根据实测 RTT 和消息大小选择在途限制。小窗口可能减少突发也可能限制吞吐;大队列可能只增加等待。
  4. 多连接共享已知瓶颈时在应用层显式限速或 pacing;SendOptions 没有每秒包数或 Mbps 参数。
  5. 对比默认/策略、随机/队列丢包、链路阶跃/恢复、稀疏/持续负载,记录交付校验、RTT 范围、队列/丢包计数及与其他流量的公平性。

链路测试必须在任务专属网络命名空间或一次性 VM 内整形,不修改主机 qdisc、路由或 sysctl。

安全与公网部署

库不提供 TLS、认证加密、身份或业务鉴权。地址、GUID 和握手成功不是身份认证,可靠交付也不认证消息内容。

接收和重组上限控制有限资源,但不是完整公网滥用防护。应用需要准入限制、有界反序列化、逐用户配额及选定的认证/安全层;加入载荷安全层时须考虑消息前缀、MTU 与互通要求。

平台与集成

普通异步/同步 API 面向依赖支持的平台。socket 分片和 recvmmsg 接收批处理仅 Linux 可用,用 #[cfg(target_os = "linux")] 保护调用;不要假定 Windows/macOS 存在这些方法。

没有内置 Sans-I/O、非阻塞轮询接口或 Bevy 插件。事件循环可通过异步任务,或独立同步网络线程与有界应用队列集成。

发送策略 · 恢复 · 高并发

Clone this wiki locally