简介本资源是南京信息工程大学计算机网络课程设计的完整实践项目面向高校计算机及相关专业学生聚焦Socket编程在局域网通信中的综合应用解决TCP连接管理、多线程并发处理、文件分包传输等核心实践难点。压缩包为ZIP格式大小5.09MB包含可运行的客户端/服务器源码、详细课程设计报告含需求分析、系统设计、测试记录与性能讨论、以及关键实现说明文档其中Java或Python源码实现一对一私聊、群聊广播与文件收发功能报告深入剖析了线程池调度、消息序列化、断点续传逻辑等技术细节。目前已有327人学习下载适合开展网络编程实训、课程设计参考或毕业设计拓展能直接复用代码结构、借鉴多线程通信架构设计并获得从编码到文档撰写的全流程范例。1. 这不是聊天软件而是一套可验证的TCP应用层协议实现沙盒在南京信息工程大学计算机网络课设现场学生常把“能连上、能发消息”当成成功标准——但真正卡住90%人的是群聊广播时消息乱序、文件传输后校验失败、多客户端并发下服务器线程阻塞崩溃。这个Socket局域网通信软件的本质不是UI界面有多漂亮而是用最朴素的TCP Socket原语在无中间件、无框架依赖的前提下完整复现了应用层通信协议的三大核心契约连接管理一对一私聊、状态同步群聊广播一致性、可靠分段文件传输完整性。它面向的是刚学完《计算机网络》前五章的学生解决的是“书上说三次握手我写出来的connect()为什么总超时”这类真实断点也面向有3年开发经验的工程师当ta需要快速搭建一个轻量级内网设备控制通道时这套经过课程压测的Socket线程模型和文件分块策略比临时拼凑的HTTP上传方案更可控、更低延迟。所有功能均限定在局域网环境不涉及NAT穿透、公网IP绑定或任何跨网段路由逻辑。2. TCP Socket通信骨架从阻塞式单连接到非阻塞多路复用演进路径2.1 为什么必须放弃while True: client, addr server_socket.accept()的原始写法初版代码常采用阻塞式accept等待导致服务器只能处理一个客户端连接。当第二个客户端尝试连接时请求被挂起直至第一个连接关闭——这直接违背群聊场景中“多用户同时在线”的基本需求。根本问题在于accept()调用会阻塞主线程而TCP服务器必须同时响应连接请求、接收消息、转发数据三类事件。解决方案不是简单加线程而是重构事件驱动模型。提示error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address错误本质是端口被占用但深层原因是未正确关闭socket资源。每次bind()前必须确保端口释放Python中需显式调用server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)。2.1.1 基于select()的I/O多路复用服务端骨架import socket import select import sys # 创建监听socket server_socket socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server_socket.bind((0.0.0.0, 8888)) server_socket.listen(5) # 初始化连接列表 sockets_list [server_socket] clients {} # {socket: {addr: (ip, port), name: user1}} print(Server started on 0.0.0.0:8888) while True: # select监控所有socket的读就绪状态 read_sockets, _, exception_sockets select.select(sockets_list, [], sockets_list, 1) for notified_socket in read_sockets: if notified_socket server_socket: # 新连接接入 client_socket, client_address server_socket.accept() sockets_list.append(client_socket) clients[client_socket] {addr: client_address, name: fuser_{len(clients)1}} print(fNew connection from {client_address}) else: # 已存在连接有数据到达 try: message notified_socket.recv(1024).decode(utf-8).strip() if message: # 解析消息协议TYPE|CONTENT if message.startswith(PRIV|): handle_private_message(notified_socket, message, clients, sockets_list) elif message.startswith(GROUP|): handle_group_message(notified_socket, message, clients, sockets_list) elif message.startswith(FILE|): handle_file_transfer(notified_socket, message, clients) except ConnectionResetError: # 客户端异常断开 print(fClient {clients[notified_socket][addr]} disconnected) sockets_list.remove(notified_socket) del clients[notified_socket] notified_socket.close()这段代码的关键在于select.select()返回的read_sockets列表它包含了所有当前可读的socket包括监听socket和已连接socket避免了为每个连接创建独立线程的资源开销。参数1表示超时1秒防止无限阻塞exception_sockets用于捕获异常连接比单纯try-except更精准。2.2 私聊消息的路由隔离机制如何保证A发给B的消息不被C看到一对一私聊不是简单地“发给服务器再转给B”而是建立双向连接上下文。服务器需维护clients字典其中每个socket对象关联其用户名和目标地址。当收到PRIV|B|Hello格式消息时流程如下解析出目标用户名B遍历clients字典找到name B对应的socket调用target_socket.send()发送而非广播给所有socketdef handle_private_message(sender_socket, message, clients, sockets_list): parts message.split(|, 2) if len(parts) 3: return target_name parts[1] content parts[2] # 查找目标用户socket target_socket None for sock, info in clients.items(): if info[name] target_name: target_socket sock break if target_socket and target_socket in sockets_list: try: # 构造私聊回执FROM|A|Hello response fFROM|{clients[sender_socket][name]}|{content} target_socket.send(response.encode(utf-8)) # 同时向发送方确认已送达 sender_socket.send(fSENT_TO|{target_name}.encode(utf-8)) except BrokenPipeError: print(fTarget {target_name} offline or disconnected)注意SENT_TO回执机制它解决了“消息是否真的送达”的可见性问题这是课程设计报告中性能分析章节必须包含的指标项消息端到端延迟统计起点。2.3 群聊广播的原子性保障为什么for sock in sockets_list会出错常见错误写法是遍历所有socket并逐个send但若某客户端网络抖动导致send()阻塞或抛出异常整个广播循环中断剩余客户端收不到消息。正确做法是分离广播逻辑与异常处理def handle_group_message(sender_socket, message, clients, sockets_list): parts message.split(|, 1) if len(parts) 2: return content parts[1] # 获取发送者名称 sender_name clients.get(sender_socket, {}).get(name, unknown) broadcast_msg fGROUP|{sender_name}|{content} # 广播给所有在线客户端排除发送者自身 failed_sockets [] for sock in sockets_list[:]: # 切片避免遍历时修改列表 if sock ! server_socket and sock ! sender_socket: try: sock.send(broadcast_msg.encode(utf-8)) except (BrokenPipeError, ConnectionResetError, OSError): # 记录失败socket稍后清理 failed_sockets.append(sock) # 统一清理失效连接 for sock in failed_sockets: if sock in sockets_list: sockets_list.remove(sock) if sock in clients: del clients[sock] sock.close()关键点sockets_list[:]创建副本遍历避免remove()操作影响迭代failed_sockets暂存异常socket统一处理而非中断广播OSError捕获底层系统错误如errno 107 Transport endpoint is not connected。3. 文件传输可靠性工程分块、校验、断点续传的最小可行实现3.1 为什么不能直接socket.send(file.read())TCP协议本身不保证“一次send对应一次recv”尤其大文件场景下操作系统内核缓冲区可能将多次send合并或单次send被拆分成多个TCP包。客户端recv时若按固定长度读取如recv(1024)极易发生粘包多个文件头混在一起或半包只收到部分文件头。必须设计自描述协议头。3.1.1 文件传输协议帧结构定义字段长度说明FILE_HEADER8字节固定字符串FILEHEAD标识帧起始FILENAME_LEN4字节文件名UTF-8编码字节数大端FILENAME变长文件名字符串FILE_SIZE8字节文件总大小大端支持4GBCHUNK_INDEX4字节当前分块序号从0开始CHUNK_SIZE4字节当前分块实际字节数最后一块可能小于1024PAYLOAD变长文件数据块此结构确保接收方可无歧义解析先读8字节判断是否为文件帧再读4字节得文件名长度依此读取后续字段最后按CHUNK_SIZE精确读取payload。3.2 客户端分块发送与服务端重组逻辑# 客户端发送函数简化版 def send_file(client_socket, filepath): filename os.path.basename(filepath) file_size os.path.getsize(filepath) chunk_size 1024 with open(filepath, rb) as f: chunk_index 0 while True: chunk f.read(chunk_size) if not chunk: break # 构造协议头 header bytearray(8 4 len(filename.encode(utf-8)) 8 4 4) header[0:8] bFILEHEAD struct.pack_into(I, header, 8, len(filename.encode(utf-8))) header[12:12len(filename.encode(utf-8))] filename.encode(utf-8) struct.pack_into(Q, header, 12len(filename.encode(utf-8)), file_size) struct.pack_into(I, header, 12len(filename.encode(utf-8))8, chunk_index) struct.pack_into(I, header, 12len(filename.encode(utf-8))84, len(chunk)) # 发送头数据 client_socket.send(header) client_socket.send(chunk) chunk_index 1 # 每发送一块等待服务端ACK防过载 ack client_socket.recv(4) if ack ! bACK!: raise RuntimeError(Server ACK timeout)服务端接收时需严格按协议头长度读取再根据CHUNK_INDEX写入临时文件对应偏移位置# 服务端接收函数关键片段 def receive_file_chunk(client_socket, temp_dir): # 先读8字节头标识 header client_socket.recv(8) if header ! bFILEHEAD: return None # 读文件名长度 fname_len_bytes client_socket.recv(4) fname_len struct.unpack(I, fname_len_bytes)[0] # 读文件名 filename_bytes client_socket.recv(fname_len) filename filename_bytes.decode(utf-8) # 读文件总大小、分块索引、分块大小 file_size_bytes client_socket.recv(8) file_size struct.unpack(Q, file_size_bytes)[0] chunk_index_bytes client_socket.recv(4) chunk_index struct.unpack(I, chunk_index_bytes)[0] chunk_size_bytes client_socket.recv(4) chunk_size struct.unpack(I, chunk_size_bytes)[0] # 读取实际数据块 payload b while len(payload) chunk_size: chunk client_socket.recv(min(4096, chunk_size - len(payload))) if not chunk: break payload chunk # 写入临时文件按索引定位 temp_path os.path.join(temp_dir, f{filename}.part) with open(temp_path, rb) as f: f.seek(chunk_index * 1024) f.write(payload) # 发送ACK client_socket.send(bACK!) return { filename: filename, file_size: file_size, chunk_index: chunk_index, total_chunks: (file_size 1023) // 1024 }注意seek()写入要求文件已存在且足够大。实际部署需先创建指定大小的空文件os.truncate(temp_path, file_size)。3.3 文件完整性校验MD5哈希值嵌入协议的设计取舍课程设计报告要求分析传输效率而哈希校验必然增加开销。权衡方案是仅对首尾块校验首块校验文件名和总大小字段防止协议头篡改尾块校验最后1KB数据MD5覆盖大部分传输错误全文件校验留作扩展项报告中可写为“优化建议增加SHA256全量校验”# 尾块校验示例服务端 if chunk_index total_chunks - 1: # 最后一块 # 计算接收到的最后1024字节MD5 tail_data payload[-1024:] if len(payload) 1024 else payload actual_tail_hash hashlib.md5(tail_data).hexdigest() # 从客户端发送的额外字段获取期望值协议扩展 expected_hash client_socket.recv(32).decode(ascii) if actual_tail_hash ! expected_hash: raise ValueError(fTail hash mismatch: {actual_tail_hash} ! {expected_hash})4. 多线程安全与资源泄漏防控课程设计中最易被忽略的硬伤4.1threading.Thread与concurrent.futures.ThreadPoolExecutor的适用边界课程设计明确要求“使用多线程技术”但很多学生误以为“每个客户端一个Thread就万事大吉”。问题在于Thread对象创建销毁开销大100个并发连接即创建100个线程远超系统默认线程栈限制Linux通常8MB/线程导致OSError: cant start new thread。正确做法是线程池复用from concurrent.futures import ThreadPoolExecutor import threading # 全局线程池最大20线程避免资源耗尽 executor ThreadPoolExecutor(max_workers20) lock threading.Lock() # 保护共享资源 def handle_client(client_socket, client_address): 处理单个客户端的完整生命周期 try: while True: data client_socket.recv(1024) if not data: break # 解析并分发消息类型 process_message(client_socket, data, clients, lock) except ConnectionResetError: pass finally: # 清理资源 with lock: if client_socket in clients: del clients[client_socket] client_socket.close() # 主循环中提交任务 while True: client_socket, client_address server_socket.accept() executor.submit(handle_client, client_socket, client_address)ThreadPoolExecutor自动管理线程生命周期max_workers20确保并发数可控lock保护clients字典的读写竞态。4.2 Socket资源泄漏的三种典型场景及检测方法场景表现检测命令修复方案close()未调用netstat -an | grep :8888显示大量TIME_WAIT或ESTABLISHED连接lsof -i :8888查看进程打开的socket数在finally块中强制client_socket.close()异常中断未清理客户端CtrlC退出服务端clients字典仍保留该socket键ss -tuln | grep :8888观察连接数持续增长select()异常socket列表中主动remove()并close()线程阻塞未退出ps -T -p pid显示线程数远超max_workersstrace -p pid -e tracenetwork抓取系统调用设置socket.settimeout(30)超时抛出socket.timeout4.2.1 使用socket.settimeout()防御永久阻塞# 服务端socket设置 server_socket.settimeout(None) # 监听socket保持阻塞 # 客户端socket设置在accept后立即设置 client_socket.settimeout(30.0) # 30秒无数据则超时 # 在recv循环中捕获超时 try: data client_socket.recv(1024) except socket.timeout: print(fClient {client_address} timeout, closing...) client_socket.close() returnsettimeout()是比select()更细粒度的控制它让单个socket在无数据时主动退出避免线程卡死。5. 课程设计报告核心指标验证用tcpdump和Wireshark抓包分析通信质量5.1 消息延迟测量从send()到recv()的真实耗时课程设计报告要求分析“消息传递延迟”但time.time()在应用层测量误差大含Python解释器开销、GIL切换。真实方法是在协议层打时间戳# 客户端发送时嵌入毫秒级时间戳 import time timestamp_ms int(time.time() * 1000) message_with_ts fMSG|{timestamp_ms}|{content} client_socket.send(message_with_ts.encode(utf-8)) # 服务端收到后立即回传 parts data.decode(utf-8).split(|, 2) if parts[0] MSG and len(parts) 3: sent_ts int(parts[1]) recv_ts int(time.time() * 1000) latency_ms recv_ts - sent_ts # 记录latency_ms到日志文件供报告分析此方法消除系统调用测量误差得到端到端网络延迟含排队、传输、处理时间。5.2 文件传输效率瓶颈定位用tcpdump抓包分析吞吐量在服务端执行# 抓取8888端口所有TCP包保存为pcap sudo tcpdump -i any port 8888 -w network_trace.pcap -s 0 # 实时统计每秒接收字节数需安装tcpreplay tshark -r network_trace.pcap -q -z io,phs关键观察点重传率tshark -r network_trace.pcap tcp.analysis.retransmission | wc -l应接近0局域网理想情况窗口大小tshark -r network_trace.pcap -T fields -e tcp.window_size若长期64KB说明接收方应用层处理慢如文件写入未用buffer吞吐量tshark -r network_trace.pcap -q -z io,stat,1,SUM(tcp.len)若实测吞吐量远低于理论带宽如千兆局域网应达100MB/s检查Python文件写入是否同步open(..., wb)默认缓冲但f.flush()后os.fsync()才真正落盘此处应禁用fsync报告中注明“为测网络性能暂不保证磁盘持久化”。5.3 群聊消息顺序性验证用Wireshark过滤特定会话流在Wireshark中应用显示过滤器tcp.port 8888 ip.addr 192.168.1.100 ip.addr 192.168.1.101替换为实际客户端IP观察TCP流中GROUP|消息的序列号Sequence Number是否严格递增。若出现乱序如Seq1000的包在Seq999之后到达说明网络层存在路径差异此时服务端必须基于CHUNK_INDEX或消息ID做应用层排序——这正是课程设计要求的“理解协议栈分层”的实证环节。提示error 2002 (hy000): cant connect to local mysql server through socket /tmp/mysql.sock类错误与本项目无关它是MySQL客户端连接Unix域套接字的路径错误而本项目全程使用IPv4 TCP套接字路径为0.0.0.0:8888二者协议族AF_INET vs AF_UNIX和地址族完全不同切勿混淆排查方向。本文还有配套的精品资源点击获取