企业官网建设流程全解析

简介：计算机网络实验报告资源包，围绕使用网络协议分析器捕捉与分析协议数据包展开，适合高校计算机、网络工程专业学生完成课程实验时参考。报告基于 macOS 环境、以太网条件，以 Wireshark 为主要分析工具，完整验证了数据帧、IP 数据报、TCP 报文段三种报文格式，并对 ARP、ICMP、TCP 三次握手、FTP 工作过程及 WWW 应用协议进行抓包分析，思路清晰，结论明确，可作为实验预习、报告撰写和考前复习的辅助材料。资源为 1 个 docx 文档，约 7.17MB，内容涵盖实验目的、环境、过程记录、结果分析和总结等模块，重点解答了访问网页时的协议层次、百度主页应答报文个数、同一持久连接、无效链接提示以及本地/远地图像对应的 TCP 连接数等思考题，便于直接对照或复用框架。已有 352 人学习/下载，适合需要系统梳理网络协议分析流程、快速产出规范实验报告的同学。

1. 网络协议分析器实验，抓的不是包而是网络行为

从ping -c 3 baidu.com这一类命令开始。你看到的是平均RTT三个数字，但网关MAC怎么拿到、DNS有没有参与、ICMP回显请求的identifier具体是多少，全被ping的输出吞掉了。开启网络协议分析器捕捉协议数据包之后，这些底层动作一条一条出现在界面里，像按下慢放键。很多人把计算机网络基础实验里的这个报告做成截图集锦，哪一步先哪一步后都说不清。实际上，这个实验的正确价值在于让TCP/IP封装关系、端口语义、报文往返顺序在同一份证据里互相印证。以下几章就按计算机网络基础课最常见的要求，把抓包前的原理准备、接口选择、过滤器参数、字段解释和结论验证讲清楚。

2. 协议数据包的分层封装与网络协议分析器的捕获原理

2.1 从应用层到链路层：协议数据包的嵌套封装

读分析结果时，先纠正一个常见的概念混淆。网络协议分析器保存的每一条记录，在以太网环境里本质上是“帧”，而不是“报文”。帧的最外层是目的MAC和源MAC，往里剥才是IP头，再往内是TCP或UDP头，最里面是应用层的数据。一次HTTP请求在被发出之前，会沿着这个链路反向封装：浏览器把请求行和Header交给HTTP库，HTTP库再把数据交给TCP，TCP在数据前追加端口号和序列号，随后IP层添上源和目标IP地址，网卡驱动最后把整个结构包进以太网帧，才打上线路。

这串步骤不是分析器给出来的，而是TCP/IP模型的实际落点。分析器的作用是“解封装”：它拿到原始帧字节后，按以太网类型字段判断后面是IPv4还是ARP，再按IP头部里的协议号判断上层是TCP还是UDP，继续解到应用层。所以你在界面里看到每一层字段井井有条，是解码器工作的结果，不是帧里天然就是一个树状结构。

封装顺序对实验的直接影响是：过滤器条件能写得多“深”，取决于帧里有哪一层。比如tcp.port == 443能作用在IP包上，是因为帧的以太网类型是0x0800，IP头里的协议号为6。如果抓到一个ARP帧，它没有IP层，所有带ip开头的显示过滤器都会自动落空。实验报告里如果出现“ARP报文带TCP端口”的说法，多半就是没弄明白封装边界。

2.2 网络协议分析器的工作位置与抓包机制

常见做法是把抓包工具说成“监听网卡”。更准确地说，帧到达网卡后，驱动在做正常上送协议栈的同时，把一份拷贝交给抓包接口，libpcap（Windows下是WinPcap或Npcap）负责给这个帧打上时间戳并送入缓冲区。分析器界面上看到的那一行数据，就是从缓冲区读出来的。这段路径意味着抓包不会影响帧的原始内容，也不改变网络流量的接收方。

混杂模式是实验里另一个容易忽略的点。默认情况下，网卡只把目的MAC是本机的单播帧和广播帧上送给系统，混杂模式会通知网卡把接收到的所有帧都收下来。在普通交换机上，端口之间做了MAC地址隔离，非本机的单播帧不会出现在你的网卡上，所以打开混杂模式也不等于能抓到整个局域网。真正想让网络协议分析器捕捉协议数据包时能“多点覆盖”，要依赖交换机端口镜像，或者干脆在自己要分析的终端上抓本机流量。本机发往外部、本机回环、外部返回本机的流，在工作站本地网卡上都能看到。

抓包是被动观测，不会改写帧内容。实验时最好统一时序：先启动抓包，再执行产生流量的操作，最后停掉抓包。倒过来会流失实验里最想比较的“发起阶段”数据。有的场景还要注意缓冲区溢出：流量大而分析器处理不过来时，libpcap会把新到的帧直接丢掉，界面上表现为包号不连续。

2.3 实验环境准备：安装、权限与接口选择

我一般会用Wireshark的纯命令行版本tshark做抓包实验，理由有三：命令能原样写进实验报告，可复现；过滤条件不容易打错；在远程服务器上也能直接跑。Windows下先装Wireshark，会附带tshark和dumpcap；Linux在Debian系里用下面命令安装：

sudo apt update && sudo apt install -y tshark tshark --version sudo tshark -D

第一行安装tshark，过程中会询问是否允许非root用户抓包，建议选是，安装程序会把dumpcap的抓包能力交给wireshark用户组，后面不必频繁使用sudo。如果当时选了否，后续命令统一用sudo执行也不影响。第二行输出版本和libpcap版本，用来排查驱动与内核不兼容这类环境问题。第三行列出当前机器能抓的接口。

第三行的输出格式在Linux下通常是“数字.接口名”的形式，常见接口如下表：

“any”接口比较特殊，它把多个网卡的数据流合并到一起，代价是帧开头会增加一个伪头部记录来源接口。做实验分析时，能用具体接口就用具体接口，否则后面按MAC地址过滤时会夹杂多台接口的干扰。

3. 用网络协议分析器捕捉协议数据包：接口、过滤器与命令行抓包

3.1 最小抓包命令：选定接口和写入文件

实验前先想清楚流量会从哪个接口过。本机访问本机，Web服务在127.0.0.1，接口就选lo；工作时访问公网HTTP，接口选以太网卡。网络协议分析器捕捉协议数据包最常用的命令行写法是：

sudo tshark -i any -f "tcp port 80" -w /tmp/http.pcap

这一句话里三个参数互相配合。-i指定接口，any是抓所有接口；-f后面跟的是BPF抓包过滤器，含义是“只保留TCP端口为80的帧”，这样DNS、SSH、系统广播帧不会进文件；-w把结果写入pcap文件，而不是打印到屏幕。如果没写-w，tshark会把解析结果逐行打到终端，流量一多就刷屏。写报告时要的是文件，建议实验开始就养成-w的习惯。

抓包时长和文件大小也应在同一命令里限制，常用的写法是：

sudo tshark -i lo -f "tcp port 443" -a duration:15 -b filesize:10000 -w quic_test.pcap

-a duration:15表示15秒后自动停止；-b filesize:10000表示单个文件达到10000KB就轮转；配合-b files:5最多保留5个文件，避免抓了一个小时把磁盘写满。流量较大时，文件轮转耗尽后会把最旧文件删掉，实验报告里要写明这个参数，别人复现时才知道你抓到的只是时间窗口内的一部分。

3.2 捕获过滤器与显示过滤器：语法不同，各自管一段

抓包命令里的-f是捕获过滤器，它的语法来自BPF，作用时机在帧进入分析器之前。帧如果不符合过滤器就被内核直接丢弃，不进文件。另一个概念是显示过滤器，作用时机在文件已经生成之后，只是“在已有文件里筛选显示”，原始文件内容不变。实验报告里经常把两者混用，导致复现时结果不一致。判断标准很简单：tcp port 80是BPF语法，tcp.port == 80是显示过滤器语法。

下面是我做抓包实验时最常用的几组过滤器对照：

使用显示过滤器从已保存文件中提取数据时，我一般这样写：

tshark -r http.pcap -Y "http.request || http.response" -T fields \ -e frame.number -e ip.src -e http.request.uri

-r指定读取文件，-Y指定显示过滤器，-T fields改变输出格式为“字段抽取”，-e列出抽取哪些字段。这里的“||”表示“或”，这个符号只存在于显示过滤器语法里，BPF里没有这种写法，这也是区分两种过滤器的一个实例。

3.3 保存、合并与按条件分割协议数据包文件

抓包实验做完，原始文件往往比需要的大，直接整个发给别人会拖慢阅读。合并和分割都建议用命令完成，别开GUI再点击导出。

mergecap -w all.pcap http.pcap dns.pcap # 两个文件按时间戳合并 editcap -c 500 -F pcapng big.pcap part # 每500个帧分成一个小文件

mergecap输出文件名由-w指定，源文件按时间戳排序后合并，适合把多个实验阶段对齐成一条时间线。editcap里的-c 500是按帧数切割，生成part_00001_2024...之类的文件；-F pcapng指定输出封装格式，有的工具只读pcap格式，需要改成pcap。还有另一种更实用的导出姿势，直接用tshark重新读过滤后再写文件：

tshark -r all.pcap -Y "dns" -w dns_only.pcap

这条命令把all.pcap里所有DNS帧单独写到一个文件。对比editcap按数量切，这种方式是按协议切，报告里引用数据时更清晰。注意这里-w和-Y同时出现，含义是“读入文件，先过滤，再写入新文件”，和刚才从接口抓包时-w的意义不同。

4. 分析协议数据包：从TCP三次握手到HTTP请求还原

4.1 在数据包文件中观察TCP握手与挥手

实验报告里最常出现的一个图表是“TCP三次握手”。打开抓好的web.pcap文件，先按TCP标志位抓出握手帧：

tshark -r web.pcap -Y "tcp.flags.syn == 1 || tcp.flags.fin == 1" -T fields \ -e frame.number -e tcp.stream -e tcp.flags.str \ -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport

输出里会看到SYN帧的flags.str显示为S，SYN-ACK帧显示为SA，ACK帧显示为A。区分不同连接的关键字段是tcp.stream，这是分析器给每个TCP四元组分配的编号。同一个stream编号的帧才属于同一条连接。如果SYN重复出现且序列号相同，说明发生了重传；如果对方回RST而不是SYN-ACK，常见原因是被访问端口没有监听或防火墙主动拒绝。

用这个命令对照自己的抓包结果时，一个有效做法是只过滤单条stream：

tshark -r web.pcap -Y "tcp.stream == 0" -T fields -e frame.number -e tcp.time_relative -e tcp.flags.str -e tcp.len

看这行的相对时间，能看到握手完成后紧接着发送HTTP请求，TCP负载数据从几十字节到几百字节的变化趋势。对计算机网络里“可靠传输”的理解很有帮助。

4.2 用 -T fields 提取HTTP请求与响应字段

TCP握手只是通信建立阶段，真正体现应用层实验价值的是HTTP请求和响应的还原。下面的命令把指定文件里的HTTP报文转成表格：

tshark -r web.pcap -Y "http.request || http.response" -T fields -E header=y \ -e frame.time_relative -e ip.src -e tcp.srcport \ -e http.request.method -e http.request.uri \ -e http.response.code -e http.content_type

-E header=y表示输出第一行写上字段名；http.request.method和http.request.uri只有请求报文才有值，响应报文对应位置为空；http.response.code只有响应报文才出现值。把这份输出直接写成实验报告里的表，比贴截图更便于核对。

常用HTTP字段对应关系如下：

看字段设计就能理解分析器的解码逻辑：请求和响应共用一套HTTP头字段，分析器用方向把字段归类，并不能光靠一个字段名区分请求还是响应。过滤条件写成http.request和http.response两个单独的布尔标志，才是区分方向的标准做法。

4.3 用DNS过滤器验证域名解析过程

上网行为从DNS开始。抓DNS包时过滤器建议直接写udp port 53，因为标准DNS查询走UDP。

tshark -r dns.pcap -Y "dns.flags.response == 1" -T fields \ -e dns.qry.name -e dns.a -e dns.flags.rcode

这个命令只留DNS响应帧，每行输出查询的域名、解析结果IP和返回码。rcode为0表示无错误，为3表示域名不存在（NXDOMAIN）。把这条结果和请求帧放在一起，能清晰看到“查询-应答”的一对一关系。

假如实验环境里没有足够多的DNS流量，可以用nslookup或dig主动构造：

dig example.com @8.8.8.8 +noall +answer

这条命令使分析器在一个稳定可控的时间点创建一次DNS查询和响应，非常适合写进报告作为验证步骤。注意要在抓包启动后再执行dig，否则抓包文件会是空的。

5. 网络协议分析器报告里最有说服力的验证与排错技巧

5.1 用统计输出证明抓包覆盖率

报告里“我抓到了50个包”这类描述没有对比意义。用分析器的统计子命令可以直接产出一张协议分层统计表，写进报告能直接体现计算机网络基础实验里的协议分布概念：

tshark -r all.pcap -z io,phs

输出里会列出每个协议的帧数、总字节数和占比。这些数字可以直接支撑报告里的“大部分流量集中在HTTP”之类结论。需要展示会话级信息时用-z conv,tcp，能看到每条TCP连接传输的字节数和持续时间。两个命令都在tshark -r读文件时执行，不会重新抓包，对已有文件反复统计也不会改变数据。把这份统计表放在实验报告末尾，比一页截图更能体现对协议数据包整体结构的把握。

5.2 抓不到数据包的三种常规排错

实验中最常见的结果是分析器打开半天一条帧都没有。先别急着重装，按顺序查三个地方。

接口选错最常见。访问127.0.0.1上的服务却不选lo，网卡上没有任何回环帧，自然一条抓不到。改成sudo tshark -i lo后立即能看到数据。第二个是权限。Linux下dumpcap需要CAP_NET_RAW能力，安装tshark时如果选了“不允许非root用户抓包”，普通用户运行会直接拒绝。用sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap一次性赋予，之后普通用户也能抓。第三个是时长太短。很多抓包命令一执行就停在等待状态，实际流量还没产生就已经因为-a duration:3退出了。把时长放宽到15到30秒，并保证另一终端同步在ping目标地址。

把这三种排错步骤写进实验报告的“排错记录”一节时，建议同时保留tshark的报错原文和接口列表截图，两者一对照，原因基本就锁定了。

本文还有配套的精品资源，点击获取