网络编程如何做复盘？

本文目录导读：

1. 第一阶段：全面信息收集（发生了什么？）
2. 第二阶段：问题定位三要素（为什么发生？）
3. 第三阶段：深入复盘“Edge Cases”（容易被忽略的致命点）
4. 第四阶段：从复盘到改进（下次怎么做？）
5. 最佳复盘模版

这是一个很好的问题，网络编程的复盘与普通业务逻辑不同，它往往涉及数据流动、状态机、并发竞态和协议细节，容易“看起来没问题，但一运行就崩”。

做网络编程复盘，核心思路是从“现象”回溯到“数据流”和“协议状态”,而不是只看代码逻辑。

以下是一套系统性的网络编程复盘框架,分为四个阶段：

第一阶段：全面信息收集（发生了什么？）

不要凭记忆复盘,第一步是拉取所有客观数据。

1. 保留现场（Crash/异常时）：

   • Core Dump / 进程快照：如果程序崩溃，ulimit -c 是否开启了 core 文件？可以使用 gdb 查看线程堆栈和变量。
   • Golang/Python 等运行时：抓取 goroutine stack trace 或线程 dump。
   • 网络连接快照：ss -tanp、netstat -anp 查看当时连接状态（ESTABLISHED, CLOSE_WAIT, TIME_WAIT）。

2. 日志是命脉：

   • 打印关键节点：每次 accept、read、write、close 的返回值和字节数。
   • 打印对端地址：fd 是对应的哪个 remote IP：Port。
   • 打印状态转移：如果用了状态机（如 HTTP 解析、MQTT 协议）,日志里必须能还原出状态流转。

3. 抓包（最高证据）：

   • 使用 tcpdump / Wireshark：
     • 命令：tcpdump -i eth0 host <ip> and port <port> -w capture.pcap
     • 重点观察：
       • 是否发生乱序（TCP Out-of-Order）？
       • 是否有重复 ACK 导致快速重传？
       • 对端 Sentinel FIN/RST 是什么时候发的？
       • 应用层数据包内容是否与预期一致？

第二阶段：问题定位三要素（为什么发生？）

拿到数据后,按以下三个维度逐一排查：

缓冲区与吞吐量

• 现象：CPU 低但吞吐上不去,或系统卡顿。
• 复盘问题：
  • SO_RCVBUF / SO_SNDBUF：是否设置过小？Wireshark 看 Window Scaling 是否协商成功？
  • 用户态缓冲区：你的 read 是固定大小（如 1024 字节）读取一次，还是读满应用协议长度？粘包/拆包处理是否有 Bug？
  • Epoll/Libevent/Reactor 模型：当大量连接同时来数据时,是串行处理还是合理分片？

连接生命周期与异常处理

• 现象：连接数不断上涨不掉、CLOSE_WAIT 堆积、ECONNRESET 报错。
• 复盘问题：
  • 被动关闭场景：对端发了 FIN，你收到了，但你调用 close 了吗？如果没有，你会卡在 CLOSE_WAIT 状态,这是最经典的泄漏。
  • 主动关闭场景：你发了 FIN 后，对端没回 FIN 直接发数据（或对端回收放），你会触发 RST，此时如果继续 write 会收到 SIGPIPE（默认杀死进程）。
  • 半关闭处理：shutdown(SHUT_WR) 与 close 的区别是否用对？（服务端常用 shutdown 配合 HTTP Keep-Alive）。
  • 非阻塞 connect：connect 返回 -1（EINPROGRESS），后续 select/epoll 触发的是可写，但需要用 getsockopt(SO_ERROR) 检查是否成功,是否处理了这个逻辑？

协议与状态机

• 现象：请求/响应错乱、解析崩溃、乱序返回。
• 复盘问题：
  • 粘包策略：你是定长包、长度前缀（TLV）、还是分隔符（如 HTTP 的 \r\n\r\n）？memmove 或 ring buffer 的逻辑在边界情况下（如读到 65535 字节+1）是否会越界？
  • 请求-对应的配对：如何确保“发送的请求 A”返回的是“应答 A”？（常见方案：请求带 ID，异步回调映射；或者严格流水线 Pipeline），如果缺少这个机制,并发请求会导致数据错位。
  • 心跳与空闲超时：有保活机制吗？tcp_keepalive 或应用层心跳，如果一方没设超时，就会“死连接”一直占着资源。

第三阶段：深入复盘“Edge Cases”（容易被忽略的致命点）

这是网络编程最折磨人的地方：

1. EINTR 信号中断：在阻塞 read/write 时，如果进程收到信号（如 SIGALRM），系统调用会返回 -1 且 errno=EINTR。你的代码是否忽略了这点，直接 break 了循环？
2. EAGAIN / EWOULDBLOCK：在非阻塞模式下，这是“正常”返回，但你是不是把它当成了“错误”直接关闭了连接？
3. 部分读写：read(fd, buf, 4096) 可能只返回了 100 字节。你的逻辑是“用返回值更新偏移量”，还是直接假定读满了？
4. 文件描述符耗尽：select 的 FD_SETSIZE（默认 1024）或者 ulimit -n 太小，没有测过 10 万连接，上线后连接数上升就会报 “Too many open files”。
5. 多线程并发：
   • 一个 fd 被两个线程同时 read/write 会发生什么？（大概率混乱或崩溃）
   • 你是否有 epoll_ctl(ADD/MOD/DEL) 的线程安全控制（通常需要在主线程处理，或加锁）？

第四阶段：从复盘到改进（下次怎么做？）

复盘的价值在于形成“Do’s and Don‘ts”清单。

1. 防御性编码报告清单：
   • 所有 read/write/send/recv 返回值必须检查。
   • 去掉所有对“一定能读取 N 字节”的假设。
   • 添加连接 setSoTimeout / 内核 tcp_user_timeout。
2. 工具自动化：
   • 能否增加 valgrind / AddressSanitizer (ASan) 检查内存越界？
   • 是否加了集成测试，专门构造半包、乱序、RST 信号？
   • 发布前是否跑过 strace -e network 做压力测试？
3. 架构调整：
   • 如果问题出在“协议状态机太复杂”，考虑用现成库（如 libevent、netty、tokio）。
   • 如果出在“大量 TIME_WAIT”，服务端可以考虑设置 SO_REUSEADDR,客户端考虑使用长连接池。

最佳复盘模版

你可以按这个格式写复盘报告：

现象：XX 服务出现大量 CLOSE_WAIT，持续 30 分钟，导致拒绝连接。 抓包证据：Wireshark 显示服务端收到对端 FIN 后，没有回复 FIN，且应用层日志显示 close 未被调用。 根因：在处理异常数据包时，代码中 if (error) return; 直接跳过了后续的 close(fd) 逻辑。 修复：在该路径中添加 goto cleanup; 统一释放资源，并加入 RAII / defer 机制保证 close 一定执行。 预防：增加单元测试，模拟对端突然发 FIN 的场景；加入连接监控告警。

网络编程的本质是管理不确定性（网络延迟、丢包、对端异常），复盘的目的是把每个“可能出错的地方”变成“确定性处理”。

标签： 网络编程