简介这份资源是广东工业大学计算机网络课程设计的完整项目包面向正在完成计网课设的本科生及需要P2P通信参考实现的学习者。项目实现了一个基于P2P架构的局域网即时通信系统程序同时充当服务器与客户端服务端口固定为3333涵盖用户注册、对等方列表获取、在线扫描与应答、TCP消息与文件传输等核心功能并配有图形界面展示对等方列表、消息记录、输入框及文件传输进度。压缩包共158个文件约20.77MB以java源码、class字节码、xml配置、properties属性文件、js脚本及index、prefs等工程文件为主另含log日志与dat数据文件完整保留了开发与运行痕迹。目前已有424人学习下载。读者可从中获取P2P节点发现与消息交换的完整实现思路、TCP文件传输的代码组织方式以及Swing界面与后台线程协作的参考写法适合作为课设答辩、代码复现与二次开发的实践素材。1. 从课程设计到真能跑P2P 局域网即时通信系统到底在做什么很多人第一次看到「基于 P2P 的局域网即时通信系统」这个题目第一反应是不就是写个 Socket两边互相发消息吗真动手才发现难点根本不在「发消息」而在「谁先找到谁」。局域网里没有公网服务器做中转两台机器要直接对话就得先解决节点发现、连接建立、消息可靠投递这三件事。这个课设真正训练的是把「计算机网络」课本里的 TCP/UDP、广播、多播、心跳、粘包这些概念落成一个能双击运行、能互相看到在线状态、能发文字和文件的桌面程序。它适合两类人一类是正在做计网课设、想拿一个结构清晰能讲清楚原理的项目另一类是想搞明白 P2P 打洞、局域网发现机制到底怎么落地的开发者。读完你能拿到一套可复现的架构选型、关键参数、以及我在实际调试中踩过的坑。下面按「先立住原理再动手复现最后讲边界」的顺序展开。2. 节点发现与连接建立局域网里谁先开口2.1 为什么不能只靠一个中心服务器课程设计里最省事的做法是架一台服务器所有客户端连它消息由它转发。但题目写的是 P2P如果所有流量都过中心节点那就退化成 C/S 架构答辩时老师一问「P2P 体现在哪」就答不上来。真正的 P2P 要求节点之间能直接建立连接中心节点最多只做「介绍人」。局域网场景下节点发现有三条常见路线UDP 广播、UDP 多播、以及手动输入 IP。广播最简单一个包发到255.255.255.255同网段所有机器都能收到多播更规范用224.0.0.1这类组播地址交换机支持 IGMP 时效率更高手动输入最土但最稳适合跨网段或者广播被防火墙拦掉的场景。我一般会做成「广播为主、手动兜底」因为很多学校机房的交换机默认关掉了广播转发纯广播方案在机房里经常一个节点都发现不了。2.2 UDP 广播发现的最小实现先看发现阶段的核心代码。节点启动后做两件事周期性往广播地址发自己的「在线通告」同时监听广播端口收别人的通告。import socket import json import threading import time DISCOVERY_PORT 37020 BROADCAST_ADDR 255.255.255.255 def broadcast_presence(self_id, tcp_port): sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) # 关键开启广播权限否则 sendto 会抛 Permission denied payload json.dumps({ type: presence, id: self_id, tcp_port: tcp_port, ts: time.time() }).encode(utf-8) while True: sock.sendto(payload, (BROADCAST_ADDR, DISCOVERY_PORT)) time.sleep(3) # 3 秒一次太频繁会刷屏太慢上线感知迟钝 def listen_presence(on_peer_found): sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.bind((, DISCOVERY_PORT)) while True: data, addr sock.recvfrom(2048) msg json.loads(data.decode(utf-8)) if msg[type] presence: on_peer_found(msg[id], addr[0], msg[tcp_port])逻辑说明广播包只携带「我是谁、我的 TCP 监听端口是多少」不携带业务数据。收到通告的一方把(id, ip, tcp_port)存进本地节点表。参数上DISCOVERY_PORT选 37020 是随手挑的高位端口避开常见服务广播间隔 3 秒是经验值低于 1 秒在几十台机器的机房里会明显增加网络负担高于 10 秒则新节点上线后要等很久才被看到。提示SO_REUSEADDR必须设否则同一台机器重启程序时会因为端口未释放而 bind 失败这个坑在调试阶段几乎人人踩一次。2.3 从发现到 TCP 长连接发现只是知道对方存在真正传消息要建立 TCP 连接。这里有个设计选择谁主动连谁如果两边同时向对方发起连接会出现两条连接消息可能从两条路走状态就乱了。常见做法是「ID 小的主动连 ID 大的」用节点 ID 的字典序做仲裁保证任意一对节点只有一条 TCP 连接。def maybe_connect(self_id, peer_id, peer_ip, peer_port): # 只有 ID 较小的一方发起连接避免双向重复连接 if self_id peer_id: try: conn socket.create_connection((peer_ip, peer_port), timeout3) register_connection(peer_id, conn) except (socket.timeout, ConnectionRefusedError): # 对方可能还没起监听下一轮广播再试 pass参数说明timeout3是连接超时局域网内正常握手在毫秒级3 秒还没连上基本就是对方没开监听或者被防火墙拦了。连接建立后要立刻发一个「握手包」带上自己的 ID让对方知道这条连接属于谁否则接收方无法把连接和节点表对应起来。3. 消息协议与可靠投递别让粘包毁掉整个系统3.1 自定义应用层协议的必要性TCP 是字节流没有消息边界。你发两次send接收方可能一次recv全收到也可能分三次收到。这就是粘包和拆包。课程设计里最常见的翻车现场就是本地测试好好的一传文件或者快速连发消息接收方解析就乱套了。解决办法是自定义一个简单的应用层协议用「长度前缀 消息体」定界。字段长度说明magic2 字节固定 0xCAFE用于快速识别非法包msg_type1 字节0x01 文本、0x02 文件元信息、0x03 文件块、0x04 心跳body_len4 字节网络字节序的消息体长度body变长JSON 或二进制数据3.2 收发循环的实现与参数import struct MAGIC 0xCAFE HEADER_FMT !HBI # 大端2字节magic 1字节type 4字节长度 HEADER_SIZE struct.calcsize(HEADER_FMT) def send_message(conn, msg_type, body: bytes): header struct.pack(HEADER_FMT, MAGIC, msg_type, len(body)) conn.sendall(header body) # sendall 保证全部发出别用 send def recv_loop(conn, on_message): buffer b while True: chunk conn.recv(4096) if not chunk: break buffer chunk while len(buffer) HEADER_SIZE: magic, msg_type, body_len struct.unpack( HEADER_FMT, buffer[:HEADER_SIZE]) if magic ! MAGIC: # 收到脏数据直接断开避免后续全部错位 return if len(buffer) HEADER_SIZE body_len: break # 半包等下一次 recv body buffer[HEADER_SIZE:HEADER_SIZE body_len] buffer buffer[HEADER_SIZE body_len:] on_message(msg_type, body)逻辑说明buffer累积字节流每次尝试从头部解析出长度只有凑够一整条消息才交给业务层。recv(4096)的缓冲区大小是权衡值太小会增加系统调用次数太大在大量小消息场景浪费内存。sendall和send的区别必须记住send返回实际发送字节数可能只发了一半sendall会循环直到发完。注意struct的格式串!HBI里!表示网络字节序大端。如果发送方用小端、接收方用大端解析出来的长度会是天文数字然后程序卡死在等数据上这种 bug 排查起来非常费劲。3.3 心跳与离线判定P2P 网络里节点随时可能关掉必须有机制感知离线。常见做法是每条 TCP 连接上跑心跳每 5 秒发一个空的心跳包连续 3 次没收到对方任何数据就判定离线从节点表移除并关闭连接。HEARTBEAT_INTERVAL 5 MAX_MISS 3 def heartbeat_worker(peer_id, conn, last_active): while is_alive(peer_id): time.sleep(HEARTBEAT_INTERVAL) if time.time() - last_active[peer_id] HEARTBEAT_INTERVAL * MAX_MISS: mark_offline(peer_id) conn.close() break send_message(conn, 0x04, b)参数上5 秒间隔 3 次容忍意味着最长 15 秒感知离线。课设演示时这个延迟可以接受如果要做更实时的在线状态可以缩到 2 秒 2 次代价是心跳流量翻倍。别把间隔设成 1 秒以下局域网里几十个节点互相心跳会把带宽吃满。4. 文件传输与并发单线程为什么一定会卡4.1 大文件分块传输的设计即时通信系统一般都要支持发文件。直接把整个文件读进内存再发遇到几百 MB 的文件内存直接爆掉。正确做法是分块先发文件元信息文件名、大小、哈希再按固定块大小循环发送接收方按块写入临时文件收完后校验哈希再改名。CHUNK_SIZE 64 * 1024 # 64KB 一块 def send_file(conn, filepath): filesize os.path.getsize(filepath) filename os.path.basename(filepath) meta json.dumps({name: filename, size: filesize}).encode() send_message(conn, 0x02, meta) with open(filepath, rb) as f: while True: chunk f.read(CHUNK_SIZE) if not chunk: break send_message(conn, 0x03, chunk) send_message(conn, 0x03, b) # 空块作为结束标志参数说明CHUNK_SIZE选 64KB 是常见折中太小则每条消息头部开销占比高太大则单次sendall阻塞时间长影响同一连接上的文字消息实时性。如果要做进度条接收方用「已收字节数 / 元信息里的总大小」计算即可。4.2 多连接并发模型一个节点可能同时和多个节点保持连接还要监听新连接、跑心跳、处理 UI 事件。单线程顺序处理必然卡。常见方案有两种一是每连接一个线程简单直观几十个节点规模够用二是用selectors做 IO 多路复用单线程管理所有连接资源占用低但代码复杂。import threading def accept_loop(server_sock): while True: conn, addr server_sock.accept() t threading.Thread( targethandle_connection, args(conn, addr), daemonTrue) t.start() # 每连接一线程daemon 保证主程序退出时线程不阻塞 def handle_connection(conn, addr): peer_id do_handshake(conn) # 先握手拿到对方 ID register_connection(peer_id, conn) recv_loop(conn, dispatch_message)逻辑说明daemonTrue很关键否则主窗口关闭后这些线程还在跑进程退不出去。线程模型下共享的节点表、连接表要加锁dict在多线程读写时不是线程安全的Python 的 GIL 只保证单条字节码原子不保证复合操作。提示如果课设要求支持 50 个以上节点线程模型会开始吃力每个线程默认 8MB 栈空间100 个线程就是 800MB 虚拟内存。这时候该上selectors或者asyncio但课设规模一般用不上。4.3 消息去重与顺序P2P 网络里同一条消息可能因为重传到达两次接收方要能去重。简单做法是每条消息带一个发送方生成的递增序号接收方维护「已见过的最大序号」小于等于它的直接丢弃。顺序问题在单条 TCP 连接上由 TCP 保证但跨连接比如一个节点通过两条路径收到同一消息就需要应用层序号来兜底。5. 避坑与排查那些让课设演示当场翻车的细节5.1 广播发了但一个节点都发现不了现象程序启动后节点列表一直空的日志显示广播包发出去了。原因通常是三层一是防火墙拦了 UDP 入站Windows 默认会弹窗询问很多人点了「取消」二是机房交换机隔离了广播域每个端口一个 VLAN三是绑定地址写成了127.0.0.1而不是0.0.0.0只收本机回环。解决先关防火墙测一次确认是防火墙问题就加例外规则交换机隔离没法改只能退回手动输入 IP绑定地址一律用或0.0.0.0。5.2 连接建立成功但消息发不出去现象create_connection返回成功sendall也不报错但对方就是收不到。原因多半是握手包没发或者对方没解析。TCP 连接建立只代表三次握手完成不代表应用层协议对齐。如果发起方连上后不发握手包接收方的recv_loop一直在等数据节点表里也没有这条连接的归属。解决连接建立后立即发送带自身 ID 的握手包接收方在recv_loop第一条消息必须是握手类型否则断开。5.3 传文件中途卡死现象小文件正常超过几十 MB 就卡住不动。原因是发送方sendall阻塞——TCP 发送缓冲区满了接收方处理慢形成背压。如果发送方和接收方在同一个线程里既发又收就会死锁发送方等接收方读接收方在等发送方发。解决发送和接收必须在不同线程或者用非阻塞 IO。另外接收方写磁盘如果很慢比如机械硬盘也会拖慢整个链路可以考虑先写内存缓冲再异步落盘。5.4 节点 ID 冲突导致连接错乱现象两个节点互相认为对方是自己消息发串了。原因是 ID 生成用了时间戳或者随机数碰撞概率虽小但存在尤其在虚拟机克隆场景下多台机器可能拿到相同的随机种子。解决ID 用uuid4()生成或者用「IP 端口 启动时间戳」的哈希保证全局唯一。节点表用 ID 做 key收到握手包时如果 ID 已存在且 IP 不同说明冲突主动断开较新的那条。5.5 程序退出后端口被占用现象关掉程序再启动报Address already in use。原因是 TCP 连接进入TIME_WAIT状态默认持续 2 倍 MSL约 60 秒。解决监听 socket 设SO_REUSEADDR这是标准做法。UDP 端口同理。如果还不行检查是不是有残留进程没退干净daemon线程没设的话主进程退了子线程还在端口自然没释放。6. 进阶技巧把课设做成能讲清楚的作品课设答辩最怕的是「能跑但说不清」。我一般会额外做两件事让整个系统从「能演示」变成「能讲原理」。第一件是加一个可视化的节点拓扑面板。不用多复杂把节点表里的(id, ip, 连接状态)画成一张图谁连着谁一目了然。答辩时老师问「P2P 体现在哪」直接指着图说「这两台机器之间是直连的 TCP消息不经过任何中心节点」比嘴上解释十句都管用。实现上用 Python 的tkinter.Canvas或者前端d3.js都行数据源就是节点表和连接表。第二件是给消息协议加一个抓包验证环节。用 Wireshark 过滤udp.port 37020看广播发现过滤tcp.port 你的监听端口看握手和消息帧。把抓包截图放进报告证明「长度前缀定界」确实生效每个 TCP 段里能看到CA FE开头的头部。这一步能直接回应「你怎么保证不粘包」这类追问。验证项工具观察点节点发现Wireshark udp.port37020周期性广播包源 IP 和端口连接建立Wireshark tcp.port监听端口三次握手 握手包消息定界Wireshark 跟随 TCP 流每帧以 CA FE 开头长度字段正确心跳离线程序日志 抓包5 秒间隔心跳3 次丢失后断开最后说个我自己的习惯每次改完协议或者并发模型先写一个「双节点本地回环测试」——同一台机器起两个实例一个绑127.0.0.1:8001一个绑127.0.0.1:8002手动指定对方 IP跑通发消息、传文件、断线重连三个用例再上真机。这个习惯帮我省掉了无数次在机房里两台机器之间来回跑的麻烦。P2P 这东西本地回环能跑通不代表局域网能跑通但本地都跑不通局域网一定跑不通。希望帮到你。本文还有配套的精品资源点击获取