前两天排查一个内网服务，客户端反复报超时，应用日志里只有一长串重试记录，完全看不出方向。我直接在服务器上开了 tcpdump，抓了三十秒的包，才发现服务端一直在向一个不存在的内部地址发起 TCP 重连，所有请求全卡在三次握手阶段。这种问题在 HTTP 世界里基本遇不到，因为浏览器开发者工具已经把网络层包装得干干净净；可一旦碰上非HTTP协议，就需要老老实实回到抓包本身上来。所谓非HTTP协议的抓包与分析，就是针对DNS、TLS、MQTT、数据库协议、私有二进制协议等不走 HTTP 封装的数据流，在链路层或网络层把原始报文摘出来，再通过工具解析出其中的会话信息、时序、状态码和应用负载。这篇内容适合后端开发、运维、嵌入式与物联网开发者、测试工程师参考，目的是帮你从零建立一套处理非HTTP流量的排查方法论，而不是只会开个浏览器看 Network 面板。
1. 为什么要抓非HTTP协议的包
1.1 HTTP之外的流量无处不在
很多人一提起抓包就想到了 HTTP 请求，尤其是 Charles、Fiddler 这类工具用得太顺手，下意识以为所有通信都是“请求-响应”加一个明文 URL。但真实环境里 HTTP 只是众多应用协议中的一种，甚至从报文数量上看，HTTP 可能只占一小部分。
最典型的例子是 DNS。每一次访问域名背后都有 DNS 查询，而你打开一个网页可能产生十几条 DNS 报文，这些全是 UDP 上的明文流量。系统更新、NTP 时间同步、ARP、DHCP，这些都是非HTTP协议在默默工作。企业和云环境里还有 MySQL、PostgreSQL、Redis 等数据库协议，Kafka、RabbitMQ 等消息队列协议，以及大量基于 TCP/UDP 的自定义私有协议。IoT 设备上报数据经常走 MQTT 或者私有二进制协议，工业场景里还有 Modbus、OPC UA 等现场总线协议。
这些协议的共同点是没有浏览器那样的“调试面板”，没有状态码，没有可视化的请求/响应树。出了问题，你面对的是二进制字节流或者一段不知道含义的明文。这时候 HTTP 时代积累的调试习惯基本失效，必须回到报文层去还原事实。抓包成为唯一可靠的信息来源。
1.2 非HTTP协议抓包的典型场景
我在实际工作中总结下来，非HTTP抓包主要出现在这么几类场景里：
- 接口联调失败：两个服务之间走的是内部 RPC，框架封装得很深，日志里只有“connect timeout”，但客户端和服务端到底卡在哪里，得抓包看 SYN、SYN-ACK、ACK 到底有没有回来。
- 外网访问异常：某台机器无法解析域名，先抓 DNS 报文，看查询有没有发出、响应有没有回来、返回码是 NOERROR 还是 NXDOMAIN。
- 数据库连接慢：从客户端到数据库总延迟 2 秒，是 TCP 握手慢、TLS 协商慢，还是数据库自身处理慢？两端同时抓包，用时间戳一对比就清楚了。
- IoT/嵌入式设备调试：设备通过 2G/4G 模块上报数据，用的往往是自定义二进制协议，服务端解析不了，只能把设备发出的原始字节抓出来，逐字节比对协议文档。
- 运维应急排查：一台机器突然对外大量发包，说不清是什么进程，抓包看目标端口和 payload 特征，比单纯看 netstat 更直观。
这些场景覆盖了后端、运维、嵌入式、安全等多个岗位。只要你负责的服务不完全跑在浏览器里，早晚都得学会跟原始报文打交道。非HTTP抓包并不是一个高深领域，但它解决问题的方式和 HTTP 调试完全不同，核心是“用事实说话”，让报文告诉你真正发生了什么。
2. 抓包前的准备工作与工具选型
2.1 工具选型：Wireshark、tcpdump、tshark怎么选
抓包工具就那么几个，但选错了会浪费大量时间。我个人的习惯是：
| 工具 | 适用场景 | 缺点 |
|---|---|---|
| Wireshark | 图形界面交互分析，适合细看协议字段、时序、过滤后的流 | 不适合远程服务器、图形界面消耗资源 |
| tcpdump | 命令行快速抓包，适合服务器现场取证 | 解析展示不友好，多用于采集+简单过滤 |
| tshark | Wireshark 的命令行版本，适合批量分析、脚本化处理 | 参数多，上手曲线略陡 |
一般在服务器上我会先用 tcpdump 落盘，生成 pcap 文件，再拉到本地用 Wireshark 做详细分析。如果纯命令行搞，优先用 tshark，因为它能用显示过滤器直接输出 JSON、指定字段，也可以做会话统计，不用开图形界面。
抓包工具的权限要求也需要注意。Linux 下抓包需要 root 或者 CAP_NET_RAW 权限，普通用户往往看不到报文。生产环境不建议随便给服务商开 root，更推荐通过 sudo 给运维人员临时提权，或者使用专门的抓包审计账号。Wireshark 在 Windows 上还需要安装 Npcap/WinPcap 驱动，这是底层抓包的基础，很多人装了主程序却抓不到包，多半是驱动没装好。
2.2 抓包位置、权限与过滤器设计
工具定好之后，最关键的是想清楚“在哪里抓”。抓包位置选错了，后面全是白忙。
第一步是确定流量路径。客户端和服务端之间的通信，至少要经过客户端网卡、服务端网卡，中间可能有交换机、路由器、负载均衡。如果问题出在客户端和服务端之间的链路，最佳方案是在两端同时抓包，然后对比时间戳；如果只能抓一端，优先抓服务端入口，因为绝大多数问题最后都体现在服务端是否收到请求。
第二步是选择网络接口。本机自问自答的服务要抓 lo 回环接口；访问外部业务，要抓物理网卡或者虚拟网卡。在容器里抓包要小心，容器内部的 eth0 对应宿主机的 veth 设备，需要进容器命名空间或用 nsenter 进入网络命名空间才能正确抓到流经容器流量。
第三步是设计过滤策略。抓包的时候最好先用“抓包过滤器”把范围收窄，而不是抓一大坨再慢慢过滤。抓包过滤器用的是 BPF 语法，常见写法如下：
# 只抓某个主机的流量 host 192.168.1.100 # 只抓某个端口 port 53 # 抓端口范围 tcp portrange 8000-8005 # 组合条件 tcp port 3306 or udp port 5353设计过滤器的原则是“先窄后宽”。你如果完全不知道进程会连哪个端口，可以先用 -c 参数限制抓包条数，或者用 -C、-W 做文件切割，抓一小段时间后再分析。不要一上来就抓全量流量，否则高负载环境几秒钟就能把磁盘写满。
3. 实战：捕获与保存非HTTP流量
3.1 用 tcpdump 完成一次完整的非HTTP抓包
tcpdump 是我在服务器场景里用得最多的工具。一个典型的落盘命令长这样：
sudo tcpdump -i eth0 -nn -s 0 -C 100 -W 10 -Z root 'tcp port 3306 or udp port 5353' -w mysql_dns.pcap各参数含义如下：
-i eth0：指定抓包接口，可以用ip link show查接口名。-nn：不做 DNS 反向解析、不把端口解析成服务名，直接显示数字，速度和可读性更好。-s 0：快照长度设置为 0，表示抓完整包，不截断 payload，这是做非HTTP协议分析必须的。如果只关心包头，可以设置-s 64减小文件体积。-C 100：每个文件达到 100MB 就自动切换新文件。-W 10：最多保留 10 个文件，超过后循环覆盖，避免磁盘写爆。-Z root：抓包初始化后切换用户为 root，注意这只是权宜之计，生产环境建议用-Z tcpdump这类低权限用户配合组权限。-w mysql_dns.pcap：保存到文件。
抓完文件后，先用 tshark 快速看结构：
tshark -r mysql_dns.pcap -Y 'tcp.port==3306' -T fields -e tcp.stream -e ip.src -e tcp.dstport这条命令能把 TCP 流编号、源 IP、目标端口提取出来，筛掉无关内容。如果只是想快速看内容，可以直接用 tcpdump 的-A参数打印 ASCII：
sudo tcpdump -i lo -nn -A port 12345 -c 10对于文本类私有协议，这种方式能直接看到消息体；如果是二进制协议，用-X打印 hex 和 ASCII 混合视图，对照协议文档逐个字节分析。
3.2 用 Wireshark 高效分析并保存现场
服务器上抓到 pcap 后，我基本都会拉到本地用 Wireshark 分析。打开 Wireshark，先选接口，设置捕获过滤器，点 Start 开始抓包。这个环节最常见的误区是把“显示过滤器”当成“捕获过滤器”。捕获过滤器是在采集阶段丢包，显示过滤器只是隐藏不符合条件的包，两个作用完全不同。
实际分析时我通常先看Statistics -> Protocol Hierarchy，了解这个 pcap 里协议分布，比如有多少 TCP、多少 UDP、多少 TLS、多少未知协议。然后进入Statistics -> Endpoints看通信端点，找到最活跃的主机。再根据目标端口或 IP 设置显示过滤器，缩小到具体会话。
常用显示过滤器如下：
| 场景 | 过滤器表达式 |
|---|---|
| 只看某个 TCP 端口 | tcp.port == 3306 |
| 只看某个 UDP 端口 | udp.port == 53 |
| 只看 TCP 三次握手 SYN 包 | tcp.flags.syn == 1 && tcp.flags.ack == 0 |
| 只看 DNS 响应 | dns.flags.response == 1 |
| 只看重传包 | tcp.analysis.retransmission |
| 找负载里的关键字 | frame contains "error" |
对于二进制私有协议，找到可疑报文后直接右键Follow -> TCP Stream，可以看到整个会话的完整数据流。Wireshark 还支持标记、注释和导出。分析时最好保留一份原始 pcap 只读存档，另存一个带过滤结果的分析副本，不要在原文件上反复修改，否则要重新抓包。
保存现场的常用命令也不能少：
# 按 10000 个包拆分大文件 editcap -c 10000 big.pcap small_00001.pcap # 合并多个 pcap mergecap -w merged.pcap part1.pcap part2.pcap抓包分析既是一个取证过程，也是一个复现过程，现场文件保存得越完整，后续复盘越容易。
4. 核心细节解析：协议识别与报文结构解读
4.1 面对未知协议时怎么下手
非HTTP抓包最常遇到的难题是“这到底是个什么协议”。端口号可以乱配，协议不能只看端口判断，但在日常排障中端口仍然是最快的突破口。先对照 /etc/services 和 IANA 端口表，能覆盖掉一大半已知服务。
如果端口表对不上，就观察 payload 的二进制特征。Wireshark 的右下角 hex 窗口很容易看出规律：
- 字节全是可打印 ASCII 字符，且有一定语义，比如 JSON、XML、Key=Value，多半是文本协议。
- 字节开头有固定魔数，比如 0xAA55、0xFEED、"MZ" 等，通常是二进制协议，魔数用于标识帧起始和协议版本。
- 每条报文的长度基本一致，可能用了定长结构；长度变化但有明确起始位，可能是 TLV 结构。
- 整体看起来“乱七八糟”，每个字节熵都很高，很可能是加密或压缩数据。
Wireshark 对未知协议有启发式解析机制。当它识别到某个 UDP 端口没有对应协议时，会尝试多个解析器，如果匹配到已知特征就会自动按该协议解码。但这种猜测不一定准确，可以在报文的详情面板右键选择Decode As，手动指定协议。比如某个自定义端口上流量本质上是个 DNS 查询，但被识别成未知协议，强制按 DNS 解析后立刻就能看到完整字段。
如果需要批量分析未知协议，我习惯用 tshark 把 payload 导出来：
tshark -r unknown.pcap -T fields -e data -E hex导出 hex 后再用脚本解析。对于稍微复杂的私有协议，这也是一种“先盲解、再自动化”的好路径。不要一开始就指望工具能自动解码，大多数私有协议需要你根据业务文档和抓包内容自己拆字段。
4.2 从TCP/UDP到DNS：三个高频协议报文结构
非HTTP协议里，传输层用得最多的就是 TCP 和 UDP，而 DNS 是 UDP 上最常见的应用协议。这三个协议结构理解了，分析其他协议会轻松很多。
TCP 报文段的关键字段包括源端口、目的端口、序列号、确认号、标志位、窗口大小、校验和。排障时最常看的就是标志位。三个 TCP 握手包一定是 SYN、SYN-ACK、ACK 依次出现，如果只有 SYN 不断重传而没有响应，就说明另一端不可达或防火墙丢弃。数据乱传时还会看到序列号回退、重复 ACK、乱序包，Wireshark 会用tcp.analysis.*标记。常见的重传间隔是 1 秒、2 秒、4 秒成倍增长，这是 TCP 的重传退避算法，注意这个特征能帮你判断“是网络丢包还是对端没处理”。
UDP 报文结构比 TCP 简单得多，只有源端口、目的端口、长度和校验和，没有确认机制。但它不代表应用层一定丢包，很多协议会在 UDP 上面自己做 ACK 和重传，比如 QUIC、TFTP、自定义 P2P 协议。分析 UDP 流量时，重点是看包长和 payload 规律，因为 UDP 天然面向消息边界，一个 UDP 报文往往就对应一个完整的应用消息。
DNS 报文结构是学习协议解析最好的入口。头部固定 12 字节，依次是事务 ID、标志位、问题计数、回答计数、权威计数、附加计数。标志位里最重要的是 QR（0 表示查询，1 表示响应）、Opcode、TC（截断标志）、RD（递归期望）、RA（递归可用）和 RCODE（返回码）。用 Wireshark 抓一条 nxdomain 响应，能看到 RCODE 字段等于 3，配合问题域名就能快速定位是哪个域名解析失败。
这些协议结构看着枯燥，但排障时是实打实的基础。TCP 握手时序能定位链路问题，DNS 的返回码能定位解析链路，UDP 的长度规律能帮你识别私有协议边界。
4.3 加密流量还是可见流量：怎么判断
非HTTP世界里，加密流量比例越来越高。TLS 不只属于 HTTPS，MySQL、SMTP、MQTT 等都可以跑在 TLS 上面。抓包时你会在 payload 里看到 TLS 握手前几个明文报文：ClientHello 里有客户端支持的加密套件列表，还带一个 SNI 扩展，里面是服务器名称。ServerHello 里能看到服务端选定的加密套件和证书链。
所以哪怕没有密钥，也能从抓包里判断“这个连接加密了、连的是哪个域名、用的什么证书”。对于排查连接建立问题，TLS 握手本身的信息基本够用：握手失败会直接体现在 Alert 报文里，能看到是 certificate unknown 还是 handshake failure。
如果确实需要解密应用层数据，前提是你拥有这个流量和密钥的合法访问权。常见做法是在应用进程启动时设置SSLKEYLOGFILE环境变量，让程序把所有会话密钥写到一个文件里，然后通过 Wireshark 的Preference -> TLS -> (Pre)-Master-Secret log filename指定这个文件，就能自动解密抓到的 TLS 流量。这个方法只适合在测试环境或你自己负责的服务上调试，生产环境开 SSLKEYLOGFILE 等于把通信内容明文落盘，风险极高，不建议随便用。
判断“能不能看到内容”是抓包分析的第一步。明文协议直接看包，加密协议看握手元数据，查证书和 SNI，再决定下一步要不要解密、能不能解密。
5. 常见问题与排查技巧实录
5.1 抓不到流量或抓得不全
这是最高频的问题，抓了半天屏幕上什么都没有，先别怀疑工具，按下面清单排查：
- 接口选错：本机回环流量要抓
lo，外网流量要抓对应物理网卡，容器流量要到容器网络命名空间里抓。可以用tcpdump -D列出所有接口，确认名字。 - 过滤条件错误：写错了端口或 IP 导致空结果。先去掉所有过滤条件，抓一个 ping 包或者 DHCP 包确认链路是通的。
- 权限不足：普通用户跑 tcpdump 会报权限错误，要用 sudo 或给账号加抓包权限。
- 流量走向不对：两端通信不经过抓包点。比如服务端在负载均衡后面，客户端直接连负载均衡，那就要在负载均衡的流量镜像口或者后端服务上抓。
- 包被内核丢弃：高流量环境下，tcpdump 使用的环形缓冲区可能溢出。可以加
-B参数调大缓冲区，例如-B 4096。
还有一个常见坑是抓包文件和系统时间不同步。现场抓包时最好在客户端和服务端执行同样的时间同步操作，然后两端同时抓包，用 pcap 里的时间戳对比，才能准确判断延迟出现在哪个方向。
5.2 抓到超大流量或磁盘空间不足怎么办
生产环境抓包最怕几分钟磁盘就满。其实 tcpdump 提供了很多控制手段：
-c 1000：抓 1000 个包后自动退出。-G 60：每 60 秒切换一个新文件。-W 5：最多保留 5 个文件，配合-G 60就表示只保留最近 5 分钟。-s 128：只抓每个包的前 128 字节，够看包头，文件体积会小很多。
另外，wireshark 的显示过滤不能减少抓包文件大小，它只是隐藏。真正节省空间要靠 BPF 捕获过滤器或者抓包参数。
还有一种情况是流量大到 10Gbps，正常抓包已经会丢包。这时候不要直接抓完整包，可以先用 sFlow/netflow 看流量分布，再找问题对象定向抓包。大多数排障场景关注的是“有没有、从哪里来、到哪去”，不一定需要完整 payload。抓包不是录纪录片，目标是锁定证据。
5.3 应急时刻怎么快速定位一次非HTTP异常
如果服务已经挂了，没有时间慢慢研究，我一般走一套“黄金五步法”：
- 确定拓扑：从客户端到服务端经过哪些设备，端口和协议是什么。
- 两端同时抓 10 秒：客户端包和服务端包各一份，最好用 tcpdump 落盘。
- 对比时间戳：看请求是否到达服务端，响应是否发出。如果客户端发了包但服务端没收到，问题在网络链路或防火墙；如果服务端收到但没回包，问题在应用层。
- 看 TCP 状态流转：用 Wireshark 打开 pcap，找到对应 TCP 流，看是卡在握手、卡在 TLS 协商、还是卡在应用层数据交互。
- 还原应用负载：对最后几个数据包做 Follow TCP Stream，确认发送的内容是否和预期一致，有没有被截断或乱码。
这套方法不需要懂协议内部细节也能先定位到范围，然后再根据具体协议深入。经验多了会发现，大部分问题到最后不是网络丢包，而是某种超时、半连接、MTU 分片或者防火墙策略在作怪，而这些全都能从抓包里找到证据。
我在实际使用中最大的体会是，抓包分析必须建立“拿到证据再动手”的习惯。不要凭感觉猜是哪个服务慢，不要看几条日志就下结论。非HTTP协议没有浏览器调试面板，但恰恰因为这样，报文才是最老实、最完整的事实记录。抓到包、会看包、能保存包，这套基本功练熟了，以后再复杂的非HTTP问题，你手里都多了一把解决问题的钥匙。
