P2P局域网即时通信系统从零实现：UDP发现、TCP通信与文件传输

简介：广工计算机网络课程设计中的基于点对点（P2P）的局域网即时通信系统，是一份完整的Java课程设计源码包，面向计网课设学生，解决局域网内图形化即时通信需求。系统采用P2P架构，程序同时扮演服务器与客户端，服务端口3333，支持用户自定义用户名与所在组，启动后自动扫描网段内在线对等方并维护动态列表，用户可从列表中选择对象建立TCP连接，实现消息与文件传输；消息格式可自定义，至少包含用户名和IP地址。界面包含对等方列表、消息显示区域、输入框及文件传输进程控制按钮，整体覆盖课程设计常见要求。包内共158个文件，以Java源码、.class编译文件、XML配置、Properties资源配置为主，同时附带工程配置文件、文档说明和日志等，压缩包20.77MB，目录结构清晰，可导入常见Java IDE进行阅读与二次开发。内容预览显示包含聊天窗口、文件发送适配、IP扫描与接收、服务端线程等核心模块源码，从界面布局到网络通信均有实现，便于深入理解点对点通信细节，目前已有426人学习，适合作为计算机网络课程设计或局域网通信项目的参考与扩展基础。

1. 基于P2P的局域网即时通信系统：从课设要求到可运行方案的完整拆解

某高校计网课设里有一道很经典的项目：做一个局域网内的即时通信系统，要求程序既是服务器又是客户端，走P2P模式，服务端口固定3333。很多人第一反应是把每个客户端都连到一个中心服务器上，结果写完才发现课设明确要求"对等方"概念——每个节点自己要能发现别人，也要能被别人发现，根本没有中心节点这个东西。这道题真正考察的不是TCP收发消息，而是"没有中心服务器的情况下，节点之间如何完成发现、注册、通信"这三件事。笔者带过几轮类似的项目，也帮A同学调试过同一道题，这里把整套方案按"需求拆解→架构设计→模块实现→避坑排查→验收答辩"的顺序完整展开，读者可以拿这份方案直接作为课设说明书或答辩底稿。

先看题目给的功能约束：图形界面、P2P消息系统、端口3333、用户注册及对等方列表获取、扫描网段在线对等方、发送消息和文件，界面要包含对等方列表、消息显示列表、消息输入框、文件传输进度显示。这些约束已经框定了实现边界——端口固定说明所有节点都在同一个局域网网段内通信，P2P说明每个节点都有对称的收发能力，界面要求说明不能做成纯命令行工具。这套方案最终落地为Java实现，原因在后面的技术选型里会讲清楚，但它同样适用于C#、Python等任何支持Socket编程的语言，读者需要的是结构，不是某种语言的死记硬背。

2. 总体架构设计：三层结构、双通道模型与五类消息格式

2.1 双通道模型：为什么发现走UDP、通信走TCP

这道题最容易翻车的设计决策是通道选择。题目要求"扫描网段中在线的对等方（3333端口打开）"，如果全部用TCP连接去探测，每个节点都要维护大量的半开连接，而且TCP的握手开销在局域网内虽然不大，但多节点同时探测时会产生大量TIME_WAIT状态，导致端口耗尽。更合理的做法是：发现阶段用UDP广播，通信阶段用TCP连接。

具体来说，每个节点启动后在3333端口创建两个Socket：一个UDP Socket用于接收和发送广播报文，一个ServerSocket用于监听TCP连接。UDP负责"谁在线"的发现与应答，TCP负责"消息和文件"的可靠传输。这个设计和TCP/IP协议栈的分工天然吻合——UDP面向无连接、开销小、适合广播探测，TCP面向连接、可靠有序、适合实际数据传输。课设答辩时如果老师问"为什么不用TCP做发现"，这个回答就够用了。

这里有个容易忽略的点：ServerSocket监听的是3333端口，UDP Socket绑定的也是3333端口，但UDP和TCP的端口空间是独立的，互不冲突，所以不需要用两个不同的端口号。很多同学担心"端口被占用"，其实只要把UDP Socket和ServerSocket分别绑定到同一个端口号即可，系统层面完全允许。

2.2 三层模块划分：界面层、协议层、传输层的职责边界

整个系统按三层来组织，层与层之间通过接口交互，避免把所有逻辑堆在事件监听器里。界面层负责对等方列表的刷新、消息显示、输入框和文件进度条；协议层负责消息的编解码、类型识别、序列化和反序列化；传输层负责UDP广播、TCP连接管理、文件分块读写。

对等方列表的数据结构建议直接用ConcurrentHashMap，键为IP地址，值为对等方信息对象，包含用户名、IP、分组、最后活跃时间。用ConcurrentHashMap而不是HashMap的原因是多线程环境下对等方发现线程、心跳线程、界面刷新线程会同时读写这个列表，HashMap在并发修改时会抛出ConcurrentModificationException。A同学第一版就用HashMap，运行几分钟后列表刷新异常，换成ConcurrentHashMap后问题消失——这是多线程编程里最典型的坑。

2.3 五类消息格式与自定义协议定义

题目允许自定义消息格式，但要求至少包含用户名和IP。实际设计时建议定义五个消息类型：注册请求、注册应答、在线通知、文本消息、文件元信息。消息格式采用"类型标记 + 长度前缀 + 字段体"的结构，各字段用竖线分隔。

一个参考的消息体结构是：MSG_TYPE|FROM_NAME|FROM_IP|TIMESTAMP|LENGTH|PAYLOAD。比如注册请求是REG|Alice|192.168.1.10|2025...|0|，文本消息是CHAT|Alice|192.168.1.10|2025...|5|Hello。协议解析时按照竖线拆分，第0个字段决定消息类型，最后一个字段是真正的载荷。字段间用分隔符而不是固定长度，因为用户名和消息内容长度不固定，固定长度会浪费空间，分隔符方式简单且易调试。

文件传输不能走这种文本消息格式，文件内容可能包含任意字节，直接拼进竖线分隔的文本里会破坏解析。文件传输单独走一条TCP连接，先发送一个JSON或自定义文本格式的文件元信息，包含文件名、大小、发送方用户名，然后再发送原始二进制流。接收方先读元信息，再按字节流读取文件内容。

2.4 线程模型：心跳、发现、消息监听三条线程的分工

线程模型设计成三条业务线程加若干连接线程。第一条是UDP监听线程，循环阻塞在DatagramSocket.receive()上，收到广播报文后解析并处理；第二条是TCP监听线程，循环阻塞在ServerSocket.accept()上，每接受一个连接就新建一个处理线程；第三条是心跳线程，每隔3秒向已知对等方发送心跳报文，同时剔除超过10秒未响应的节点。

界面刷新不能占用主线程。Swing的Event Dispatch Thread负责界面绘制，网络线程不能直接调用界面组件的更新方法，否则会界面卡死。标准做法是利用SwingUtilities.invokeLater()把列表刷新操作提交到EDT线程。文件传输进度条也走这个机制，传输线程计算百分比后投递到EDT更新进度条，而不是直接在传输线程里setValue()。

3. 核心技术实现：注册发现机制、消息收发通道与文件分块传输

3.1 对等方发现机制：UDP广播注册与应答的完整流程

对等方发现是整套系统的核心，它解决的是"我如何知道局域网里有哪些人和我在同一个程序里"。流程分为三步：广播注册、接收应答、加入列表。程序启动后，用户先设置用户名和分组，随后节点构造一个注册请求报文，通过UDP广播发送到255.255.255.255:3333，并等待应答。局域网内所有监听3333端口UDP Socket的节点都会收到这条广播。收到广播的节点解析出对方的用户名和IP，把它加入自己的对等方列表，然后向对方的3333端口发送一条单播应答报文。发起方收到应答后，把应答方加入自己的列表。

// 广播注册请求的关键实现 public void sendRegisterBroadcast(String userName, String ip) throws IOException { DatagramSocket socket = new DatagramSocket(); socket.setBroadcast(true); String msg = "REG|" + userName + "|" + ip + "|" + System.currentTimeMillis() + "|0|"; byte[] data = msg.getBytes(StandardCharsets.UTF_8); DatagramPacket packet = new DatagramPacket(data, data.length, InetAddress.getByName("255.255.255.255"), 3333); socket.send(packet); socket.close(); }

这段代码的要点是setBroadcast(true)必须开启，否则广播报文不会发出；目标地址用255.255.255.255，这是子网广播地址，局域网内所有节点都会收到。socket.close()放在发送完成后立即释放，避免扫描结束后遗留无用的Socket。真实场景下，路由器是否允许广播转发会影响结果，但局域网内交换机直接转发广播帧，所以这个机制在单个局域网内是可靠的。

接收广播的核心逻辑在UDP监听线程里，循环调用receive()后解析报文类型。如果是REG请求，则把发送方加入本地列表，并回发一条REG_ACK应答；如果是REG_ACK应答，则把应答方加入本地列表。列表更新操作需要加锁，因为广播监听线程和TCP处理线程可能同时操作列表。

3.2 点对点文本消息：TCP连接建立与JSON消息格式的发送流程

文本消息走点对点TCP连接，发送方从对等方列表中选中目标节点，动态创建一个TCP连接，发送消息后关闭连接。每次发送都新建连接的好处是逻辑简单，不需要维护连接池；缺点是频繁建连有一定开销，但局域网内这个开销完全可以忽略。

// 发送文本消息的实现 public void sendMessage(String targetIp, String content, String fromUser) throws IOException { Socket socket = new Socket(targetIp, 3333); DataOutputStream out = new DataOutputStream(socket.getOutputStream()); String msg = "CHAT|" + fromUser + "|" + getLocalIp() + "|" + System.currentTimeMillis() + "|" + content.getBytes().length + "|" + content; out.writeUTF(msg); out.flush(); socket.close(); }

这里用writeUTF而不是write，因为writeUTF会自动写入两个字节的长度前缀，接收方用readUTF就能完整读回消息，避免粘包问题。消息内容用getBytes().length计算字节长度，因为中文字符在UTF-8下占3个字节，直接content.length()得到的是字符数，两者在粘包拆包时会出现偏差。接收方在TCP处理线程里先readUTF拿到完整字符串，再按竖线拆分解析字段。

3.3 文件传输模块：元信息握手与分块读写、进度回调的实现

文件传输是这道题最容易卡壳的点。很多人的第一版实现是直接把FileInputStream复制到SocketOutputStream，接收方不知道文件多大、文件名是什么，无法正确落盘。正确做法是两个阶段：先传元信息，再传文件字节流。

// 文件发送方：先发元信息JSON，再分块发送文件内容 public void sendFile(String targetIp, File file, String fromUser) throws IOException { Socket socket = new Socket(targetIp, 3333); DataOutputStream out = new DataOutputStream(socket.getOutputStream()); String meta = "FILE|" + fromUser + "|" + getLocalIp() + "|" + System.currentTimeMillis() + "|" + file.length() + "|" + file.getName(); out.writeUTF(meta); out.flush(); byte[] buffer = new byte[8192]; try (FileInputStream in = new FileInputStream(file)) { int len; while ((len = in.read(buffer)) != -1) { out.write(buffer, 0, len); // 进度百分比在此计算，通过回调通知界面更新 } } out.flush(); socket.close(); }

接收方的逻辑是：readUTF读取元信息，解析出文件名和大小，创建FileOutputStream，然后循环read文件内容直到读到的字节数等于元信息里声明的大小。这里必须记录已接收字节数，否则无法知道文件是否传输完。传输完成后，FileOutputStream关闭，TCP连接关闭。

文件传输进度计算是(已传字节数 / 文件总字节数) * 100，这个值不能直接在传输线程里更新进度条，要通过SwingUtilities.invokeLater()提交到EDT线程执行。界面上的文件传输进程显示区域建议定义为一个表格或列表，每一行代表一个传输任务，包含文件名、目标IP、进度条、取消按钮。

3.4 对等方列表实时维护：UDP心跳保活与超时剔除的策略

对等方列表不是静态的，节点随时可能下线，所以需要心跳机制。心跳线程每隔3秒广播一条HEARTBEAT消息，内容包含用户名和IP；收到心跳的节点更新列表中该节点的最后活跃时间。每次心跳广播后，遍历列表，剔除最后活跃时间超过10秒的节点，并刷新界面。

心跳间隔和超时阈值需要配合调。间隔太短（如500毫秒）会占用大量带宽，且局域网内广播风暴风险高；间隔太长（如30秒）则列表更新不及时，用户看不到节点下线。笔者的经验值是心跳3秒、超时10秒，即连续3次心跳未收到就剔除。实际测试中这个参数在20个节点规模下表现稳定。界面刷新频率建议每秒一次或仅在列表变化时刷新，不要跟随每次心跳刷新，否则界面会频繁重绘导致闪烁。

// 心跳线程的核心逻辑示意 while (running) { broadCastHeartbeat(); long now = System.currentTimeMillis(); for (Peer peer : peerList.values()) { if (now - peer.getLastSeen() > 10000) { peerList.remove(peer.getIp()); } } SwingUtilities.invokeLater(() -> refreshPeerListUI()); Thread.sleep(3000); }

列表遍历时不能直接在遍历过程中删除元素，否则会抛ConcurrentModificationException。上面代码用peerList.values()遍历再remove，在ConcurrentHashMap下是安全的，因为它的弱一致性迭代器允许遍历过程中删除。如果换用普通HashMap，这里就需要先收集要删除的key再统一删除。

4. 网络编程避坑指南：五个最容易翻车的技术点与排查路径

4.1 端口绑定失败：提示"Address already in use"的常见原因

现象：程序启动时报java.net.BindException: Address already in use: bind。原因有三个：上一次程序异常退出，Socket没有释放，端口处于TIME_WAIT状态；或者同一台机器上启动了两个程序实例；再者是UDP Socket绑定失败，因为某个程序实例已经占用了3333端口的UDP或TCP空间。解决：杀掉残留的Java进程，用netstat -ano | findstr 3333查看占用端口的进程PID并终止；代码里对bind异常做捕获并给出友好提示，而不是直接打印堆栈后退出。

4.2 广播包能收到但程序收不到：防火墙拦截UDP报文

现象：A节点广播后，B节点没有任何反应，但B节点如果开启抓包工具能看到UDP报文到达了网卡。原因：Windows防火墙默认拦截未授权的UDP入站报文。解决：开发调试时在防火墙入站规则里放行3333端口的UDP和TCP协议；如果是正式演示，预先在目标机器上执行netsh advfirewall firewall add rule name="P2P Chat" dir=in action=allow protocol=UDP localport=3333，TCP同理。这个操作要在演示前完成配置，否则现场答辩时演示翻车。A同学就遇到过一次：程序在本机能跑，换到另一台演示机就找不到对等方列表，一查就是防火墙拦截。

4.3 TCP粘包导致消息解析错乱：出现半个消息或合并消息

现象：连续发送两条消息，接收方第一次解析得到的字符串是两条消息拼在一起，或者一条消息被拆成两半。原因：TCP是字节流协议，没有消息边界，多个write的数据可能被合并成一个包传过来，也可能一个write的数据被拆成多个包。解决：用writeUTF和readUTF配对读写可以解决大部分问题，因为writeUTF自动写入2字节长度前缀，readUTF会先读取长度再按长度读取内容。文件传输阶段不需要writeUTF（二进制流没有UTF编码的概念），要自行维护已接收字节数的计数，读够大小就停止。

4.4 界面卡死或假死：网络操作阻塞了EDT线程

现象：点击"发送消息"按钮后界面无响应，鼠标变成转圈状态，几秒后才恢复。原因：网络I/O操作写在了按钮的事件监听器里，socket.connect()或FileInputStream.read()阻塞了Swing的事件处理线程。解决：所有网络操作必须放到后台线程执行，事件监听器只负责启动线程并返回。可以简单封装new Thread(() -> sendMessage(...)).start()，或者用ExecutorService提交任务。文件传输尤其要放后台线程，因为大文件的read和write会长时间占用CPU和网络。

4.5 对等方列表不同步：一侧看到对方在线，另一侧看不到

现象：A能看到B在线，B却看不到A。原因：注册请求广播和应答的逻辑不对称——A只把收到应答的节点加入列表，而B收到广播就加入列表但没有正确处理应答的发送；或者UDP广播做了socket.setBroadcast(true)，但应答发送时用的是另一个没有开启广播的Socket，导致应答发不出去。解决：检查应答发送是否使用了连接到对方IP的单播方式（不需要广播标志），并确认注册请求和应答的处理逻辑对称。调试时可以打印日志，把每次收发的消息类型和IP地址输出到控制台，对照两端日志排查哪一步断了。

5. 界面设计与系统联调：从可运行到可演示的完整交付

5.1 界面布局：对等方列表、消息区、输入框与传输进度区的分区设计

图形界面的框架由题意直接决定：对等方列表、消息显示列表、消息输入框、文件传输进程显示区，四个区域缺一不可。布局建议用BorderLayout：左侧放对等方列表（JList或JTable），右侧中间放消息显示区域（JTextArea，只读模式），底部放消息输入框和发送按钮，最底部或侧边放文件传输进度区。

对等方列表建议用JTable而不是JList，因为每个对等方除了名字还有IP和分组信息，JTable可以展示多列。双击列表项可以触发发送文件的操作，单击或选中后点击"发送消息"按钮则进入文本聊天。消息显示区域要支持滚动，用JScrollPane包裹JTextArea，设置setEditable(false)。聊天消息格式按照[用户名] [时间]: 内容的格式追加显示，便于阅读。

文件传输进度区用JTable加自定义渲染器实现每一行的进度条。进度条JProgressBar嵌入到表格单元格里，传输过程中更新这一行的进度值。每个传输任务行显示文件名、对方IP、进度百分比和取消按钮。取消按钮需要维护一个传输控制标志，线程在读取文件每个分块前检查标志，如果被置为取消则终止发送并关闭Socket。

5.2 系统联调流程：两台机器测试到十台机器压力测试的标准步骤

联调测试要按从简到繁的顺序走，不要直接开十个实例做全量测试，否则问题堆在一起没法定位。第一步是单机双实例测试，在同一台机器上启动两个程序实例，使用不同的用户名，验证发现、消息、文件传输三个功能是否正常。单机测试能排除网络和防火墙干扰，最容易定位代码逻辑问题。

第二步是双机局域网测试，用两台真实机器或两台虚拟机桥接网络，分别设置不同IP，验证UDP广播是否真能穿透到另一台机器。这一步验证防火墙和网络配置，同时观察对等方列表是否在两台机器上双向同步。第三步是多节点测试，用四台以上机器同时在线，观察心跳保活和超时剔除是否正常，连续运行半小时以上看是否会内存溢出或Socket泄漏。最后一步是文件传输压力测试，传输一个100MB以上的大文件，观察进度条是否平滑更新，接收端文件是否完整（用MD5校验）。

5.3 主要功能清单与运行验证矩阵

5.4 效果演示的组织方式：串行脚本化演示优于随机操作演示

答辩演示时最忌讳的是现场随机点按钮，因为不可控因素太多。建议准备一个串行演示脚本：启动节点A（命名为Alice），设置用户名后截图记录；启动节点B（命名为Bob），等待3秒让列表互现，此时切到A的界面截图；A向B发送一条文本消息，B回复一条消息，截图确认消息区；A向B传输一个文件，在传输过程中截图进度条，传输完成后在B侧打开文件确认内容；最后关闭B节点，回到A界面等待10秒，确认B从列表中消失。整个演示过程大约5分钟，每个关键节点都截图，裁判或导师不需要看你操作细节，只需要看到结果符合预期。

演示前强制检查的项目包括：防火墙规则已配好；所有机器的IP在同一网段；测试文件放在桌面上；两台机器的输出控制台窗口提前打开。检查完再开始演示，避免现场手忙脚乱。

6. 验收与答辩策略：评分标准拆解、演示顺序与高频追问预答

6.1 课设评分结构与得分点权重分配

计网课设的评分通常分成四块：功能完整性与稳定性、协议设计合理性、代码结构规范性、现场演示与问答表现。其中功能实现是基础分，占大头；协议设计是区分度分，决定优秀还是良好；问答表现决定答辩是否顺利。

具体来说，功能分至少要覆盖题目列出的全部功能点：注册、发现、消息、文件传输、界面分区，缺一个功能直接掉档。协议设计分看是否能说清楚UDP和TCP的分工、消息格式的设计理由、粘包和拆包的处理方式。代码规范性看是否有分层、是否避免了在EDT线程做网络操作、是否处理了资源释放。问答表现没有固定标准，但老师通常会问实现细节和设计决策依据，比如为什么要广播、广播和组播的区别、TCP三次握手和四次挥手在这个系统里发生在哪一步。

6.2 现场演示的执行顺序：先功能后异常，先简单后复杂

演示顺序建议按"核心功能→协同功能→容错能力"排列。先演示单机启动和列表自发现，让老师明白这个程序启动后就会自动扫描局域网；再演示双节点消息收发，这一步是最稳妥的得分点；然后演示文件传输，重点展示进度条和接收端文件落盘；最后演示异常场景——关闭一个节点，展示另一侧列表自动剔除。

文件传输放在演示的中后段的原因是大文件传输耗时长，如果放在最前面，演示节奏会被拖慢。容错演示放在最后，即使超时剔除效果不理想，前面的功能得分已经拿到。整个演示控制在8分钟以内，不要展开讲代码细节，等老师提问时再深入。

6.3 高频追问与预设回答：广播、连接生命周期与协议细节

老师最常问的第一个问题是"为什么发现用广播，通信用TCP"。回答的要点是：发现阶段只需要知道"谁在线"，数据量小且对可靠性要求低，UDP广播一条报文就能让全网收到，开销远小于逐个建立TCP连接探测；通信阶段的文本消息和文件内容需要有序、可靠、不丢失，TCP的确认重传机制正好满足。补充一句"广播只发生在发现阶段，实际传输不依赖广播"，能展现对设计的理解。

第二个常见追问是"TCP连接什么时候建、什么时候关"。回答：每次发送消息或文件时动态创建连接，发送完毕后立即关闭。不维护长连接的原因是对等方可能随时下线，长连接保活复杂且节省不了多少开销；动态连接每次握手一次，局域网内握手耗时可忽略。老师如果追问"频繁建连会不会性能差"，可以答"文件传输的单次建连开销相对于文件传输时间占比极小，文本消息则本来就要求低延迟"。

第三个追问是"如果局域网内节点超过几百个，广播机制会有什么问题"。回答：广播会占用大量带宽，每个节点的广播会被全网收到，节点规模大时产生广播风暴。这是这个设计方案适应的场景限制——题目限定局域网，节点规模通常不超过几十个。顺势可以提一句"如果要扩展到大规模网络，应改用组播或引入目录服务器"，体现你知道方案的边界在哪里。

6.4 验收习惯：从那次演示翻车后我固定执行的检查单

有一年组里的项目演示翻车，原因特别低级：演示机的防火墙弹窗在后台挂着，广播报文被拦截，现场两台机器互相看不到。从那以后，笔者每次做局域网联调都强制走一遍检查清单：两台机器先ping通，确认二层和三层的可达性；用telnet IP 3333检查TCP端口是否可达；用命令行工具或一个小脚本发送UDP测试包确认UDP端口可通过防火墙；所有机器的系统时间同步，避免日志定位时时间错乱。这套检查单5分钟能走完，但能把现场翻车的概率降到接近于零。希望帮到正在做这道课设的你——方案的价值不在代码写了多少，而在每一步决策是否有依据、出现异常是否能定位，这份文档至少给出了一个不需要踩坑就能落地的完整路径。

本文还有配套的精品资源，点击获取