网络协议栈代码审查要看哪些问题协议栈的代码往往在理想网络里显得很干净一端写一端读消息顺序正确连接也会正常关闭。真实网络却会带来分片、合包、乱序、重复、半开连接、超时和恶意输入。评审的重点不是证明一次往返能成功而是确认状态机在这些条件下不会越界、泄漏资源或把错误状态误当成正常数据。开始前先明确实现覆盖的协议层和信任边界。是应用协议编解码、传输封装还是同时处理加密和认证哪些字段来自不可信网络哪些由本端生成没有边界图评审很容易把“上层会校验”当成安全保证却找不到实际校验发生的位置。消息边界和长度检查TCP 提供的是字节流不保留应用消息边界一次读取可能只有半帧也可能包含多帧。代码应维护缓冲区和明确的帧格式只有收到完整头部和负载后才解码。长度字段、可变长度编码和压缩后的大小都要在分配内存或复制数据前检查上限避免一个伪造长度造成内存耗尽。读取字节 → 解析固定头 → 校验长度/标志 → 等待完整负载 → 解码消息错误帧不能简单跳过后继续按原状态解析是否关闭连接、丢弃当前消息或发送协议错误应由协议规范和风险决定。解析器要对不完整、超长、未知类型和非法组合有明确行为。状态机和顺序约束握手、认证、请求、响应和关闭都应有可枚举的状态与允许转换。评审时检查每个入口是否验证当前状态认证前能否访问业务消息关闭后是否仍接收数据重复的控制帧会不会重复释放资源。把状态隐含在多个布尔变量或回调顺序里很容易在重连和异常路径上产生矛盾。如果协议允许并发请求或多路复用需要确认请求 ID 的范围、重复处理、响应匹配和取消语义。网络层可能重复投递或连接重建应用层则要决定哪些操作可重试、哪些必须依靠幂等标识。不要把传输成功等同于对端已经完成业务操作。超时、背压和资源所有权连接、读写操作、握手和空闲状态都需要适合场景的超时。超时发生后应取消相关任务、从注册表移除连接并释放缓冲区仅返回错误而不清理长期运行后会积累半死连接和 goroutine。反过来过短超时也会在网络波动中制造无意义重连因此阈值应来自真实网络和业务时限。写入端还要处理背压。对端读取变慢时无界发送队列会把压力变成进程内存。设置队列大小、写入截止时间和按消息类型的丢弃或拒绝策略关键控制消息与可丢弃的通知通常不应共享同一策略。所有关闭分支都要明确谁负责关闭 socket、停止定时器和回收缓冲池。安全校验不要留给“后面”认证、完整性校验、重放防护和密钥更新应发生在协议定义的正确阶段。解密或解压失败时错误信息不要向对端暴露内部细节日志也要避免记录密钥、完整载荷或令牌。若协议依赖 TLS 或其他成熟安全层评审应确认配置、证书验证和版本策略而不是假设“用了库就安全”。对来自网络的标识符、路由字段和扩展属性分别校验格式、长度和权限。未知扩展是否可忽略应遵循协议约定随意宽容解析会带来不同实现之间的语义分歧。测试要让坏网络出现除了正常互通测试还应构造分片、合包、截断、乱序控制消息、重复请求、慢读端、连接中断和资源耗尽。模糊测试适合发现解析器的崩溃和越界集成测试则验证真实 socket、超时和重连。记录连接 ID、状态转换、错误类别、队列水位和关闭原因排障时才不必从海量字节日志中猜发生了什么。协议栈评审的标准不是“从不出错”而是输入不可信、网络不稳定时状态仍可解释资源仍有上限错误仍能被安全地处理。这些边界比一个顺利的演示更能决定实现能否长期运行。