TCP 是诊断网络问题的第一层：应用“慢”、重试、断连，先看 TCP。下面以工程实战为主线，给出可复制的抓包命令、判断指标、典型故障的判定方法与修复方向。
一、抓包工具与落地命令（快速上手）
- tcpdump（服务器/命令行）：轻量、可直接在生产抓包。示例：
sudo tcpdump -i any host 10.0.0.5 and port 443 -s 0 -w /tmp/cap.pcap
- Wireshark / tshark / PyShark：交互式分析与脚本化读取 pcap。
- Scapy：造包与复现（RST、伪造重传等）。
- Sniffmaster（抓包大师）：当需要在 iOS/Android 真机抓包且代理不可用或遇到 SSL Pinning 时，通过 USB 直连导出 pcap，能按 App 过滤流量，减少噪声。
二、抓包前的准备与采样建议
- 明确抓点（客户端、服务端或中间链路）；优先在最接近问题的一端抓包。
- 限定过滤条件（IP、端口、flow），避免海量无关数据。
- 使用
-s 0捕获完整报文，必要时启 ring buffer：-C-W。
三、Wireshark 常用过滤与关键指标
- 过滤重传：
tcp.analysis.retransmission - 重复 ACK：
tcp.analysis.duplicate_ack - RTT、三次握手耗时（查看 SYN/ACK 时间差）
- Follow TCP Stream 用于重组应用层数据
四、典型故障与定位方法（实战）
- 大量重传/重复 ACK → 链路丢包：对比客户端与服务端抓包，若丢包仅出现在中间某段，定位到该设备或链路。解决：排查链路错误、替换接入设备或调整 MTU。
- 长建连延时 / SYN 未回应 → 路由/防火墙或服务端 listen 问题：看三次握手是否完成，若 SYN 到达无 SYN-ACK，检查防火墙或服务是否挂起。
- 应用超时但 TCP 看似正常 → 应用层问题或 TLS 握手失败：Follow TCP Stream 看是否为 TLS Alert（握手失败），若是证书/ALPN/ClientHello 问题，从握手报文分析。
- 频繁短连接且大量 TIME_WAIT → 服务器 socket 策略不当：建议使用 keepalive 或调优
SO_REUSEADDR/ 连接复用。
五、MTU / 分片与 ICMP 问题
若大包丢失或页面资源加载异常，检查是否有 ICMP Fragmentation Needed（Type 3 Code 4）。可用 ping -M do -s <size> 测试路径 MTU，或在 Wireshark 中筛 icmp.type==3 && icmp.code==4。
六、多点抓包做对比（定位丢包位置）
在客户端、中间路由器与服务器分别抓包，比较序号/ACK 时序：若客户端发送但中间未见或中间可见而服务端无，则问题在上游设备。多点抓包是定位网络问题的黄金手段。
七、真机/移动场景的特殊处理
移动设备常受代理限制或 SSL Pinning 影响，桌面代理无法工作时：
- 若是浏览器可抓但 App 不行，优先怀疑 Pinning 或 mTLS；
- 使用 抓包大师（Sniffmaster） USB 直连：直接从设备接口抓 TCP/TLS 流量、按 App 过滤并导出 pcap，随后在 Wireshark 中查看 ClientHello、ServerHello、TLS Alert 和 TCP 重传，能在不改 App 的前提下定位握手或网络层问题。
八、故障复现与修复流程（可执行清单）
- 在问题时间段抓 pcap（客户端/服务器/可疑中间点）。
- 用 Wireshark 查看三次握手、重传、Dup ACK、RST/FIN 代码。
- 若为 TLS 问题，跟踪 ClientHello→ServerHello→Certificate→Alert，判断证书链或 cipher 不兼容。
- 针对发现采取修复：调整 MTU、修复链路、扩容/调优 socket、修正证书或调整客户端配置。
- 回归验证并归档 pcap 与日志。
九、脚本化与自动化建议
用 PyShark/tshark 抽取重传计数、平均 RTT 并把异常报警接入监控；把常用过滤器写成脚本，便于按时间窗口批量分析。
十、合规与数据治理
抓包会暴露敏感信息（cookie、token、用户数据），在生产抓包要遵守合规流程：最小化采集、脱敏存储、限定访问。
结语：把 TCP 抓包分析视为一个工程化流程：精确采样→多点对比→协议分层分析→针对性修复。将 Sniffmaster 这类能在真机环境下补齐证据链的工具纳入常用工具箱，能缩短定位时间并减少误判。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
