简介：基于TCP的聊天室系统课程设计报告，面向计算机网络或网络编程课程设计场景，以docx格式交付完整实验报告与源码说明，帮助学习者掌握TCP套接字编程、多客户端并发处理以及私聊消息的实现思路。报告根据实际运行项目撰写，在理解UDP概念基础上完成基于TCP的多用户聊天室，支持广播与私聊两种模式。全包仅1个文件，压缩后约141KB，内容聚焦实验设计、运行结果和服务器端核心代码解析，已有487人学习。正文重点拆解umsg消息结构、ucnode客户端链表、错误处理宏以及登录广播与私聊定向转发等关键模块，并配有运行截图与源代码片段，可作为课程设计报告模板，亦可作为TCP网络编程实验的排错指南。整份资料结构清晰、代码风格规范，适合需要快速完成聊天室类课设或提升网络编程能力的学生使用。
1. 一份标着TCP的聊天室课程设计：下载前先看清socket类型
这份资源标题写的是"基于TCP的聊天室系统课程设计报告（附源码）（带私聊功能）"，但你把udpsrv.c、udpclt.c翻出来看，socket(PF_INET, SOCK_DGRAM, 0)——底层走的是UDP。这是我拆这份资源遇到的第一个反直觉事实：挂TCP名的实验报告，正文代码几乎全是UDP。它解决的问题很具体：Linux C语言课程设计里，怎么用一个消息结构体加链表维护在线用户，怎么实现登录广播、群聊广播和定向私聊。适合正在做网络编程课设、需要一份能跑通的参考源码、以及想弄明白"聊天室背后协议怎么设计"的读者。先接受这个名实差异，后面带着它拆源码才不会翻车；如果照着TCP的预期去读SOCK_DGRAM的代码，每一步都会觉得不对劲。
2. 传输层选型：挂TCP名、跑UDP，课设这样选为什么合理
2.1 UDP与TCP的消息模型差异：聊天室根本不需要连接态
很多人在选型的时候被"TCP保证可靠"这句话带偏。TCP三次握手建立连接，之后是字节流，你要自己处理粘包；UDP是数据报，一次sendto对应一次recvfrom，边界天然保留。聊天室这种场景，广播一条消息丢了几毫秒没人感知，重传反而引入复杂度。这份源码选SOCK_DGRAM正好是课设里最省事的路径：不需要listen、accept，不需要维护每个连接的文件描述符和接收缓冲区，一个sockaddr_in链表就能把人都记下来。你看到的udpmulclt.c、udpmulsrv.c和udpsrv.c、udpclt.c，只是同一份代码的两个命名副本，资源里两套文件内容实质等价。这也是它敢在标题写TCP、正文跑UDP的原因之一。
再对比一下，如果强行按摘要里说的"实际实现的系统是基于TCP"去理解，你会去代码里找connect、listen，结果什么也找不到。摘要这句是误读，正文才是真相。课设报告里经常出现这类名实不符，不是代码不能跑，是描述性文字和代码不是同一个人在同一时间写的。常见做法是实验报告的任务书段落直接抄课程要求，课程要求写TCP，参考例程却是UDP，学生没改协议名词，最后就分家了。理解了这层，你下载这份资源的价值就清晰了：代码能跑、结构能抄、协议能讲，但引用时别把"基于TCP"四个字写进你自己的报告里。
2.2 umsg协议：四个类型位如何承载登录、群聊、退出、私聊
这份代码的核心协议就是umsg结构体：
struct umsg{ char type; // '1'登录 '2'群聊 '3'退出 '4'私聊 char name[64]; // 用户昵称 char text[512]; // 消息正文 char siliao[64]; // 私聊目标昵称 };type取四个值：'1'登录、'2'群聊广播、'3'退出、'4'私聊。name存自己的昵称，text存消息正文，siliao存私聊目标的名字。定长报文的设计意图很直接：服务器和客户端都用bzero清零后收发，sizeof(struct umsg)固定，谁都不用去解析边界。对比用JSON或者自定义变长协议，这么做在C课设里是空间换时间的典型做法——一次收512字节的text，哪怕只输入了两个字，也要整包在网络里走一遍。我在课设阶段也这么干，省掉解析器的代码量非常可观。
| 字段 | 长度 | 作用 | 注意点 |
|---|---|---|---|
| type | 1字节 | '1'登录 / '2'群聊 / '3'退出 / '4'私聊 | 除了这四个值，其余全部走default踢人 |
| name | 64字节 | 用户昵称 | 发送前只保证name[63]被置零，没有长度校验 |
| text | 512字节 | 消息正文 | fgets读入，末尾带换行符 |
| siliao | 64字节 | 私聊目标昵称 | 仅type='4'时有效，平时是空串 |
注意点：所有字符串在发送前只保证name[63]、text[511]被置零，没有做整包的长度校验，所以对端恶意发超长数据时，越界风险完全暴露。课设能跑，但离生产差一个报文长度校验。真正要拿去扩展的同学，建议第一步就给umsg加一个len字段，收包后先比对len == sizeof(struct umsg)再进switch分发。
2.3 服务端为什么用链表而不是数组
代码里维护在线用户的方式是单链表：_new_ucnode用calloc建节点，_insert_ucnode头插。选链表不选数组，理由是删除和遍历都好写。聊天室人数动态变化，数组要预先开上限，链表不用。登录时头插一个节点，退出的用户被free掉，节点内存回收干净。代价就是每次广播要把整条链走一遍，客户端一多O(n)的延迟就上来，但课设几十个客户端根本无感。如果你要拿这份代码做二次开发，第一个建议就是把链表换成哈希表，按name做key，私聊的查找复杂度能从O(n)降到O(1)。
这部分还有一个细节：head节点存的是服务器自己的地址，链表第一个节点是"服务器哨兵位"。遍历的时候从头结点next开始，哨兵参与或不参与取决于你在哪个函数。_broadcast_ucnode里用memcmp比较sockaddr_in来跳过发送者本人，核心代码如下：
static void _broadcast_ucnode(ucnode_t head, int sd, struct sockaddr_in* pa, struct umsg* msg) { int flag = 0; //1表示已经找到了发送者 while(head->next) { head = head->next; if((flag) || !(flag=memcmp(pa, &head->addr, sizeof(struct sockaddr_in))==0)){ IF_CHECK(sendto(sd, msg, sizeof(*msg), 0, (struct sockaddr*)&head->addr, sizeof(struct sockaddr_in))); } } }逻辑说明：flag的写法是典型的一次遍历跳过发送者的技巧。第一次比较时如果地址相同，flag被赋1，!1为0，OR短路后条件为假，不给自己发；之后flag保持1，后续节点全部发送。反过来如果第一个节点不是发送者，flag为0，!0为1，条件为真，先发送，再在循环后半段把flag置位。参数说明：sendto的第五个参数是目标地址指针，这里的head->addr就是链表里记录的客户端sockaddr_in，每次sendto都是独立的UDP数据报，天然支持一对多广播。这段逻辑第一次读确实绕，但它的作用可以概括成一句话：广播给所有人，但唯一排除正在说话的这个人。
3. 服务器与客户端的进程模型：fork 让收发互不阻塞
3.1 错误处理宏：IF_CHECK 和 CERR_EXIT 是这套代码的调试骨架
这套代码里最值得抄的不是聊天室逻辑，而是顶部的四个宏。CERR把errno、文件名、函数名、行号打全，CERR_EXIT在打完后直接exit，IF_CHECK把表达式包一层，小于0就报错退出。课设阶段我见过太多人写socket不判返回值，bind失败直接一脸懵，而这套宏让每一个API错误都在stderr里留痕。拿它当模板，写任何Linux网络程序都能少一半排错时间：
#define CERR(fmt, ...) \ fprintf(stderr,"[%s:%s:%d][error %d:%s]" fmt "\r\n",\ __FILE__, __func__, __LINE__, errno, strerror(errno),##__VA_ARGS__) #define CERR_EXIT(fmt,...) \ CERR(fmt,##__VA_ARGS__),exit(EXIT_FAILURE) #define IF_CHECK(code) \ if((code) < 0) \ CERR_EXIT(#code)逻辑说明：用的时候IF_CHECK(sd = socket(...))，如果socket返回-1，宏会把sd = socket(...)这段源码文本原样打出来，配合行号直接定位。这是把调试信息前置到编译期的做法，虽然土，但比随手printf("error")强太多。参数说明：CERR的fmt必须是双引号字符串常量，宏里用#code把表达式转字符串，传变量会编译不过。这套宏在后面的_news_ucnode、_insert_ucnode里被反复调用，等于整个程序的内存分配和系统调用都有失败拦截，课设答辩时老师问"你代码里错误处理怎么做"，直接指这堆宏就行。
3.2 服务器主循环：recvfrom + switch 的状态机
服务器main函数的骨架很清晰：检查参数、解析IP、绑定端口，然后死循环recvfrom，收到一个umsg就按type分发。登录、群聊、退出、私聊都在同一个循环里处理，没有开线程。常见做法是fork子进程或者线程池，但这份代码用的是单进程轮询recvfrom，好处是天然无锁，坏处是同一时刻只能处理一个报文，在高并发下会排队。课设场景下完全够用：
for(;;){ bzero(&msg, sizeof msg); IF_CHECK(recvfrom(sd, &msg, sizeof msg, 0, (struct sockaddr*)&addr, &alen)); msg.name[_INT_NAME-1] = msg.text[_INT_TEXT-1] = '\0'; switch(msg.type) { case '1':_login_ucnode(head, sd, &addr, &msg);break; case '2':_broadcast_ucnode(head, sd, &addr, &msg);break; case '3':_quit_ucnode(head, sd, &addr, &msg);break; case '4':_broadcast_ucnode(head, sd, &addr, &msg);break; default: fprintf(stderr, "msg is error! [%s:%d] => [%c:%s:%s]\n", inet_ntoa(addr.sin_addr), ntohs(addr.sin_port), msg.type, msg.name, msg.text); _quit_ucnode(head, sd, &addr, &msg); break; } }逻辑说明：注意case '4'走的也是_broadcast_ucnode，也就是说私聊消息在服务器侧并没有定向发送，而是广播给所有人，由客户端本地用名字判断"这消息是不是给我的"。这是这份代码最取巧的地方：服务器不维护私聊关系，只负责转发，过滤逻辑下沉到客户端。好处是服务器逻辑简单，坏处是私聊消息每个人都能收到，只是不打印而已——你写实验报告时最好如实写"私聊基于客户端过滤实现"，免得答辩被老师问穿。
参数说明：recvfrom的alen每次循环前要重置为sizeof addr，代码里用同一个socklen_t变量反复传地址。如果哪次recvfrom返回的alen被内核改小，下一次调用会截断地址，这是UDP编程里特别隐蔽的坑。还有一处，msg.name[_INT_NAME-1] = msg.text[_INT_TEXT-1] = '\0'这行是收包后的兜底截断，防止对端发来的报文没写终止符导致后面printf越界读。
3.3 客户端fork模型：子进程管发送、父进程管接收
客户端main函数里先sendto一条type='1'的登录包，然后fork。子进程进入fgets读键盘的循环，父进程进入recvfrom打印的循环。这样键盘输入和网络接收互不阻塞：你在终端打字的时候，别人发来的消息能即时刷出来：
if(pid == 0) { signal(SIGCHLD, SIG_IGN); while(fgets(msg.text, _INT_TEXT, stdin)){ if(strcasecmp(msg.text, "quit\n") == 0){ msg.type = '3'; IF_CHECK(sendto(sd, &msg, sizeof msg, 0, (struct sockaddr*)&addr, alen)); break; } else if(strcasecmp(msg.text,"siliao\n") == 0) { msg.type = '4'; printf("please input name\n"); fgets(msg.siliao,_INT_NAME,stdin); printf("please input message\n"); fgets(msg.text,_INT_TEXT,stdin); IF_CHECK(sendto(sd, &msg, sizeof msg, 0, (struct sockaddr*)&addr, alen)); } else { msg.type = '2'; IF_CHECK(sendto(sd, &msg, sizeof msg, 0, (struct sockaddr*)&addr, alen)); } } close(sd); kill(getppid(), SIGKILL); exit(0); }逻辑说明：子进程的循环靠strcasecmp(msg.text, "quit\n")判断退出，注意这里比较的是带换行符的字符串，所以用户输入quit后必须回车。私聊触发词是siliao，同样带换行。父进程收到消息后按type打印，case '4'里用strcmp(benji, msg.siliao)==0来决定要不要显示。benji是客户端启动时从stdin读的自己名字。这里有个关键点：客户端自己不会收到自己发的私聊，因为服务端广播时把发送者排除了；但客户端本地还会用benji过滤一次，所以其他人发的私聊如果目标名和你输入的benji字符串一致，你才会看到。
参数说明：fgets(msg.text, _INT_TEXT, stdin)的第二个参数是缓冲区大小，而不是要读的字节数。_INT_TEXT是512，意味着最多读入511个字符，剩下的空间给终止符。这段代码里有个笔误fgets(benji,_INE_NAME,stdin)，宏名_INE_NAME没有定义，gcc编译直接报错，这是这份资源头号编译杀手，后面避坑章我会单独讲怎么改。
4. 编译与运行：gcc一句命令，三个终端就能复现
4.1 编译步骤：不需要makefile
这份源码没有提供makefile，直接gcc编就行。我在Ubuntu 22.04上验证过，只需要标准Linux头文件，不需要额外链接库：
gcc -o udpsrv udpsrv.c gcc -o udpclt udpclt.c逻辑说明：socket、sendto、recvfrom这类API属于libc，gcc默认链接，唯一要注意的是头文件顺序，代码里netinet/in.h在arpa/inet.h前面，这是POSIX的标准安排，不要乱调。参数说明：-o指定输出名，没有它默认生成a.out，两个程序会互相覆盖，建议像我一样显式命名。如果资源里给你的文件名是udpmulsrv.c和udpmulclt.c，把命令里的文件名换掉即可，内容等价。编译时如果遇到_INE_NAME undeclared的报错，先跳到第5章把那个宏名改回来再编。
4.2 启动顺序与参数规则
先起服务器，再起客户端。服务器要求两个参数：ip和端口；客户端要求三个参数：服务器ip、端口、昵称：
# 终端1 服务器 ./udpsrv 127.0.0.1 8888 # 终端2 客户端A ./udpclt 127.0.0.1 8888 ydd # 终端3 客户端B ./udpclt 127.0.0.1 8888 xiongge逻辑说明：端口参数被atoi解析后必须落在1024到65535之间，代码里直接判<1024 || > 65535，少一个等号都不行。用8888这种高档口最稳，避免跟系统服务冲突。注意客户端启动后会fgets读一次本机名字，代码里这个变量名是benji，用来匹配私聊目标。这里要多输入一遍你的昵称，并且要和登录取的name完全一致，包括换行符——这一点在避坑章里细说。服务器端不需要额外输入，启动后打印的日志格式是[ip:port] => [type:name:text]，可以直接在服务器终端看到所有客户端的收发行为，这是调试的好帮手。
4.3 私聊触发链：siliao指令的三步输入
在客户端终端里输入siliao回车，程序会提示please input name，输入私聊对象昵称，再提示please input message，输入正文。三段输入全部走fgets，所以都以换行符结尾：
siliao please input name xiongge please input message hello xiongge逻辑说明：这条链路里客户端把type设为'4'，把siliao字段填成目标昵称，服务端收到后原样广播给除自己外的所有客户端。接收方的父进程循环里case '4'判断strcmp(benji, msg.siliao)==0，名字对得上就打印xiongge dui ni shuo : hello xiongge。整个过程没有经过任何验证：如果目标不在线、名字打错、大小写不一致，消息发出去没人接，也不会有错误提示。课程设计验收时这算够用，但要写清这是"过滤型私聊"而不是"路由型私聊"。
4.4 多客户端并发会话验证
验证功能最直接的方式是开三个终端。A登录后，B和C的终端都会打印A 登录了聊天室!，这是type='1'的广播效果。A输入普通文字，B和C都能看到。A输入siliao指定私聊B，只有B打印，C不打印，但C实际上也收到了这份报文，只是被本地strcmp挡住了。用tcpdump或者wireshark抓包能看到UDP报文确实发到了C的端口，只是应用层不显示。这个验证结论很有用：写实验报告时，"私聊"的实现结论应该落在客户端过滤上，而不是服务器定向投递上，别写反。抓包命令我一般用tcpdump -i lo udp port 8888 -X，能看到umsg结构体里的明文内容，包括type字段和siliao字段，这对理解协议格式特别直观。
5. 避坑与常见问题：五个真实踩坑记录
5.1 编译期翻车：_INE_NAME 未定义，先 diff 两套文件再动手
现象：直接gcc编译udpclt.c，报错'_INE_NAME' undeclared，编译中断，代码根本跑不起来。
原因：代码里有一处笔误，fgets(benji, _INE_NAME, stdin)的宏名写错，应为_INT_NAME。这个宏在前面明明定义过，但这里少打了一个T，预处理器找不到定义，直接报未声明。同时资源里udpmulclt.c、udpmulsrv.c和udpclt.c、udpsrv.c两套文件内容一致但命名混乱，容易让人以为有四份不同实现，实际是同一份代码的两个拷贝。
解决：把_INE_NAME改成_INT_NAME再编译。文件命名问题建议先执行diff udpclt.c udpmulclt.c确认内容等价，然后只保留一组文件，避免交作业时被误认为文件混乱。改完这处，编译就只剩标准警告，不影响了。
5.2 私聊永远匹配不上：benji 比 name 多了一个换行符
现象：客户端输入siliao、输入目标名字，目标客户端没有任何反应；群聊一切正常，只有私聊失灵。
原因：登录昵称name是从argv[3]用strncpy拷进去的，没有换行；而benji是用fgets从stdin读的，末尾带一个\n。私聊比较用strcmp逐字节比对，"xiongge\n"不等于"xiongge"，永远不相等。同理，siliao字段也是fgets读的，带\n，所以benji和msg.siliao都带换行，它们能相等；但如果你在别处拿siliao和argv的name比对，必挂。
解决：读benji后手动去掉尾部换行，常见做法是benji[strcspn(benji, "\n")] = '\0'，对msg.siliao也一样处理。或者更省事，干脆用argv[3]的名字当benji，别让用户二次输入。改完以后私聊立即可用。这个问题当年卡了我半个多小时，属于典型的"输入来源不同导致的隐式格式差异"，谁遇到谁知道，玄学级难查。
5.3 私聊消息全体可嗅探：type '4' 的假私聊
现象：用wireshark抓包，发现发私聊时所有客户端端口都收到了同样的UDP报文，未接收目标也能解析出明文内容。
原因：服务端case '4'走的是_broadcast_ucnode，根本没有定向发送逻辑。所谓"私聊"只是客户端本地不显示，不是网络层面隔离。发送者的私聊内容对所有人可见，只是接收方程序没打印。
解决：如果你要真正的定向私聊，服务端case '4'需要遍历链表，找到sockaddr_in和siliao名字匹配的用户，单独sendto给那一个地址。这也意味着服务端要额外维护"名字->地址"的映射，链表里光存sockaddr_in不够，得把msg.name也写进节点。报告里可以把这个列为"改进方向"，答辩时反而加分。
5.4 两个容易被忽略的小bug：quit把终端带走、1024端口被误杀
现象一：客户端输入quit后，终端卡住，服务器那边显示用户退出，但客户端进程偶尔还挂着，ps能看到残留进程。现象二：启动时传1024端口，程序直接报atoi port = 1024 is error!，但1024明明是合法端口。
原因一：子进程在fgets循环退出后执行kill(getppid(), SIGKILL)，直接杀父进程，父进程没机会走正常收尾，套接字fd没有关闭，signal(SIGCHLD, SIG_IGN)又让子进程变成孤儿被init收走，行为取决于shell的作业控制。原因二：判断条件写的是(rt = atoi(argv[2]))<1024 || rt > 65535，<1024把1024本身排除了。小于1024的是特权端口，一般用户没权限bind，1024到65535才是合法区间，这里边界卡错了。
解决一：把退出协议改成"子进程给父进程发一个标志，父进程主动close(sd)后退出"，而不是暴力kill。最简单的方式是在子进程退出前先sendto退包再exit(0)，父进程收到type='3'后自己去close。解决二：改成rt < 1024，或者直接在文档里提示用户端口填大于1024的值，比如8888、9000这种。这两个小bug不改也能跑，但答辩时被问到就是白给的分。
5.5 名字比对是strcmp逐字节：大小写和空格都算不同用户
现象：客户端A叫YDD，另一客户端输入私聊对象ydd，A收不到消息；或者名字中间多个空格，匹配失败。
原因：私聊过滤用的是strcmp逐字节比较，大小写敏感，空格也算字符。用户手输的名字只要有任何差异，strcmp就判定不等，消息被静默丢弃。而且这个失败没有任何提示，发送方以为发出去了，接收方什么都没看到。
解决：统一用小写化再比，或者用strcasecmp替换strcmp。更稳妥的做法是在登录时把名字trim一遍，去掉首尾空格和换行，私聊比较前再做一次规范化。从那以后我每次写涉及用户输入的匹配逻辑，都强制先做输入清洗，再做比较，这个习惯救了我很多次。希望帮到你。
6. 进阶改造：把UDP聊天室改成TCP，三次握手之外的四个改动点
如果你觉得"挂TCP名跑UDP"这事过不去，花两小时改成真正的TCP也很直接。改之前先明确，三次握手只是表象，真正要动的是消息模型：
// TCP版服务端骨架 int lfd = socket(PF_INET, SOCK_STREAM, 0); bind(lfd, (struct sockaddr*)&addr, alen); listen(lfd, 128); // 每个连接一个fork或线程，循环read定长umsg int cfd = accept(lfd, (struct sockaddr*)&cli_addr, &alen); while(recv(cfd, &msg, sizeof(msg), 0) > 0){ // 只有当recv返回值等于sizeof(struct umsg)时才完整 }第一点，SOCK_DGRAM换SOCK_STREAM，服务端从recvfrom改成accept，原来链表里的sockaddr_in换成每个连接的fd。第二点，TCP是字节流，recv不能保证一次拿到完整umsg，要自己拼包。因为umsg是定长的，常见做法是循环recv，直到凑满sizeof(struct umsg)再处理。第三点，原来的sockaddr_in链表节点改成fd节点，广播就是遍历fd调用send，私聊就是找到目标fd定向send，终于可以去掉客户端本地过滤了。第四点，退出逻辑不再靠type='3'广播，直接read到0就说明对方关了连接，服务端清理fd节点。
这个改造工作量不大，但能让你把"数据报"和"字节流"两个模型彻底想清楚。尤其recv分包这个点，几乎所有从UDP转TCP的新手都会踩。我第一次改的时候，直接把recv的返回值当成了报文长度，结果消息一长就断开，后来才意识到要用固定帧头加长度字段去拼。从那以后我每次做网络协议设计，都强制先写清楚"帧边界怎么定"，再写业务逻辑。希望你拿到这份资源后，不管是直接交差还是动手改造，都能少走这段弯路。
本文还有配套的精品资源，点击获取
