简介：基于TCP的客户/服务器通信程序大作业，采用C语言实现，覆盖注册、登陆、单聊、私聊、在线人数列表、退出等完整功能，以有连接服务为主、无连接服务为辅，结合事件对象I/O管理完成通信调度，适合计算机网络或TCP/IP课程设计参考。资源为1个doc文档，压缩包大小1.54MB，文档内包含总体设计、基本通信协议选取、通信过程与数据包设计、程序流程图、客户端与服务器端程序清单以及运行结果截图。内容从协议选型到数据包格式均有说明，尤其对TCP与UDP差异、固定长度数据包与checksum校验、事件对象I/O管理下的多客户端交互有较完整呈现，可直接用于理解课程设计思路、对照编写代码或完善实验报告。文档结构层次清晰，便于按章节查阅。已有973人学习下载，适合正在完成TCP/IP网络编程大作业的学生参考。
1. 为什么一个 TCP 大作业值得你认真写完：先搞清楚它考的是什么
又到了TCPIP课程交大作业的季节，打开文档模板，标题写着“基于TCP的网络通信编程C语言版”，很多人的第一反应是上网找一份能跑的代码交差。但如果你只下载一个现成的 socket 程序改改名字，答辩时老师问“三次握手发生在哪个函数里”“为什么服务器主动 close 后端口不能立刻重用”，你大概率会卡在原地。这门课设真正想验证的，不是你能不能调通 API，而是你对 TCP 连接生命周期、缓冲区语义、并发模型的理解——这些恰好是 C 语言最擅长暴露问题的地方。
这篇文章以一个能答辩、能扩展、能跑出稳定吞吐的完整 C 语言 TCP 通信程序为主线，把 socket API 从 socket() 到 send() 的每一环拆开讲。中间会给出可以直接抄的代码骨架、需要手动调整的参数、以及我当年反复翻车的三个典型坑。最后一部分落到性能调优和抓包验证上，帮你把这份大作业从“能跑”提升到“敢在老师面前演示”。
2. TCP 通信程序的骨架：先想清楚服务端和客户端各自要管什么
写 TCP 程序之前，先把职责边界划清楚。服务端是“被动方”，它要做四件事：创建套接字、绑定地址、监听、接受连接。客户端是“主动方”，它也做四件事：创建套接字、连接服务器、发送数据、接收数据。这个对应关系看起来简单，但 C 语言初学者通常会栽在“服务端怎么知道客户端发来的是什么”“客户端怎么知道服务端什么时候关闭了连接”这两个问题上。
2.1 从 socket() 到 listen()：服务端初始化的四个调用
服务端的初始化代码在每一份大作业里都长得差不多，但参数的含义值得逐行看。常见做法是先创建一个流式套接字，再绑定到本机的某个端口，然后进入监听状态准备接受连接。
int server_fd = socket(AF_INET, SOCK_STREAM, 0); if (server_fd < 0) { perror("socket"); exit(EXIT_FAILURE); } int opt = 1; setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); struct sockaddr_in server_addr; 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(8080); if (bind(server_fd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) { perror("bind"); exit(EXIT_FAILURE); } if (listen(server_fd, 10) < 0) { perror("listen"); exit(EXIT_FAILURE); }socket() 的第三个参数 0 表示让内核根据协议族和类型自动选择协议，AF_INET 加 SOCK_STREAM 组合出来的就是 TCP，不用显式写 IPPROTO_TCP。bind() 之前设置 SO_REUSEADDR 是血泪经验：不设这个选项的话，服务端 Ctrl+C 退出后立刻重启，bind 会报 Address already in use，因为上一次的连接还处在 TIME_WAIT 状态。listen() 的第二个参数 10 是连接请求队列的长度，它不代表最大并发连接数，只代表内核能为这个套接字缓冲多少个尚未被 accept() 取走的连接。
一个新手经常问的点是：为什么 bind 时端口要 htons，IP 要 htonl？因为 x86 机器是小端序，而网络字节序规定多字节整数是大端。INADDR_ANY 展开为 0.0.0.0，表示监听本机所有网卡，这样客户端从回环地址或者局域网 IP 都能连进来。如果你只想让本机连，可以改成 inet_addr("127.0.0.1")，但演示时不够灵活。
2.2 accept() 和 recv() 的阻塞语义：程序卡住不代表死掉
服务端初始化完成后进入 accept() 循环。这里的核心认知是：accept() 在没有客户端连接时会一直阻塞，直到有连接请求到达才返回。很多初学者以为程序“卡死”了，抢着加 printf 探针，实际它只是安静地等在系统调用里。
while (1) { struct sockaddr_in client_addr; socklen_t client_len = sizeof(client_addr); int client_fd = accept(server_fd, (struct sockaddr*)&client_addr, &client_len); if (client_fd < 0) { perror("accept"); continue; } char remote_ip[INET_ADDRSTRLEN]; inet_ntop(AF_INET, &client_addr.sin_addr, remote_ip, sizeof(remote_ip)); printf("client connected: %s:%d\n", remote_ip, ntohs(client_addr.sin_port)); char buffer[1024]; ssize_t n = recv(client_fd, buffer, sizeof(buffer), 0); if (n > 0) { buffer[n] = '\0'; printf("received: %s\n", buffer); } close(client_fd); }accept() 返回的是一个全新的套接字 client_fd，它专门用于和这个客户端通信。server_fd 仍然在监听端口上等着下一个连接。inet_ntop 把二进制的 IP 转成点分十进制字符串，ntohs 把端口转回主机字节序，这两个转换在答辩时经常被追问。recv() 的返回值是本次实际收到的字节数，它是收到多少返回多少，不保证一次收完应用层的一条完整消息——这就是后面要重点说的“粘包”问题。
这段代码里我是串行处理的，一个连接关闭后才 accept 下一个。它适合演示，但不适合老师追问“同时两个客户端连上来会怎样”这种问题。如果被问到，就顺着说“用 fork 或线程处理并发”，这是后话，先确保基础链路的逻辑是通的。
3. 把客户端写出来：连接、发送、优雅关闭的完整闭环
服务端的代码回答了“怎么接”，客户端的代码要回答“怎么连、怎么发、怎么收、怎么关”。大作业里客户端往往是得分点，因为老师会在同一台机器上跑两个终端，亲眼看到一端输入的内容从另一端打印出来。所以客户端的代码不能写得比服务端还草率。
3.1 connect() 的三次握手：失败时不要急着调代码，先看 errno
客户端的 connect() 调用会触发 TCP 三次握手：客户端发 SYN，服务器回 SYN+ACK，客户端再回 ACK。握手期间 connect() 是阻塞的，直到握手完成或者超时出错才返回。这个函数看起来只有一个动作，但它背后的状态机是老师最爱提问的考点。
int client_fd = socket(AF_INET, SOCK_STREAM, 0); if (client_fd < 0) { perror("socket"); exit(EXIT_FAILURE); } struct sockaddr_in server_addr; memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_port = htons(8080); if (inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr) <= 0) { perror("inet_pton"); exit(EXIT_FAILURE); } if (connect(client_fd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) { perror("connect"); exit(EXIT_FAILURE); }connect() 失败时常见的三种 errno：ECONNREFUSED 表示服务器没在监听对应的端口，也就是你连了一个没人 listen 的地址；ETIMEDOUT 表示 SYN 发出去了但没有收到 SYN+ACK，通常是网络不通或者对端防火墙丢包；EHOSTUNREACH 表示目标主机不可达，多见于 IP 配错或跨网段。答辩时把这三条背下来，比多写两百行代码更有说服力。
inet_pton 是推荐写法，它比 inet_addr 更安全，因为后者无法区分“转换失败”和“地址是 255.255.255.255”这两种情况。用 127.0.0.1 做演示，客户端和服务端在同一台机器上跑，数据走的是回环接口，不会受到防火墙干扰。如果你想演示跨机器通信，把 IP 换成局域网地址，并确保对端防火墙放行了这个端口。
3.2 send() 的字节数迷思：返回值是“已交给内核”的量，不是“对方已收到”的量
send() 的返回值经常让学生困惑。它返回的字节数表示内核接收缓冲区成功接纳了多少数据，不代表对端已经 recv 到了多少。如果 send 一个很大的字符串只发出去了前半截，不要惊讶，这是 TCP 的正常行为。完整发送要自己写循环。
const char *msg = "hello tcp server, this is the client speaking"; size_t sent = 0; size_t len = strlen(msg); while (sent < len) { ssize_t n = send(client_fd, msg + sent, len - sent, 0); if (n < 0) { perror("send"); break; } sent += n; }这里每轮 send 从上次未发送的位置继续推数据，msg + sent 是 C 语言指针算术的典型用法。第一个参数是套接字描述符，第二个参数是发送缓冲区起点，第三个参数是剩余长度，第四个参数 0 表示默认行为。send 返回 -1 时，常见错误是 EPIPE——对端已经关闭了连接，你还往管道里写数据，内核会触发 SIGPIPE 信号，默认动作是直接终止进程。很多人程序无声无息退出就是这个原因，解决方法是忽略 SIGPIPE 或者检查 send 返回值后主动退出。
这段循环可以写成一个 send_all 工具函数，客户端收数据时也照此办理，做一个 recv_all。不要把“一次 send 对应一次 recv”当成 TCP 的工作方式，它是字节流，不是消息边界。这是整个大作业里最容易翻车的地方，后面展开说。
3.3 优雅关闭：close 和 shutdown 的差别，以及为什么不能只信 close
通信结束后要关闭连接。很多人一条 close(client_fd) 就完事了，但老师如果问“你和对方的关闭动作有什么区别”，你要能说清楚 close 和 shutdown 的差异。
shutdown(client_fd, SHUT_WR); // 此时还可以 recv，等待服务器把余下数据发完 while (recv(client_fd, buffer, sizeof(buffer), 0) > 0) { // drain } close(client_fd);close 是把描述符的引用计数减一，只有当计数归零时才真正发起 FIN。如果你在这个进程里 fork 过，子进程继承了描述符，父进程 close 后连接还没关。shutdown 则直接操作连接本身，SHUT_WR 表示“我不再发送数据了，但还能收”，对端 recv 会返回 0，表示对方关闭了写半部。客户端先 shutdown(SHUT_WR)，再循环 recv 直到返回 0 或 -1，这才叫完整的关闭流程。
服务端这边，recv 返回 0 意味着对方主动关闭了连接。这时候服务端也要 close(client_fd)，否则会一直占着一个已经没用的文件描述符。交互式演示场景里，客户端发完消息就关，服务端收完也能收尾，两者都能正常退出。真正复杂的半关闭场景，是客户端发完请求后想等一个很大的响应，这时 SHUT_WR 就非常有用——它告诉服务端“请求发完了”，同时保留读方向的能力。
4. 协议怎么定：字节流模型下，维护消息边界才是这个作业真正的难点
TCP 是流式协议，send 的字符串到了对端只是字节流，没有天然的“消息”边界。客户端先发 abc 再发 def，服务端 recv 可能一次收到 abcdef。反过来，客户端一次 send 一万字节，服务端每次收 1024 字节，就要用循环收七次再加个尾巴。这个现象就是大作业答辩里的经典问题——“粘包”。解决思路也很固定：应用层自己定义消息格式。
4.1 定一个 4 字节长度头 + 负载的协议：最小可用的消息分帧方案
最常用的分帧协议是“长度前缀”：每个消息前面加一个固定长度的字段，说明后面负载有多少字节。收方先读这个长度，再循环 recv 直到凑满，就拿到了完整的一条消息。
typedef struct __attribute__((packed)) { uint32_t length; char payload[]; // flexible array member } message_t; // 发送一条消息 uint32_t net_len = htonl((uint32_t)strlen(payload_str)); send_all(client_fd, &net_len, sizeof(net_len)); send_all(client_fd, payload_str, strlen(payload_str)); // 接收一条消息 uint32_t net_len = 0; recv_all(client_fd, &net_len, sizeof(net_len)); uint32_t host_len = ntohl(net_len); char *buf = malloc(host_len + 1); recv_all(client_fd, buf, host_len); buf[host_len] = '\0';attribute((packed)) 是 GCC 扩展，告诉编译器不要在 length 后面补零对齐，保证结构体的 pai 布局就是网络上的字节布局。htonl/ntohl 用于 4 字节整数的字节序转换。这个方案很朴素，但它解决了一个核心问题：收方知道什么时候一条消息端到端完整了。你把这段代码写进大作业，再配一句“长度头让 TCP 的字节流变成有边界的消息流”，老师很难挑出毛病。
头部塞的字段可以不止长度：加一个 type 位表示消息种类，加一个 seq 位做序列号，就变成像 HTTP/1.1 那样的简单应用协议了。大作业如果想拔高，把 length 换成“4 字节魔数 + 4 字节长度 + 负载”，能有效抵抗偶发的字节错位，但这个入门版足够应付课设了。
4.2 为什么不要用 send 后立刻 sleep 的方式换边界
很多学生选择“每次 send 后 usleep(1000)”来避免粘包，原理是想让内核把两段数据分成两个段发送。这是一个典型的“能跑但错”的方案。第一，sleep 不能保证 TCP 分段，Nagle 算法和内核缓冲区策略决定了数据可能合并，sleep 只是降低了合并概率。第二，sleep 让程序吞吐量急剧下降，老师如果写个测试脚本跑一万条消息，你的程序会比长度头版慢一个数量级。
正确的思路永远是：用协议把自己的数据包装成有边界的形式，接收端用状态机或分段解析来还原消息。TCP_NODELAY 选项可以关闭 Nagle 算法，让每个 send 尽量独立发送，但它依旧不能替代显式的分帧，只是让延迟更小而已。
4.3 缓冲区开多大：1KB 和 64KB 不是拍脑袋定的
服务端和客户端各自维护一个应用层缓冲区。初学者喜欢开 1024 字节，但如果你要传输文件或长文本，1024 意味着非常多轮 recv/send 循环，每次循环都有系统调用开销。我一般会把接收缓冲区开成 4096 或 8192，配合 recv_all 循环。更讲究的做法是动态扩容：recv 时发现 buffer 不够，用 realloc 翻倍并继续。但是课设场景里，直接把栈上缓冲开到 4096 或 8192 是最务实的。
注意一点：应用层缓冲区的大小和内核 TCP 接收缓冲区无关。内核有接收窗口，recv 拿走的只是应用层读走的量。如果你不 recv，内核窗口被填满后，TCP 会通过窗口更新机制让对端停止发送，这就是背压。理解这个之后，你就明白单一的 recv 不足以支撑高吞吐，必须 recv 完立刻处理或转存。
5. TCP 大作业的避坑手册：三次踩坑记录，从现象到根治
这部分写给想安安稳稳完成课设、又要扛住答辩追问的同学。下面三条都是我见过的高频事故，每一条都给出现象、原因、解决方式。把这些写进报告，比贴大段注释更显诚意。
5.1 服务端重启时 bind 报 Address already in use
现象：程序刚退出就立刻重新启动，bind() 返回 -1，perror 打印 Address already in use。原因：服务端主动 close，连接进入 TIME_WAIT 状态，默认要等 2MSL（大约 60 秒）才完全消失。期间端口被占用，新进程绑定同一个端口时被拒。解决：给服务端套接字加 SO_REUSEADDR 选项，放在 bind() 之前执行。我平时写代码会把这个选项默认加上，不允许跳过——因为大多数时候我们想快速重启调试。如果你在内网环境里做课设，还可以考虑设置 SO_REUSEPORT，但它依赖内核版本，课设里不一定要用。答辩时记得说清楚：SO_REUSEADDR 允许重用处于 TIME_WAIT 状态的本地端口，而不是覆盖一个正在 listen 的端口。
5.2 客户端 send 大块数据时程序被 SIGPIPE 干掉
现象：程序运行到一半，终端输出 “Broken pipe”，进程直接终止，没有打印任何错误消息。原因：对端已经 close，但你还在 send。内核发送 RST 或 FIN 后，write 会触发 SIGPIPE。默认信号处理是终止进程，于是程序静默消失。解决：在 main 里忽略 SIGPIPE，然后完全依赖 send 的返回值判断连接状态。signal(SIGPIPE, SIG_IGN) 之后，send 到已关闭连接会返回 -1 且 errno 为 EPIPE，你就可以按业务逻辑退出或重连。这个改动五行就能完成，但它能救回你很多次演示。完整的做法是给套接字设置 MSG_NOSIGNAL 标志位，即 send(..., MSG_NOSIGNAL)，Linux 下也有同样效果，和全局忽略信号二选一就行。
5.3 粘包导致服务端接收到奇怪的拼接字符串
现象：客户端连续发三条不同消息，服务端只 recv 到一次调用，收到的字符串是三条消息拼接在一起的完整内容。原因：TCP 字节流不分消息边界，应用层没有做长度分帧，接收端收到的是合并后的流。解决：按第四节的做法，服务端先 recv 4 字节长度头，再循环收完整个 payload。注意长度头也要做字节序转换，否则你在 x86 上读到的数字是乱的。调试时可以用 tcpdump 抓包看报文段，或打印每次 recv 的字节数——我发现新同学最喜欢怀疑“数组越界”或“指针错误”，其实 90% 的粘包问题就是没分帧。
6. 性能调试与扩展：从能跑通到敢演示，差的就是这几个细节
大作业交上去不是终点，老师很可能让你现场改一个参数，或者扩大负载来压一下。下面三个点是我每次做这类实验都会过一遍的，既能让程序稳定，也能在答辩现场多讲两分钟。
我把服务端从单进程串行改成 fork 多进程，每个连接用子进程处理。虽然课设不强制，但老师看到 accept 后 fork，会知道你理解并发连接的真实形态。现代 Linux 下更推荐线程或 epoll，但 fork 是最容易解释的并发模型，适合 C 语言课设。
pid_t pid = fork(); if (pid == 0) { close(server_fd); // 子进程不需要监听 fd handle_client(client_fd); // 业务逻辑 close(client_fd); exit(0); } else { close(client_fd); // 父进程不直接处理数据 }这段代码的关键是 fork 后父子进程各自关闭不需要的描述符。子进程继承 server_fd 和 client_fd，server_fd 只用于监听，子进程留着它没有意义；父进程留着 client_fd 会占用文件描述符且不读写，必须 close。这个细节可以展示你对文件描述符生命周期的理解。当并发量变大时，fork 的开销也会变大，此时可以换成 pthread 创建线程，对端的处理逻辑不变，只是要把 client_fd 传进线程函数。
关于调优，有两个常用方向值得做。一是调整 TCP_NODELAY，在低延迟场景下关闭 Nagle 算法，让每一个 send 都立即发包。用 setsockopt(client_fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag)) 即可。二是调整内核 TCP 缓冲区大小，但我倾向于在代码里尽量用合理的 recv/send 循环，而不依赖系统级调的参，那需要 root 权限而且不好解释。如果你自己学了 tcpdump，可以用如下命令验证报文行为：sudo tcpdump -i lo -nn port 8080 -c 20 观察握手序列和连接关闭的 FIN/ACK 交换。写报告时贴一张抓包截图，课设档次能拔高一个层级。
如果系统里一时没有 tcpdump，也可以用 ss -tanp 查看当前 TCP 连接状态，确认连接确实进入了 ESTABLISHED 而不是 SYN_SENT。我记得自己在课设还拿过 netsh int tcp set global timestamps=enabled 调过 Windows 的 TCP 时间戳选项，用于排查 Windows 上连接被重置的问题——但大作业的程序本身不需要这个，它是系统级网络调优，写进报告容易被认为偏题，我最终只在答辩时当补充知识提了一句。
回到开头那个问题：这个课设值不值得认真做？我的答案是一直值得。不是因为 C 语言有多酷，而是 TCP 的每一次握手、每一个缓冲区，都能在这个作业里被真实地触摸到。本地编译一下这段代码，用两个终端跑起来，输入一段中文，看着服务端原样打印出来，那一刻比任何截图都有说服力。希望这篇笔记能让你少踩两个坑，把这份大作业写成一个能自圆其说的完整工程。
本文还有配套的精品资源，点击获取
