企业官网建设流程全解析

简介：燕山大学计算机网络三级项目的 TCP 传输数据包实践资源，面向正在学习 TCP 协议或需要完成网络编程课程设计的学生。项目以客户端与服务器之间的数据通信为场景，覆盖三次握手、数据分片与重组、滑动窗口流量控制、拥塞控制以及慢启动、快速重传等关键机制，通过 C/C++ 源码与可执行程序让学习者直观对照协议原理与实际实现。压缩包内共有 60 个文件，大小约 27.88MB，主要内容包含 cpp/h 源代码、sln/vcxproj 工程文件、可直接运行的 exe，以及 obj、pdb、tlog 等编译中间产物与日志，便于自行重新编译和调试。其中 server1 与 client1 为两个完整的 Visual Studio 工程，服务端和客户端代码齐全，直接运行即可观察 TCP 数据包传输过程。已有 1352 人学习下载，适合作为计算机网络课程设计参考、协议分析实验素材或 TCP 网络编程入门实践。

1. 燕大计算机网络三级项目里的 TCP 传输数据包：先看清交什么再动手

拿到“燕大计算机网络三级项目TCP传输数据包”这个题目，多数人的第一反应是写一个 socket demo：客户端发给服务端一段字符串，跑通、截图、交差。这个做法在答辩时很容易被一个问题击穿——你代码里那个 send() 在链路上到底生成了几个 TCP 数据包？三次握手各自带了什么标志位？应用载荷为什么是 PSH/ACK 而不是单独一个 PSH？这个三级项目真正要交的东西不是“能跑的代码”，而是代码、抓包证据、以及一份能讲清 TCP 传输过程的报告。它适合正在做课程设计的学生，也适合想借一个完整流程补齐 TCP 协议栈细节的入门从业者。

2. TCP 数据包长什么样：三次握手、报文段格式与状态流转

2.1 先把“数据包”这个词对齐：字节流与 TCP 报文段

“TCP 传输数据包”这个说法里最容易被忽略的词是“包”。很多人把应用层一次性 send 出去的 buffer 误认为是一个 TCP 数据包，实际上 TCP 是面向字节流的协议，数据从 send() 进入内核发送缓冲区后，会被按 MSS（最大报文段长度）切分，加上 TCP 头、交给 IP 层封装成 IP 包，再走链路层。Wireshark 和 tcpdump 里看到的 TCP segment，才是“包”。

在常见的 MTU=1500 的以太网上，MSS 默认是 1460 字节，也就是 1500 减去 20 字节 IP 头、再减去 20 字节 TCP 头。如果 send() 一次写入超过 1460 字节，内核会把这次写入切分成多个报文段依次发送。这个点答辩时经常被追问：一次 send 不一定等于一个包，一个大包也不一定等于一次 send。项目报告里能在开头把这个概念写清楚，后面的抓包分析才有说服力。

2.2 三次握手和四次挥手在包上是四组标志位

三次握手对应链路上的三个报文段。第一个是客户端发出的 SYN，携带初始序号 seq=A；第二个是服务端回应的 SYN+ACK，携带自己的初始序号 seq=B，同时确认号 ack=A+1；第三个是客户端回应的 ACK，seq=A+1，ack=B+1。注意第三次握手在常规场景下不带应用载荷，载荷长度为 0。TCP Fast Open 可以让第三次握手携带数据，但这是特殊机制，三级项目不需要做，答辩时反而要能解释“为什么这里是 0”。

四次挥手同样在包上非常直观：主动关闭方先发 FIN+ACK，对端回一个 ACK，然后对端也发 FIN+ACK，主动关闭方再回 ACK，随后进入 TIME_WAIT。这里容易讲错的是 FIN 包通常带 ACK 标志，因为 TCP 是全双工的，关闭发送方向之前，接收方向的数据可能还没确认完。项目报告里写状态转移时，别只写 FIN 两个字，要把 ACK 标志位一起标出来。

2.3 报文段格式里要会画会背的 6 个字段

TCP 报文段格式是报告里必须出现的一张表。抓包里我们实际能用到的字段集中在下面这张表，把这几个字段说清楚，答辩基本就稳了。

确认号这个字段写报告时最容易翻车。它的含义是“期待对端下一个字节的序号”，不是“我已经收到的最后一个字节序号”。抓包时看到 ack=100，意思是“你下一个带序号的字节请从 100 开始发”，也就是序号 0 到 99 我已经收齐了。把这个定义写进报告，并在抓包分析里对照一次，比背十遍八股文都管用。

2.4 从 LISTEN 到 TIME_WAIT：状态机只记关键 5 态

TCP 状态机本身很庞杂，三级项目不需要全部展开，但几个关键状态必须能和代码对应上。服务端调用 listen() 后进入 LISTEN；客户端调用 connect() 阻塞返回后，双方进入 ESTABLISHED；主动关闭方发 FIN 后进入 FIN_WAIT_1，收到对端 ACK 后进 FIN_WAIT_2，最后发出对 FIN 的确认后进入 TIME_WAIT。TIME_WAIT 持续 2MSL，在 Linux 上通常是 60 秒，这也是后面避坑章里端口复用的根源。

这些状态在项目运行过程中可以直接观察。客户端连接上后，在另一个终端执行ss -tan，能看到一条ESTAB记录；程序退出后再执行一次，主动关闭方那条记录会短暂保持TIME_WAIT。把这个观察结果截图放进报告，状态机部分就不只是背概念了。

3. 从 socket 到可提交代码：用 C 写一个 TCP 传输 demo

3.1 环境与端口：WSL 也能跑，端口避开 1024 以下

代码在纯 Linux 和 WSL 里都能跑。需要确认两点：系统里有 gcc，以及没有别的进程占用测试端口。端口建议选 1024 以上的高位端口，比如 45678，避开 HTTP、SSH 这类常见服务，免得抓包时混进无关流量。如果用的是 WSL，回环地址 127.0.0.1 可以直接用，不需要额外配虚拟网卡。

3.2 服务端最小代码：socket → bind → listen → accept → recv → send

下面这段是服务端完整可编译的代码。它只接收一次数据、原样回显一次，然后关闭连接，足够支撑抓包分析。

#include <stdio.h> #include <string.h> #include <stdlib.h> #include <unistd.h> #include <arpa/inet.h> #include <sys/socket.h> #define PORT 45678 #define BUF_SIZE 4096 int main(void) { int listen_fd, conn_fd; struct sockaddr_in server_addr, client_addr; socklen_t client_len = sizeof(client_addr); char buf[BUF_SIZE]; // 创建 IPv4 TCP socket listen_fd = socket(AF_INET, SOCK_STREAM, 0); if (listen_fd < 0) { perror("socket"); exit(1); } // 端口复用，避免 TIME_WAIT 导致重启失败 int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = htonl(INADDR_ANY); server_addr.sin_port = htons(PORT); if (bind(listen_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) { perror("bind"); exit(1); } // 监听队列长度为 5，演示场景够用 if (listen(listen_fd, 5) < 0) { perror("listen"); exit(1); } printf("server listening on port %d\n", PORT); // 阻塞等待一个客户端连接 conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &client_len); printf("client connected: %s:%d\n", inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port)); // 接收客户端发来的数据 ssize_t n = recv(conn_fd, buf, sizeof(buf), 0); if (n < 0) { perror("recv"); close(conn_fd); close(listen_fd); exit(1); } buf[n] = '\0'; printf("received %zd bytes: %s\n", n, buf); // 原样回显，让客户端确认链路是通的 send(conn_fd, buf, n, 0); close(conn_fd); close(listen_fd); return 0; }

逻辑说明：socket(AF_INET, SOCK_STREAM, 0)创建流式 socket，第三个参数 0 表示让内核选 TCP；listen(fd, 5)里的 5 是未完成和已完成连接队列总和的上限，不是最大连接数；accept返回的conn_fd才是收发数据的 socket，listen_fd只负责接收新连接。接收用recv(conn_fd, buf, sizeof(buf), 0)，这里是一次性读，缓冲区大小 4096 字节，超过这个长度的数据会留在内核缓冲区等下一次 recv。

3.3 客户端最小代码：socket → connect → send → recv → close

#include <stdio.h> #include <string.h> #include <stdlib.h> #include <unistd.h> #include <arpa/inet.h> #include <sys/socket.h> #define SERVER_PORT 45678 #define BUF_SIZE 4096 int main(void) { int sock_fd; struct sockaddr_in server_addr; char buf[BUF_SIZE]; sock_fd = socket(AF_INET, SOCK_STREAM, 0); if (sock_fd < 0) { perror("socket"); exit(1); } memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; // 本机测试，回环地址 server_addr.sin_addr.s_addr = inet_addr("127.0.0.1"); server_addr.sin_port = htons(SERVER_PORT); // connect 内部完成 TCP 三次握手，成功才返回 if (connect(sock_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) { perror("connect"); exit(1); } printf("connected to server\n"); const char *msg = "hello tcp packet from yanshan"; // send 返回发送成功的字节数，不等于对端 recv 到的字节数 ssize_t sent = send(sock_fd, msg, strlen(msg), 0); if (sent < 0) { perror("send"); close(sock_fd); exit(1); } printf("sent %zd bytes\n", sent); // 等待服务端回显 ssize_t n = recv(sock_fd, buf, sizeof(buf), 0); if (n < 0) { perror("recv"); close(sock_fd); exit(1); } buf[n] = '\0'; printf("echo received: %s\n", buf); close(sock_fd); return 0; }

逻辑说明：client_addr.sin_addr.s_addr = inet_addr("127.0.0.1")把点分十进制的回环地址转成网络字节序整数；connect()会阻塞直到三次握手完成或超时失败，所以 connect 能返回值本身就说明握手协商成功了。send()返回的是成功写入发送缓冲区的字节数，不代表对端已经 recv 到这些数据，TCP 的可靠性由协议栈保证，不体现在 send 的返回值上。这个区别项目报告里值得写一笔。

3.4 编译与验证顺序：先起服务端，再起客户端，再对着抓包

编译命令在项目根目录执行：

gcc -Wall -o tcp_server tcp_server.c gcc -Wall -o tcp_client tcp_client.c

-Wall打开常见警告，结构体字段赋值遗漏、返回值忽略这类问题会直接暴露出来。运行顺序有讲究，先启动服务端：

./tcp_server

看到server listening on port 45678后，在另一个终端启动客户端：

./tcp_client

客户端输出connected to server，服务端输出client connected: 127.0.0.1:端口号和收到的消息内容，然后客户端输出回显内容。到这里 demo 是通的，但这只是程序层面通了。下一步要抓包验证 TCP 传输数据包的真实形态，这才是三级项目评分的关键。

3.5 关键参数怎么改：缓冲区、监听队列、端口

BUF_SIZE只影响应用层读写缓冲区，不影响 TCP 报文段切分；把 4096 改成 8192 或 65536 都行，但 recv 一次最多只能读到缓冲区大小的数据，超过的部分留在内核等下一次调用。listen(fd, 5)里的 5 在并发量小时够用，如果项目扩展成多客户端连接，可以调到 128，同时给 accept 套上循环。端口号直接改两处PORT宏，注意服务端和客户端要一致。SO_REUSEADDR建议服务端固定加上，后面避坑章会解释为什么没有它会翻车。

4. 抓包验证传输数据包：tcpdump 过滤、握手与挥手判读

4.1 tcpdump 抓回环包的过滤表达式：-i lo、-S、port

抓包工具用系统自带的 tcpdump 就够了，不需要额外安装。运行服务端和客户端之前，先在一个独立终端启动抓包：

sudo tcpdump -i lo -nn -S tcp port 45678 -w tcp_demo.pcap

参数说明：-i lo指定回环接口，本机 127.0.0.1 的流量全走 lo，不指定的话默认抓第一块网卡，回环包一个都看不见；-nn关闭主机名和端口名解析，避免把 45678 解析成未知服务拖慢输出；-S显示绝对序号而不是相对序号，三次握手判读时更直观；tcp port 45678是过滤表达式，只抓与测试端口相关的 TCP 包；-w tcp_demo.pcap把原始包写入文件，避免终端刷屏丢包。注意必须在客户端运行之前启动，否则漏掉前几个握手包。

再给一个只抓 SYN 包的过滤表达式，答辩时可以用它演示“我在几十个包里精确定位连接建立”：

sudo tcpdump -i lo -nn -S 'tcp port 45678 and tcp[13] & 0x02 != 0'

tcp[13]是 TCP 头第 13 个字节，也就是标志位所在的字节，0x02是 SYN 位掩码。这个写法是抓包报告里很好的加分细节。

4.2 抓包结果怎么对应三次握手：前三包逐行看

抓完后用回放命令直接看：

tcpdump -nn -S -r tcp_demo.pcap

输出大致是三段。前三行对应三次握手，每行字段可以拆成下面这样理解：

第一包：客户端 → 服务端，标志位 S，seq=A。这是 SYN，客户端随机生成初始序号 A。
第二包：服务端 → 客户端，标志位 S.，seq=B，ack=A+1。这是 SYN+ACK，服务端携带自己的初始序号 B，同时确认客户端序号 A。
第三包：客户端 → 服务端，标志位 .，seq=A+1，ack=B+1。这是纯 ACK，载荷长度为 0，确认服务端序号 B。

这里要理解为什么第三条 ack=B+1：B 是服务端的初始序号，虽然 SYN 包本身没有应用数据，但 SYN 标志要消耗一个序号位，所以确认号要加 1。同理第一条的 SYN 也消耗一个序号位，所以客户端第三条的 seq 是 A+1 而不是 A。这个“标志位消耗序号”的细节是答辩时最常被追问的点。

4.3 数据传输段判读：PSH/ACK 载荷长度与序号推进

握手完成后，抓包文件中间几行就是应用数据传输。客户端调用send()发送 “hello tcp packet from yanshan”，链路上出现类似这样的一行：标志位 P.，seq=A+1，ack=B+1，length=32。P. 表示 PSH+ACK，载荷长度就是应用层消息的字节数。服务端回显时再出现一行反向的 PSH+ACK。

数据传输段的判读要点是序号推进。握手结束后客户端的 seq 是 A+1，这个值加上载荷长度，就是下一条数据的起始序号。抓包里能看到 seq 从 A+1 跳到 A+33，中间没有空洞。这就是 TCP 按字节流编号的直接证据。另外 PSH 标志表示“请对端尽快把数据交给应用层”，小数据包一次 send 时通常能看到；如果开了 Nagle 算法且数据量小，PSH 不一定每次都出现，报告里不必纠结。

4.4 四次挥手与 TIME_WAIT 的证据：ss -tan 配合看

程序退出时，抓包尾部出现四行收尾：客户端发 FIN+ACK，服务端回 ACK；服务端发 FIN+ACK，客户端回 ACK。注意这个 demo 里服务端 recv 完、send 完就 close，服务端反而是主动关闭方，时序会反过来：先看到服务端的 FIN 包。谁先 close，谁就是主动关闭方，这一点的判断依据是代码顺序而不是客户端/服务端身份。

四次挥手里还有个细节，收到 FIN 的一方如果还有数据要发，可以合并到后续发送里；这个 demo 里两边都没额外数据，所以挥手是标准的四包。抓包结束后立刻执行：

ss -tan | grep 45678

能看到主动关闭方那条 TCP 连接处于TIME_WAIT，状态会保留约 60 秒。如果动作够快，能拍到 ESTAB 消失、TIME_WAIT 出现的瞬间。这个截图放在报告里，比任何文字描述都直观。

5. 避坑与常见问题：粘包、端口占用、recv 返回 0、抓不到回环包

5.1 一次 send 不等于一次 recv：粘包与拆包

现象：客户端连续两次 send 小数据，服务端一次 recv 把两份数据都读出来了，看起来像“粘包”。反过来的情况是 send 一大块数据，服务端分好几次 recv 才读完，叫“拆包”。

原因：TCP 是字节流协议，没有消息边界。内核只保证字节顺序，不保证 send 和 recv 的次数一一对应。Nagle 算法会把多个小数据合并成一个报文段，网络拥塞时大报文段又会拆成多个小段，都在应用层表现为粘包/拆包。

解决：应用层必须自己加消息边界。常见做法是每个消息前面加 4 字节长度头，发送端先写长度再写内容，接收端先读 4 字节，解析出长度，再按长度把内容读满。发送端演示如下：

uint32_t len = htonl((uint32_t)strlen(msg)); send(sock_fd, &len, 4, 0); // 先发长度 send(sock_fd, msg, strlen(msg), 0); // 再发内容

htonl把主机字节序转成大端网络字节序，接收端用ntohl转回来。注意两个 send 之间不能合写成一个 send，否则对端读到的前 4 字节可能是半个长度加半个内容。

5.2 bind 报 Address already in use：TIME_WAIT 后悔药

现象：服务端跑完一次 demo，Ctrl+C 杀掉进程，立刻重启时报bind: Address already in use。

原因：主动关闭方进入了 TIME_WAIT 状态，连接的四元组还没完全释放，端口被占用。TIME_WAIT 要持续 2MSL，Linux 上通常 60 秒左右，这是 TCP 保证可靠关闭的机制，不是 bug。

解决：在 bind 之前设置 SO_REUSEADDR。注意必须在 bind 之前调用才有效，这就是第 3 章服务端代码里setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt))存在的意义。如果项目里服务端频繁重启调试，这行代码能省掉大量等待时间。

5.3 本机实验抓不到包：回环流量不在 eth0 上

现象：tcpdump 开了，客户端服务端都在运行，终端始终没有输出。

原因：127.0.0.1 的流量走的是 lo（loopback）接口，不是 eth0 也不是 wlan0。默认抓包接口抓不到回环流量，这个问题在新手实验里出现率极高。

解决：抓包命令里显式指定-i lo，或者先用ip addr查看本机网卡列表确认接口名。另外 WSL2 里接口命名可能不同，同样以ip addr输出为准。

5.4 recv 返回 0 被当成错误：半关闭是正常语义

现象：客户端发送完数据后 close，服务端 recv 返回 0，代码里走 perror 分支打印错误。

原因：recv 返回 0 表示对端正常关闭了发送方向，TCP 连接进入半关闭状态。这不是网络错误，更不是读失败。只有返回 -1 才需要查 errno。

解决：recv 返回 0 时应把对应 socket 关闭、退出读取循环。很多多线程网络框架里，recv 返回 0 就是连接断开的标准信号。项目代码里写成if (n < 0) { perror; }是错的，正确判断是if (n <= 0) { close; break; }。

5.5 传大文件速度上不去：Nagle 与缓冲区上限

现象：传输几百 MB 文件时，带宽利用率很低，CPU 也不高，速度就是上不去。

原因：两个常见因素。一是 Nagle 算法，小数据被延迟等待确认，交互式传输时吞吐受损；二是 socket 内核收发缓冲区默认值偏小，对端没有及时 recv 时，发送方 buffer 填满就会阻塞。

解决：对已知要传大文件的连接，可以关闭 Nagle：setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on));。缓冲区可以在两端调大，比如setsockopt(sock_fd, SOL_SOCKET, SO_SNDBUF, &size, sizeof(size));。调大缓冲区不是万能的，接收方应用层要配合及时读取，否则缓冲区再大也会被标满接收窗口、逼停发送方。这个组合是传文件类项目能跑出吞吐量的底线配置。

6. 把项目从能跑做到能讲：trace 证据表与 iperf 吞吐验证

6.1 把 pcap 整理成一张 trace 证据表

答辩时直接放 tcpdump 原始输出，评委扫一眼很难看出门道。我一般建议把抓包结果整理成一张表，每个关键阶段选一两个代表包，列成下面这种格式：

表中序号统一写相对序号，比如第一条 SYN 记为 seq=A，第三条写成 seq=A+1，评委会更快看懂序号推进逻辑。这条表的生成过程不复杂，就是对照 tcpdump 输出逐行抄，但它是报告里最有分量的一页。

6.2 用 iperf 验证传输速率与 MSS 上限

如果想让项目多一个数据支撑点，可以用 iperf3 测一次吞吐。服务端终端跑：

iperf3 -s -p 45678

客户端终端跑：

iperf3 -c 127.0.0.1 -p 45678 -t 5

-t 5表示测 5 秒，输出会包含带宽、重传次数、MSS 等。回环口的吞吐会远高于真实网卡，测出来的值不能代表外网性能，但能验证一个问题：TCP 的传输上限由窗口和 RTT 决定，回环下 RTT 极小，带宽可以冲得很高。报告里写结论时把这个限制讲清楚，显得你理解测试边界而不是只会跑命令。

这个项目到最后真正的分水岭，不在于 send 了几行代码，而在于被问“第三次握手为什么载荷是 0”时能立刻答出来，被问“seq 和 ack 差多少”时能指着抓包说清序号推进。我自己做这类实验早期翻过一次车：代码跑通就以为完事了，答辩现场被追问两次握手区别时，脑子里只有 socket API 的返回状态，连包都没抓过。那次之后养成的习惯是——任何网络 demo 跑通后先抓包，把包数、标志位、载荷长度和代码逐行对齐，再截图存档，这个流程也一直在用。希望帮到你。

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