Python-Websockets 中关于分片消息大小限制的错误报告问题分析

在 WebSocket 协议实现中，消息分片（message fragmentation）是一个重要的特性，它允许将大消息拆分成多个帧（frame）进行传输。然而，python-websockets 项目在处理分片消息时出现了一个关于大小限制（max_size）的错误报告问题。

当服务器或客户端配置了 max_size 参数来限制消息大小时，协议解析器会在读取每个分片帧时递减 max_size 的值。这种递减逻辑在处理分片消息时会导致一个不直观的错误现象：当最后一个分片帧到达时，max_size 可能已经被递减到零，此时系统会错误地报告 "message too big" 异常，声称消息大小超过了限制（例如显示 "1048576 > 0 bytes"），而实际上消息总大小可能并未超过初始限制。

这个问题的核心在于 max_size 的递减方式。正确的做法应该是：

1. 累计所有分片帧的负载大小
2. 在完整消息组装完成后检查总大小
3. 仅当总大小超过初始 max_size 时才报错

当前实现的问题在于过早地应用了大小限制检查，并且在错误消息中展示了令人困惑的数值对比。这种实现不仅会给开发者带来困扰，还可能掩盖真正的大小限制违规情况。

从技术实现角度来看，修复这个问题的关键在于重构 Protocol.parse 和 Frame.parse 的交互逻辑，确保：

• 分片消息的大小检查推迟到完整消息组装完成时
• 错误消息准确反映实际的大小限制违规情况
• 保持现有 API 的兼容性

这个问题虽然不影响协议的基本功能，但对于需要精确控制消息大小的应用场景（如安全敏感或资源受限环境）来说，准确的大小限制检查和错误报告至关重要。开发者应当关注这个问题，特别是在处理可能超过默认大小限制的消息时。

对于使用 python-websockets 的开发者来说，如果遇到类似 "message too big" 的错误，但确认消息实际大小并未超过限制，可以考虑这个问题是否相关。在问题修复前，临时解决方案可以是适当增大 max_size 参数或实现自定义的大小检查逻辑。