企业官网建设流程全解析

简介：这份东南大学《信息通信网络概论》第四次实验报告，围绕计算机网络通信应用程序设计展开，适合正在学习 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.syn==1 || tcp.flags.syn==1 && tcp.flags.ack==1" \ -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 header=y -E separator=,

这条命令的每个参数都值得在报告里写清楚：-r读入抓包文件，-Y后面跟显示过滤器，这里筛出纯 SYN 和 SYN+ACK 两种包；-T fields表示输出自定义字段而不是 Wireshark 默认的树形结构；-e指定要导出的字段名，frame.number 是包序号，frame.time_epoch 是 Unix 时间戳，ip.src/ip.dst 是地址，tcp.seq/tcp.ack 是序号和确认号；-E header=y让第一行输出列名，-E separator=,把结果落成 CSV，方便直接用 Excel 或 pandas 打开。

导出后你会看到类似这样的结构：第一个包是客户端发给服务器的 SYN，seq 是一个很大的绝对序号；第二个包是服务器回应的 SYN+ACK，它的 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 96

ethtool -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 和 SYN+ACK 包之后，把关键字段整理成表，表格是报告里最能说明问题的形式：

这个表有两条隐藏信息值得展开。第一，第二个包的 ack=1，表示客户端初始 seq 已经被收到，三次握手中的确认号永远是「对方初始序号 + 1」，而不是 +0，因为 SYN 本身要消耗一个序号；第三包同理，seq=1 是第一个数据字节的编号。第二，如果抓包时看到某个端点直接发 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 header=y -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.dstport==5201" \ -T fields -e frame.time_epoch -e tcp.analysis.bytes_in_flight \ -E header=y -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", header=0, 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"], where="post") 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", dpi=300)

这段脚本里，plt.step画的是阶梯线而不是连续曲线，因为 bytes_in_flight 只在每个 ACK 到达时跳变，用阶梯线才符合 TCP 的离散特性；where="post"表示数据点只在变化后保持新值，还原真实语义。观察这个图，你会看到慢启动阶段曲线呈指数上升，丢包后突然掉下来再爬升，这就是拥塞控制的直观证据。报告里放这张图再加两行解读，比如「第 12 秒出现带宽凹陷，对应一次超时重传」，比任何文字描述都有力。

4. 写这份报告最容易翻车的五个抓包细节：现象、原因与解法

4.1 现象：整个 pcap 的 TCP checksum 全是红色

打开抓包文件，Expert Info 里拉出一长串 checksum 错误，每一个 TCP 段都标红。第一次遇到的人容易以为是网卡坏了或者数据有问题，其实是网卡帮忙干了协议栈的活。

原因：现代网卡开启了校验和卸载（checksum offload），TCP 校验和的计算发生在网卡硬件层，抓包软件是在网卡驱动上交包之后才看到数据的，这时候校验和已经被硬件算好甚至被替换，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.syn==1" -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.syn==1" \ -T fields -e frame.time_epoch | head -2 | awk 'NR==2{print $1- prev} {prev=$1}' echo "== 平均RTT（ms）==" 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 (n>0) 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 拥塞证据图、重传间隔退避图这三张是最能体现功底的。希望这份思路能帮你在期末周少走一点弯路，把实验报告从「能交」写到「能复现」。

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