简介这份资源是一份计算机网络实验报告文档面向正在学习计算机网络课程、需要完成抓包分析实验的高校学生与自学者帮助解决协议数据包捕捉与格式验证的实操记录问题。压缩包内共1个docx文件约7.17MB内容为完整的实验报告正文涵盖实验目的、环境、内容、过程与总结等模块。报告以MacOSARM架构以太网环境为背景使用WiresharkEthereal完成抓包逐项验证数据帧、IP数据报与TCP数据段的报文格式并分析ARP报文、ping与tracert中的ICMP报文参数、TCP三次握手过程以及FTP工作流程的协议包。WWW应用部分还整理了从应用层到网络层的协议使用、百度主页应答报文数量与RTT计算、持久连接、无效域名报错、多图像页面TCP连接次数等思考题。目前已有352人学习适合作为实验报告撰写模板与抓包分析思路的参考。1. 从一份实验报告说起Mac 上抓包到底能验证什么很多人第一次在 Mac 上做网络协议分析都会卡在同一个地方Ethereal 早就停止维护了官网下载链接指向的是 Wireshark而 ARM 架构的 macOS 又让一部分老教程里的安装命令直接报错。这份《计算机网络实验报告——使用网络协议分析器捕捉和分析协议数据包》记录的就是这样一次真实实验在 MacOS ARM 环境下用 Wireshark 替代 Ethereal依次完成数据帧、IP 数据报、TCP 数据段、ARP、ICMP、TCP 三次握手以及 WWW 应用协议报文的捕捉与分析。它解决的不是“抓包软件怎么装”这种单点问题而是把从链路层到应用层的协议格式验证串成了一条可复现的路径。适合正在做计算机网络实验的学生、需要给新人讲协议分层的工程师以及想用抓包结果反推 HTTP/1.0 与 HTTP/1.1 连接差异的从业者。下面按实验顺序拆开讲每一步都落到具体过滤器和字段上。2. 环境搭建与首包验证ARM Mac 上的 Wireshark 选型与过滤2.1 为什么是 Wireshark 而不是 EtherealEthereal 在 2006 年因商标问题更名为 Wireshark原项目早已不再更新。实验报告里写“安装 ethereal 软件”实际落地时选择 Wireshark 是正确做法。在 Apple Silicon 机器上Wireshark 官方提供 macOS Arm64 的 dmg 包安装后需要额外处理权限问题抓包依赖 BPF 设备普通用户默认没有读取权限。常见做法是把当前用户加入access_bpf组或者每次用sudo启动但后者会导致配置文件归属 root后续改过滤器容易出玄学问题。安装完成后第一件事不是急着抓包而是确认网卡列表和捕获接口。Mac 上通常有en0Wi-Fi和lo0回环做协议分析实验建议优先用有线以太网因为 Wi-Fi 帧头包含 802.11 管理帧会干扰对以太网帧格式的观察。如果只有 Wi-Fi可以在 Wireshark 的捕获选项里勾选“monitor mode”但这不是本实验必需。2.2 抓第一个包并验证三层报文格式实验要求验证数据帧、IP 数据报、TCP 数据段的报文格式。最直接的办法是打开浏览器访问一个 HTTP 页面同时用 Wireshark 抓包。为了减少噪声先设置捕获过滤器只抓 TCP 80 端口# 捕获过滤器在 Wireshark 捕获选项的 BPF 栏填写 tcp port 80抓到一个完整的 HTTP GET 请求后在 Wireshark 的协议树里逐层展开。以太网帧头部看 Destination 和 Source 的 MAC 地址Type 字段为 0x0800 表示上层是 IPv4。IP 数据报头部重点看 Version4、Header Length20 字节即无选项、Total Length报告里记录为 1102、Destination Address203.107.62.254。TCP 数据段则看 Source Port、Destination Port、Sequence Number、Acknowledgment Number 以及 Flags。这里有个容易翻车的点Wireshark 默认可能开启“Allow subdissector to reassemble TCP streams”导致你看到的 TCP 段长度和 IP 总长度对不上。做格式验证时建议在 TCP 协议首选项里关掉 reassembly让每个段独立显示。报告里“结果符合”的结论前提就是关闭了重组否则 Total Length 会被合并成更大的值。提示如果抓不到 80 端口的包先确认目标网站是否已经全站 HTTPS。现代浏览器访问百度会走 443需要把过滤器改成tcp port 443但 TLS 加密后看不到 HTTP 内容只能验证 TCP 和 IP 层。3. ARP、ICMP 与 tracert把控制报文拆到字段级3.1 清空 ARP 缓存再抓请求报文ARP 是实验里少数需要“制造条件”才能稳定抓到的协议。Mac 的 ARP 缓存默认保留一段时间如果目标 IP 刚被访问过就不会再发 ARP 请求。报告里用arp -d -a清空缓存这个命令在 macOS 上需要 root 权限# 清空 ARP 缓存需要管理员权限 sudo arp -d -a # 确认缓存已清空 arp -a清空后立刻用浏览器访问www.gzhu.edu.cnWireshark 里用arp过滤器就能看到广播请求和单播应答。ARP 请求报文的关键字段Hardware type 为 1以太网Protocol type 为 0x0800IPv4Hardware size 为 6Protocol size 为 4Opcode 为 1 表示请求、2 表示应答。报告里“硬件地址长度 6 字节、协议地址长度 4 字节”对应的就是这两个 size 字段。一个常见误解是 ARP 只出现在同一网段。实际上只要目标 IP 和本机不在同一子网ARP 请求的是默认网关的 MAC而不是目标主机的 MAC。抓包时如果看到请求的 Target IP 是网关地址不要觉得抓错了。3.2 ping 与 tracert 的 ICMP 参数对照ping 命令在 Mac 上默认发 ICMP Echo Request收到 Echo Reply。Wireshark 过滤器用icmp即可。展开 ICMP 头部Type 8 是请求、Type 0 是应答Code 均为 0。报告里提到的 Sequence number 用来匹配请求和应答Checksum 是 ICMP 校验和Response time 是 Wireshark 根据请求和应答时间戳算出的往返时延不是 ICMP 报文里的字段。tracert 在 macOS 上对应traceroute默认走 UDP 高端口而不是 ICMP。如果实验要求捕捉 ICMP 报文需要用traceroute -I强制走 ICMP# macOS 下强制使用 ICMP 进行路由跟踪 traceroute -I www.baidu.com # 对应的 Wireshark 过滤器 icmptraceroute 的原理是逐跳增加 TTL路由器在 TTL 减到 0 时回送 ICMP Time ExceededType 11。报告里“每个报文发三次”对应 traceroute 默认每跳探测 3 次。关于“跟踪的路由器 IP 是哪个接口的”抓包时看到的源 IP 就是该路由器面向本机方向的接口地址不一定是路由器的管理地址。这一点在多层 NAT 环境下尤其要注意看到的可能是运营商侧接口。注意部分网络会屏蔽 ICMP导致 traceroute 中间跳显示为星号。这不是抓包工具的问题换用 TCP SYN 方式traceroute -T可能绕过但那就不是 ICMP 实验了。4. TCP 三次握手与 WWW 协议分析从 curl 到连接复用4.1 用 curl 触发三次握手并定位 SYN 包实验里用curl获取百度源码来触发三次握手比浏览器更干净因为 curl 不会自动加载图片、脚本等额外资源。命令如下# 只请求头部减少后续数据传输干扰 curl -I https://www.baidu.com # Wireshark 过滤器只看与百度建立的 TCP 流 tcp.port 443 ip.addr 110.242.68.66实际抓包时第一次握手是客户端发 SYNSeq0相对序列号Flags 里 SYN1。第二次握手是服务端回 SYNACKAck1同时带自己的 Seq0。第三次握手是客户端回 ACKAck1Seq1。报告里写的“ACKSYNseq11”描述的就是第三次握手的确认号等于对方初始序列号加一。Wireshark 默认显示相对序列号如果想看真实随机序列号在 TCP 首选项里关掉“Relative sequence numbers”。4.2 WWW 应用协议问题的抓包验证实验最后列了一组 WWW 思考题其中几个可以直接用抓包结果回答。访问主页时从应用层到网络层用到的协议应用层 DNS 解析域名然后 HTTP 或 HTTPS 传输网页传输层 TCP网络层 IP。DNS 本身通常走 UDP 53 端口所以一次完整访问会同时出现 UDP 和 TCP 流量。关于“客户端接收到几个应答报文”以 HTTP/1.1 访问百度为例DNS 应答通常 1 个TCP 握手 2 个SYNACK 和后续 ACK 算入握手HTTP 响应 1 个如果页面有重定向还会多几个。报告里 RTT0.14ms 是局域网级别的时延实际公网访问百度 RTT 通常在 10ms 以上。从请求到完整页面出现的时间粗略估算为 DNS 解析时间 TCP 握手 1 个 RTT HTTP 请求响应 1 个 RTT 页面渲染时间。两个同服务器不同路径的页面能否在同一持久连接上发送取决于 HTTP 版本。HTTP/1.1 默认开启持久连接只要服务器不主动关闭可以在同一 TCP 连接上依次请求。HTTP/1.0 默认每次请求新建连接除非显式发送Connection: keep-alive。抓包时看 TCP 流是否复用同一个源端口就能验证。超链接指向无效计算机名时浏览器报告的是 DNS 解析失败通常显示“找不到服务器”或“DNS_PROBE_FINISHED_NXDOMAIN”而不是 404。404 是服务器收到请求但资源不存在两者发生在不同阶段。关于 gif 图像的 TCP 连接数报告里的结论是HTTP/1.0 下文本 1 个加图像 3 个共 4 次 TCP 连接UDP 过程 0 次HTTP/1.1 下全部复用 1 次 TCP 连接。这里“本地.gif”如果指本地文件系统里的图片根本不会产生网络连接只有远地 gif 才需要建立连接。报告里把本地 gif 也算进连接数严格说是把“页面引用的图像”都当成了网络资源实际抓包时本地图片不会出现在 Wireshark 里。# 统计同一 TCP 流上的 HTTP 请求数验证持久连接 tshark -r capture.pcap -Y http.request -T fields -e tcp.stream -e http.request.uri这条命令用 tshark 读取抓包文件过滤所有 HTTP 请求输出 TCP 流编号和请求 URI。如果多个请求的 tcp.stream 相同说明复用了同一连接。参数-Y是显示过滤器-T fields指定输出字段-e指定字段名。这是验证 HTTP/1.1 持久连接最直接的方法比在 Wireshark 界面里手动数包可靠。提示HTTPS 流量看不到 HTTP 请求行但可以通过tcp.stream和 TLS 握手后的 Application Data 包数量间接判断连接复用。如果实验只要求 HTTP优先访问http://开头的教学站点。5. 避坑与排查抓包实验里最容易翻车的五件事5.1 抓不到 ARP 请求现象清空缓存后访问目标站点Wireshark 里只有 TCP 包没有 ARP。原因目标 IP 在同一子网且缓存未真正清空或者系统用了 IPv6 邻居发现替代 ARP。解决确认arp -a输出为空且目标站点解析到 IPv4 地址如果只有 IPv6需要抓 ICMPv6 的 Neighbor Solicitation。5.2 TCP 三次握手只看到两次现象过滤器里只有 SYN 和 SYNACK没有第三次 ACK。原因第三次 ACK 可能被 Wireshark 归入后续数据包或者抓包在握手完成前停止。解决用tcp.flags.syn1 or tcp.flags.ack1放宽过滤并确保抓包持续到 curl 命令结束。5.3 IP 总长度和 TCP 段长度对不上现象IP Total Length 显示 1102但 TCP 协议树里 Segment Length 只有 1050。原因TCP 首部 20 字节加 IP 首部 20 字节剩余才是数据如果开启了 TCP 重组显示会更混乱。解决关掉 TCP 协议首选项里的 reassembly用ip.len和tcp.len字段分别核对。5.4 tracert 中间跳全是星号现象traceroute -I输出大量* * *。原因中间路由器配置了不回应 ICMP Time Exceeded或者防火墙过滤。解决换traceroute -T -p 80用 TCP SYN 探测但这样抓不到 ICMP 报文实验报告里需要说明差异。5.5 HTTP/1.1 持久连接验证失败现象tshark 统计发现每个 HTTP 请求的 tcp.stream 都不同。原因服务器返回了Connection: close或者客户端主动关闭连接。解决检查 HTTP 响应头里的 Connection 字段如果服务器不支持持久连接换一个支持 HTTP/1.1 keep-alive 的教学站点重试。6. 进阶技巧用 tshark 批量提取字段做协议统计实验报告停留在“抓包看字段”的层面但真正做协议分析时手工数包效率太低。我一般会用 tshark 把关键字段导出成表格再用命令行工具做统计。比如要验证一次页面访问中 TCP 连接数和 UDP 过程数可以这样# 统计抓包文件中的 TCP 流数量和 UDP 流数量 tshark -r www.pcap -T fields -e tcp.stream | sort -u | wc -l tshark -r www.pcap -T fields -e udp.stream | sort -u | wc -l # 提取所有 DNS 查询和响应验证域名解析过程 tshark -r www.pcap -Y dns -T fields -e dns.qry.name -e dns.a第一条命令用-T fields -e tcp.stream输出所有 TCP 流编号sort -u去重后wc -l计数得到独立 TCP 连接数。第二条同理统计 UDP 流。第三条过滤 DNS 报文输出查询域名和解析出的 A 记录。参数-Y是显示过滤器dns.qry.name是查询名dns.a是应答中的 IPv4 地址。这套方法可以直接回答实验报告里的思考题把www.pcap换成实际抓包文件跑一遍就能得到 TCP 连接数和 UDP 过程数不用在 Wireshark 界面里一个个数。对于 HTTP/1.0 和 HTTP/1.1 的对比分别抓两次包用同样的命令统计差异一目了然。还有一个容易被忽略的字段是tcp.time_delta它表示同一 TCP 流中相邻两个包的时间差。用 tshark 导出这个字段可以画出粗略的往返时延分布# 导出 TCP 流中每个包相对前一个包的时间差 tshark -r www.pcap -Y tcp -T fields -e tcp.stream -e tcp.time_delta如果某个流的 time_delta 在握手阶段是几十毫秒在数据传输阶段降到几毫秒说明连接建立后网络路径稳定。如果 time_delta 忽大忽小可能是无线链路重传或拥塞。这个技巧在排查“为什么 ping 正常但网页打开慢”时特别有用因为 ping 只测 ICMP 往返不反映 TCP 握手和 TLS 协商的耗时。从那以后我每次做协议分析实验都会先用 tshark 把字段导出来跑一遍统计再回到 Wireshark 界面里核对关键包。这样既不会漏掉连接复用这类需要聚合观察的现象也能在报告里给出可复现的命令而不是“目测结果”。希望帮到你。本文还有配套的精品资源点击获取 Mac ARM 环境下 Wireshark 抓包实验：从协议分层到 TCP 连接复用分析
简介这份资源是一份计算机网络实验报告文档面向正在学习计算机网络课程、需要完成抓包分析实验的高校学生与自学者帮助解决协议数据包捕捉与格式验证的实操记录问题。压缩包内共1个docx文件约7.17MB内容为完整的实验报告正文涵盖实验目的、环境、内容、过程与总结等模块。报告以MacOSARM架构以太网环境为背景使用WiresharkEthereal完成抓包逐项验证数据帧、IP数据报与TCP数据段的报文格式并分析ARP报文、ping与tracert中的ICMP报文参数、TCP三次握手过程以及FTP工作流程的协议包。WWW应用部分还整理了从应用层到网络层的协议使用、百度主页应答报文数量与RTT计算、持久连接、无效域名报错、多图像页面TCP连接次数等思考题。目前已有352人学习适合作为实验报告撰写模板与抓包分析思路的参考。1. 从一份实验报告说起Mac 上抓包到底能验证什么很多人第一次在 Mac 上做网络协议分析都会卡在同一个地方Ethereal 早就停止维护了官网下载链接指向的是 Wireshark而 ARM 架构的 macOS 又让一部分老教程里的安装命令直接报错。这份《计算机网络实验报告——使用网络协议分析器捕捉和分析协议数据包》记录的就是这样一次真实实验在 MacOS ARM 环境下用 Wireshark 替代 Ethereal依次完成数据帧、IP 数据报、TCP 数据段、ARP、ICMP、TCP 三次握手以及 WWW 应用协议报文的捕捉与分析。它解决的不是“抓包软件怎么装”这种单点问题而是把从链路层到应用层的协议格式验证串成了一条可复现的路径。适合正在做计算机网络实验的学生、需要给新人讲协议分层的工程师以及想用抓包结果反推 HTTP/1.0 与 HTTP/1.1 连接差异的从业者。下面按实验顺序拆开讲每一步都落到具体过滤器和字段上。2. 环境搭建与首包验证ARM Mac 上的 Wireshark 选型与过滤2.1 为什么是 Wireshark 而不是 EtherealEthereal 在 2006 年因商标问题更名为 Wireshark原项目早已不再更新。实验报告里写“安装 ethereal 软件”实际落地时选择 Wireshark 是正确做法。在 Apple Silicon 机器上Wireshark 官方提供 macOS Arm64 的 dmg 包安装后需要额外处理权限问题抓包依赖 BPF 设备普通用户默认没有读取权限。常见做法是把当前用户加入access_bpf组或者每次用sudo启动但后者会导致配置文件归属 root后续改过滤器容易出玄学问题。安装完成后第一件事不是急着抓包而是确认网卡列表和捕获接口。Mac 上通常有en0Wi-Fi和lo0回环做协议分析实验建议优先用有线以太网因为 Wi-Fi 帧头包含 802.11 管理帧会干扰对以太网帧格式的观察。如果只有 Wi-Fi可以在 Wireshark 的捕获选项里勾选“monitor mode”但这不是本实验必需。2.2 抓第一个包并验证三层报文格式实验要求验证数据帧、IP 数据报、TCP 数据段的报文格式。最直接的办法是打开浏览器访问一个 HTTP 页面同时用 Wireshark 抓包。为了减少噪声先设置捕获过滤器只抓 TCP 80 端口# 捕获过滤器在 Wireshark 捕获选项的 BPF 栏填写 tcp port 80抓到一个完整的 HTTP GET 请求后在 Wireshark 的协议树里逐层展开。以太网帧头部看 Destination 和 Source 的 MAC 地址Type 字段为 0x0800 表示上层是 IPv4。IP 数据报头部重点看 Version4、Header Length20 字节即无选项、Total Length报告里记录为 1102、Destination Address203.107.62.254。TCP 数据段则看 Source Port、Destination Port、Sequence Number、Acknowledgment Number 以及 Flags。这里有个容易翻车的点Wireshark 默认可能开启“Allow subdissector to reassemble TCP streams”导致你看到的 TCP 段长度和 IP 总长度对不上。做格式验证时建议在 TCP 协议首选项里关掉 reassembly让每个段独立显示。报告里“结果符合”的结论前提就是关闭了重组否则 Total Length 会被合并成更大的值。提示如果抓不到 80 端口的包先确认目标网站是否已经全站 HTTPS。现代浏览器访问百度会走 443需要把过滤器改成tcp port 443但 TLS 加密后看不到 HTTP 内容只能验证 TCP 和 IP 层。3. ARP、ICMP 与 tracert把控制报文拆到字段级3.1 清空 ARP 缓存再抓请求报文ARP 是实验里少数需要“制造条件”才能稳定抓到的协议。Mac 的 ARP 缓存默认保留一段时间如果目标 IP 刚被访问过就不会再发 ARP 请求。报告里用arp -d -a清空缓存这个命令在 macOS 上需要 root 权限# 清空 ARP 缓存需要管理员权限 sudo arp -d -a # 确认缓存已清空 arp -a清空后立刻用浏览器访问www.gzhu.edu.cnWireshark 里用arp过滤器就能看到广播请求和单播应答。ARP 请求报文的关键字段Hardware type 为 1以太网Protocol type 为 0x0800IPv4Hardware size 为 6Protocol size 为 4Opcode 为 1 表示请求、2 表示应答。报告里“硬件地址长度 6 字节、协议地址长度 4 字节”对应的就是这两个 size 字段。一个常见误解是 ARP 只出现在同一网段。实际上只要目标 IP 和本机不在同一子网ARP 请求的是默认网关的 MAC而不是目标主机的 MAC。抓包时如果看到请求的 Target IP 是网关地址不要觉得抓错了。3.2 ping 与 tracert 的 ICMP 参数对照ping 命令在 Mac 上默认发 ICMP Echo Request收到 Echo Reply。Wireshark 过滤器用icmp即可。展开 ICMP 头部Type 8 是请求、Type 0 是应答Code 均为 0。报告里提到的 Sequence number 用来匹配请求和应答Checksum 是 ICMP 校验和Response time 是 Wireshark 根据请求和应答时间戳算出的往返时延不是 ICMP 报文里的字段。tracert 在 macOS 上对应traceroute默认走 UDP 高端口而不是 ICMP。如果实验要求捕捉 ICMP 报文需要用traceroute -I强制走 ICMP# macOS 下强制使用 ICMP 进行路由跟踪 traceroute -I www.baidu.com # 对应的 Wireshark 过滤器 icmptraceroute 的原理是逐跳增加 TTL路由器在 TTL 减到 0 时回送 ICMP Time ExceededType 11。报告里“每个报文发三次”对应 traceroute 默认每跳探测 3 次。关于“跟踪的路由器 IP 是哪个接口的”抓包时看到的源 IP 就是该路由器面向本机方向的接口地址不一定是路由器的管理地址。这一点在多层 NAT 环境下尤其要注意看到的可能是运营商侧接口。注意部分网络会屏蔽 ICMP导致 traceroute 中间跳显示为星号。这不是抓包工具的问题换用 TCP SYN 方式traceroute -T可能绕过但那就不是 ICMP 实验了。4. TCP 三次握手与 WWW 协议分析从 curl 到连接复用4.1 用 curl 触发三次握手并定位 SYN 包实验里用curl获取百度源码来触发三次握手比浏览器更干净因为 curl 不会自动加载图片、脚本等额外资源。命令如下# 只请求头部减少后续数据传输干扰 curl -I https://www.baidu.com # Wireshark 过滤器只看与百度建立的 TCP 流 tcp.port 443 ip.addr 110.242.68.66实际抓包时第一次握手是客户端发 SYNSeq0相对序列号Flags 里 SYN1。第二次握手是服务端回 SYNACKAck1同时带自己的 Seq0。第三次握手是客户端回 ACKAck1Seq1。报告里写的“ACKSYNseq11”描述的就是第三次握手的确认号等于对方初始序列号加一。Wireshark 默认显示相对序列号如果想看真实随机序列号在 TCP 首选项里关掉“Relative sequence numbers”。4.2 WWW 应用协议问题的抓包验证实验最后列了一组 WWW 思考题其中几个可以直接用抓包结果回答。访问主页时从应用层到网络层用到的协议应用层 DNS 解析域名然后 HTTP 或 HTTPS 传输网页传输层 TCP网络层 IP。DNS 本身通常走 UDP 53 端口所以一次完整访问会同时出现 UDP 和 TCP 流量。关于“客户端接收到几个应答报文”以 HTTP/1.1 访问百度为例DNS 应答通常 1 个TCP 握手 2 个SYNACK 和后续 ACK 算入握手HTTP 响应 1 个如果页面有重定向还会多几个。报告里 RTT0.14ms 是局域网级别的时延实际公网访问百度 RTT 通常在 10ms 以上。从请求到完整页面出现的时间粗略估算为 DNS 解析时间 TCP 握手 1 个 RTT HTTP 请求响应 1 个 RTT 页面渲染时间。两个同服务器不同路径的页面能否在同一持久连接上发送取决于 HTTP 版本。HTTP/1.1 默认开启持久连接只要服务器不主动关闭可以在同一 TCP 连接上依次请求。HTTP/1.0 默认每次请求新建连接除非显式发送Connection: keep-alive。抓包时看 TCP 流是否复用同一个源端口就能验证。超链接指向无效计算机名时浏览器报告的是 DNS 解析失败通常显示“找不到服务器”或“DNS_PROBE_FINISHED_NXDOMAIN”而不是 404。404 是服务器收到请求但资源不存在两者发生在不同阶段。关于 gif 图像的 TCP 连接数报告里的结论是HTTP/1.0 下文本 1 个加图像 3 个共 4 次 TCP 连接UDP 过程 0 次HTTP/1.1 下全部复用 1 次 TCP 连接。这里“本地.gif”如果指本地文件系统里的图片根本不会产生网络连接只有远地 gif 才需要建立连接。报告里把本地 gif 也算进连接数严格说是把“页面引用的图像”都当成了网络资源实际抓包时本地图片不会出现在 Wireshark 里。# 统计同一 TCP 流上的 HTTP 请求数验证持久连接 tshark -r capture.pcap -Y http.request -T fields -e tcp.stream -e http.request.uri这条命令用 tshark 读取抓包文件过滤所有 HTTP 请求输出 TCP 流编号和请求 URI。如果多个请求的 tcp.stream 相同说明复用了同一连接。参数-Y是显示过滤器-T fields指定输出字段-e指定字段名。这是验证 HTTP/1.1 持久连接最直接的方法比在 Wireshark 界面里手动数包可靠。提示HTTPS 流量看不到 HTTP 请求行但可以通过tcp.stream和 TLS 握手后的 Application Data 包数量间接判断连接复用。如果实验只要求 HTTP优先访问http://开头的教学站点。5. 避坑与排查抓包实验里最容易翻车的五件事5.1 抓不到 ARP 请求现象清空缓存后访问目标站点Wireshark 里只有 TCP 包没有 ARP。原因目标 IP 在同一子网且缓存未真正清空或者系统用了 IPv6 邻居发现替代 ARP。解决确认arp -a输出为空且目标站点解析到 IPv4 地址如果只有 IPv6需要抓 ICMPv6 的 Neighbor Solicitation。5.2 TCP 三次握手只看到两次现象过滤器里只有 SYN 和 SYNACK没有第三次 ACK。原因第三次 ACK 可能被 Wireshark 归入后续数据包或者抓包在握手完成前停止。解决用tcp.flags.syn1 or tcp.flags.ack1放宽过滤并确保抓包持续到 curl 命令结束。5.3 IP 总长度和 TCP 段长度对不上现象IP Total Length 显示 1102但 TCP 协议树里 Segment Length 只有 1050。原因TCP 首部 20 字节加 IP 首部 20 字节剩余才是数据如果开启了 TCP 重组显示会更混乱。解决关掉 TCP 协议首选项里的 reassembly用ip.len和tcp.len字段分别核对。5.4 tracert 中间跳全是星号现象traceroute -I输出大量* * *。原因中间路由器配置了不回应 ICMP Time Exceeded或者防火墙过滤。解决换traceroute -T -p 80用 TCP SYN 探测但这样抓不到 ICMP 报文实验报告里需要说明差异。5.5 HTTP/1.1 持久连接验证失败现象tshark 统计发现每个 HTTP 请求的 tcp.stream 都不同。原因服务器返回了Connection: close或者客户端主动关闭连接。解决检查 HTTP 响应头里的 Connection 字段如果服务器不支持持久连接换一个支持 HTTP/1.1 keep-alive 的教学站点重试。6. 进阶技巧用 tshark 批量提取字段做协议统计实验报告停留在“抓包看字段”的层面但真正做协议分析时手工数包效率太低。我一般会用 tshark 把关键字段导出成表格再用命令行工具做统计。比如要验证一次页面访问中 TCP 连接数和 UDP 过程数可以这样# 统计抓包文件中的 TCP 流数量和 UDP 流数量 tshark -r www.pcap -T fields -e tcp.stream | sort -u | wc -l tshark -r www.pcap -T fields -e udp.stream | sort -u | wc -l # 提取所有 DNS 查询和响应验证域名解析过程 tshark -r www.pcap -Y dns -T fields -e dns.qry.name -e dns.a第一条命令用-T fields -e tcp.stream输出所有 TCP 流编号sort -u去重后wc -l计数得到独立 TCP 连接数。第二条同理统计 UDP 流。第三条过滤 DNS 报文输出查询域名和解析出的 A 记录。参数-Y是显示过滤器dns.qry.name是查询名dns.a是应答中的 IPv4 地址。这套方法可以直接回答实验报告里的思考题把www.pcap换成实际抓包文件跑一遍就能得到 TCP 连接数和 UDP 过程数不用在 Wireshark 界面里一个个数。对于 HTTP/1.0 和 HTTP/1.1 的对比分别抓两次包用同样的命令统计差异一目了然。还有一个容易被忽略的字段是tcp.time_delta它表示同一 TCP 流中相邻两个包的时间差。用 tshark 导出这个字段可以画出粗略的往返时延分布# 导出 TCP 流中每个包相对前一个包的时间差 tshark -r www.pcap -Y tcp -T fields -e tcp.stream -e tcp.time_delta如果某个流的 time_delta 在握手阶段是几十毫秒在数据传输阶段降到几毫秒说明连接建立后网络路径稳定。如果 time_delta 忽大忽小可能是无线链路重传或拥塞。这个技巧在排查“为什么 ping 正常但网页打开慢”时特别有用因为 ping 只测 ICMP 往返不反映 TCP 握手和 TLS 协商的耗时。从那以后我每次做协议分析实验都会先用 tshark 把字段导出来跑一遍统计再回到 Wireshark 界面里核对关键包。这样既不会漏掉连接复用这类需要聚合观察的现象也能在报告里给出可复现的命令而不是“目测结果”。希望帮到你。本文还有配套的精品资源点击获取