简介南京信息工程大学计算机网络课程设计Socket局域网通信软件项目面向计算机网络相关专业学生及需要完成类似课设的开发者核心目标是掌握基于TCP/IP的Socket编程、多线程并发与文件传输技术。软件实现了一对一私聊、群聊和文件发送三类典型功能并通过课程设计报告完整记录需求分析、系统设计、编码实现、测试调试及问题解决方案。压缩包约5.09MB具体文件构成请以下载页面为准。目前已有337人学习适合需要参考完整实现思路和报告撰写框架的读者。报告中详细展示了私聊场景下独立Socket连接的建立与消息私密性保障群聊场景下基于线程池的聊天室维护与消息广播机制以及文件传输时数据分包、重组保存和丢包重传等处理细节对深入理解计算机网络应用层开发很有参考价值也能为课程设计文档写作与答辩准备提供实用帮助。1. 计算机网络课程设计中的Socket局域网通信软件不是聊天框那么简单拿到“南京信息工程大学计算机网络课程设计Socket局域网通信软件一对一、群聊、发送文件含报告”这个题的时候大部分人的第一反应是拉一个窗体、拖两个输入框让Socket在回环地址上跑通一句“你好”就算交差。但真正做下去才会意识到这个题目考察的并不是界面而是协议怎么设计、线程怎么组织、文件数据怎么在TCP流里不被淹掉。Socket局域网通信软件同时覆盖一对一会话、群组广播和文件分块传输三条链路做好了它TCP粘包处理、应用层协议设计、并发访问临界区这些问题就不再是课本上的黑匣子。这个方向适合计算机网络课程刚结课、想通过一次完整实践把Socket从会用变成能讲清楚的同学也适合想在报告里拿出点别人没有的排错记录的人。2. 先定协议再写代码把一对一群聊文件传输收敛成同一套转发模型很多课程设计翻车不是代码写不出来而是上来就直接写代码。三个功能看起来是三条独立逻辑其实背后都是同一件事客户端产生一条消息服务端根据消息里的路由信息决定把它交给谁。如果你一开始不定协议做到后面一定会发现私聊消息和文件块互相穿插、群聊广播范围越界、消息长度边界丢失。所以我做这个题的第一原则是在写任何Socket监听逻辑之前先把应用层协议定死。2.1 自定应用层协议用“4字节长度前缀 JSON体”给TCP画边界TCP是流式协议它不保证一次send对应一次recv。发送方连续调用两次send接收方可能一次recv就把两段数据一起读走发送方一次send很大一块数据接收方也可能分三次才能读完。因此应用层必须自己定义消息边界。常见做法是每一条消息前面加一个固定长度的头部头部里存这条消息体的字节数接收方先读固定长度的头部拿到长度值再按长度去读取完整消息体。这个题的三种场景里聊天消息、群聊广播、文件控制消息都是结构化数据用JSON序列化最直观而文件块内容更适合用Base64转成文本放进JSON。下面这段是我在这个项目里封装的编解码函数收发双方共用同一套避免头部和消息体长度对不上import struct import json def encode_message(msg: dict) - bytes: body json.dumps(msg, ensure_asciiFalse).encode(utf-8) header struct.pack(I, len(body)) return header body def decode_message(sock) - dict: header recv_exact(sock, 4) if header is None: return None body_len struct.unpack(I, header)[0] body recv_exact(sock, body_len) if body is None: return None return json.loads(body.decode(utf-8))struct.pack(I, ...)里的表示大端字节序I表示无符号整数。选择大端是TCP/IP协议族的标准做法和IP头、TCP头里的字段字节序保持一致写报告时这个细节能体现你确实理解网络字节序。recv_exact函数是必须自己实现的因为Python的socket.recv(n)不一定一次返回n个字节它只在缓冲区收到数据时就返回。只有循环读、直到累计字节数达到目标才能保证拿到完整消息体。这个方案的代价是每条消息大概多出4个字节的头部在局域网内完全可以忽略。相比用\\r\\n这类分隔符拆包长度前缀方案最稳妥的地方在于消息体本身可以包含任意字符包括换行符和二进制数据不会出现“正文里恰好出现分隔符导致解析错位”的问题。2.2 并发模型多线程、select还是“每连接一线程加全局锁”局域网通信软件的连接数上限取决于机房规模和测试机数量一般不会超过50个。这个量级下select和每连接一线程都能轻松扛住。select模型的优势是单线程内完成所有socket的轮询不涉及共享资源的并发访问但代码写起来比较绕而且一个连接阻塞在recv里会影响其他连接。每连接一线程的模型则更贴近人的直觉每个连接的读循环是独立的谁有数据谁就阻塞在读互不干扰。我一般会选“主线程accept 每个连接一个读线程 全局客户端表加锁”。原因是这个模型的并发冲突点只有一个就是所有线程同时读写的那个客户端表。只要把它用一把锁保护住就不太容易出现隐藏的竞态问题。select模型虽然性能更好但课程设计的核心考察点不是高并发而是“你能否把TCP通信链路讲清楚”多线程模型的代码可读性明显更高后期排错和写报告都更省力。import threading clients {} # username - socket套接字 clients_lock threading.Lock() # 保护clients字典的全局锁 def register_client(username, conn): with clients_lock: clients[username] conn这里必须强调的是Python的dict本身是线程安全的但“判断用户存在→取出套接字→发送数据”这三步组合起来并不是原子的。如果两个线程同时处理一个用户掉线和一条发给他的消息就可能出现拿到的socket已经被关闭、sendall抛异常的情况。用一个全局锁包住这些复合操作是课程设计阶段最简单也最不容易错的并发方案。2.3 消息类型与会话模型登录、点对点聊天、群聊广播和文件消息把三种功能统一成一套消息系统之后接下来要定义消息类型。我在这个项目里一共定义了六种消息login表示注册用户名、chat表示一对一私聊、group表示群聊广播、file_start表示文件传输开始、file_block表示文件数据块、heartbeat表示心跳。每类消息的头部结构完全一致区别只体现在msg_type字段和body内容上。这样的话服务端的分发逻辑就可以收敛成一张路由表chat消息按to_user字段找到目标连接转发group消息遍历全连接表广播file_start和file_block按to_user字段点对点转发。文件消息之所以单独拆成两种类型是为了让接收端能区分“文件元信息”和“文件内容数据块”前者用来创建本地文件并初始化接收状态后者用来持续写入磁盘。这种设计我在报告里是重点写的因为老师最想看到的是你能否把复杂问题拆成一致模型而不是堆砌三个互相独立的if分支。一套转发内核支撑三种功能代码量少测试路径也统一这本身就是通信软件架构里很重要的“聚敛设计”思想。3. 从零跑通最小系统服务端、客户端与文件传输链路的完整代码协议和并发模型定下来之后代码实现就变成了按图索骥。先搭出最小可运行的项目结构然后按服务端、客户端、文件传输三步补齐。下面这套实现基于Python 3不需要装任何第三方库标准库里的socket、threading、json、struct就能跑完整个课程设计的全部功能。3.1 项目文件结构与最小运行环境整个项目我习惯拆成三个文件protocol.py放编解码函数server.py放服务端逻辑client.py放客户端逻辑和工作界面。如果做C#课程设计对应关系就是Protocol类、Server类、Client窗体类。拆文件的目的不是凑结构而是后续报告里画模块图和数据流图时可以直接引用。文件职责关键对象protocol.py消息编解码、长度前缀处理encode_message / decode_messageserver.py监听、连接管理、消息路由clients字典、每连接读线程client.pyUI交互、接收线程、文件收发回调接口、发送方法运行环境只要Python 3.8以上即可Windows和Linux都支持。如果你最后想交给老师一个双击可运行的程序用PyInstaller把client.py打包成exe就行但要注意打包时勾选“单文件”模式否则换一台机器运行会缺依赖。3.2 服务端实现accept主循环、读线程与消息路由服务端是整个系统的核心。它的任务是维护一张“在线用户表”并把收到的消息转发给正确的目标。下面的代码实现了私聊、群聊和文件块转发的完整逻辑注意线程退出时的资源清理这是最容易漏的部分import socket import threading import struct import json LISTEN_PORT 8888 clients {} clients_lock threading.Lock() def recv_exact(conn, n): data b while len(data) n: chunk conn.recv(n - len(data)) if not chunk: return None data chunk return data def pack_msg(msg): body json.dumps(msg, ensure_asciiFalse).encode(utf-8) return struct.pack(I, len(body)) body def read_msg(conn): header recv_exact(conn, 4) if header is None: return None body_len struct.unpack(I, header)[0] body recv_exact(conn, body_len) if body is None: return None return json.loads(body.decode(utf-8)) def handle_conn(conn, addr): username None try: first_msg read_msg(conn) if not first_msg or first_msg.get(msg_type) ! login: conn.close() return username first_msg[from_user] with clients_lock: clients[username] conn while True: msg read_msg(conn) if msg is None: break msg_type msg.get(msg_type) if msg_type in (chat, file_block, file_start): target None with clients_lock: target clients.get(msg.get(to_user)) if target: target.sendall(pack_msg(msg)) else: conn.sendall(pack_msg({ msg_type: error, content: f用户 {msg.get(to_user)} 不在线 })) elif msg_type group: with clients_lock: targets list(clients.values()) for c in targets: if c is not conn: try: c.sendall(pack_msg(msg)) except OSError: pass except (ConnectionResetError, BrokenPipeError): print(f[{addr}] 连接异常断开) finally: if username: with clients_lock: clients.pop(username, None) conn.close() def main(): srv socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((0.0.0.0, LISTEN_PORT)) srv.listen(50) while True: conn, addr srv.accept() threading.Thread(targethandle_conn, args(conn, addr), daemonTrue).start() if __name__ __main__: main()这里的三个细节值得注意。第一finally块里的clients.pop必须执行否则用户异常掉线后他的用户名永远留在在线表里后续发给他的消息全部会转发到一个死Socket上。第二群聊广播时先在锁内复制一份targets列表再在锁外遍历发送如果直接在锁内遍历并调用sendall一旦某个客户端的网线被拔掉sendall会阻塞甚至抛异常进而把锁卡死在持锁线程里。第三daemonTrue让每个连接线程成为守护线程主程序CtrlC退出时不需要逐个join。参数说明LISTEN_PORT选端口时避开80、443、8080这类容易冲突的常用端口选一个1024以上的高位端口比如8888。listen(50)表示内核里的连接请求队列长度课程设计场景下20到50都够用。3.3 客户端设计接收线程与UI回调的分离客户端的核心矛盾在于UI主线程不能阻塞在recv()上等消息因为这样窗口会假死但你又必须时刻准备着接收服务端转发来的消息。解决方案是让Socket接收跑在独立线程里把收到的消息通过回调抛回主线程更新界面。import socket import threading import json import time class LanChatClient: def __init__(self, host, port, username): self.username username self.sock socket.create_connection((host, port)) self.running True self.on_message None # 回调UI层注入 self.sock.sendall(self.pack({ msg_type: login, from_user: username })) threading.Thread(targetself._recv_loop, daemonTrue).start() def pack(self, msg): body json.dumps(msg, ensure_asciiFalse).encode(utf-8) return len(body).to_bytes(4, byteorderbig) body def _recv_n(self, n): data b while len(data) n: chunk self.sock.recv(n - len(data)) if not chunk: return None data chunk return data def _recv_loop(self): while self.running: try: header self._recv_n(4) if header is None: break body_len int.from_bytes(header, byteorderbig) body self._recv_n(body_len) if body is None: break msg json.loads(body.decode(utf-8)) if self.on_message: self.on_message(msg) except Exception: break self.running False def send_chat(self, to_user, content): self.sock.sendall(self.pack({ msg_type: chat, from_user: self.username, to_user: to_user, content: content, ts: time.strftime(%H:%M:%S) })) def send_group(self, content): self.sock.sendall(self.pack({ msg_type: group, from_user: self.username, content: content, ts: time.strftime(%H:%M:%S) })) def close(self): self.running False self.sock.close()客户端的重点在_recv_loop和on_message回调。在C#的WinForm项目里这个回调的对应写法是BeginReceive加委托收到数据后在BeginInvoke里更新控件在Java Swing里则是SwingUtilities.invokeLater。虽然语言不同但思路一致网络接收线程和UI线程必须分离。很多人工Timer轮询Socket缓冲区的方式不建议使用它既浪费CPU又容易漏消息。send_chat和send_group两个方法目前只负责发送不关心结果如果想做“消息发送失败提醒”可以在发送后等待服务端的error回执再由回调层弹窗提示。回调里根据msg_type分别走聊天显示、群聊显示、文件接收逻辑这部分已经和UI强相关我习惯在回调里写一个switch语句分发到各处理方法。3.4 文件传输控制消息先到数据块按序落盘文件传输最容易犯的错误是把整个文件一次性读进内存再发送。局域网带宽虽高但一个200MB的文件就会吃光客户端内存而且sendall在TCP窗口满时会阻塞内存占用叠加阻塞程序基本就死了。正确做法是分块读取、分块发送每块用一个独立文件块消息承载。文件传输的流程分成三步第一步发送方发送一个file_start消息里头包含文件名、文件总大小、总分块数第二步接收方收到后在本地创建一个空文件准备好写入状态第三步发送方循环读取文件、按块发送file_block消息接收方收到后根据块号写入对应位置。块号字段很重要它不光能验证顺序还能让后续的断点续传有据可依。CHUNK_SIZE 64 * 1024 BLOCK_HEADER { from_user: sender_name, to_user: receiver_name, } def send_file_by_path(sock, pack, username, to_user, filepath): import os, base64 file_size os.path.getsize(filepath) file_name os.path.basename(filepath) total_blocks (file_size CHUNK_SIZE - 1) // CHUNK_SIZE start_msg BLOCK_HEADER.copy() start_msg.update({ msg_type: file_start, file_name: file_name, file_size: file_size, total_blocks: total_blocks }) sock.sendall(pack(start_msg)) with open(filepath, rb) as f: for idx in range(total_blocks): chunk f.read(CHUNK_SIZE) block_msg BLOCK_HEADER.copy() block_msg.update({ msg_type: file_block, block_index: idx, data: base64.b64encode(chunk).decode(ascii) }) sock.sendall(pack(block_msg))块大小取64KB是比较平衡的折中。小于16KB会导致循环次数过多每条消息的头部开销占比变高大于256KB会让单条消息的编码耗时变长一旦某个块丢包重传代价也大。base64.b64encode把二进制转成纯ASCII文本编码后体积膨胀约三分之一但好处是二进制数据可以安全嵌进JSON字符串接收端解码后再写磁盘二进制不会因为编码格式受损。如果你想压缩体积可以在文件块消息里改用纯二进制协议但需要单独设计二进制头课程设计阶段不推荐。接收端的处理逻辑写在on_message回调里收到file_start时用open(path, wb)创建一个空文件并记录received_blocks计数器收到file_block时按block_index写入每写一块把计数器加一当计数器等于total_blocks时关闭文件并提示传输完成。如果收到一个block_index缺失的块可以记下来并在最后统一请求补发这就是最朴素的断点续传模型。3.5 局域网联调验证从本机测试到跨机器跑通代码写完先在本机验证再用局域网内两台真实机器对调。我用的是下面这套顺序每步都能明确判断故障边界。第一步只开服务端和两个客户端三个程序都跑在同一台机器上服务端监听0.0.0.0客户端连接127.0.0.1:8888。这一步验证协议编解码和路由逻辑本身是否正常。第二步把其中一个客户端换成另一台机器连接服务端的局域网IP。这里要先在服务端机器上用ipconfig或ifconfig确认实际局域网IP别把127.0.0.1发给别人。第三步让第三台机器加入发起群聊广播确认所有在线客户端都能收到同一条消息。第四步从机器A向机器B发送一个10MB左右的文件传输完成后对比两个文件的大小和MD5值确认数据块没有错位。如果你手头只有一台电脑可以用VirtualBox或VMware开一台虚拟机把网络模式改成“桥接”或“仅主机”虚拟机和物理机就处在同一个局域网里也能完成跨机器验证。只在本机跑两个进程不叫局域网通信课程设计答辩时老师通常会要求你现场展示两台真实机器互发。4. 局域网Socket课程设计最常见的四个坑现象、原因与解法这部分是我在这个方向上的血泪心得。下面四条每一个都能让程序“看起来没报错但实际跑不通”而且每条都是课程设计答辩时容易栽跟头的真实场景。4.1 服务端在本机能连另一台机器却连接超时现象服务端监听0.0.0.0:8888本机用127.0.0.1能正常连接。换到局域网另一台机器客户端connect一直超时或提示“连接被拒绝”。原因Windows防火墙默认阻止入站连接。Socket服务端监听了端口但系统防火墙在TCP三次握手的SYN阶段就会把外来连接请求丢在门外。教室或者宿舍的网络环境还经常同时存在多个网络配置文件防火墙规则作用在专用网络和公用网络上的策略不一样规则没选对也会拦。这是所有局域网通信程序“别人连不上”的头号祸首。解决在服务端机器上用管理员身份执行下面的命令放行指定端口netsh advfirewall firewall add rule nameSocketCourseDemo dirin actionallow protocolTCP localport8888执行完用netsh advfirewall firewall show rule nameSocketCourseDemo确认规则已生效。如果连的是公用网络还要把规则的作用域里的“远程地址”改成“任何”否则Windows会区分网络配置文件公用网络的强度规则通常默认拒绝入站。4.2 服务端重启时报“通常每个套接字地址只允许使用一次”现象服务端程序运行中直接CtrlC杀掉立即重新启动bind()报错。Windows下错误信息是“每个套接字地址(协议/网络地址/端口)只允许使用一次”Linux下通常返回Address already in use。原因TCP断开连接之后主动关闭方会进入TIME_WAIT状态这个状态默认持续两倍的最大报文段生存期Windows上通常是几十秒到两分钟。TIME_WAIT是为了防止延迟的旧数据包被新连接接收但副作用就是端口被占住无法立即重新绑定。解决在服务端创建socket之后、bind之前设置地址复用选项srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)这行代码在Linux上能直接解决TIME_WAIT导致的bind失败Windows上的行为虽然和Linux有些差别但对课程设计场景来说加上它能极大降低调试阶段反复重启服务端的挫败感。开发调试期间如果仍然遇到这个报错最省事的办法是换一个监听端口。报告里如果能写清楚TIME_WAIT状态产生的原因以及SO_REUSEADDR的作用是明显的知识点加分项。4.3 聊天正常但文件一传就损坏粘包和缓冲区截断现象文本聊天怎么发都正常一旦传文件接收端保存下来的文件打不开或者大小对不上。偶尔文件成功了多传几遍又坏了时好时坏像玄学一样。原因文件数据的量级远大于聊天文本TCP的粘包和半包问题在这里集中爆发。如果接收端只调用一次recv()就把数据当成一条完整消息解析那么多个file_block消息会粘连在一起被一次读出程序却只解析了第一个块或者一个长文件块被拆成多个TCP分段接收端还没收完就试图解析导致JSON解析失败或数据截断。解决严格使用“4字节长度前缀”的接收逻辑任何消息都必须走recv_exact循环物理读满再解析。不要用recv(65535)碰运气不要依赖消息末尾的特殊分隔符更不要根据聊天内容长度来猜接收长度。文件消息的每一个块都是一个独立的应用层消息都带长度前缀只有这样才能保证每个数据块的边界在应用层是清晰的。发完文件后务必对比原文件和接收文件的MD5MD5一致才能算传输成功。4.4 跑一会之后私聊发不出去僵尸连接和强退客户端的后遗症现象系统刚启动时一切正常跑一段时间后某些用户明明界面还在但发给他的私聊消息开始没有任何回应服务端也不报错。原因客户端程序被强制关闭、电脑休眠、网线被拔等情况下服务端在短时间内感知不到连接已经失效。按TCP协议正常关机时才会发出FIN握手拔网线和断电源都不会主动发FIN。于是服务端里的clients字典一直保留着那个失效的socket向它转发消息时第一次可能失败但没到超时阈值或者系统仍未探测到连接已断消息就无声无息地丢失了。解决靠业务层心跳机制兜底。客户端每隔30秒发送一条msg_type为heartbeat的空消息服务端在接收循环里看到心跳就更新该用户最后一次活跃时间。每过60秒扫描一次在线表把超过90秒没有心跳的连接强制关闭并从clients字典里清理掉。心跳机制不是可选项它是稍微有点规模的局域网通信软件必须有的保活手段也是报告里论证系统健壮性的重要素材。5. 答辩前的最后两层保险心跳检测与报告的证据链前两层的保活逻辑再补一步就能达到课程设计评优的标准。我在最终版代码里加了一个轻量级的断线重连客户端检测到recv返回None或连接异常后先关闭旧socket然后按照1秒、2秒、4秒、8秒的间隔指数退避重连最多重试五轮。重连成功后自动用原来的用户名重新发login消息而不是让用户手动重启程序。这一步的意义不只是减少故障感更重要的是文件传输中断后能具备从断点继续的基础——重新登录后可以提示对方补发缺失的文件块。报告里最容易被忽视的是“测试证据链”。不要只写“运行成功”四个字要把实际联调过程的现场记录放进去两台机器的IP地址、防火墙放行规则截图、传文件前后的MD5值对比、断网后心跳超时清线的日志。表格是最经济的呈现方式像下面这样测试场景操作步骤预期结果实测结果一对一私聊机器A向机器B发三条连续消息B按顺序收到三条通过群聊广播3台客户端同时在线A发群聊B、C同时收到通过文件传输A传B一个10MB随机文件B收到后MD5一致通过异常掉线B拔网线90秒后看服务端日志B被心跳机制清出在线表通过我当年在这个题目上吃过亏功能全部做完但报告里只贴了界面截图没有写协议设计和异常处理思路答辩被老师连续追问了几次TIME_WAIT和粘包问题答得磕磕绊绊。后来带同学做这个题我都会先让他们把休息时间用来补心跳机制和排错记录。希望你花在这门课上的时间不只是为了交一份作业而是真的把这些协议设计和工程细节变成自己的东西。希望帮到你。本文还有配套的精品资源点击获取