测试人必备的网络问题定位实战指南

1. 这不是复习笔记而是一张“网络世界生存地图”你打开浏览器输入一个网址几秒后页面就跳出来——这背后没有魔法只有一套精密协作的协议体系在默默运转。我带过不少刚入行的测试人发现一个普遍现象他们能熟练写接口用例、跑自动化脚本、看抓包数据但一旦被问到“为什么这个HTTP请求会超时”“TCP三次握手失败时Wireshark里会看到什么”“DNS解析卡住该从哪一层开始排查”很多人会愣住甚至下意识翻文档。这不是能力问题而是知识结构存在断层我们太习惯站在应用层“用网络”却很少蹲下来摸一摸物理层的网线温度、听一听传输层的重传心跳。这篇内容就是为这类“看得见流量、摸不着脉络”的测试人准备的。它不叫《计算机网络复习大纲》也不叫《协议栈速查手册》我把它称作一张“网络世界生存地图”——地图上标出的不是景点而是你每天调试接口、分析性能、定位线上故障时真正会踩到的坑、会用到的工具、会调用的知识点。核心关键词就三个测试人、计算机网络、学习梳理。它不追求把OSI七层模型背得滚瓜烂熟而是聚焦在“测试视角下哪些网络知识是高频刚需、哪些原理必须懂、哪些工具必须会、哪些现象一眼就能判断出问题在哪一层”。比如当你看到Postman里一个POST请求耗时2.3秒其中TTFBTime to First Byte占了1.8秒这1.8秒里DNS查询花了多少TCP连接建了多久TLS握手又耗了多少这些时间切片就是测试人手里的“网络显微镜”。这篇文章就是教你如何校准这台显微镜并读懂它放大的每一个细节。我做过一个粗略统计在某公司近半年的500条线上接口性能告警中约37%的问题根源在应用层以下——DNS配置错误、CDN节点异常、TCP连接池耗尽、SSL证书过期、防火墙策略拦截。这些故障日志里往往只显示“Connection refused”或“Timeout”但真正的线索就藏在三次握手的SYN包是否发出、ACK是否返回、FIN是否正常关闭这些最基础的网络行为里。所以这不是给网络工程师看的深度协议分析而是给测试人量身定制的“网络问题定位实战指南”。无论你是刚转测开的开发还是做了三年功能测试想突破瓶颈的同事只要你需要和HTTP、HTTPS、WebSocket、gRPC这些协议打交道这张地图上的每一个坐标都值得你停下来亲手验证一遍。2. 内容整体设计与思路拆解为什么测试人要学网络学什么怎么学2.1 测试人的网络知识盲区恰恰是线上问题的高发区很多测试人觉得“网络是运维的事是开发的事我只要保证用例覆盖全、脚本跑得稳就行。”这种想法在单体架构、内网测试环境下或许成立但在今天它已经成了最大的认知陷阱。我们面对的系统早已不是部署在一台服务器上的“小作坊”而是由CDN、负载均衡、API网关、微服务集群、消息队列、对象存储等组成的分布式网络。一次用户点击背后可能触发10次跨地域、跨云厂商、跨协议的网络交互。在这种场景下“网络”不再是背景板而是整个系统的毛细血管和神经末梢。我带的一个模拟项目X就曾遇到一个典型问题前端页面加载缓慢监控显示后端API平均响应时间100ms但用户侧首屏时间高达4.2秒。开发和后端同学反复检查代码、数据库、缓存一无所获。最后是我用Wireshark在客户端抓包发现大量TCP重传Retransmission和重复ACKDup ACK。顺着这个线索我们最终定位到是某云厂商的SLBServer Load Balancer健康检查配置不当导致部分后端实例被误判为宕机流量被集中打向少数节点引发TCP连接拥塞。这个问题日志里没有任何报错APM工具只显示“慢请求”但网络层的重传风暴像海面下的暗流直接决定了用户体验的生死。这就是测试人必须懂网络的根本原因我们是离用户最近的一道防线也是最容易捕捉到“网络异常信号”的人。2.2 拒绝“教科书式”学习聚焦“测试现场高频问题域”市面上的网络教材动辄上千页从香农定理讲到BGP路由协议。对测试人而言这是巨大的时间浪费。我们的学习目标非常明确在最短时间内建立一套能快速定位、高效分析、准确归因的网络问题处理能力。因此整个内容设计完全摒弃了传统教材的“自顶向下”或“自底向上”逻辑而是采用“问题驱动”的逆向拆解法。我们以测试日常中最高频的5类问题为锚点反向梳理所需知识问题1接口超时Timeout→ 需要理解TCP连接建立三次握手、TLS握手、HTTP/HTTPS协议栈差异、DNS解析流程。问题2连接拒绝Connection Refused/Reset→ 需要掌握端口状态LISTEN/ESTABLISHED、防火墙规则、服务进程存活状态、TCP RST包含义。问题3数据丢包/乱序Packet Loss/Out-of-Order→ 需要了解IP分片、MTU路径发现、TCP滑动窗口、拥塞控制算法如Cubic。问题4HTTPS证书错误→ 需要厘清PKI体系、证书链验证、OCSP Stapling、SNI扩展。问题5WebSocket连接不稳定→ 需要明白HTTP升级机制、TCP长连接保活Keep-Alive、代理服务器对Upgrade头的处理。你看这5个问题没有一个是关于“OSI模型第几层叫什么名字”的考题全部来自真实压测报告、线上告警工单和晨会复盘记录。每一个问题背后都对应着一组精简、精准、可立即上手验证的知识模块。比如针对“接口超时”我们不会花大篇幅讲TCP滑动窗口的数学推导而是直接告诉你在Wireshark里如何用tcp.time_delta过滤出三次握手各阶段耗时如何用tshark -r trace.pcap -Y ssl.handshake -T fields -e frame.time_epoch命令一键提取所有TLS握手时间戳如何通过对比curl -w curl-format.txt -o /dev/null -s http://example.com输出的time_namelookup、time_connect、time_appconnect等字段精准切分DNS、TCP、TLS各环节耗时。这才是测试人需要的“网络知识”。2.3 工具链选择轻量、开源、可嵌入CI/CD拒绝重型黑盒测试人的工作流天然要求工具必须“轻、快、稳、可集成”。因此在工具选型上我们严格遵循三条铁律零安装依赖优先选择纯命令行工具如curl、dig、telnet、tshark它们无需GUI、不占内存、可在任意Linux容器中秒级启动。一个curl -v https://api.example.com比打开Fiddler再配置代理快10倍。数据可编程所有工具输出必须是结构化文本JSON/CSV/TXT方便用Python或Shell脚本做二次分析。例如mtr --report example.com生成的网络路径报告可以直接用awk提取每一跳的丢包率写入监控大盘。与测试框架无缝衔接工具必须能作为测试步骤嵌入Pytest、JUnit或Postman Collection Runner。我们甚至封装了一个network_check的Pytest fixture它能在每个API测试用例执行前后自动运行ping、traceroute、curl -I三连招并将结果作为测试附件上传到Allure报告中。基于此我们彻底放弃了那些需要复杂配置、依赖特定操作系统、输出难以解析的商业工具。整个工具链就是一张极简的“瑞士军刀”清单curl协议交互、digDNS诊断、mtr路径探测、tshark深度抓包、ss连接状态、nmap端口扫描。它们加起来不到50MB却能覆盖95%以上的网络问题初筛场景。我试过在一个只有2核4G的CI流水线Agent上这套组合拳跑完一个完整的网络健康检查耗时不到800ms。这才是工程化的生产力。3. 核心细节解析与实操要点从“看到现象”到“读懂本质”3.1 DNS解析那个总在“看不见的地方”拖慢你的第一步DNS全称Domain Name System中文叫“域名系统”。它的作用就是把www.example.com这样人类好记的名字翻译成192.0.2.1这样机器能懂的IP地址。对测试人来说DNS不是“第一次接触网络时学的概念”而是每次发起HTTP请求时必须先完成的前置动作。如果这一步卡住后面所有操作都是空谈。为什么DNS会成为性能瓶颈递归查询链路过长你的本地DNS服务器如运营商DNS可能需要向根域名服务器、顶级域服务器.com、权威域名服务器example.com逐级查询每跳都增加RTTRound-Trip Time。缓存失效或缺失本地/etc/hosts、系统DNS缓存、浏览器DNS缓存、ISP DNS缓存任何一层失效都会触发完整查询。DNS污染或劫持某些网络环境会返回错误IP导致请求发往错误服务器最终超时。实操要点用dig做精准诊断dig是DNS领域的“万用表”比nslookup更强大、输出更规范。记住这几个核心命令# 基础查询查看example.com的A记录IPv4地址 dig example.com A short # 指定DNS服务器查询绕过本地DNS直连114.114.114.114国内公共DNS dig 114.114.114.114 example.com A short # 追踪完整查询路径模拟递归过程看哪一跳最慢 dig trace example.com A # 查询DNSSEC签名状态验证响应是否被篡改 dig example.com DNSKEY dnssec提示short参数让输出极度精简只返回IP方便脚本解析trace则像一个“探路者”它会从根服务器开始一步步告诉你example.com的权威服务器是谁、响应时间是多少。我在某次压测中就用dig trace api.prod.company.com发现某海外CDN的权威DNS服务器响应时间高达1.2秒而国内DNS只需20ms。这直接解释了为什么海外用户访问慢——问题不在后端而在“找门牌号”这一步。关键参数解读;; Query time: 23 msec本次查询耗时23毫秒这是最核心的性能指标。;; SERVER: 192.168.1.1#53(192.168.1.1)当前使用的DNS服务器IP和端口。;; WHEN: Tue Oct 10 14:22:33 CST 2023查询发生的时间用于交叉比对日志时间戳。避坑心得不要迷信pingping www.example.com会先做DNS解析再发ICMP包。如果ping不通你无法区分是DNS失败还是网络不通。务必先用dig确认DNS是否正常。curl的-w参数是神器curl -w DNS: %{time_namelookup}s, Connect: %{time_connect}s, AppConnect: %{time_appconnect}s, Total: %{time_total}s\n -o /dev/null -s https://example.com。这条命令会精确告诉你整个HTTP请求生命周期里DNS花了多久、TCP连接花了多久、TLS握手花了多久。这是我每天必跑的“三分钟健康快检”。3.2 TCP连接三次握手不是仪式而是建立信任的契约HTTP/1.1、HTTPS、MySQL连接底层都依赖TCPTransmission Control Protocol。TCP的核心价值在于它提供了一种“可靠、有序、无丢失”的字节流传输服务。而这一切的起点就是著名的“三次握手”Three-Way Handshake。三次握手的本质是什么它不是一个技术炫技而是一个严谨的“双向确认”过程目的是解决两个根本问题同步初始序列号ISN双方约定一个随机数作为数据包编号的起点防止旧连接的数据包被新连接误收即“历史包”问题。确认双方的收发能力Client发SYNServer回SYN-ACKClient再回ACK。只有当Server收到最后一个ACK才敢认为Client不仅能发还能收。Wireshark里如何一眼识别三次握手打开Wireshark过滤器输入tcp.flags.syn 1 or tcp.flags.ack 1然后找连续的三个包Packet 1 (SYN)Source Port54321, Destination Port443, Flags[SYN], Seq123456789Packet 2 (SYN-ACK)Source Port443, Destination Port54321, Flags[SYN, ACK], Seq987654321, Ack123456790Packet 3 (ACK)Source Port54321, Destination Port443, Flags[ACK], Seq123456790, Ack987654322注意SeqSequence Number和AckAcknowledgment Number的数值关系。Packet 2的Ack值 Packet 1的Seq 1Packet 3的Ack值 Packet 2的Seq 1。这是TCP协议的硬性规定也是你判断握手是否成功的黄金法则。常见故障模式与排查故障现象Wireshark表现根本原因排查命令SYN发送后无响应只有Packet 1后续无Packet 2目标端口未监听、防火墙DROP、路由不可达telnet target_ip 443或nc -zv target_ip 443SYN-ACK返回后无ACK有Packet 1和2无Packet 3Client端防火墙拦截、Client主机崩溃、网络中间设备如NAT异常ss -tn state syn-sent查看Client端连接状态连接建立后立即RST握手完成后立刻出现Flags[RST]包Server端应用进程崩溃、端口被其他程序占用、TLS版本不兼容ss -tnlp | grep :443查看哪个进程在监听实操心得ss命令比netstat更快、更现代。ss -tn列出所有TCP连接-l显示监听端口-p显示进程名需root权限。一条ss -tnlp \| grep :8080就能立刻知道8080端口是被Java还是Node.js占着。在压测中如果发现大量SYN_RECV状态连接Server端说明Server的accept()队列满了可能是后端处理能力不足也可能是恶意SYN Flood攻击。这时ss -s会显示TCP: inuse 1234 orphan 567 synrecv 890其中synrecv数字就是待处理的半连接数。3.3 HTTPS与TLS加密不是黑箱证书链才是信任的基石当URL从http://变成https://背后增加的不只是一个“S”而是一整套名为TLSTransport Layer Security的加密协议。对测试人而言理解TLS不是为了去实现一个密码学库而是为了能看懂浏览器地址栏的锁图标为什么是灰色的、为什么Postman会报SSL certificate problem、为什么线上环境证书更新后App突然无法登录。TLS握手的核心四步简化版Client HelloClient告诉Server自己支持的TLS版本、加密套件Cipher Suites、一个随机数Client Random。Server Hello CertificateServer选择一个双方都支持的加密套件返回自己的随机数Server Random并附上自己的数字证书。Certificate Verify Key ExchangeClient验证Server证书的有效性签名、有效期、域名匹配、吊销状态然后生成一个“预主密钥”Pre-Master Secret用Server证书里的公钥加密后发给Server。Finished双方用Client Random、Server Random、Pre-Master Secret共同生成“主密钥”Master Secret并用它派生出对称加密密钥。最后双方发送Finished消息用新密钥加密互相验证。证书链Certificate Chain为什么一个网站需要多个证书浏览器信任的不是你的网站证书而是根证书颁发机构Root CA的证书。但Root CA不会直接给你签发而是通过中间CAIntermediate CA来签。所以一个完整的证书链是Your Site Cert← signed by ←Intermediate CA Cert← signed by ←Root CA Cert。Web服务器如Nginx必须把Your Site Cert和Intermediate CA Cert一起发给浏览器否则浏览器无法构建完整信任链就会报错。实操诊断用openssl做证书体检# 获取服务器证书并打印详细信息 openssl s_client -connect api.example.com:443 -servername api.example.com 2/dev/null | openssl x509 -text -noout # 检查证书有效期一行命令输出剩余天数 echo | openssl s_client -connect api.example.com:443 2/dev/null | openssl x509 -noout -dates | grep notAfter | awk {print $4, $5, $7} | xargs -I {} date -d {} %s | xargs -I {} echo $(($(date -d now %s) - {})) | xargs -I {} echo Days left: $(($_/86400)) # 检查证书链完整性返回0表示完整非0表示缺失中间证书 openssl s_client -connect api.example.com:443 -showcerts -servername api.example.com /dev/null 2/dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout -inform PEM 2/dev/null | wc -l注意-servername参数SNI至关重要。在虚拟主机Virtual Hosting环境下一个IP可能托管多个HTTPS站点Server需要根据SNI头来决定返回哪个证书。漏掉它openssl可能拿到默认证书或错误证书。避坑心得浏览器报NET::ERR_CERT_AUTHORITY_INVALID90%的原因是缺少中间证书。用上面的openssl命令检查如果只返回1个证书那基本就是它了。解决方案在Nginx的ssl_certificate指令中把网站证书和中间证书合并成一个.pem文件。curl的--insecure或-k选项只是忽略证书验证绝不在生产环境或自动化脚本中使用。它相当于把门锁撬开而不是修好锁。正确的做法是用--cacert /path/to/ca-bundle.crt指定受信任的CA证书包。4. 实操过程与核心环节实现一个完整的“接口超时”故障定位实战4.1 场景设定一个真实的压测故障复现我们以某次压测中的一个具体案例为蓝本进行全流程实操演示。场景如下系统一个提供用户注册服务的RESTful API部署在Kubernetes集群中入口由Nginx Ingress Controller暴露。现象在200并发用户压测下约15%的POST /api/v1/register请求返回504 Gateway Timeout平均响应时间飙升至8.2秒正常应300ms。初步排查后端服务Pod CPU、内存、GC日志均正常数据库慢查询日志无新增Ingress Controller自身监控无异常。这是一个典型的“网络层问题伪装成应用层故障”的案例。现在我们开始动手用测试人的方法论一层层剥开洋葱。4.2 第一步隔离问题域——确认是网络问题而非应用问题首先我们必须排除“是应用本身慢还是网络卡”。最直接的方法是绕过所有网络中间件直连后端服务。获取后端服务的真实IP和端口# 在K8s集群内获取Service的ClusterIP kubectl get svc user-service -o jsonpath{.spec.clusterIP} # 输出10.96.123.45 # 获取Service的端口映射 kubectl get svc user-service -o jsonpath{.spec.ports[0].port} # 输出8080在Ingress Pod内直连后端Service# 进入Ingress Controller的Pod kubectl exec -it nginx-ingress-controller-xxxxx -- sh # 使用curl直连注意这里用的是ClusterIP不是域名 curl -w Total: %{time_total}s, HTTP: %{http_code}\n -o /dev/null -s http://10.96.123.45:8080/api/v1/register -H Content-Type: application/json -d {username:test,email:testexample.com} # 输出Total: 0.023s, HTTP: 201结果直连耗时仅23ms且返回201成功。这证明后端服务本身完全健康问题一定出在“从外部用户到Ingress”这段路径上。4.3 第二步分段测量——用curl -w切分网络耗时既然直连没问题问题就在Ingress之前的链路上。我们回到压测机对同一个/api/v1/register接口运行带时间戳的curl# 创建一个格式化模板文件 curl-format.txt cat curl-format.txt EOF time_namelookup: %{time_namelookup}s time_connect: %{time_connect}s time_appconnect: %{time_appconnect}s time_pretransfer: %{time_pretransfer}s time_redirect: %{time_redirect}s time_starttransfer: %{time_starttransfer}s time_total: %{time_total}s http_code: %{http_code} EOF # 执行10次请求观察耗时分布 for i in {1..10}; do echo Request $i curl -w curl-format.txt -o /dev/null -s https://api.example.com/api/v1/register -H Content-Type: application/json -d {username:test,email:testexample.com} echo done典型输出分析 Request 1 time_namelookup: 0.004s time_connect: 0.021s time_appconnect: 1.842s # 关键TLS握手耗时1.84秒 time_pretransfer: 1.842s time_starttransfer: 1.845s time_total: 1.845s http_code: 201我们立刻锁定time_appconnect这个字段。它代表从TCP连接建立完成到TLS握手完成的时间。正常值应在100ms以内而这里是1842ms暴涨了18倍。这清晰地告诉我们问题出在TLS握手环节。4.4 第三步深度抓包——用tshark捕获TLS握手细节为了看清TLS握手到底卡在哪一步我们在压测机上启动tshark只抓取目标域名的HTTPS流量# 开始抓包后台运行保存到tls.pcap tshark -i eth0 -f host api.example.com and port 443 -w tls.pcap # 同时用curl触发一次请求 curl -s https://api.example.com/api/v1/register -H Content-Type: application/json -d {username:test} /dev/null # 停止抓包 kill %1 # 分析抓包文件只显示TLS握手相关包 tshark -r tls.pcap -Y ssl.handshake -T fields -e frame.number -e ip.src -e ip.dst -e ssl.handshake.type -e ssl.handshake.version -e ssl.handshake.ciphersuite -e _ws.col.Info关键输出解读1 192.168.1.100 203.0.113.5 1 TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Client Hello 2 203.0.113.5 192.168.1.100 2 TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Server Hello 3 203.0.113.5 192.168.1.100 11 TLSv1.2 (null) Certificate 4 203.0.113.5 192.168.1.100 12 TLSv1.2 (null) Server Key Exchange 5 203.0.113.5 192.168.1.100 14 TLSv1.2 (null) Server Hello Done 6 192.168.1.100 203.0.113.5 16 TLSv1.2 (null) Client Key Exchange 7 192.168.1.100 203.0.113.5 20 TLSv1.2 (null) Change Cipher Spec 8 192.168.1.100 203.0.113.5 22 TLSv1.2 (null) Encrypted Handshake Message 9 203.0.113.5 192.168.1.100 20 TLSv1.2 (null) Change Cipher Spec 10 203.0.113.5 192.168.1.100 22 TLSv1.2 (null) Encrypted Handshake Message我们重点关注Packet 3Certificate和Packet 6Client Key Exchange之间的时间差。在Wireshark GUI中右键Packet 3 - “Set Time Reference”然后看Packet 6的“Delta Time”发现间隔为1.82秒。这证实了curl的time_appconnect读数。为什么证书传输这么慢继续分析Packet 3Certificatetshark -r tls.pcap -Y ssl.handshake.type 11 -T pdml | grep -A 20 x509if输出显示Server返回的证书链包含了3个证书总大小为4.2KB。而我们的Ingress ControllerNginx配置中ssl_buffer_size默认是4KB。这意味着4.2KB的证书链需要至少2个TCP包才能发完。而第二个包在网络拥塞时出现了重传。4.5 第四步根因定位与修复——优化证书链与缓冲区综合所有证据我们得出结论在高并发下Ingress Controller的TLS证书链过大4.2KB超过了默认的ssl_buffer_size4KB导致证书传输被拆包而第二个TCP包在网络抖动时重传从而拉长了TLS握手时间最终触发了上游负载均衡器的超时5秒返回504。修复方案双管齐下精简证书链联系证书提供商获取最小化的证书链通常只包含网站证书一个中间证书确保总大小4KB。我们最终将证书链压缩到2.8KB。增大Nginx缓冲区在Ingress Controller的ConfigMap中添加data: ssl-buffer-size: 8192 # 从默认4KB提升到8KB验证修复效果# 重新运行curl -w测试 curl -w curl-format.txt -o /dev/null -s https://api.example.com/api/v1/register -d {username:test} # 输出time_appconnect: 0.089s 恢复正常 # 重新压测504错误率从15%降至0%这个案例完美诠释了测试人学网络的价值我们没有修改一行业务代码没有扩容一台服务器仅仅通过curl -w、tshark和openssl这三个命令就定位并解决了一个困扰团队两天的线上难题。网络知识就是测试人的“第二双眼睛”。5. 常见问题与排查技巧实录那些年我们踩过的网络坑5.1 “Connection refused” vs “Connection timeout”一字之差千差万别这是测试人最常混淆的两个错误但它们指向完全不同的故障域。错误信息含义网络层位置常见原因快速验证命令Connection refusedClient发出了SYN包但Server立即返回了RST包TCP层Server端口未监听、防火墙DROP、服务进程崩溃telnet target_ip port或nc -zv target_ip portConnection timeoutClient发出了SYN包但一直没收到Server的SYN-ACKIP层或以下路由不可达、防火墙静默丢弃、Server宕机、网络设备故障ping target_ip、traceroute target_ip、mtr target_ip实操心得telnet是诊断Connection refused的黄金标准。如果telnet target_ip 8080返回Connected to target_ip.说明端口通如果返回Connection refused说明端口有监听但拒绝连接如应用层鉴权如果卡住几秒后报No route to host或直接超时则是timeout。mtr比traceroute更强大它结合了ping和traceroute能实时显示每一跳的丢包率和延迟。在排查跨境网络问题时mtr --report example.com的输出比任何文字描述都直观。5.2 抓包抓不到Wireshark的“隐形开关”与权限陷阱很多测试人第一次用Wireshark会遇到“明明在发请求但Wireshark里一片空白”的情况。这通常不是软件问题而是几个关键设置没打开。必须检查的三项网卡选择Wireshark左上角的网卡列表一定要选对。如果你在笔记本上有Wi-Fi、Ethernet、Loopback等多个接口而你的请求是走Wi-Fi发出的却在Loopback上抓包自然什么都看不到。一个简单办法在开始抓包前先ping一下目标地址看Wireshark里是否有ICMP包出现以此确认网卡选对了。混杂模式Promiscuous Mode默认是开启的图标为一个蓝色的“P”它允许网卡接收所有经过它的数据包而不仅是发给自己的。在虚拟机或某些特殊网络环境中可能需要手动勾选。权限问题Linux/macOSWireshark需要CAP_NET_RAW能力才能抓包。普通用户运行时会提示“Permission denied”。解决方案临时sudo wireshark永久推荐sudo setcap cap_net_raw,cap_net_admineip /usr/bin/dumpcap这样普通用户也能用tsharkWireshark的命令行版。独家技巧用tcpdump替代Wireshark做轻量抓包当Wireshark太重或者你只想快速确认某个现象时tcpdump是更好的选择# 抓取所有到80端口的HTTP请求只抓包头不抓body节省空间 tcpdump -i eth0 -A -s 1024 tcp port 80 and (((ip[2:2] - ((ip[0]0xf)2)) - ((tcp[12]0xf0)2)) ! 0) # 抓取并保存为pcap文件供后续用Wireshark分析 tcpdump -i eth0 -w debug.pcap host api.example.com and port 4435.3 “localhost”和“127.0.