简介面向南京信息工程大学计算机网络课程设计该资源为Socket局域网通信软件完整项目内含可运行的程序源码与配套课程设计报告。软件实现一对一私聊、群聊及文件发送三大功能深入涉及TCP/IP协议栈应用层开发、多线程并发处理、文件分包传输与重组等关键网络编程知识点适合高校计算机网络课程设计参考也适合希望系统掌握Socket通信开发的初学者研习。压缩包以zip格式打包大小5.09MB主要包含项目源码、配置文件及报告文档报告完整记录需求分析、系统设计、编码实现、测试调试和性能优化建议等环节。目前已有337人学习借助该资源可以快速梳理局域网通信软件的完整开发流程掌握Socket接口、线程池管理、数据包收发与文件重组的典型实现方法是理论与实践结合的优质课程设计范例。1. Socket局域网通信软件私聊、群聊、文件发送和报告一次填平的全套资源如果你正在找计算机网络课程设计的现成素材大概率见过两类东西一类是只能两个人来回发一句话的 demo另一类是代码能跑但报告和代码对不上号的拼凑包。这份南京信息工程大学计算机网络课程设计完整包不一样它把 Socket 局域网通信软件的私聊、群聊、文件发送三条功能链路都做齐了还带一份能直接对着代码讲解的课程设计报告。它能解决的不只是“能跑”而是“能讲”答辩老师问多线程为什么这么开、大文件为什么分包、在线列表要不要清理答案都在源码和报告里。适合两类人一类是想在期末项目上少折腾、快速拿到完整可运行工程的同学另一类是已经在写自己的 Socket 程序需要对照成熟方案找边界的比如心跳超时、并发写锁、文件分包这些细节。2. 先看整体框架服务端与客户端职责边界、启动顺序和最小验证闭环写 Socket 课程设计最怕的就是把服务端和客户端写成一个 class所有逻辑堆在 main 方法里。这份包里服务端、客户端、公共协议是分开的我一般拿到手先不急着改功能而是把每份文件按职责归位再跑一遍最小链路确认这条链路通了才往下看。2.1 服务端与客户端的角色谁监听、谁连接、谁维护在线列表服务端负责三件事绑定端口并监听、接收客户端的连接请求、为每个连接分配处理线程并维护在线列表。客户端则只负责发起连接、发送消息、接收消息。理解这个边界非常重要因为答辩时最常见的追问就是“断开连接后服务端怎么知道”如果你把在线列表写在客户端里这个问题基本答不上来。服务端的主循环通常长这样以 Java 实现为例换到你手里那份包的语言也是一样的逻辑ServerSocket serverSocket new ServerSocket(8888); // 监听8888端口 while (true) { Socket client serverSocket.accept(); // 阻塞等待客户端连接 int clientId idGenerator.incrementAndGet(); // 生成全局唯一客户端编号 onlineClients.put(clientId, client); // 加入在线列表 new Thread(new ClientHandler(client, clientId)).start(); // 每个连接一个线程 }这段代码的关键在accept()。它是个阻塞调用没有客户端连接时线程挂在这里不占 CPU一旦有连接进来它返回代表该连接的 Socket 对象。之后的收发都不能在这个循环里做否则一个客户端发消息会把所有其他客户端的处理都卡住所以必须new Thread单独处理。这里有两个参数值得你调一调。第一个是端口号 8888局域网内不冲突即可服务端和客户端必须一致第二个是ServerSocket内部的 backlog默认 50含义是“还没被 accept 的连接队列长度”做课程设计 50 绰绰有余但你要是把课堂演示改成几十台机器同时连这个值就该调大否则超过排队上限的连接会被内核直接拒绝。提示如果手里那份包是 C# 写的连接管理的整体思路没有区别只是收发有同步和异步两套写法BeginReceive 回调那一套但“每个连接一个处理线程”的模型是一样的下文的心跳、分组逻辑可以直接平移。2.2 启动顺序先服务端后客户端这个顺序为什么不能反# 1. 先启动服务端参数分别是监听地址和端口 java -jar ServerApp.jar 0.0.0.0 8888 # 2. 再启动客户端指向服务端所在机器的局域网IP java -jar ClientApp.jar 192.168.1.100 8888 # 3. 先发一条私聊文本验证链路再测文件发送顺序不能反的原因很直接客户端 connect 时服务端必须在监听状态否则底层直接抛ConnectException: Connection refused。这个异常是 Socket 踩坑第一课。如果你在 Windows 下演示注意 Windows 防火墙第一次运行会弹窗记得勾选“专用网络”允许否则客户端会一直卡在连接超时看起来像是代码写错了其实是防火墙在中间做拦截。跑通最小闭环之后你的验证目标是服务端在线列表出现一个客户端编号客户端能收到服务端广播的“欢迎上线”消息两边互发一条文本不丢字。这个闭环通了说明 TCP 连接和基础读写没问题后面加群聊、文件发送都是在上面扩展。如果在这里就卡住优先检查 IP 是否写对、端口是否被占不要往下走。双机联调时有几个隐藏注意点。同一台机器测试用127.0.0.1没问题但换到两台真实机器时客户端里的 IP 必须是服务端那台机器的局域网地址可以用ipconfig查。另外服务端监听地址写0.0.0.0表示接受所有网卡上的连接写127.0.0.1则只能本机连想给隔壁宿舍演示的话监听地址别写回环地址。2.3 报告里的六部分怎么和代码位置一一对应这份包的价值在于它带的报告不是那种复制粘贴的大路货。报告结构是需求分析、系统设计、编码实现、测试调试、性能分析、优化建议六部分每一部分都能在源码里找到对应位置。需求分析对应的是功能列表——私聊、群聊、文件发送、上线通知这些系统设计对应的是服务端/客户端类图和线程模型图编码实现对应的是 ClientHandler、MessageRouter 这些核心类测试调试对应的是你实际跑过哪些用例、修过哪些 bug。我建议你把报告当作阅读源码的索引来用不要当作交作业的素材。比如报告里写“为避免粘包消息体采用长度头数据”对应的代码就是发送端往流里先写 int 数据长度、再写字节数组。答辩老师大概率不会逐字检查报告但他会问“粘包你怎么处理的”你能指到具体代码行这关就过了。报告每写一句话你都去找代码验证一遍找到的就标注行号找不到就说明报告在吹牛这种报告拿出去反而扣分。3. 私聊与群聊多线程的两种取舍心跳与超时怎么定私聊和群聊虽然都是多线程但思路完全是两个方向。私聊要求连接隔离A 发 B 的消息 C 绝对不能看见群聊要求复制分发一条消息给所有人。这两套逻辑同时存在于一个服务端里自然就引出了线程安全和并发遍历的问题。3.1 一对一私聊独立线程连接私密性由连接隔离保证私聊的经典实现是“每对客户端一条专线”。服务端为每个客户端分配了独立的 ClientHandler 线程当 A 要给 B 发消息时服务端在 A 的线程里根据消息里的目标 ID从在线列表里查出 B 的 Socket然后往 B 的连接里写数据。这里的关键是不要让消息经过第三方中转存储否则私聊就名存实亡了。public synchronized boolean sendToUser(int targetId, byte[] data) { Socket target onlineClients.get(targetId); if (target null || target.isClosed()) { return false; // 目标不在线或已断开 } OutputStream out target.getOutputStream(); out.write(data); out.flush(); return true; }synchronized在这段代码里不是可有可无的。两个线程同时调用这个方法时如果不去锁两个消息的字节会在同一个 OutputStream 里交叉接收方读出来的就是一段文字里插着另一段文字的乱文这就是业内常说的“串消息”。这类问题在课程设计演示时尤其容易暴露因为群聊和私聊往往同时进行触发概率非常高。返回值也有讲究。target.isClosed()只是本地视图目标断开但服务端没收到 RST 时isClosed 还是 false要等真正 write 时抛 IOException 才能确认。所以更稳妥的写法是把 write 包在 try-catch 里catch 到 IOException 就从在线列表踢掉目标。这块逻辑可以写进 ClientHandler 里你在报告的性能分析部分也可以顺带提一句“TCP 断开检测存在延迟采用心跳补偿”。3.2 群聊广播在线列表遍历注意并发遍历的坑群聊的模型和私聊完全相反它需要把一条消息复制给在线列表里的所有人。这里有个常见的翻车点广播时如果有人同时下线你正在遍历的在线列表被另一个线程 remove 了直接抛ConcurrentModificationException。for (Integer id : onlineClients.keySet()) { if (id.equals(senderId)) continue; // 不发给发送者自己 Socket s onlineClients.get(id); try { s.getOutputStream().write(msgBytes); s.getOutputStream().flush(); } catch (IOException e) { onlineClients.remove(id); // 发不出去说明连接断了顺手清理 } }这里能把异常写在遍历内部处理掉是因为onlineClients用的是ConcurrentHashMap它的迭代器是弱一致性的允许遍历期间其他线程修改。如果你用普通 HashMap这段代码在群聊人数超过两个、且有人强退时就容易炸查起来还很玄学因为不是每次必现。注意不要在遍历过程中直接调用onlineClients.values()再转成 List 来处理那样要复制整个列表群聊人数多了每次广播都复制浪费内存。直接用 keySet 遍历 单条 get 就够了。参数方面广播复杂度是 O(n)课堂演示几十个客户端毫无压力如果做到上百人循环里逐个 write 就会让发消息的线程阻塞时间变长这时候可以升级成每个客户端一个写队列、由独立写线程消费这就是线程池管理连接池的思路报告的系统设计部分可以这么写。这属于优化建议章节的素材不用一开始就实现。3.3 心跳与超时怎么判断一个客户端真的下线了课程设计里最容易被忽略、也最容易被答辩老师追问的就是“假死连接”。客户端直接被拔网线或断电TCP 不会立刻通知服务端服务端在线列表里这条记录会一直残留群聊消息发给它永远没有响应。我见过不少同学的演示就是栽在这现场断网演示群聊结果消息发到一个死连接上界面没有任何反应。while (true) { Thread.sleep(30000); // 每30秒扫一次 long now System.currentTimeMillis(); for (Integer id : onlineClients.keySet()) { if (now - lastHeartbeat.get(id) 90000) { // 90秒没心跳判离线 onlineClients.remove(id); lastHeartbeat.remove(id); } } }这里的三个参数是配套的客户端心跳间隔 30 秒服务端扫描间隔 30 秒超时阈值 90 秒3 个心跳周期。阈值不能设成 30 秒否则网络抖动一次就把在线用户全部误踢设成 90 秒则能容忍一次心跳丢失。实验室局域网里可以把心跳间隔缩短到 10 秒、阈值 30 秒让断开检测更灵敏但如果你跑在无线网络下建议保持 30/90因为 Wi-Fi 丢包比有线高不少。心跳包本身还可以携带额外信息。我在这个项目里习惯让心跳包带上当前时间戳和客户端版本号这样服务端不仅能判断连接是否存活还能顺便统计消息往返时延。这些数据写进报告的性能分析部分比只贴功能截图更有说服力因为老师能看出你真的理解了连接生命周期的管理。4. 文件发送分包与重组流程以及两个翻车点文本消息和文件发送是两种完全不同的思路。文本可以一次性 write文件不行。这一章把分包、重组、校验三个环节拆开讲并指出我实测中最容易翻车的两个坑。4.1 为什么不能一次 write 完整个文件你往 Socket 里 write 的数据会经过发送缓冲区、TCP 分段、接收缓冲区。Socket 的发送缓冲区默认在几十 KB 量级你把整个文件一次性丢进去底层会截断成多个 TCP 段。接收端如果以为自己能一次 read 完全部只会读到一部分剩下的数据继续留在连接里造成后续消息错位。更隐蔽的问题是阻塞。如果文件大于发送缓冲区write 调用会一直等待缓冲区腾出空间整个发送线程被挂住。课程设计版通常不会专门做异步所以最直观的解决办法是把文件切成小块一块一块地发送、一块一块地接收这就是分包。分包也让你能在数据块之间插入序号和长度信息接收端能校验完整性。4.2 分包发送与接收重组的实现先定义一种简单的报文格式1 字节包类型 4 字节包序号 4 字节数据长度 数据体。固定长度的头部放在每个包最前面接收端先读 9 个字节的头再根据长度读对应数据这样顺便解决粘包问题。发送端读取文件并逐包发送FileInputStream fis new FileInputStream(filePath); byte[] buf new byte[8192]; // 每个包8KB int seq 0; int len; while ((len fis.read(buf)) ! -1) { ByteBuffer packet ByteBuffer.allocate(9 len); packet.put((byte) 0x02); // 包类型0x02代表文件数据 packet.putInt(seq); // 包序号从0递增 packet.putInt(len); // 本包数据字节数 packet.put(buf, 0, len); // 文件数据 socket.getOutputStream().write(packet.array()); socket.getOutputStream().flush(); seq; }接收端每收到一个包头就先看包序号然后按seq * 8192找到写入位置byte[] header new byte[9]; input.read(header); // 先读固定9字节头 byte type header[0]; int seq ((header[1] 0xFF) 24) | ((header[2] 0xFF) 16) | ((header[3] 0xFF) 8) | (header[4] 0xFF); int len ((header[5] 0xFF) 24) | ((header[6] 0xFF) 16) | ((header[7] 0xFF) 8) | (header[8] 0xFF); byte[] body new byte[len]; input.read(body); out.skip(seq * 8192L); // 跳到对应位置 out.write(body);这里需要说明两点。第一包头固定长度是这套方案的立足点接收端靠长度头区分边界这也是文件传输不粘包的关键。第二严格并发场景需要对包序号做检查如果真的出现乱序局域网 TCP 几乎不会但无线网络可能发生简单的做法是接收端先缓存所有包、收齐后按序号落盘而不是边收边写代价是需要额外的临时空间。4.3 包大小、等待策略和校验方式包大小我习惯用 8192 字节原因很简单它是 8KB和常见 Socket 缓冲区大小在一个数量级发送时不会频繁触发 flush再大一些比如 64KB发送线程被阻塞的概率明显上升课程设计没必要去挑战这层。包大小还要和文件名长度、总包数一起在发送前进行一次握手协商接收端才知道一共要等多少包。协商包我一般放在文件传输的第一个包前面接收端收到后先初始化临时文件、分配序号表再进入接收循环。收完最后一块后建议做校验最简单的方案是收发两端各自计算 CRC32发送端把校验值放在“文件结束包”里发过去接收端比对// 发送端发送结束包时附带校验值 byte[] fileBytes ...; // 已发送的文件字节 long crc new CRC32().update(fileBytes); packet.put((byte) 0x03); // 0x03代表文件结束 packet.putLong(crc);第一个翻车点二进制文件用文本流发送。有人为了省事用BufferedReader或DataOutputStream.writeUTF发送文件内容二进制数据被当字符串处理遇到换行符、0x00这些字节就变了结果就是文件传过去能打开但内容错乱。文件传输全程必须用 InputStream/OutputStream 字节流任何 Reader/Writer 都不要碰。这个错我见过不止一次光排查就花了半天。第二个翻车点忽略接收进度确认。不加任何确认机制时接收端少收一包是完全静默的文件写到一半就停了你还要重新传。我在文件发送方案里会加一个“每收 50 包回一个 ACK发送端连续收不到 ACK 就重发”的简化机制代码量不多但对演示稳定性的提升非常明显。报告里要说清这是简化版真正的可靠性传输要参考 TCP 序号和滑动窗口的做法。5. 局域网通信常见问题排查端口占用、消息串台、文件乱码与假死连接这章的内容全部来自实际跑这份代码时踩过的坑每条我都按现象、原因、解决的顺序写。你照着排查能省下大量在答辩前夜对着屏幕发愁的时间。这几个问题也是答辩时老师最爱用来挖坑的点提前排掉心里有底。5.1 “通常每个套接字地址只允许使用一次”是什么鬼现象服务端上次正常退出这次重启直接抛 SocketException报错原文是“通常每个套接字地址(协议/网络地址/端口)只允许使用一次”。原因上次进程结束TCP 连接进入 TIME_WAIT 状态端口还在被内核占用新的 bind 没法立刻接管。Windows 下 TIME_WAIT 最长要等几十秒如果程序是强杀关闭的你会发现端口一直被占重启永远报错。解决在服务端 bind 之前调用serverSocket.setReuseAddress(true);这行代码要放在new ServerSocket(8888)之前。如果还是起不来说明有进程真的占着端口用命令查netstat -ano | findstr 8888 tasklist /fi pid eq 1234 taskkill /f /pid 1234查到 PID 后看是哪个进程确认是残留的旧服务端就强杀。注意setReuseAddress 只能解决重启自身端口的问题不能解决其他进程占用别把这行代码当成万能后悔药。5.2 群聊消息串台现象群聊里 A 发的消息有时候显示在 B 的昵称下甚至一次广播里混进两条消息的内容。原因多个线程每个客户端一个线程同时往同一个客户端的 Socket 写入没有同步更隐蔽的情况是群聊广播正写到一半另一条私聊消息也拿到了同一个 OutputStream两个 write 交错字节在流里混在一起。解决所有写操作统一走一个加锁的发送方法就像第 3 章里的sendToUser加synchronized。如果嫌全局锁影响性能可以改成每个客户端连接维护一个写队列专门的写线程消费队列所有消息只入队不直接写 Socket。课程设计用全局锁就够了但报告里可以写上写队列方案作为优化方向这样项目看起来有“可演进性”。5.3 文本正常、文件一传就乱码现象聊天文本没有任何问题一传文件接收方打开后要么图片花屏要么 Word 提示文件损坏偶尔文件大小还对不上。原因发送端用了文本流处理二进制内容常见写法是BufferedReader.readLine读取文件按行发送。但图片、压缩包这类二进制文件里可能包含0x0A、0x0D这样的字节readLine 会按换行把数据切断重组后文件必然残缺。这跟消息编码搞混是两回事问题出在“把字节流当字符流”。解决文件通道全部改成FileInputStream/FileOutputStream字节流按第 4 章的分包格式发送每个包固定头数据。改完之后再用一张 JPG 和一个大一点的 zip 各传一遍确认字节数和源文件完全一致这个测试用例建议写进报告的测试部分。验收标准很简单fc /b比较两个文件完全一致才算通过。5.4 客户端“假死”服务端一直以为它在线现象聊天窗口关了客户端进程也结束了但服务端在线列表里还显示在线群聊消息也不报错一直发往一个已经断开的连接。原因TCP 是双全工协议连接断开时如果对端没有发送 FIN 或 RST比如拔网线、断电服务端无法感知这个连接就成了半开连接。你往这个 Socket 写数据第一次大概率不报错数据只是进了内核发送缓冲区对端根本不会读。解决心跳机制。客户端每 30 秒发一个心跳包服务端每 90 秒扫一次在线列表超时直接清掉。这套机制我在第 3.3 节写出来了你直接搬过去用。有个小技巧心跳包除了维持连接最好顺带携带当前时间戳这样服务端还能算出消息往返延迟写进性能分析正好。排查时也可以用netstat -ano看连接处于 ESTABLISHED 还是 CLOSE_WAIT 状态CLOSE_WAIT 多的连接基本都是对端已关闭、服务端没感知到的半开连接。6. 拿到这份资源后怎么验证与扩展日志埋点、测试矩阵和抓包排错技巧拿到源码包不要急着改功能。先做 15 分钟的“完整性验证”把全链路打通一次再决定动哪里。这是我拆任何一套课程设计工程的第一习惯能省掉后面几小时的瞎猜。6.1 日志埋点三行日志验证完整链路我一般会在三个位置打日志客户端连接成功、服务端消息转发完成、文件接收结束时。不需要引入 log4j直接System.out.println 时间戳就够System.out.println([CONNECT] clientId 加入在线列表当前在线 onlineClients.size()); System.out.println([FORWARD] fromId - targetId 长度 data.length); System.out.println([FILE] 文件接收完成 fileName 总包数 totalSeq 校验通过);跑一遍私聊、群聊、发文件日志顺序能对上就说明主链路是通的。这份包的完整价值要在日志里体现出来你可以对照报告里的测试调试章节逐条勾选。6.2 测试矩阵把课程设计的验收要求逐条落到用例上场景操作预期结果连接建立启动服务端后启动客户端在线列表出现客户端编号一对一私聊A 发消息给 BB 收到C 收不到群聊广播A 发群消息所有在线客户端收到文件发送A 发 B 一张 JPG文件大小一致、可正常打开异常断开拔网线后群聊90 秒后在线列表清除该客户端以上每条都跑通再去调参数。表格里最后一行的测试尤其重要因为它能帮你验证心跳清理是否生效这是加分项。6.3 抓包验证与后续扩展用 Wireshark 抓一次回环网络或局域网流量过滤条件设tcp.port 8888重点看三次握手以及消息发送时是否有大量重传包。重传多说明包太大或网络不稳先把第 4 章的包大小从 8192 降到 4096 试试。抓包也能直观看到粘包现象如果多个消息在同一个 TCP 段里出现就该检查你的长度头协议是否正确。从那以后我每次拿到一份课程设计源码都会先花 15 分钟做完整链路验证再动参数这个习惯省掉了我至少两三次答辩前的返工。希望帮到你。本文还有配套的精品资源点击获取