简介面向计算机网络编程入门者这份rar压缩包以C语言完整实现了一个基于TCP协议的多人聊天室能够支撑课程设计、实验报告或毕业设计前期调研。项目按服务端、客户端与入口模块拆分为3个C源文件搭配公共头文件与makefile构建脚本清晰演示了TCP三次握手、用户登录验证、服务端统一转发与多客户端并发管理服务端维护在线用户列表客户端登录后持续监听消息形成了典型的C/S交互模型。txt说明文件则对运行流程和关键代码做了整理降低了自学门槛。压缩包共8个文件整体仅7KB身形小巧却覆盖了socket编程的主要脉络已有96人浏览学习。通过阅读源码与说明读者可以掌握从连接建立、消息广播到数据封装的完整链路并在此基础上扩展心跳检测、离线消息存储或SSL加密等进阶功能是快速理解TCP实际应用的轻量素材。1. tcp.rar 里那类 TCP 登录聊天室最容易被低估的是登录协议看到 tcp.rar 这种名字的资源包先别急着解压跑起来——它背后大概率是一个带“登录”功能的 TCP 多人聊天室项目。这类项目我见过不少人拿来做网络编程练手最容易翻车的地方反而不是并发、不是广播而是登录。两个人测试时随手输入昵称、密码就进去了人一多就重名冲突、消息错位、某些客户端完全收不到消息。根本原因多半是把登录当成一次 input 加一次 sendall没把它当成一个完整协议来设计。这篇文章围绕登录协议、线程模型、客户端读写、上线避坑这几个点把一套能支撑几十人局域网同时聊天的实现讲透。适合正在做课程设计、要搭局域网小工具、或者第一次接触 TCP socket 编程的读者——照着写能跑跑起来知道下一步改哪里。2. 设计登录报文为什么三次握手之后还要一个“登录握手”2.1 三次握手只证明了“能通”没证明“你是谁”TCP 三次握手建好连接服务端只知道“有个人连上来了”不知道他是谁。聊天室所有后续动作——消息归属、私聊、踢人、下线通知——都依赖“这条连接对应哪个用户”所以必须在 TCP 连接之上再定义一层登录握手。常见的做法是客户端连上来后第一件事必须发一个登录报文服务端校验通过前不收其他业务消息。从 tcp.rar 这类资源包里看到的聊天室项目多数问题就出在这层被省略了。拿最基础的场景说用户 A 输入昵称“小明”回车客户端直接把“小明大家好”发出去服务端收到后随便从字符串里拆出名字。这种方案看似简单但一旦有人把“小明大家好有人吗”当昵称消息解析就全乱了。更常见的隐患是消息边界TCP 协议栈不保证一次 recv 正好拿到一条完整消息它只保证字节顺序。没有严格报文格式登录和聊天全在赌“这次运气好”。一个可靠的登录握手应当由三部分组成明确定义的报文格式、服务端返回的状态码、客户端状态切换逻辑。这套东西看起来比“一行 sendall”复杂但它是后面所有功能的地基。地基不打牢广播、踢人、断线重连都会跟着出连锁问题。下面先定报文格式。2.2 把登录包拆成“41N”三段式长度、类型、内容我做这种小规模聊天室项目最常用的是固定 4 字节大端长度、1 字节类型、N 字节内容的报文组合。接收方先读 4 字节拿到长度再按长度读正文正文里放 UTF-8 编码的字符串。长度字段只统计 payload 的字节数不包含包头本身这样两边都好算。import struct MSG_LOGIN 1 # 客户端 - 服务端登录请求 MSG_LOGIN_RESP 2 # 服务端 - 客户端登录结果 MSG_CHAT 3 # 双向聊天消息 def pack_message(msg_type: int, payload: bytes) - bytes: # !I 表示网络字节序的无符号 4 字节整数 # 长度字段只统计 payload不算类型字节 return struct.pack(!I, len(payload)) bytes([msg_type]) payload def recv_exactly(sock, n: int) - bytes: buf b while len(buf) n: chunk sock.recv(n - len(buf)) if not chunk: raise ConnectionError(对端关闭了连接) buf chunk return buf def recv_message(sock): header recv_exactly(sock, 5) length struct.unpack(!I, header[:4])[0] if length 1024 * 1024: raise ConnectionError(报文长度超出限制) msg_type header[4] payload recv_exactly(sock, length) return msg_type, payload代码逻辑并不复杂关键在 recv_exactly 这个循环。TCP 是字节流recv(5) 可能只返回 3 个字节另外 2 个字节还在路上必须循环读够为止。很多聊天室登录偶发失败就是因为把一次 recv 当成了完整报文。struct.pack 里用!I是网络字节序标准写法两端都这样做以后换语言也容易对齐。长度上限要加。我遇到过客户端发了个超大昵称把服务端内存吃满的情况虽然聊天室规模小但 1MB 上限能拦住最常见的误操作。这里顺带说一句TCP 不负责帮你分消息包格式是自己定的所以后面所有收发都要走 pack_message / recv_message 这对函数不要直接 sendall 字符串。2.3 服务端校验的三个语义非空、唯一、密码对登录请求的 payload 我用昵称|密码这种分隔格式服务端收到后拆开依次做三轮校验昵称非空、昵称没被占用、密码正确。返回码用 200 表示成功其他为失败。返回码设计成数字客户端才好做分支不要只返回“成功”或“失败”两个词。def handle_login(conn, username, password, clients, lock): username username.strip() if not username: return 101, 昵称不能为空 if len(username.encode(utf-8)) 20: return 102, 昵称不能超过 20 字节 if not password: return 105, 密码不能为空 with lock: if username in clients.values(): return 103, 昵称已被占用 if password ! 123456: return 104, 密码错误 with lock: clients[conn] username return 200, f欢迎加入聊天室, {username}注意这段里锁只包住字典读写的瞬间密码校验放在锁外。很多人一上来直接把整个函数塞进锁里登录高峰期所有客户端排队等校验完全没必要。昵称唯一性判断的是 clients.values()它存的是每个连接对应的用户名如果以后要做多开同一个用户名允许两个客户端在线这里就得改成计数结构。用户名做 strip 也很重要。客户端输入 小明 和小明如果被当成两个人聊天室里就会出现两个看着几乎一样的昵称排查起来非常费劲。密码为什么允许空串但登录时校验我的经验是空密码容易误触不如明着告诉用户。2.4 登录成功后才放行聊天用连接状态拦住非法消息服务端按连接维护登录状态。这里有个常见的黑匣子说法TCP 连接存活着不代表对方已经通过了登录校验。一个没登录的客户端连上来就狂发聊天消息服务端不该把消息广播出去。维护方式很简单用两个集合pending_connections表示已连上但未登录clients表示完成登录的。def handle_client(conn, addr, clients, pending, lock): conn.settimeout(10) try: msg_type, payload recv_message(conn) if msg_type ! MSG_LOGIN: conn.close() return username, password payload.decode(utf-8).split(|, 1) code, text handle_login(conn, username, password, clients, lock) resp pack_message(MSG_LOGIN_RESP, f{code}:{text}.encode(utf-8)) conn.sendall(resp) if code ! 200: conn.close() return broadcast(f[系统] {username} 加入了聊天室, senderNone, clientsclients, locklock) while True: msg_type, payload recv_message(conn) if msg_type ! MSG_CHAT: continue text payload.decode(utf-8) if text #quit: break broadcast(f{username}: {text}, senderconn, clientsclients, locklock) except (ConnectionError, socket.timeout): pass finally: with lock: pending.discard(conn) if conn in clients: clients.pop(conn) broadcast(f[系统] {username} 离开了聊天室, senderconn, clientsclients, locklock) conn.close()这段代码把登录失败直接断开连接登录成功的客户端才进入聊天消息循环业务逻辑上没有太多需要解释的地方。唯一要注意的是 conn.settimeout(10)给登录阶段加 10 秒超时防止有人连上来后一直不发登录包白白占用线程。settimeout 放在收第一条消息前登录成功之后最好调回 None否则聊天过程中长时间没人说话服务端 recv 会超时把正常连接断开。服务端“只认连接不认人”的设计还有一个好处广播时不需要频繁把用户名带在每条消息里反复校验。用户名只在登录时确认一次登录后的消息默认可信。如果你做的是需要审计的场景可以在服务端把用户名持久化到一个 dict 里而不是每次都透传。3. 服务端线程模型与广播机制从 accept 到广播别卡在锁上3.1 选型为什么这个规模用多线程而不是 select多人聊天室的服务端要同时受理多个连接常见的三种方案是阻塞 socket 加多线程、select/poll 事件循环、异步框架。对于 50 人以内的局域网聊天室我一般直接用多线程。select 在连接数少时反而麻烦——每次循环都得重新扫描 fd 集合业务逻辑被“可读/可写”事件切成碎片。多线程模型下每个连接有一个独立线程代码写起来像处理单个客户端调试也直观。选型还要考虑一个点聊天室天然是 IO 密集而不是计算密集。广播一条消息给 50 个人大部分时间是耗在 socket 发送等待上多线程在线程切换上的开销可接受。当然如果目标是上万人同时在线的公网聊天室当然要换成事件循环。但那类场景已经超出 tcp.rar 这种小型项目的范畴没必要用杀鸡的牛刀。还有一种方案是 select 加非阻塞 socket好处是不依赖操作系统的线程调度但坏处是每个连接都要维护发送缓冲队列消息没发完得记下“还有多少字节没写”代码量直接翻一倍。做课程设计或内部工具优先选择可读性强的多线程模型未来如果真要撑大规模再把收发层替换成 asyncio 或者 epoll业务协议不变。3.2 服务端骨架accept 循环、处理线程、广播函数服务端主流程是一个无限循环accept 到新连接后立刻开一个 daemon 线程去处理。daemon 线程设为 True是为防止客户端异常断开时线程堆积——具体原因放第 5 章细讲。广播函数的要点是持锁时间要短只做快照复制发送动作放到锁外。import socket, threading def serve_forever(host, port): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) # SO_REUSEADDR 允许 TIME_WAIT 状态的端口被重新绑定 server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((host, port)) server.listen(16) print(f服务端已启动: {host}:{port}) while True: conn, addr server.accept() threading.Thread(targethandle_client, args(conn, addr, clients, pending, lock), daemonTrue).start() def broadcast(text, sender, clients, lock): msg pack_message(MSG_CHAT, text.encode(utf-8)) with lock: snapshot list(clients.keys()) for conn in snapshot: if conn is sender: continue try: conn.sendall(msg) except OSError: passsocket.listen(16) 里的 16 是连接队列长度超过这个数的握手请求会被内核排队不代表最多只支持 16 个客户端。accept 循环本身是阻塞的新连接到了才会返回所以这个数是内核帮你缓冲待处理连接的深度不是并发上限。clients 字典的 key 是 socket 对象。用 socket 做 key 的好处是广播遍历和下线清理都方便缺点是字典的可读性差一点调试时想看到底是谁占着这个连接还得反向查值。不过在这个规模下问题不大。clients 和 pending 这两个集合共享一把 lock广播函数里先拿锁复制快照再放锁发送就是不想让一个慢客户端拖住整个字典。snapshot 复制为什么必须做假设广播时某个客户端接收很慢sendall 阻塞了十几秒这期间其他线程想登录、下线都得抢同一把锁。如果发送动作在锁内等于所有人陪着一个卡顿的客户端等待。复制快照后锁只保护字典本身发送失败最多丢一条消息不影响全局。3.3 登录超时与下线清理finally 里把连接状态抹干净下线清理是最容易被忽略的环节。客户端点关闭窗口TCP 会发 FIN 包服务端 recv 返回空字节触发 ConnectionError但如果是客户端断电、网络断开服务端可能要等到 TCP 重传超时才能感知。所以清理动作必须不管什么异常都要执行写进 finally。dead_connections [] def cleanup_conn(conn): with lock: clients.pop(conn, None) pending.discard(conn) try: conn.close() except OSError: pass用户下线时广播一条系统消息需要用到用户名。我的习惯是在 handle_client 最前面定义username None登录成功后再赋值finally 里判断它是否为 None避免异常发生在登录前导致消息广播一个空名字。这里有个隐藏细节下线广播如果发给已经断开的客户端sendall 会抛 OSErrorbroadcast 里已经用 except OSError 兜住了不会让清理线程崩溃。还有一类“半开连接”问题。客户端程序卡死不主动发 FIN服务端 recv 永远阻塞着这类连接占着线程资源。常见做法是服务端每隔一段时间做心跳。简单方案是在每条聊天消息中记录最后活跃时间另一个线程每分钟扫一遍清掉超过 3 分钟没动静的连接。心跳不做太复杂定时扫描就够了别为此引入一堆额外协议。4. 客户端登录与读写双线程把“登陆”做成正经的“登录”4.1 客户端登录三步连接、发包、等返回码客户端登录流程很固定先建 TCP 连接再发登录报文然后等服务端返回码。很多人忽略最后一步发完包立刻进入聊天循环服务端还没来得及返回失败就开聊等发现没登录成功时消息已经丢了好几条。def login(host, port, username, password): # create_connection 自带重试和超时比裸 socket 稳 sock socket.create_connection((host, port), timeout5) payload f{username}|{password}.encode(utf-8) sock.sendall(pack_message(MSG_LOGIN, payload)) msg_type, payload recv_message(sock) if msg_type ! MSG_LOGIN_RESP: sock.close() raise RuntimeError(服务端没有返回登录结果) code, text payload.decode(utf-8).split(:, 1) return sock, int(code), textsocket.create_connection 和 socket() 有什么区别create_connection 内部帮你处理了地址解析和多地址尝试还支持 timeout 参数连接失败时直接抛异常裸 socket 的 connect 在连接失败时容易卡住初学者很容易踩到。聊天室这种低并发场景用 create_connection 足够。登录成功后服务端返回码是 200客户端继续往下走不是 200 就打印失败原因并重试。失败原因由服务端给出文本客户端只负责展示。把业务文案放在服务端客户端逻辑就只剩数字分支后面调整提示语不用改客户端。4.2 收发分离主线程管 input子线程管 recv客户端必须两个线程主线程循环 input 读用户输入子线程循环 recv_message 等服务器消息。如果只有一个线程User 输入时收不到别人消息聊天体验完全不可用。input 是阻塞式函数这个阻塞不会给子线程让路所以子线程必须独立存在。def receive_loop(sock): while True: try: msg_type, payload recv_message(sock) if msg_type MSG_CHAT: print(payload.decode(utf-8)) except ConnectionError: print(连接已断开, 按回车退出) break def send_loop(sock): while True: text input() if text #quit: try: sock.sendall(pack_message(MSG_CHAT, b#quit)) except OSError: pass break if text.strip(): sock.sendall(pack_message(MSG_CHAT, text.encode(utf-8))) def chat(sock): threading.Thread(targetreceive_loop, args(sock,), daemonTrue).start() send_loop(sock) sock.close()receive_loop 里只捕获 ConnectionError这个异常来自 recv_exactly 中对空字节的判断也就是服务端主动关了连接。如果服务端正常踢人或者下线客户端会立刻感知。text.strip() 的判断是为了防止输入一串空格被当消息发出去这种误操作在聊天室里特别常见。关闭连接的姿势也有细节。最稳妥的做法是客户端输入 #quit 后主动发送退出标记等 200ms 给服务端一点处理时间再 close。如果直接 closeTCP 会发 FIN服务端那边的 recv 返回空字节也能感知但广播下线消息时可能连接已经被操作系统回收。这个小延迟能显著减少“某某离开了聊天室”偶尔不生效的问题具体做法是在发完 #quit 后加一个time.sleep(0.2)。4.3 登录细节昵称 trim、密码空串、失败重试标题里写的“登陆”正规说法是“登录”。客户端拿到用户输入时第一件事是去除首尾空白。很多人直接拿 input 原始值发出去换行符、空格全带上了服务端明明已经做 strip但客户端输入框的回车符还是会被某些终端混进字符串里。客户端这样处理服务端那层校验就只是兜底了。def read_credentials(): username input(昵称: ).strip()[:20] password input(密码: ).strip() return username, password def login_with_retry(host, port): while True: username, password read_credentials() try: sock, code, text login(host, port, username, password) except (ConnectionRefusedError, socket.timeout) as e: print(f连接失败: {e}) continue if code ! 200: print(f登录不成功({code}): {text}) continue print(text) return sock注意这里把连接失败和登录失败分开处理连接失败说明服务器没起来或网络不通也会提示后让用户重试。登录失败中的昵称占用、密码错误都是业务语义直接返回给用户重输。一个容易被忽略的边界是用户名里有|符号服务端协议里用|当分隔符如果用户昵称里含有|payload 拆分就会出错。比如昵称a|b拆出来密码变成了b|123456。所以协议里最好约定昵称不允许包含|客户端输入时校验服务端也校验一遍。登录成功后的返回文本里带了欢迎语客户端直接打印就行。这套带重试的登录循环是聊天室体验的底线用户登录失败不应该退出程序而是回到输入昵称的步骤。很多 tcp.rar 里的实现是一失败就 exit体验很差。5. 避开这五个坑多人聊天室才敢叫“多人”排查与修复记录5.1 一人网卡全员陪跑广播慢客户端阻塞现象某个客户端画面卡住不动其他所有人的消息发送都明显变慢甚至完全没反应。 原因广播函数里 sendall 在锁内执行。一个客户端接收慢sendall 长时间阻塞这把锁被占用其它线程的登录、下线操作全在排队等锁。 解决把 sendall 挪到锁外先 with lock 复制客户端列表快照释放锁后再逐个发送。快照里的连接可能在发送过程中已经失效OSError 直接忽略。更进一步可以为每个连接设置发送超时conn.settimeout(1)超过一秒的慢客户端直接踢掉。5.2 粘包半包是登录偶发失败的头号元凶现象客户端登录时偶发struct.error: unpack requires a buffer of exactly 4 bytes或者服务端收到一串乱码。 原因TCP 是字节流不是消息队列。客户端两次 sendall 的报文可能被内核合并成一次发送服务端 recv 一次读到了两条消息反过来一条长消息也可能分多次到达。直接拿 recv 的返回值当完整报文解析必然崩。 解决必须做“读够长度”的循环也就是前面写的 recv_exactly。先精确读 4 字节长度再按长度读正文。读取长度时同样要循环因为 4 字节也可能被拆开。这个函数写好后一劳永逸——如果引入半包问题说明这中间还有路径绕过了 recv_message。5.3 客户端强退后服务端线程堆积daemon 与 finally 全要现象用任务管理器强杀客户端服务端进程的线程数只增不减运行一天后内存飙高。 原因客户端没发 FIN服务端 recv 一直阻塞在读取上。线程没设 daemon主进程退出时也不会强制结束。每次强退都留一个僵尸线程越积越多。 解决所有处理线程设 daemonTruehandle_client 最外层用 try/finally 包住确保退出时把连接从集合中移除并关闭。最后加心跳扫描做兜底超过 3 分钟没收发过消息的连接直接关闭。注意 daemon 线程不是解决资源泄漏的银弹真正解决问题的是 finally 里的清理动作。5.4 局域网联调连不上先查监听地址再查端口占用现象同一台机器上客户端登录成功换到另一台电脑就连不上报 ConnectionRefusedError。 原因服务端 bind 了127.0.0.1只监听回环地址局域网内其他机器当然访问不到。 解决服务端绑定0.0.0.0而不是 localhost。绑定 0.0.0.0 表示监听本机所有网卡局域网 IP 也能访问。然后检查端口是否被防火墙拦了Windows 上首次监听会弹防火墙授权框直接放行即可。如果端口被别的小程序占用可以用netstat -ano | findstr 9000查看占用端口的 PID然后去进程管理器确认是不是上次没杀干净的服务端。5.5 端口被 TIME_WAIT 占着服务端重启失败现象改了代码重启服务端bind 报Address already in use过一会又自己好了。 原因大量客户端连接关闭后TCP 连接进入 TIME_WAIT 状态端口被内核暂时占用。是否允许立即绑定取决于内核参数socket 默认是允许的但如果你创建 socket 时没设置 SO_REUSEADDR或者还有旧进程没退干净就会撞上。 解决服务端创建 socket 后立即setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)。再不行就用netstat -ano查端口对应的 PID杀掉残留进程。另外注意客户端进程没退出也会占着端口聊天室测试时经常是客户端开了一堆没关。6. 用并发登录脚本给聊天室做一次压力验证6.1 并发注册脚本一次创建 50 个登录连接写完服务端和客户端真正要验证的不是“两个人能聊”而是“同时进来几十个人会不会乱”。手工开几十个窗口不现实直接在测试脚本里用多线程并发登录即可。import threading, time success [] lock threading.Lock() def try_login(i): try: sock, code, text login(127.0.0.1, 9000, fuser{i}, 123456) if code 200: with lock: success.append(i) sock.close() except Exception as e: print(fuser{i} 失败: {e}) threads [] for i in range(50): t threading.Thread(targettry_login, args(i,)) threads.append(t) t.start() for t in threads: t.join() print(f登录成功 {len(success)}/50) if len(success) 50: print(有登录失败的, 去服务端查异常日志)这个脚本验证的是登录接口在高并发下的表现。如果 50 个线程同时登录服务端返回码全为 200说明锁和字典操作没有逻辑冲突。如果出现失败优先检查是不是 nickname 重复、payload 解析错误再看服务端日志里有没有异常堆栈。压测之后还要验证广播保持客户端在线脚本里每个连接随机发一条消息通过服务端统计“发出 N 条、成功 N 条”来确认没有丢消息。我在实际测试中遇到过广播偶发丢失最后定位到是某个连接已关闭但还残留在快照里sendall 抛 OSError 后被静默吞掉。所以压测脚本里也要统计发送失败次数不要一味吞异常。6.2 观察在线数与连接状态用服务端日志代替黑匣子压测时我习惯在服务端放一个后台线程每秒打印一次当前在线数和线程数。Thread 数是非常有价值的信号如果在线数下降而线程数不降说明清理逻辑出问题了。一个简单的监控代码如下def monitor(): while True: with lock: online len(clients) print(f[monitor] online{online}, threads{threading.active_count()}) time.sleep(1) threading.Thread(targetmonitor, daemonTrue).start()把这个函数插到 serve_forever 的启动步骤里压测过程中全程看输出。线程数如果持续不降基本可以断定有连接泄漏。这些技能组合起来聊天室从“demo”变成“能交付的工具”就只差这一步验证。最后补一个我的教训最早我做聊天室时不写 recv_exactly把粘包问题当玄学折腾了一整晚后来把循环读长度这个习惯固化下来所有 socket 项目都先封装这段再也没为半包发过愁。希望帮到你。本文还有配套的精品资源点击获取