简介这是北航研究生计算机网络课程的实验三报告围绕ARP协议与网络层工作原理展开面向计算机网络方向研究生及高年级本科生。报告基于Wireshark抓包系统分析了ARP请求/应答报文结构Opcode1请求、2应答、ARP缓存维护、默认网关的必要性以及同网段与跨网段通信时MAC地址解析的差异同时结合ICMP回显报文与地址掩码/时间戳请求实验梳理了报文类型、字段对应关系及一一对应机制。资源为1个PDF文件约40KB内容紧凑包含完整实验步骤、命令执行结果、报文截图字段表与答问分析可直接作为同类实验的参考蓝本。已有111人学习适合正在学习计算机网络、需要理解IP-MAC映射及网络层数据传递过程的学习者借鉴。1. 实验3不是“做一遍就行”北航研究生计算机网络实验这份PDF真正想让你练的是什么拿到“实验3北航研究生计算机网络实验.pdf”大多数人的第一反应是打开PDF按步骤抓包、截图、填报告但真正做完才发现分数差距出在“为什么”上。本科生实验是照步骤复现研究生实验要求你先预测报文长什么样再用Wireshark验证这份PDF里的实验3不管落在TCP状态机、应用层协议还是路由协议本质上都在逼你把课本上的时序图变成屏幕上一条条真实报文。如果你正在赶这份实验或者想用“计算机网络自顶向下”的方法把协议栈学扎实这篇文章能帮你把PDF里的目标和参数变成一台虚拟机上可复现、可解释的实验流程顺便少踩几个别人已经踩过的坑。2. 先看懂实验3的考核点从PDF目录反推协议栈主线2.1 研究生阶段实验3与本科实验的本质差别研究生计算机网络实验和本科实验最大的区别不是网络规模变大而是验证方式变了。本科做TCP实验老师会给一张步骤表你照着输入命令、抓包、在报告里贴三张截图实验就算过了。研究生实验PDF里通常只给目标和工具不给完整答案尤其实验3这类传输层实验会要求你利用抓包工具解释某个协议机制比如“为什么SYN重传间隔是1秒、2秒、4秒”。你需要具备从现象倒推状态机的能力也就是先在自己的脑子里跑一遍协议再看报文是否和预期一致。这个过程很像在打开一个黑匣子抓包文件就是探针协议状态机就是地图。常见做法是实验3落在传输层因为传输层协议有状态、有定时器、有可观察的报文交互适合用实验室里一台电脑加Wireshark就完成不需要高并发、多路由器等大型环境。而且传输层是自顶向下教学里承上启下的部分应用层协议的行为全部依赖TCP/UDP这一层一旦有盲区后面分析HTTP、DNS全都会发飘。另外研究生实验的评分维度也变了。PDF里经常有一项“实验分析”分值占三成以上。也就是说光截图不够你必须说明每一步发生的原因。比如抓到一个乱序报文得回答“这是TCP快速重传还是SACK出现的场景”。这种题没有固定模板但有一个稳妥的答题结构先给出报文时间线再用状态机解释最后把参数变化列出来。这也是为什么我建议你花二十分钟把PDF里的参数表摘出来而不是直接开Wireshark抓包。2.2 实验3最常见的三种主线TCP状态机、UDP应用层、路由协议拿到PDF先翻目录和预期结果截图判断实验3属于哪条主线。我判断的顺序依次是看有没有三次握手的截图有的话九成是TCP状态机看有没有HTTP/DNS的过滤表达式有的话是应用层分析看有没有路由器配置命令有的话是动态路由实验。主线ATCP状态机与重传。这是最“研究生”的选题也是出现频率最高的一种。PDF通常会要求你抓取一次TCP连接标出三次握手、数据段、ACK、四次挥手然后模拟一种故障比如丢包观察重传定时器退避。这种实验的难点不在抓包而在制造精确的故障。你没法在公有云上随手丢一个包必须在本地虚拟机上用网络模拟器控制。后面第4章我会专门走一遍这个流程。主线B应用层协议分析。常见的是HTTP/1.1与DNSPDF会要求你打开某个网页或发起网络请求分析请求行、响应码、DNS查询过程。看起来简单但研究生实验往往会加一个尾巴比如“解释TCP连接复用和HTTP流水线的差异”这就必须同时抓TCP和HTTP的包不能再只看应用层。我一般会把抓包过滤器写成tcp port 80 or tcp port 443 or udp port 53先把三路流量都收进来再在显示过滤器里分别拆。主线C路由协议与转发行为。如果实验3落在网络层常见的是用FRRouting跑OSPF或者RIP抓包观察Hello报文和LSA泛洪。这种实验至少需要三台虚拟路由器拓扑搭建成本最高但报文特征明显适合做对比实验。如果你在PDF里看到了area 0、network 10.0.0.0/24这类命令果断往这个方向准备。有了主线判断再去读PDF里的参数列表就会轻松很多。比如PDF中出现“SYN重传次数5”“初始RTO1秒”这类字样基本可以锁定是主线A出现“DNS response Time”则大概率是应用层分析。2.3 用表格把PDF里出现的参数拆成自己的验证清单拿到PDF不要从头逐字读先花二十分钟把里面的参数、预期结果和命令提取出来列成一张验证清单。我一般会这样做把PDF里所有带数字、带单位、带协议字段的内容摘出来表格左边是实验阶段中间是关键参数右边是验证方式。实验阶段关键参数验证方式TCP三次握手seq随机数SYN1ACK seq对方seq1Wireshark筛选tcp.flags.syn1数据发送接收窗口win65535查看TCP头部Window字段丢包重传RTO初始值RFC 6298建议1秒tshark统计TCP Retransmission四次挥手FIN和ACK报文的先后顺序显示过滤器tcp.flags.fin1拥塞控制cwnd和ssthresh变化tcpdump抓包配合ss -ti这张表的作用是让你在实验前先有预期。比如你知道三次握手里ACK的序列号是“对方seq1”那么抓包看到ack_seq对不上就能立刻意识到连接建立阶段有数据段同时携带或者发生了TCP Fast Open。在验证的时候能提前说出预期结果比事后翻协议栈解释更有说服力也更容易拿分。把PDF的验证清单做完下一步就是搭环境。这里提醒一句实验3不需要服务器也不需要在真机上装双系统一台虚拟机加Wireshark加Python的Scapy库就够了。下面第3章我会把这个最小环境一步步讲清楚。3. 复现实验3的最小环境一台虚拟机加两个软件跑通抓包和造流3.1 虚拟网络拓扑怎么搭VMware/UTM 加双网卡我在给学生排错时发现一半的“抓不到包”问题出在虚拟网络拓扑上。实验3最小环境只需要一台虚拟机但网卡要选对。这里有个血泪经验如果你用VMware Workstation创建虚拟机时默认是NAT模式虚拟机访问宿主机或者外网都正常但在NAT模式下Wireshark能看到的最多只是虚拟机自身收发流量抓不到宿主机和外部主机交互的真实链路。要模拟网络故障最好再加一张“仅主机模式”的网卡或者直接用VirtualBox的internal network。我一般会这样配置虚拟机操作系统选Ubuntu 22.04 LTS磁盘给20GB就行内存2GB足够抓包和分析。添加两张网卡第一张NAT用于下载软件包第二张仅主机模式host-only用于实验流量这样抓包的时候不会混入大量后台SSH、更新流量。在虚拟机里把host-only网卡设为静态IP比如192.168.56.101/24宿主机端对应192.168.56.1。搭建后先做一个连通性验证在虚拟机里执行ping -c 3 192.168.56.1只要收到回显说明二层以下已经通了。接下来用Wireshark抓这个host-only网卡就能看到ARP广播和ICMP报文这是最干净的实验底噪。如果连这个都没有先查VMware虚拟网络编辑器里的CIDR配置不要急着进入协议实验。3.2 Wireshark抓包过滤器与显示过滤器先定边界再抓包很多人打开Wireshark就直接点开始抓满一张表再加过滤条件结果把自己也绕晕了。正确做法是先设置抓包过滤器Capture Filter减少写入磁盘的报文量。抓包过滤器用的是BPF语法在Wireshark界面最上方的“捕获选项”里填。我常用的几个# 只看host-only网段忽略SSH和DHCP噪声 host 192.168.56.0/24 # 只看某台主机到8080端口的TCP流量 tcp port 8080 and host 192.168.56.101 # 同时抓TCP 80/443和DNS tcp port 80 or tcp port 443 or udp port 53注意BPF语法里的and、or是C语言风格不要写成。抓包过滤器在抓包那一刻就过滤掉数据包文件会小很多适合长时间跑实验。显示过滤器Display Filter则是抓包后再从文件里筛数据。Wireshark的显示过滤语法更丰富比如# 只看SYN包三次握手第一步 tcp.flags.syn 1 and tcp.flags.ack 0 # 只看TCP重传 tcp.analysis.retransmission # 只看DNS响应且IP不是本机 dns.flags.response 1 and ip.src ! 192.168.56.101这两个过滤器的区别就是“先过滤再存盘”和“先存盘再过滤”。实验3我建议抓包时用BPF卡边界显示时用Wireshark表达式卡细节不要反过来。如果抓包过滤器太宽一个两分钟的抓包文件能到几百兆后面分析时界面卡顿不说导出字段也容易崩。3.3 用Scapy生成异常TCP报文最小可改脚本和参数说明Wireshark负责“看”但实验3光看不行有时候需要主动“制造”一些异常的报文。最常见的是用Scapy构造TCP SYN包。Scapy是Python的报文生成库可以精确控制序列号、窗口、标志位。下面这个脚本是我在实验里经常用的最小模板from scapy.all import * # 构造一个TCP SYN包 ip IP(src192.168.56.101, dst192.168.56.1) tcp TCP(sport12345, dport8080, flagsS, seq1000, window65535) syn_pkt ip / tcp # 发送3个SYN包间隔1秒 for i in range(3): send(syn_pkt, verboseFalse) time.sleep(1)逻辑说明IP对象定义了三层地址TCP对象设置了四层端口和标志位。flagsS表示SYNseq1000是伪造的起始序列号window65535声明接收窗口。send函数是三层发送不经过本机协议栈所以构造出来的包可以自由设定违法值比如SYN和ACK同时为1或者序列号不随机。实验里可以用它来验证“收到不合法SYN时对端会直接丢弃还是回RST”。参数调节上三个值最常改第一个是sport/dport用来匹配过滤表达式第二个是flags换成“SA”就是SYNACK换成“A”就是纯ACK第三个是seq改成与真实连接相同就变成乱序报文。如果要在真实连接里注入异常包需要先用Wireshark抓到连接的五元组和当前seq再构造相应报文不然对端会直接扔进receive queue。Scapy脚本跑完之后Wireshark里应该能看到这三个SYN包。如果看不到先检查Scapy是不是以root权限运行因为构造原始套接字需要root。这是很多人第一次跑Scapy翻车的点也是最容易被忽略的。环境搭好后就可以做第4章的核心实验——模拟丢包并观察TCP重传。这一步也是PDF里最容易被扣分的地方因为不只是“看到重传”还要解释RTO退避和拥塞窗口的关系。4. 把PDF里的理论步骤落成真实报文以TCP重传定时器为例4.1 用netem制造可量化的丢包率模拟丢包的首选工具是Linux内核自带的tc-netem不需要额外安装。它能在网卡的发送方向按指定概率丢包也能控制延迟和乱序。最常用的命令是# 在eth0上增加10%丢包率 sudo tc qdisc add dev eth0 root netem loss 10%注意这里的丢包影响的是通过eth0发送出去的报文。如果你在客户端网卡上加了丢包那么客户端发出的SYN和ACK都可能被丢在服务端网卡上加丢包则影响服务端发出的SYNACK。要精确模拟“第三次握手ACK丢失”理论上应当只丢弃客户端发出的纯ACK报文而不是全部报文。常见的做法是用iptables的概率模块匹配特征包。比如只丢弃从本机发往8080端口、且TCP标志位为ACK的包sudo iptables -A OUTPUT -p tcp --dport 8080 \ -m tcp --tcp-flags ACK ACK \ -m statistic --mode random --probability 0.5 \ -j DROP参数说明--tcp-flags ACK ACK表示匹配ACK位为1的包--probability 0.5表示有50%的命中概率。这样三次握手的第三步就有大约一半概率丢失观察到服务端重传SYNACK的概率也会很高。跑了这个规则后再用sudo iptables -L -v查看匹配计数确认规则确实生效。我这里更推荐先做全量丢包因为更直观。把丢包率设为10%然后在客户端发起一个HTTP下载请求Wireshark里能看到大量TCP Retransmission和Dup ACK。数值上10%丢包率对TCP吞吐的损伤非常明显是一个很适合分析的“异常对照组”。4.2 抓包定位SYN重传和RTO退避启动抓包后用curl发起一次普通HTTP请求同时让服务端用Python起一个简单的HTTP服务# 在服务端启动HTTP服务 python3 -m http.server 8080 # 在客户端发起请求 curl http://192.168.56.1:8080/抓包时显示过滤器设为tcp.analysis.retransmission or tcp.analysis.fast_retransmission or tcp.analysis.duplicate_ack这个过滤器会标出所有重传、快速重传和重复ACK。然后逐个看时间戳就能还原RTO退避过程。正常情况下TCP第一次重传发生在1秒后第二次在2秒后第三次在4秒后。这是RFC 6298规定的指数退避RTO 初始RTO * 2^(retry_count - 1)。如果实验环境里没有丢包但Wireshark里已经出现重传那就要排查路径上的拥塞设备。在我看来最稳的做法是先用netem人为制造10%丢包这样你能控制变量而不是靠玄学让网络自己“卡一下”。4.3 从抓包结果反推PDF里的序列号窗口和确认号规律实验报告里最容易被老师追问的就是“序列号和确认号怎么对应”。其实只要抓一次纯下载就能把规律讲清楚。以下是一个用tshark提取关键字段的命令避免用GUI一个个看# tshark提取TCP关键字段 tshark -r capture.pcap -Y tcp.port 8080 \ -T fields \ -e frame.number -e frame.time_relative \ -e ip.src -e ip.dst \ -e tcp.seq -e tcp.ack \ -e tcp.len -e tcp.flags.str参数说明-r读入抓包文件-Y用显示过滤语法筛端口-T fields输出自定义字段。tcp.seq是报文的序列号tcp.ack是确认号tcp.len是TCP负载长度tcp.flags.str输出标志位字符串比如A代表ACK。看输出数据时有三条规律可以写进报告里对端发来的ACK号永远等于自己上一个报文的seqtcp.len。如果TFO或时间戳有偏移偏移量也是可计算常量。纯ACK包本身不消耗序列号所以确认下一个包seq不变。重传报文的seq完全一致但时间戳不同Wireshark识别重传靠的就是“相同seq相同IP相同端口”。你可以把tshark的输出导入Python统计重传间隔做一个简单的数据验证import subprocess, re # 执行tshark命令 cmd tshark -r capture.pcap -Y tcp.port 8080 -T fields -e frame.time_relative -e tcp.seq -e tcp.len result subprocess.check_output(cmd, shellTrue, textTrue) # 按行解析标出相同seq的报文 seen {} for line in result.strip().split(\n): parts line.split(\t) if len(parts) 3: continue time_s float(parts[0]); seq parts[1]; length int(parts[2]) if seq in seen: gap time_s - seen[seq] print(fseq {seq} 重传间隔: {gap:.3f} 秒) else: seen[seq] time_s这段代码会打印出相同seq的报文间隔。如果你看到了1.000、2.000、4.000这样的间隔就完成了一次对RTO退避的实证。这是PDF实验里最有说服力的一张结果表。到这里一个完整的“丢包重传”实验闭环就通了。接下来的避坑章我会集中写几个我自己替学生排过的、反复出现的问题。很多问题不是技术多难而是一开始方向就错了。5. 实验3避坑指南5个让研究生在PDF实验里栽跟头的常见问题5.1 现象Wireshark一片红全是RST包现象刚打开Wireshark抓包什么正经流量都没有界面上全是黑色或红色带RST标志的包目标端口五花八门。原因绝大多数情况是虚拟机或宿主机上安装了云端同步软件、即时通讯软件在主动探测网络发起TCP连接但端口没人监听于是对端回RST。另一个常见原因是你抓的是NAT网卡宿主机上其他进程的流量也经过了虚拟网卡RST自然一堆。解决先把抓包过滤器收紧到实验用的网段和端口比如host 192.168.56.0/24 and tcp port 8080。如果RST仍然存在就在虚拟机里暂时关闭所有用户态服务用netstat -tunlp查看端口监听列表。最稳妥的做法是只用host-only网卡抓实验流量别抓NAT网卡。5.2 现象三次握手抓到了但连接就是建立不起来现象Wireshark里能看到SYN、SYNACK但之后客户端没有发出ACK或者发出后服务端直接回RST。原因这通常不是抓包问题而是内核协议栈把连接重置了。可能原因有半连接队列溢出服务端accept队列满了连接被防火墙synproxy接走TCP时间戳校验失败。其中最常见的是服务端应用没开比如HTTP server根本没监听8080端口这样内核协议栈在完成三次握手后找不到应用直接回RST。解决先在服务端执行ss -tlnp | grep 8080确认监听。如果服务在再看ss -tunap的Recv-QSend-QSend-Q超过accept队列长度时要调大net.core.somaxconn。如果是自己用socket写服务别忘了在listen时设backlog参数默认值只有128压测时很容易丢连接。5.3 现象回环地址lo上抓不到任何包现象在Wireshark里选了lo网卡也设置了过滤器tcp port 8080但抓不到curl访问127.0.0.1的流量。原因Wireshark默认不监听回环接口的虚拟流量除非安装Npcap时勾选了“支持回环抓包”或者在Linux下用dumpcap -i lo。另外有些应用走的是IPv6回环::1你抓IPv4流量当然看不到。解决在Linux虚拟机上直接用sudo tcpdump -i lo -w /tmp/loop.pcap抓回环包再用Wireshark打开pcap文件。如果坚持要在Wireshark里实时抓回环确认安装Npcap时勾选Loopback选项并且在过滤条件里写ip6 or ip不要只写IPv4。5.4 现象脚本里的socket超时但Wireshark显示报文正常现象Python socket客户端报TimeoutError但服务端Wireshark明明已经能看到SYN和SYNACK甚至看到ACK客户端却还一直重试。原因很多虚拟化网卡开启了TCP校验和卸载checksum offloading网卡在发送前才填充校验和Wireshark捕获的是驱动交付前的数据所以校验和字段是脏的。服务端内核校验失败后直接丢包应用层收不到数据自然超时。解决这是一道经典送分题。要么在Wireshark里右键校验和错误的包选择“禁用该连接的校验和校验”要么在虚拟机里执行ethtool -K eth0 tx off rx off关闭硬件校验和卸载。注意这个设置重启后失效实验前要重新关。如果你已经抓包完成只需要在显示里忽略校验和错误别再重新抓包因为那是最省事的路。5.5 现象PDF里的截图和你的抓包对不上现象按PDF上的步骤抓包窗口大小、seq号范围等跟PDF截图差别很大甚至没有同款TSval值。原因TCP的随机初始序列号和窗口缩放因子每次连接都可能不同PDF截图来自当时的操作系统和内核参数比如Linux默认tcp_window_scaling为1Windows则可能在SYN包里直接带窗口缩放选项。不同内核的初始RTO也略有差异所以对比截图没有意义。解决抓包前先自己在PDF里找出“预期应该固定”的项目比如SYN重传次数、SYNACK的最大重传次数、挥手时FIN的顺序这些是协议栈确定行为与环境和时间戳无关。窗口大小、seq、TSval这类动态值直接用你自己的抓包结果重新描述并主动和PDF对比说明差异原因反而能加分。6. 进阶验证用SS命令把PDF里的数值变成可重复的结论6.1 用 ss -ti 观察窗口和重传队列抓包看到的是一次性的报文片段但要证明你理解了TCP状态机最好在实验的同时用ss查看内核里实时维护的连接状态。ss是netstat的现代替代品输出更结构化。实验时在客户端头发起一次下载然后迅速执行# 查看本机TCP连接的内核统计信息 ss -tinp | grep -A 1 8080输出里的关键字段包括cwnd拥塞窗口、rto当前重传超时、rtt平滑后往返时间、qack是否启用快速确认。拿其中一行举例cubic rto:1000 rtt:12/2 ato:40 mss:1460 cwnd:4 bytes_acked:2000参数说明rto:1000表示当前重传超时是1秒cwnd:4表示拥塞窗口只有4个MSS说明刚进入拥塞避免阶段bytes_acked:2000是已确认字节数。你可以把这条结果和Wireshark里的重传间隔对照如果rto从1000变成2000说明内核已经做了一次指数退避。6.2 一个习惯每个异常实验都要留一条“正常对照组”我在做这个实验时养成了一个习惯每次模拟丢包前先在同样的拓扑里跑一轮不丢包的抓包保存为baseline.pcap。这看起来多花两分钟但最后整理报告时会非常香。因为你说“发成丢包导致重传”必须有正常数据说明本来没有重传你说“三次握手失败”必须有正常握手对照说明不是网卡问题。比如在netem造丢包之前先执行一次干净的HTTP请求保存基线然后设置丢包再请求一次保存异常。两份抓包放在同一个Wireshark窗口里用“导出分组”合并或者用mergecap合并时间轴错开。到这一步你手里的实验就不再是“跑完就没有”而是“随时能复现、能改参数再跑一遍”的完整实验套装。希望这个思路帮到你至少让你在结课前不再为实验3临时抱佛脚。提示mergecap -w all.pcap baseline.pcap abnormal.pcap可以把两份抓包合并到一个文件注意这是按时间戳穿插不是简单拼接。本文还有配套的精品资源点击获取