简介这份东南大学《信息通信网络概论》第四次实验报告围绕计算机网络通信应用程序设计展开适合正在学习 TCP/IP、UDP 编程及 WinSock 接口的本科生作为实验参考。报告完整记录了实验目的、原理、客户机/服务器工作流程、界面设计与功能实现并包含基于 TCP/IP 和 UDP/IP 两套通信程序的详细步骤、实验记录、总结与思考题附录附有部分核心代码TCP 部分重点讲解套接字创建、绑定、监听、连接与数据收发UDP 部分则对比说明无连接通信的实现差异。尤其对“获取发送方主机名与发送时间”“自定义字符画”等改进功能有具体说明能帮助读者理解网络通信程序的架构设计与排错思路。资源为单个 PDF 文件容量仅 20KB内容紧凑但结构完整已有 88 人学习是计算机网络实验报告撰写与复习备考的实用参考。1. 东南大学计算机网络第四次实验报告这份PDF怎么从「能交」写到「能复现」期末周一到「东南大学计算机网络第四次实验报告.pdf」这个文件名就会在班级群里来回传。多数人的做法是把 Wireshark 截图贴满十几页老师追问一句「这个 RTT 是哪个包到哪个包的时间」就答不上来。实际上这类实验报告的价值不在截图多不多而在你能不能留下原始抓包文件、让每一步分析都能重跑一遍。这篇要讲的就是一套从环境准备到数据核对的完整做法适合正在写这份实验报告、或者想把传输层协议真正看明白的人。第四次实验通常落在 TCP 协议分析或 Socket 编程上下面以抓包分析主线展开Socket 编程也能平移这套方法。2. 抓包环境搭建先把实验准备落到能复现再动笔写报告2.1 为什么第四次实验的标配是 Wireshark tshark实验报告要过老师这一关核心不是「我看到了三次握手」而是「我拿什么证据证明我看到了」。Wireshark 图形界面用来人眼确认和截图但报告里真正撑场面的是数据字段这就要靠 tshark 从 pcapng 文件里按字段导出。我一直的习惯是抓包文件保存两份一份原始 pcapng 留档一份是 tshark 导出的 CSV 字段表贴在报告附录里。老师按你的命令自己跑一遍能得到同样的输出这份报告才算可复现。另外要明确一个边界拥塞窗口这类发送端内部状态是抓包看不到的抓包侧能观测的是 ACK、序号、重传、bytes in flight 这些在线路上真实存在的证据。写报告时不要把 Wireshark 的推测性标注当成协议栈内部数据术语上区分「观测值」和「推断值」这一句话就能让报告上一个档次。2.2 最小抓包命令tshark 过滤与导出字段的写法假设已经抓了一份 lab4.pcapng第一步是用 tshark 把三次握手相关的包导出来。命令如下tshark -r lab4.pcapng -Y tcp.flags.syn1 || tcp.flags.syn1 tcp.flags.ack1 \ -T fields -e frame.number -e frame.time_epoch -e ip.src -e ip.dst \ -e tcp.srcport -e tcp.dstport -e tcp.seq -e tcp.ack -e tcp.flags \ -E headery -E separator,这条命令的每个参数都值得在报告里写清楚-r读入抓包文件-Y后面跟显示过滤器这里筛出纯 SYN 和 SYNACK 两种包-T fields表示输出自定义字段而不是 Wireshark 默认的树形结构-e指定要导出的字段名frame.number 是包序号frame.time_epoch 是 Unix 时间戳ip.src/ip.dst 是地址tcp.seq/tcp.ack 是序号和确认号-E headery让第一行输出列名-E separator,把结果落成 CSV方便直接用 Excel 或 pandas 打开。导出后你会看到类似这样的结构第一个包是客户端发给服务器的 SYNseq 是一个很大的绝对序号第二个包是服务器回应的 SYNACK它的 seq 是服务器的初始序号ack 是第一个包的 seq 加一。写报告时建议统一用相对序号因为绝对序号是随机初始化的看起来像天书相对序号从 0 开始一眼就能看出数据偏移量。Wireshark 默认显示相对序号命令行导出的是绝对序号记得在报告里注明这个差异或者导出的字段里保留原始值再在软件里换算。2.3 关掉抓包玄学三个开关与一条 tcpdump抓包第一次就成功是运气不是常态。我踩过最深的坑是网卡 offload抓下来的包 TCP checksum 几乎全红整个 pcapng 在 Wireshark 的 Expert Info 里拉出一长串错误。原因是现代网卡在硬件层面替 TCP 协议栈计算了校验和抓包点看到的是网卡算完交付的成品不是线路上的原始包。Windows 下在网卡属性里把「校验和卸载」相关项全部禁用Linux 下执行sudo ethtool -K eth0 tx off rx off sudo tcpdump -i eth0 -w lab4.pcapng -s 96ethtool -K关闭网卡发送和接收路径的校验和卸载-s 96表示每个包只抓前 96 字节。对 TCP 分析来说96 字节足够覆盖以太网头、IP 头和 TCP 头省磁盘空间避免抓一个 4GB 文件却全是应用层 payload 的尴尬。抓完实验数据记得把 offload 恢复不然会影响本机正常上网性能。第三个开关是浏览器缓存。如果实验涉及 HTTP 请求第一次访问和第二次访问的时序完全不同第二次可能根本没走网络全从本地缓存读了。我一般会在抓包前清一次 DNS 和 ARP 缓存Windows 下是ipconfig /flushdns再用netsh interface ip delete arpcache清 ARP。写报告时把「实验环境准备」列成一段含操作系统版本、客户端工具、抓包网卡、是否关闭 offload这段看似废话的内容恰恰是老师判断你是否真的做过实验的关键。3. 从抓包里抽出三个能写进报告的分析点三次握手、RTT 与拥塞证据3.1 三次握手seq 与 ack 的增量怎么算三次握手是期末复习八股里的必考项抓包里看它却是另一回事。过滤出 SYN 和 SYNACK 包之后把关键字段整理成表表格是报告里最能说明问题的形式包号方向seqack标志位1客户端→服务器0相对0SYN2服务器→客户端0相对1SYNACK3客户端→服务器1相对1ACK这个表有两条隐藏信息值得展开。第一第二个包的 ack1表示客户端初始 seq 已经被收到三次握手中的确认号永远是「对方初始序号 1」而不是 0因为 SYN 本身要消耗一个序号第三包同理seq1 是第一个数据字节的编号。第二如果抓包时看到某个端点直接发 RST 而不是 ACK说明对端协议栈拒绝了这次连接常见原因是端口未监听或者 SYN 缓存被丢弃这也是报告里能写的排错记录。我个人习惯把「为什么初始序号是随机数」也写进实验报告。iWireshark 里点开第一个 SYN 包能看到 tcp.seq 是一个接近几十亿的值这是 TCP 防序号猜测攻击的设计。写报告时说明「绝对序号由 ISN 随机生成相对序号便于分析二者差值是固定的」既解释了手里的数据又显得你理解了协议设计意图。3.2 RTT 与时延抖动用 ack_rtt 字段而不是自己掐表计算 RTT 最常犯的错是把「相邻两个包的时间差」当成 RTT。frame.time_delta 只是包到达抓包点的时间间隔受发送方突发、接收方延迟确认影响和真正的往返时间是两码事。Wireshark 的分析引擎已经算好了这个值字段名叫 tcp.analysis.ack_rtt它统计的是从数据包发出到收到对应 ACK 之间的时间。导出命令tshark -r lab4.pcapng -Y tcp.analysis.ack_rtt \ -T fields -e frame.number -e frame.time_epoch -e ip.src -e ip.dst \ -e tcp.analysis.ack_rtt -E headery -E separator,导出的 ack_rtt 单位是秒Wireshark 界面里显示成 ms。写报告时建议统一换算成毫秒保留三位小数。还要注意ack_rtt 只对「数据段 对应 ACK」这种配对有效三次握手那三个包没有这个字段因为需要数据段来锚定时间。如果实验是在本机回环接口 lo 上抓包RTT 会极小几乎稳定在 0.03ms 左右图表看起来像一条直线这时候别慌在报告里注明「回环接口消除了真实网络链路的传播时延本实验侧重观察协议行为而非绝对时延」顺手还能对比一下跨虚拟机或跨物理机抓包时的差异。3.3 拥塞控制的证据bytes_in_flight 序列拥塞窗口 cwnd 是发送端内存里的变量抓包永远看不到它本身但能看到由它决定的现象在途字节数。Wireshark 的 tcp.analysis.bytes_in_flight 字段表示「已经被发出但尚未收到 ACK 的字节数」它就等于当前飞行中的数据量。当接收窗口足够大时bytes_in_flight 的变化曲线能间接反映发送窗口的增减这是抓包侧能拿到的最接近 cwnd 的证据。导出时应加上一个长 TCP 流没有条件下载大文件就自建流tshark -r lab4.pcapng -Y tcp.analysis.bytes_in_flight tcp.dstport5201 \ -T fields -e frame.time_epoch -e tcp.analysis.bytes_in_flight \ -E headery -E separator, inflight.csv用 iperf3 在本地起一条 TCP 流iperf3 -c 127.0.0.1 -t 30就能制造足够长的传输过程抓包就有数据可看。拿到 CSV 后用一段 Python 画阶梯图import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(inflight.csv, header0, names[time, bytes_in_flight]) df[time] df[time] - df[time].min() # 归零便于展示 plt.figure(figsize(10, 4)) plt.step(df[time], df[bytes_in_flight], wherepost) plt.xlabel(time (s)) plt.ylabel(bytes in flight) plt.title(TCP bytes in flight over time) plt.grid(True) plt.tight_layout() plt.savefig(inflight.pdf, dpi300)这段脚本里plt.step画的是阶梯线而不是连续曲线因为 bytes_in_flight 只在每个 ACK 到达时跳变用阶梯线才符合 TCP 的离散特性wherepost表示数据点只在变化后保持新值还原真实语义。观察这个图你会看到慢启动阶段曲线呈指数上升丢包后突然掉下来再爬升这就是拥塞控制的直观证据。报告里放这张图再加两行解读比如「第 12 秒出现带宽凹陷对应一次超时重传」比任何文字描述都有力。4. 写这份报告最容易翻车的五个抓包细节现象、原因与解法4.1 现象整个 pcap 的 TCP checksum 全是红色打开抓包文件Expert Info 里拉出一长串 checksum 错误每一个 TCP 段都标红。第一次遇到的人容易以为是网卡坏了或者数据有问题其实是网卡帮忙干了协议栈的活。原因现代网卡开启了校验和卸载checksum offloadTCP 校验和的计算发生在网卡硬件层抓包软件是在网卡驱动上交包之后才看到数据的这时候校验和已经被硬件算好甚至被替换Wireshark 重新计算就永远对不上。解决Windows 网卡属性高级里把 TCP/UDP 校验和卸载全部禁用Linux 用sudo ethtool -K eth0 tx off rx off。抓完包再恢复卸载。如果不关也不影响 seq 和 ACK 的分析但报告里贴的截图满屏红叉老师会质疑数据可用性关了更省心。4.2 现象抓了一晚上全是 TLS 加密流应用层什么都看不到实验要求分析 HTTP 或 DNS 明文协议打开抓包文件却看到协议列是 TLSv1.3左侧全是 Application Data右键看明文也看不到。原因现代系统默认 HTTPS浏览器访问的链接全部走 TLS 加密Wireshark 只能看到 TCP 层加密后的应用层内容无法直接解读。解决实验环境里建一个本地 HTTP 服务python3 -m http.server 8000再用浏览器访问http://localhost:8000抓 lo 回环接口即可。这样做还有一个好处本地无实际链路噪声抓包文件干净三次握手、HTTP GET、ACK 序列全部一目了然。如果实验要求必须是远程站点至少选一个 HTTP 明文站点并在报告里注明「为避免加密流量干扰本实验选择明文 HTTP 站点」法理上说得通。4.3 现象重传统计和预想的对不上用tcp.analysis.retransmission过滤得到一大串重传包数出来的数量远超预期甚至出现大量「伪重传」。原因Wireshark 对重传的判断是基于序列号和时间推测的不是协议栈亲口告诉它的。路径丢包、乱序到达、Wi-Fi 链路层重传都可能让 Wireshark 把一个普通包误判为超时重传这就是所谓的 spurious retransmission。解决区分过滤条件tcp.analysis.fast_retransmission是快速重传tcp.analysis.spurious_retransmission是伪重传正文里分开统计。报告里要把「统计口径」写清楚例如「本报告重传统计采用 Expert Info 的 retransmission 口径包含快速重传剔除 spurious」。如果数据仍然过乱换有线网络重抓一次很多玄学问题都会消失。4.4 现象第二次抓的数据跟第一次完全对不上同一个 URL第一次抓包三次握手正常第二次抓包握手消失了或者 RTT 从 20ms 变成 2ms第一反应是抓包姿势不对。原因系统缓存了 DNS 解析和 ARP 映射第二次请求走了不同路径浏览器 keep-alive 复用 TCP 连接压根没有新的握手网卡 offload 状态也被前一次实验改过忘了恢复。解决抓包前统一做一次环境清理ipconfig /flushdns清 DNS删 ARP 缓存关闭后台自动更新和云同步进程。访问动作用curl -o /dev/null http://localhost:8000/test.txt代替浏览器curl 不带 keep-alive 缓存行为每次请求都是新连接复现性远好于浏览器操作。报告里的环境描述也要写上这些命令。4.5 现象SYN 重传间隔不是固定间隔三次握手握不上Wireshark 里看到连续多个 SYN包间隔是 1 秒、2 秒、4 秒递增。有人以为是抓包丢包或者以为协议栈坏了。原因TCP SYN 重传采用指数退避这是 RFC 6298 明确要求的。初始 RTO 大约 1 秒每次重传 RTO 翻倍直到达到系统上限部分系统还在第二次重传后引入随机抖动防止多台机器同时重传造成共振。解决这不是抓包问题是协议行为恰恰是报告里最能加分的观察点。用tshark -Y tcp.flags.syn1 -T fields -e frame.time_delta -e tcp.srcport导出相邻两个 SYN 的时间差能直观看出 1、2、4 的翻倍序列结合 RFC 6298 的 RTO 计算公式写一段说明把挖坑点变成亮点。5. 把抓包数据变成报告里的图和表一个核对技巧报告里所有的图、表、数值都必须在交付前做一次三方核对这是我交实验报告前雷打不动的习惯。具体做法是对同一份 pcapng 文件分别用 tshark 和 Wireshark 图形界面统计三个核心值三次握手总耗时、平均 RTT、重传总数。如果两个工具读出来的数据不一致一定是字段或口径选错了先解决再截图。echo 握手时延第三包时间 - 第一包时间 tshark -r lab4.pcapng -Y tcp.flags.syn1 \ -T fields -e frame.time_epoch | head -2 | awk NR2{print $1- prev} {prev$1} echo 平均RTTms tshark -r lab4.pcapng -Y tcp.analysis.ack_rtt \ -T fields -e tcp.analysis.ack_rtt 2/dev/null | \ awk {sum$1; n} END {if (n0) printf %.3f\n, sum*1000/n} echo 重传总次数 tshark -r lab4.pcapng -Y tcp.analysis.retransmission || tcp.analysis.spurious_retransmission 2/dev/null | wc -l这三段输出的核对逻辑是这样的握手时延必须等于第三个包和第一个包的时间戳差值如果算出来的值比肉眼在 Wireshark 里看的大得多说明中间混入了重传或乱序平均 RTT 应该和 Expert Info 里显示的均值一致不一致时优先怀疑混入了三次握手包重传总次数用两个字段取并集避免漏掉被标记为 spurious 的伪重传。全对上了再把这些命令和结果一起贴进 PDF 附录。我自己写这份实验报告时的习惯是先落实验数据再写分析文字绝不先写了结论再回来凑数据。数据跑不出预期的结论说明实验条件控制得不好或者观察口径错了这时候老老实实把「实际现象 可能的解释」写进报告反而比硬凑一个教科书式结论更让人信服。图不要贪多三次握手时序图、bytes in flight 拥塞证据图、重传间隔退避图这三张是最能体现功底的。希望这份思路能帮你在期末周少走一点弯路把实验报告从「能交」写到「能复现」。本文还有配套的精品资源点击获取