测试工程师进阶网络分层模型精讲 tcpdump 抓包实战附真实抓包数据本文是高级测试工程师课程第 9 章配套实操笔记。所有命令均在真实 Ubuntu 24.04 云主机上执行抓包输出全部为真实回显拒绝纸上谈兵。前言做测试工程师尤其是做接口测试、性能测试网络知识是绕不开的地基接口报 500到底是应用问题还是网络问题性能测试中 TTFB 偏高是 DNS 慢、TCP 慢还是服务端处理慢为什么说 HTTPS 能防抓包Fiddler 又是怎么破解HTTPS 的这些问题靠背八股文是答不好的。本文带你从OSI/TCP 模型 → ICMP/DNS 工具 → tcpdump 抓包 → curl 深度使用一路实操下来把三次握手、四次挥手、HTTP 明文、TLS 加密流量全部真实抓一遍。看完你就能把网络分层从概念变成手上功夫。一、实验环境项目配置云主机华为云 ECS华南-广州操作系统Ubuntu 24.04.4 LTSnoble内核Linux 6.8.0-106-generic x86_64配置8 vCPU / 14 GiB 内存 / 40 GiB 系统盘带宽5 Mbit/s主要工具tcpdump 4.99、curl 8.5.0、bind9-dnsutilsdig/nslookup、mtr、traceroute被测服务本机 Flask 演示应用127.0.0.1:5000提示Ubuntu 24.04 的 apt 源已改为 deb822 格式/etc/apt/sources.list.d/ubuntu.sources换国内镜像源用 sed 替换域名即可cp/etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.baksed-is|//[a-zA-Z0-9.-]*/ubuntu|//mirrors.huaweicloud.com/ubuntu|g/etc/apt/sources.list.d/ubuntu.sourcesaptupdate二、网络分层模型OSI 七层 vs TCP/IP 四层2.1 模型对照表OSI 是理论模型TCP/IP 是实际落地的模型。测试工程师面试必考、工作必用OSI 七层TCP/IP 四层核心职责典型协议/设备本机验证命令7 应用层应用层为应用程序提供网络服务HTTP、HTTPS、DNS、SSH、FTPss -tlnp看服务端口6 表示层应用层数据格式转换、加密解密TLS/SSL、ASCII、JPEGopenssl s_client5 会话层应用层建立/管理/终止会话RPC、NetBIOS—4 传输层传输层端到端可靠传输、端口寻址TCP、UDPss -tlnp、ss -s3 网络层网络层网际层路由寻址、跨网段转发IP、ICMP、路由器ip addr、ip route、ping2 数据链路层网络接口层帧封装、MAC 寻址Ethernet、ARP、交换机ip link、arp -n1 物理层网络接口层比特流传输网线、光纤、集线器ethtool eth0记忆口诀应表会传网数物Application / Presentation / Session / Transport / Network / Data-link / Physical。实际抓包时 TCP/IP 四层更实用链路层以太网帧→ 网络层IP→ 传输层TCP/UDP→ 应用层HTTP 等。2.2 在本机上看见每一层光背表没用我们在真实主机上把每一层摸出来。网络层 —— 看 IP 地址ip addr1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP group default qlen 1000 link/ether fa:16:3e:13:6b:ec brd ff:ff:ff:ff:ff:ff inet 192.168.0.129/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0 inet6 fe80::f816:3eff:fe13:6bec/64 scope link逐项解读fa:16:3e:13:6b:ec是 eth0 的MAC 地址数据链路层fa:16:3e是华为云虚拟网卡常见前缀192.168.0.129/24是内网 IP网络层云主机的公网 IP 通过 NAT 映射本机看不到mtu 1500是以太网最大传输单元抓包时经常看到 mss 14601500 - 20 IP 头 - 20 TCP 头。网络层 —— 看路由表ip routedefault via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.129 metric 100 169.254.169.254 via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.129 metric 100 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.129 metric 100解读default via 192.168.0.1是默认网关所有非本网段的流量都交给它转发169.254.169.254是云厂商的元数据服务地址获取实例信息用第三条是本网段直连路由。传输层 —— 看监听端口ss -tlnpState Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:((sshd,pid5527,fd3)) LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* users:((systemd-resolve,pid543,fd17)) LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:((systemd-resolve,pid543,fd15))解读0.0.0.0:22表示 SSH 服务监听所有网卡的 22 端口127.0.0.53:53是 systemd-resolved 的本地 DNS 缓存传输层 UDP/TCP 53 端口。排查端口不通问题时第一步就是确认服务到底有没有 LISTEN。应用层 —— 看 DNS 配置cat /etc/resolv.confnameserver 127.0.0.53 options edns0 trust-ad search openstacklocal解读127.0.0.53是 systemd-resolved 提供的本地 stub 解析器真正的上游 DNS 要用resolvectl status查看。很多域名解析失败问题最后都查到这个文件。三、ICMP 三剑客ping / traceroute / mtrICMP 是网络层的诊断协议ping 和 traceroute 都是基于它实现的。3.1 ping测连通性与时延ping-c4mirrors.huaweicloud.comPING mirrors.huaweicloud.com (120.46.63.139) 56(84) bytes of data. 64 bytes from ecs-120-46-63-139.compute.hwclouds-dns.com (120.46.63.139): icmp_seq1 ttl61 time1.53 ms 64 bytes from ecs-120-46-63-139.compute.hwclouds-dns.com (120.46.63.139): icmp_seq2 ttl61 time0.707 ms 64 bytes from ecs-120-46-63-139.compute.hwclouds-dns.com (120.46.63.139): icmp_seq3 ttl61 time0.679 ms 64 bytes from ecs-120-46-63-139.compute.hwclouds-dns.com (120.46.63.139): icmp_seq4 ttl61 time0.678 ms --- mirrors.huaweicloud.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3059ms rtt min/avg/max/mdev 0.678/0.898/1.529/0.364 ms逐项解读(120.46.63.139)第一行就完成了 DNS 解析应用层 → 网络层icmp_seqICMP 报文序号序号不连续说明丢包ttl61生存时间每过一个路由器减 1。Linux 默认发出时 TTL6461 说明中间经过了 3 跳time0.68~1.53ms往返时延 RTT同机房镜像源所以非常快最后一行统计丢包率 0%rtt 最小/平均/最大/标准差。3.2 traceroute追踪路由路径原理发送 TTL 从 1 开始递增的探测包利用TTL 超时 ICMP 差错报文依次暴露路径上的每一跳。traceroute-n-m15mirrors.huaweicloud.com# 默认 UDP 探测traceroute to mirrors.huaweicloud.com (124.70.61.162), 15 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * ...全部超时❌ 翻车了默认 UDP 模式在云网络里全被静默丢弃。换 ICMP 模式-I和 TCP 模式-T -p 443再试traceroute-I-n-m12mirrors.huaweicloud.comtraceroute to mirrors.huaweicloud.com (1.92.76.132), 12 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 1.92.76.132 1.244 ms 1.380 ms 1.276 ms✅ 成功4 跳到达目标。前 3 跳是 VPC 内部网关默认不回应 TTL 超时报文云网络常见现象不代表不通。踩坑记录 ①云主机上 traceroute 默认 UDP 模式经常全*优先用-IICMP或-T -p 443TCP模拟真实业务流量还能验证防火墙策略。3.3 mtrping traceroute 合体mtr-n-c5-rmirrors.huaweicloud.comHOST: ecs-7b14-81c9-0003 Loss% Snt Last Avg Best Wrst StDev 1.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 2.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 3.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 4.|-- 123.249.118.101 0.0% 5 1.5 1.4 1.3 1.5 0.1解读mtr 会持续统计每一跳的丢包率Loss%、平均/最优/最差时延和标准差StDev。定位网络抖动比 ping 好用得多——比如第 2 跳 Wrst 很高而 Best 正常说明中间链路抖动。这里目标跳 Loss 0%、StDev 0.1ms链路质量极佳。四、DNS 解析dig 与 nslookup4.1 dig 看完整解析过程digmirrors.huaweicloud.com;; -HEADER- opcode: QUERY, status: NOERROR, id: 27514 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;mirrors.huaweicloud.com. IN A ;; ANSWER SECTION: mirrors.huaweicloud.com. 213 IN A 120.46.63.139 mirrors.huaweicloud.com. 213 IN A 120.46.2.67 mirrors.huaweicloud.com. 213 IN A 123.249.118.101 mirrors.huaweicloud.com. 213 IN A 124.70.61.162 mirrors.huaweicloud.com. 213 IN A 1.92.76.132 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)逐项解读status: NOERROR解析成功常见还有 NXDOMAIN 域名不存在、SERVFAIL 服务器故障QUESTION SECTION查询的是 A 记录IPv4 地址ANSWER SECTION返回5 个 A 记录这是典型的 DNS 轮询负载均衡CDN/镜像站常用213是 TTL 秒数过期前走本地缓存SERVER: 127.0.0.53#53 (UDP)由本地 stub 解析器回答走的 UDP 53 端口DNS 默认 UDP报文过大或区传送时切 TCPQuery time: 0 msec命中缓存。4.2 dig trace递归解析全过程digtrace baidu.com. 312623 IN NS e.root-servers.net. . 312623 IN NS j.root-servers.net. ...13 台根域名服务器 com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. ....com 顶级域服务器解读trace从根.→ 顶级域com.→ 权威服务器逐级查询完整还原 DNS 递归解析链条。这就是教科书里根 → 顶级域 → 权威三级查询的真实样子。小坑本机没有 IPv6 出口时trace会刷UDP setup with 2001:7fd::1#53 failed: network unreachable不影响 IPv4 结果忽略即可。4.3 nslookup快速查询nslookupmirrors.huaweicloud.comServer: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: mirrors.huaweicloud.com Address: 124.70.61.162 ...共 5 条 A 记录Non-authoritative answer表示结果来自缓存而非权威服务器。dig 适合看细节nslookup 适合随手快查。五、tcpdump 抓包实战重点5.1 抓包入门先抓 20 个包看看(ping-c8127.0.0.1/dev/null21)tcpdump-iany-c20-nn真实输出节选tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 17:08:30.197745 eth0 Out IP 192.168.0.129.22 113.90.145.122.57054: Flags [P.], seq ..., length 96 17:08:30.571284 eth0 In IP 139.162.116.160.59415 192.168.0.129.500: isakmp: parent_sa ikev2_init[I] 17:08:31.228588 lo In IP 127.0.0.1 127.0.0.1: ICMP echo request, id 9664, seq 2, length 64 17:08:31.228598 lo In IP 127.0.0.1 127.0.0.1: ICMP echo reply, id 9664, seq 2, length 64 17:08:32.631741 eth0 In IP 138.226.239.66.59554 192.168.0.129.13113: Flags [S], seq 1379007035, win 1024, length 0 17:08:32.631783 eth0 Out IP 192.168.0.129.13113 138.226.239.66.59554: Flags [R.], seq 0, ack 1379007036, win 0, length 0 20 packets captured解读-i any抓所有网卡-c 20抓满 20 个自动停-nn不做域名/端口名反解更快更直观第一行是我自己的 SSH 会话流量22 端口中间两行是 lo 回环上的 pingecho request/reply 成对出现最有意思的是最后两条138.226.239.66这个境外 IP 在扫我 13113 端口内核直接回了 RSTFlags [R.]。公网 IP 上线几分钟就会被扫描器盯上这就是为什么安全组要最小化开放端口。5.2 常用过滤表达式tcpdump 用 BPF 语法过滤常用组合表达式含义host 120.46.2.67只抓与某 IP 相关的包src host x / dst host x按源/目的 IP 过滤port 80/src port 5000按端口过滤tcp/udp/icmp按协议过滤tcp port 443 and host example.com组合条件and/or/nottcp[tcpflags] tcp-syn ! 0只抓 SYN 包新建连接按协议过滤抓 ICMP 示例timeout15tcpdump-ieth0-c6-nnicmpsleep1;ping-c3mirrors.huaweicloud.com;wait17:11:10.187547 IP 192.168.0.129 120.46.2.67: ICMP echo request, id 9931, seq 1, length 64 17:11:10.189250 IP 120.46.2.67 192.168.0.129: ICMP echo reply, id 9931, seq 1, length 64 ... 6 packets captured请求/回复一一对应RTT 约 1.7ms两个时间戳之差。5.3 抓 TCP 三次握手与四次挥手教科书照进现实对本机 Flask 服务127.0.0.1:5000抓包最可控——发起方和接收方都在自己手里timeout15tcpdump-ilo-c14-nntcp port 5000sleep1curl-shttp://127.0.0.1:5000/-o/dev/null;wait真实抓包结果每行都有编号解读# ---- 三次握手 ---- ① 17:11:30.846363 IP 127.0.0.1.46686 127.0.0.1.5000: Flags [S], seq 1978681805, win 65495, options [mss 65495,sackOK,TS...,wscale 7] ② 17:11:30.846376 IP 127.0.0.1.5000 127.0.0.1.46686: Flags [S.], seq 327279246, ack 1978681806, win 65483 ③ 17:11:30.846387 IP 127.0.0.1.46686 127.0.0.1.5000: Flags [.], ack 1, win 512 # ---- 数据传输HTTP 请求/响应---- ④ 17:11:30.846430 IP 127.0.0.1.46686 127.0.0.1.5000: Flags [P.], seq 1:78, ack 1, length 77 # curl 发出 GET 请求, 77 字节 ⑤ 17:11:30.846435 IP 127.0.0.1.5000 127.0.0.1.46686: Flags [.], ack 78, length 0 # 服务端 ACK ⑥ 17:11:30.847123 IP 127.0.0.1.5000 127.0.0.1.46686: Flags [P.], seq 1:174, ack 78, length 173 # 响应头 173 字节 ⑦ 17:11:30.847146 IP 127.0.0.1.5000 127.0.0.1.46686: Flags [P.], seq 174:236, ack 78, length 62 # 响应体 62 字节 # ---- 四次挥手本次合并为三个包---- ⑧ 17:11:30.847178 IP 127.0.0.1.46686 127.0.0.1.5000: Flags [F.], seq 78, ack 236 # 客户端 FIN ⑨ 17:11:30.847220 IP 127.0.0.1.5000 127.0.0.1.46686: Flags [F.], seq 236, ack 79 # 服务端 ACKFIN 合并 ⑩ 17:11:30.847231 IP 127.0.0.1.46686 127.0.0.1.5000: Flags [.], ack 237 # 客户端最后 ACK逐行解读① SYN客户端临时端口 46686发起握手Flags [S]表示 SYN 置位初始序列号 seq1978681805 是随机的防序列号猜测攻击options 里协商了 MSS、SACK、时间戳、窗口扩大因子。② SYNACK服务端回Flags [S.].代表 ACK注意ack 客户端 seq 11978681806表示你发的我收到了下一个字节从 1806 开始。③ ACK客户端确认三次握手完成。整个握手只用了24 微秒0.846363→0.846387本机回环就是这么快。④~⑦ 数据传输Flags [P.]的 P 是 PSH催促接收方尽快把数据交给应用层seq 区间1:78和length 77对应——序列号就是字节流的编号。⑧~⑩ 挥手curl 收到完整响应后主动关闭FIN。教科书里是 4 个包FIN→ACK→FIN→ACK这里服务端把 ACK 和自己的 FIN合并成一个包⑨ 同时带 ack 79 和 FIN 标志所以只看到 3 个——这就是四次挥手可能变成三次的真实案例。5.4 抓 HTTP 明文-A 选项直接看报文内容timeout15tcpdump-ilo-nn-Atcp port 5000 and (((ip[2:2] - ((ip[0]0xf)2)) - ((tcp[12]0xf0)2)) ! 0)sleep1curl-shttp://127.0.0.1:5000/api/users-o/dev/null;wait后面那串 BPF 表达式的含义是只抓 TCP 载荷非空的包过滤掉纯 ACK输出更干净。真实输出关键部分17:12:07.787450 IP 127.0.0.1.37450 127.0.0.1.5000: Flags [P.], length 86 ........GET /api/users HTTP/1.1 Host: 127.0.0.1:5000 User-Agent: curl/8.5.0 Accept: */* 17:12:07.788167 IP 127.0.0.1.5000 127.0.0.1.37450: Flags [P.], length 166 ........HTTP/1.1 200 OK Server: Werkzeug/3.1.8 Python/3.12.3 Date: Sat, 05 Sep 2026 09:12:07 GMT Content-Type: application/json Content-Length: 173 Connection: close 17:12:07.788190 IP 127.0.0.1.5000 127.0.0.1.37450: Flags [P.], length 173 ........{code:0,data:[{id:1,name:张三,role:admin},...],total:3}解读-A把每个包的载荷按 ASCII 打印出来。HTTP 请求行、请求头、状态行、响应头、响应体全部裸奔——请求头里的User-Agent、服务端的Server: Werkzeug/3.1.8版本信息泄露安全测试的关注点一目了然。这就是 HTTP 明文传输的本质链路上任何一环都能看你的报文。5.5 抓 HTTPS只能看到加密的乱码同样方法抓 HTTPS访问华为云镜像站timeout15tcpdump-ieth0-nn-c12tcp port 443 and host mirrors.huaweicloud.comsleep1curl-shttps://mirrors.huaweicloud.com/-o/dev/null;wait17:12:37.784985 IP 192.168.0.129.58706 120.46.2.67.443: Flags [S], seq 4037687797 ... # TCP 握手 17:12:37.786671 IP 120.46.2.67.443 192.168.0.129.58706: Flags [S.], seq 180668233, ack 4037687798 17:12:37.786688 IP 192.168.0.129.58706 120.46.2.67.443: Flags [.], ack 1 17:12:37.787962 IP 192.168.0.129.58706 120.46.2.67.443: Flags [P.], seq 1:518, length 517 # TLS ClientHello 17:12:37.793558 IP 120.46.2.67.443 192.168.0.129.58706: Flags [.], seq 1:1461, length 1460 # TLS ServerHello证书(满包) 17:12:37.793567 IP 120.46.2.67.443 192.168.0.129.58706: Flags [P.], seq 1461:3532, length 2071 17:12:37.804384 IP 192.168.0.129.58706 120.46.2.67.443: Flags [P.], seq 518:611, length 93 # 密钥交换 ...后续全是加密后的应用数据对比结论面试高频对比项HTTP80HTTPS443TCP 握手明文可见明文可见TLS 在 TCP 之上请求行/请求头-A直接可读加密只能看到长度和时序响应内容明文裸奔加密能看到什么一切源/目的 IP、端口、包大小、时间、SNIClientHello 中域名明文HTTPS 抓包时即使加-A也只是一堆二进制乱码。第一个 517 字节的包是 TLS ClientHello里面 SNI 扩展携带目标域名这是明文之后握手完成应用数据全部加密。Fiddler/Charles 能抓HTTPS是因为它们作为中间人代理并让你信任了它的 CA 证书而不是破解了 TLS。5.6 保存 pcap 文件离线分析timeout15tcpdump-ilo-nn-w/root/perf-lab/http.pcaptcp port 5000sleep1curl-shttp://127.0.0.1:5000/-o/dev/nullcurl-shttp://127.0.0.1:5000/api/users-o/dev/nullsleep1;waittcpdump: listening on lo, link-type EN10MB 24 packets captured -rw-r--r-- 1 tcpdump tcpdump 2761 Sep 5 17:13 /root/perf-lab/http.pcap读取分析不用 root、不占网卡可反复过滤# 只过滤 pcap 里的 SYN 包(找新建连接)tcpdump-nn-r/root/perf-lab/http.pcaptcp[tcpflags] tcp-syn ! 017:12:57.780288 IP 127.0.0.1.48458 127.0.0.1.5000: Flags [S], seq 284988523 ... 17:12:57.780300 IP 127.0.0.1.5000 127.0.0.1.48458: Flags [S.], seq 2095744827, ack 284988524 ... 17:12:57.785585 IP 127.0.0.1.48460 127.0.0.1.5000: Flags [S], seq 4004287251 ... 17:12.57.785591 IP 127.0.0.1.5000 127.0.0.1.48460: Flags [S.], seq 317378753, ack 4004287252 ...两次 curl 两条新连接 两对 SYN/SYN-ACK与预期完全吻合。-w保存 -r读取是抓包标准工作流线上抓包存文件 → 下载到本地用 Wireshark 图形化分析。踩坑记录 ②-w写入的 pcap 属主是tcpdump用户Ubuntu 的 tcpdump 有权限降权机制普通用户读取前注意权限。踩坑记录 ③tcpdump 的 “listening on…” 和统计信息输出在stderr脚本里重定向时要加21。六、curl 深度使用6.1 -v看清请求全过程curl-vhttp://127.0.0.1:5000/api/users* Trying 127.0.0.1:5000... ← DNS 解析开始 TCP 连接 * Connected to 127.0.0.1 (127.0.0.1) port 5000 ← TCP 握手完成 GET /api/users HTTP/1.1 ← 发送请求( 开头) Host: 127.0.0.1:5000 User-Agent: curl/8.5.0 Accept: */* HTTP/1.1 200 OK ← 接收响应( 开头) Server: Werkzeug/3.1.8 Python/3.12.3 Content-Type: application/json Content-Length: 173 {code:0,data:[...],total:3} ← 响应体 * Closing connection是发出去的是收回来的*是 curl 自身的日志。定位请求到底发出去没有、服务端回了什么一条-v搞定。6.2 -w性能测试的时间分解利器curl-s-o/dev/null-wDNS解析: %{time_namelookup}s\nTCP连接: %{time_connect}s\nTLS握手: %{time_appconnect}s\n首字节TTFB: %{time_starttransfer}s\n总耗时: %{time_total}s\nHTTP状态: %{http_code}\n下载大小: %{size_download} bytes\nhttps://mirrors.huaweicloud.com/DNS解析: 0.004959s TCP连接: 0.006510s TLS握手: 0.026122s 首字节TTFB: 0.044890s 总耗时: 0.044938s HTTP状态: 200 下载大小: 11208 bytes整理成阶段耗时表各变量是从请求开始的累计时间相减得到阶段耗时阶段计算方式本次耗时说明DNS 解析time_namelookup4.96 ms未命中缓存时的真实解析TCP 建连time_connect − namelookup1.55 ms三次握手同机房极快TLS 握手time_appconnect − connect19.61 msHTTPS 额外开销比 TCP 握手贵 10 倍服务端处理(TTFB)starttransfer − appconnect18.77 ms服务端处理首字节返回内容传输total − starttransfer0.05 ms11 KB 小页面瞬间传完这个表就是性能测试定位问题的标准套路TTFB 高就拆成 DNS/TCP/TLS/服务端四段哪段高查哪段。比如 time_connect 高 → 网络或防火墙appconnect 高 → 证书/TLS 协商starttransfer 高 → 服务端应用逻辑或慢 SQL。6.3 -X / -H / -d构造各类接口请求接口测试最常用的三板斧对本机 Flask 应用实测# POST JSON 请求体 自定义头curl-s-XPOST http://127.0.0.1:5000/api/login\-HContent-Type: application/json\-d{username:admin,password:123456}# → {code:0,msg:login success,token:fake-token-abc123}# 错误密码 -w 输出状态码curl-s-XPOST http://127.0.0.1:5000/api/login\-HContent-Type: application/json\-d{username:admin,password:wrong}-w\nHTTP_CODE%{http_code}\n# → {code:401,msg:invalid username or password}# HTTP_CODE401常用参数速查参数作用示例-X指定方法-X PUT/DELETE-H加请求头-H Authorization: Bearer xxx-d请求体自动 POST-d a1b2/-d file.json-s静默模式脚本里必加-o输出到文件-o /dev/null只看指标-k跳过证书校验自签证书测试用-b/-c读/写 Cookie会话保持测试--resolve指定域名解析 IP测指定后端节点七、常见抓包工具横向对比工具形态工作层级优点局限适用场景tcpdumpLinux 命令行链路层~应用层服务器标配、表达式灵活、可存 pcap无图形界面、HTTPS 内容不可见线上服务器抓包Wireshark图形界面链路层~应用层协议解析最强、可配 SSLKEYLOGFILE 解密 TLS需要 GUI/抓包文件导入深度协议分析FiddlerWindows 代理应用层(HTTP/HTTPS)可改包重放、断点调试只能抓 HTTP 系、需配代理证书Web/移动端接口调试Charles跨平台代理应用层(HTTP/HTTPS)同 FiddlerMac 友好收费移动 App 抓包浏览器 DevTools浏览器内置应用层零成本、直接看前端请求只能抓当前标签页前端联调、H5 测试经验之谈DevTools 看前端 → Fiddler/Charles 调接口 → tcpdumpWireshark 查线上网络问题三层递进覆盖测试工程师 99% 的抓包需求。八、踩坑记录汇总#现象原因解决1traceroute 全程* * *云网络静默 UDP 探测包用-I(ICMP) 或-T -p 443(TCP)2apt install慢/失败默认源在海外换华为云镜像源deb822 格式用 sed 改 URIs3SSH 里后台跑 tcpdump 命令卡住不返回后台进程继承了 SSH 会话的 stdoutsetsid ... log 21 /dev/null 彻底脱离4脚本里抓不到 tcpdump 的统计行统计信息走 stderr加215dig trace 刷 IPv6 unreachable无 IPv6 出口忽略或加-46pcap 文件普通用户读不了tcpdump 降权写入chmod或用 root 读九、总结OSI 七层/TCP 四层不是八股文ip addr网络层、ip route网络层、ss -tlnp传输层、resolv.conf应用层 DNS都能在本机一一对应验证ping 测连通、traceroute 追路径云环境用-I/-T、mtr 看链路质量dig 看 DNS 解析细节tcpdump 是测试工程师的X 光机过滤表达式定方向-A看明文-w/-r存取 pcap三次握手[S][S.][.]、挥手[F.][F.][.]抓到一次终身难忘HTTPS 只能看到 TLS 握手和加密流量Fiddler 的原理是中间人代理而非破解curl -w的时间分解DNS/TCP/TLS/TTFB/Total是性能问题定位的第一刀。参考链接tcpdump 官方文档https://www.tcpdump.org/manpages/tcpdump.1.htmlcurl 时间变量说明https://curl.se/docs/manpage.htmlRFC 793TCP 协议https://www.rfc-editor.org/rfc/rfc793RFC 792ICMP 协议https://www.rfc-editor.org/rfc/rfc792