简介资源为计算机网络课程配套的聊天室课程设计完整报告面向计算机及相关专业学生、需完成类似课程设计或在线聊天小项目的开发者。报告基于Java环境与JDK1.8围绕注册登录、聊天、文件传输三大功能模块详细阐述需求分析、系统设计、功能流程并给出完整程序源代码及注释。读者可借此掌握ServerSocket与Socket的TCP通信机制、ObjectOutputStream消息封装、多线程处理用户连接等核心知识点同时借鉴报告中流程图与模块划分思路直接复用到自己的课程设计或实战项目中。资源包仅含1个docx文档大小约283KB内容集中、便于阅读与打印。截至目前已有197人学习浏览适合正在编写网络通信类课程设计报告或初学Java网络编程的同学参考。1. 计算机网络聊天室课程设计报告书先想清楚要交付什么再动手写代码计算机网络课到后半程最常见的课程设计就是「局域网聊天室」一组客户端连上一个服务端能发群聊、私聊服务端把消息转发给所有人。题目看着朴素实际是 Socket 编程、TCP 字节流边界、并发安全三个知识点的集中考查。更关键的是这门课最终交的是一份 docx 格式的课程设计报告书代码只是一个附件。我见过不少人把精力全花在让聊天室「能跑」最后两三天熬夜补报告结果答辩时连「消息粘包怎么处理」都讲不清楚。这篇笔记就按选型、协议、编码、避坑、写报告的顺序讲一条能落地、能过答辩的完整路径。2. 服务端架构与消息协议课设聊天室先定这两件事报告才有技术深度上手就写代码是最常见的翻车起点——这样写出来的程序多半只有一个能跑通的群聊没有协议设计也没有并发控制到了写报告时「概要设计」和「详细设计」两章只能靠截图硬凑。聊天室虽然小但有两个决策必须在动手写代码前定下来用哪种 IO 模型以及消息怎么定帧。这两件事直接决定代码规模也决定报告书里最吃篇幅的两个章节怎么填。2.1 BIO、NIO、AIO课设阶段选阻塞式 IO 是性价比最高的决定Java 里做网络聊天室有三条路。BIOBlocking IO是阻塞式——accept 和 read 都会把当前线程挂住来一个连接就开一个线程代码逻辑和教材里 socket 生命周期一一对应。NIONon-blocking IO用 Selector 在一个线程里轮询几千个通道是生产环境的高并发方案AIO 则是操作系统等数据就绪后再回调代码量和心智负担最大。它们的取舍可以用一张表说清楚模型线程数典型连接规模代码量排查难度课设推荐度BIO连接数等于线程数几十到几百小低高NIO固定几个线程加 Selector上千到上万大高低AIO回调线程池上万更大更高不推荐聊天室课设通常也就二三十个客户端BIO 是性价比最高的选择。不管教材用的是谢希仁老师的《计算机网络》还是库罗斯的《计算机网络自顶向下方法》传输层章节讲的 accept、connect、三次握手在 BIO 里都能直接对应到代码行。选 NIO 不是不可以但你要在答辩时把「课设规模为什么还要引入多路复用」这个问题解释过去很难绕。BIO 不是落后是匹配规模这个理由写进报告的「概要设计」里本身就是得分点。2.2 消息帧格式用「4 字节长度 1 字节类型 内容」拆掉 TCP 粘包TCP 是字节流不是消息流。你 send 两次「你好」和「收到」对方一次 read 拿到的可能是「你好收到」反过来一条长消息也可能被拆在两个 read 里。这就是粘包和半包属于计算机网络聊天室最容易翻车的点。常见做法是自定义帧发消息前先写 4 个字节声明「后面这段有多长」接收方按这个长度去凑齐一帧。我给一个最小可行的帧定义字段长度说明消息长度4 字节int 大端序从类型字节到内容末尾的总字节数消息类型1 字节1登录、2群聊、3私聊、4心跳、5退出消息内容可变UTF-8 编码的文本正文编码端用 Java 写是这样// 把一条消息打包成一个完整帧长度头 类型 内容 public byte[] encodeFrame(byte type, String content) throws IOException { byte[] contentBytes content.getBytes(StandardCharsets.UTF_8); // 缓冲区大小 4 字节长度头 1 字节类型 内容字节数 ByteArrayOutputStream buf new ByteArrayOutputStream(4 1 contentBytes.length); DataOutputStream out new DataOutputStream(buf); out.writeInt(1 contentBytes.length); // 长度头里包含类型字段 out.writeByte(type); out.write(contentBytes); return buf.toByteArray(); }这里有两个值得在报告里写清楚的参数决策。第一为什么长度头用 4 字节而不是 2 字节2 字节最大表示 65535一条超过 64KB 的群聊消息会溢出4 字节能覆盖单帧上限也免得答辩时被老师追问边界。第二为什么长度头包含类型字段因为接收端一次 readFully 拿到完整帧后第一字节就是类型不用再做偏移换算。对应的接收逻辑是「先 readInt 拿长度再按这个长度 readFully 读整数帧」具体代码放在第 3 章这里先记住这个约定。2.3 端口、线程模型和在线用户表三个配置决定聊天室能撑多少人端口选 5527 这种高位端口而不是 80、8080一是避免在 Linux 上启动要 sudo 权限二是降低和实验室共用机器上其他服务冲突的概率。线程模型在 BIO 下就是「每连接一线程」这里有个新手很容易踩进去的误区用固定大小的线程池去「省线程」。在阻塞模型里read 会一直占着线程线程池 10 个线程等于同时只能服务 10 个连接第 11 个客户端连上来只能排队或报错。生产环境用 NIO 才配线程池BIO 课设直接 new Thread(handler).start()简单直白报告也好讲。在线用户表用 ConcurrentHashMapString, Socketkey 是登录用户名value 是该用户对应的连接套接字。为什么不用 HashMap一个客户端下线时它的处理线程和广播线程会同时操作这张表HashMap 在并发写时会丢数据甚至死循环。但注意ConcurrentHashMap 只保证单次操作的线程安全不保证遍历时被其他线程修改是安全的这个坑第 4 章专门讲。把这三个配置汇总成一张表可以直接搬进报告参数取值建议理由监听端口55271024 以上避开特权端口和被占用的常用端口线程模型每连接一个线程匹配 BIO 阻塞特点连接数等于线程数在线用户表ConcurrentHashMap处理并发登录和下线字符编码UTF-8避免 GBK、UTF-8 混用乱码消息头长度4 字节 int支持超过 64KB 的长消息这些配置项写进「概要设计·性能约束」小节比贴五十行代码更能体现设计取舍。3. 聊天室核心代码服务端广播、客户端收发、消息分发一次跑通这一章把上一章的协议落成可运行代码。我以 Java 实现为例原因有两个一是 DataInputStream 和 DataOutputStream 天然支持写入 int、readFully 读定长帧处理长度头最方便二是课设报告里 Java 代码可读性最好老师看起来不吃力。用 C 写 recv 要自己维护缓冲区偏移不是不行是没必要在课设里给自己加难度。3.1 服务端骨架ServerSocket 监听 每连接一个线程// 服务端入口监听端口每来一个连接就开一个处理线程 public class ChatServer { private static final int PORT 5527; // 在线用户表key 为登录名value 为该用户的 Socket private final MapString, Socket onlineUsers new ConcurrentHashMap(); public void start() throws IOException { try (ServerSocket serverSocket new ServerSocket(PORT)) { System.out.println(聊天室服务端已启动端口 PORT); while (true) { // accept 阻塞直到一个客户端完成 TCP 三次握手 Socket socket serverSocket.accept(); // 每个连接单独一个线程避免某个客户端的慢操作拖住整个服务端 new Thread(new ClientHandler(socket, this)).start(); } } } }逻辑说明try-with-resources 保证服务端进程退出时 ServerSocket 自动释放accept 每返回一个 Socket代表完成一次 TCP 连接。这里故意没用线程池正如第 2 章所说BIO 下连接数等于线程数每连接一线程是最稳的模型。把 this 传给 ClientHandler是为了让处理线程能访问在线用户表和广播方法这比写一堆静态工具方法清晰得多。3.2 消息循环readInt 读长度头readFully 读完整消息体// 每个客户端连接的处理器负责读取该连接上的完整帧并交给服务端分发 public class ClientHandler implements Runnable { private final Socket socket; private final ChatServer server; private DataInputStream in; private DataOutputStream out; private String userId; // 登录后记录用户名用于私聊寻址 Override public void run() { try { in new DataInputStream(socket.getInputStream()); out new DataOutputStream(socket.getOutputStream()); while (true) { int frameLen in.readInt(); // 阻塞读 4 字节长度头 byte[] frame new byte[frameLen]; in.readFully(frame); // 凑够一帧才返回天然解决半包 // 第一字节是消息类型其余是 UTF-8 正文 byte type frame[0]; String content new String(frame, 1, frame.length - 1, StandardCharsets.UTF_8); server.dispatch(this, type, content); // 交给服务端做分发 } } catch (EOFException e) { System.out.println(userId 连接被关闭); } catch (IOException e) { System.out.println(userId 连接异常: e.getMessage()); } finally { server.removeClient(userId, socket, this); // 无论怎么退出都要清理 } } }逻辑说明readInt 会把线程阻塞到 4 个字节到齐返回的是这帧的总长度。readFully 会继续阻塞直到 frameLen 个字节全部到达所以 TCP 拆包导致的半包问题在这一层就解决了后续处理业务时拿到的永远是一整帧。EOFException 表示对方正常关闭连接IOException 多半是网络中断或进程被杀finally 是兜底清理的关键——这一行直接关系到第 4 章的断线坑。3.3 消息分发群聊广播、私聊点对点、上下线通知// 根据帧里的类型字段分发登录、群聊、私聊、退出 public void dispatch(ClientHandler handler, byte type, String content) throws IOException { switch (type) { case 1: { // 登录 handler.userId content; onlineUsers.put(content, handler.getSocket()); broadcast([系统] content 加入了聊天室); break; } case 2: { // 群聊 broadcast(handler.userId : content); break; } case 3: { // 私聊传输格式为 目标用户|消息正文 String[] parts content.split(\\|, 2); if (parts.length 2) { sendTo(parts[0], handler.userId (私聊): parts[1]); } break; } case 5: { // 主动退出 handler.getSocket().close(); break; } } } // 向所有在线用户广播一条群聊消息 private void broadcast(String text) throws IOException { // 快照遍历先取 key 数组再逐个发送避免遍历中集合被修改 String[] keys onlineUsers.keySet().toArray(new String[0]); for (String key : keys) { Socket target onlineUsers.get(key); if (target null) continue; try { writeFrame(target, text, (byte) 2); } catch (IOException ignored) { // 单个客户端发送失败不影响其他人真正的清理交给 handler finally } } }参数说明私聊消息用 split(\|, 2) 是因为消息正文里可能带竖线把分割次数限制为 2前半段是目标用户名后半段保留完整消息内容keySet().toArray(new String[0]) 生成快照遍历期间其他线程增删在线用户不会影响这次广播。写帧统一走 writeFrame内部就是 writeInt(1 正文UTF-8字节数)、writeByte(类型)、write(正文) 三个操作。removeClient 的逻辑也很简单按 userId 从 map 里移除如果移除成功就广播「xx 已下线」最后关闭 socket它会被 handler 的 finally 调用保证异常路径不遗漏。写代码时有个习惯值得养成广播里每个 socket 单独 try-catch。这个习惯能避免第 4 章里最典型的「一个死连接拖垮整个聊天室」事故。3.4 客户端接收线程和主线程各干各的事// 客户端主线程负责读键盘发送独立线程负责接收服务端广播 public class ChatClient { public static void main(String[] args) throws Exception { Socket socket new Socket(127.0.0.1, 5527); DataOutputStream out new DataOutputStream(socket.getOutputStream()); // 接收线程服务端任何广播都由它打印避免占住主线程 new Thread(() - { try { DataInputStream in new DataInputStream(socket.getInputStream()); while (true) { int len in.readInt(); byte[] frame new byte[len]; in.readFully(frame); System.out.println(new String(frame, 1, len - 1, StandardCharsets.UTF_8)); } } catch (IOException e) { System.out.println(连接已断开); } }).start(); // 主线程先登录再循环发送群聊消息 BufferedReader reader new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8)); System.out.print(输入昵称: ); String name reader.readLine(); sendFrame(out, (byte) 1, name); // 登录帧类型 1 String line; while ((line reader.readLine()) ! null) { sendFrame(out, (byte) 2, line); // 键盘输入全部按群聊发送 } } // 封装发送一帧长度头 类型 UTF-8 正文 static void sendFrame(DataOutputStream out, byte type, String text) throws IOException { byte[] body text.getBytes(StandardCharsets.UTF_8); out.writeInt(1 body.length); out.writeByte(type); out.write(body); out.flush(); } }逻辑说明接收必须放在新线程里——如果主线程先 read 再读键盘read 会一直阻塞你永远打不了字反过来在接收循环里穿插写操作也会因为阻塞而错乱。发送帧的组装和服务端保持一致私聊只需要把 line 按「目标|内容」拆分类型改成 3服务端那边已经定义好了对应逻辑。4. 聊天室实测避坑清单粘包、并发、断线、端口、乱码五条记录程序能跑和经得起折腾是两回事。下面五条是我做聊天室课设时真实踩过、也在帮别人排查时反复遇到的坑。每一条按「现象 → 原因 → 解决」写正好能对应到报告里的「测试与问题分析」小节。4.1 粘包和半包不是每次都出现一出现就是「串台」现象客户端偶尔收到「张三: 你好李四: 在吗」这种两帧拼在一起的内容或者一条很长的消息只显示一半。原因TCP 是字节流发送方调用 write 只是把数据交给内核网络状况、Nagle 算法都可能导致小包合并接收方 read 一次拿到的字节数不确定没有帧边界就是玄学问题——同样的代码有人跑一天没事有人第三分钟就翻车。解决严格按「先读 4 字节长度再按长度 readFully」解析。注意一个细节readFully 必须反复循环直到读满不能只调一次 read因为一次 read 可能只返回几个字节。Java 的 DataInputStream.readFully 内部已经处理了循环所以不用自己写 while。4.2 关掉一个客户端窗口整个服务端的广播「卡死」现象某个客户端被强制关闭后其他人再也收不到群聊消息服务端控制台没有任何异常输出。原因服务端写数据到已关闭的 socket 时会抛 SocketException如果这个异常发生在广播循环中间后面的客户端全部遭殃更隐蔽的是该客户端的 handler 线程如果没在 finally 里移除在线表服务端永远留着这个用户名每次广播都先给死连接写数据然后中断等于一颗定时炸弹。解决广播循环里每个 socket 单独 try-catch写一个失败就跳过继续写给下一个handler 的 finally 里执行 onlineUsers.remove(userId) 并广播「xx 已下线」。两条缺一条都会出事故我一般建议先写 finally 再写广播逻辑因为清理路径比正常路径更容易被忽略。4.3 ConcurrentHashMap 不等于遍历安全并发修改照样抛异常现象多个客户端同时登录或退出时广播方法里 for 遍历 keySet 抛出 ConcurrentModificationException。原因一个线程正在遍历 keySet另一个线程执行 put 或 remove在线表结构被修改。ConcurrentHashMap 保证单个操作的线程安全但不保证迭代器遍历期间其他线程的写操作不打扰你——这是对并发安全的常见误解。解决遍历前做快照String[] keys onlineUsers.keySet().toArray(new String[0])然后按快照数组逐个取 socket。哪怕取的时候用户已经下线最多 target 为 null跳过去就行不会崩。4.4 端口被占用BindException 的三种常见来源现象启动服务端直接报 Address already in use: bind。原因最常见是上次运行的服务端进程没杀掉其次是端口小于 1024在 Linux 上没有 root 权限不能绑定再有就是同学共用的电脑上别人占了同一个端口。解决先用 netstat 查占用情况# Linux/macOS查看 5527 端口被哪个进程占用 netstat -anp | grep 5527 # Windows netstat -ano | findstr 5527找到 PID 后结束对应进程或者把端口改成 5528 这种高位端口。如果改了端口报告里的截图和控制台日志要同步更新我见过代码里是 8080、截图里是 5527 的拼凑现场答辩时被老师一眼看出来。4.5 中文乱码控制台乱码但本地文件用记事本打开又正常现象Windows 上客户端发中文服务端控制台打出「浣犲ソ」把内容写进文件用记事本打开又正常。原因Java 的 String.getBytes() 和 new String(bytes) 不带字符集时使用平台默认字符集Windows 控制台默认 GBKSocket 另一侧却按 UTF-8 解码两边对不上。解决所有涉及字节和字符串转换的地方统一写 StandardCharsets.UTF_8包括 new String(...)、getBytes(...)、InputStreamReader。还有一个细节Windows 控制台本身要把代码页切到 UTF-8命令是 chcp 65001否则日志输出和程序解码标准不一致。5. 把 docx 报告书写成能过答辩的交付物结构、图表、测试记录课程设计报告书也就是那个 .docx 文件很多人拖到最后才写结果代码什么样报告就抄什么样从头到尾堆代码截图。实际上评判一份课设报告书看的是「能不能让人不看代码就知道你做了什么、怎么做的、为什么这样做」。这一章给出一套模板按这套结构写章节、图表、测试数据都很容易组织起来。5.1 docx 的结构八个部分从「问题」走到「验证」章节建议篇幅核心内容封面1 页课程名、题目、学号姓名、日期摘要200 字左右做了什么、用了什么、达到什么效果需求分析500 字左右功能需求和非功能需求别写「有聊天功能」这种一句话需求概要设计800 字左右架构图、线程模型、协议帧格式详细设计1200 字左右核心代码片段加逐段说明测试记录800 字左右用例表、运行截图、问题分析心得400 字左右具体踩坑和解决过程参考文献5 条左右教材加官方文档需求分析要列清楚功能点登录、群聊、私聊、上下线通知、异常处理每一条对应一个验收场景。概要设计是老师最爱翻的章节必须有图有表。详细设计不要整段贴代码只贴帧格式定义、消息循环、广播分发这三块核心逻辑然后把第 2、3 章里的参数说明拆进去。5.2 架构图和消息时序图用 Word 形状画不要贴截图报告里最重要的有两张图一张是系统架构图画「客户端 1…N ↔ 服务端 → 在线用户表 / 广播模块」一张是消息收发时序图画「客户端 A → 服务端 → 客户端 B」的 write、read 顺序。这两张图用 Word 的「插入 → 形状」画就够了。为什么别用代码工具生成的截图每个老师电脑上的字体不一样截图放大就糊答辩时要改一个端口号Word 图改一处就行截图要重新截。画图时注意三个细节矩形框统一用圆角箭头用带单箭头的线条文字标注放在框内而不是悬空。图下面补一句图注比如「图 2-1 聊天室系统架构图」后面正文引用时直接写「如图 2-1 所示」这份 docx 的规范感马上就出来了。5.3 测试记录5 条用例加四组截图让报告有实验数据测试记录是拉开分数差距的地方。我常用的表格模板是这样用例编号操作步骤预期结果实际结果结论T01启动服务端启动一个客户端并登录服务端显示新用户加入在线人数 1与预期一致通过T02两个客户端登录A 发群聊消息B 和 A 自己都收到消息与预期一致通过T03A 给 B 发私聊只有 B 收到其他客户端不显示与预期一致通过T04强制关闭 B 的窗口A 收到「B 已下线」服务端不崩溃与预期一致通过T05用脚本同时登录 20 个客户端并广播20 个客户端都收到无粘包乱码与预期一致通过每条都要写清楚操作步骤、预期结果、实际结果、结论看起来就像一份真实的实验记录。截图放四组就够服务端启动、两人群聊、私聊、断线提示。截图里的窗口标题、端口号、用户名要和正文代码完全一致拼凑痕迹最容易在这里露馅。注意截图里的端口、用户名、控制台编码要和正文一致图实不符是答辩时最容易被挑出来的问题。5.4 心得和参考文献怎么写不显得空洞答辩会问什么心得部分最常见的写法是「本次课程设计让我深刻了解了计算机网络的知识提高了动手能力」这种话等于没写。写心得的技巧是找一处真实的坑来写比如「最初没有设计消息帧格式两个人聊天正常三个人同时发消息就出现串台后来加了长度头解决」这 40 个字的信息量比上面那句 30 字的空话大得多老师一看就知道你真做过。参考文献不要乱编常用的就是谢希仁《计算机网络》、库罗斯《计算机网络自顶向下方法》外加 Java 官方 Socket 文档出版社和版次照着你手头那本书的封面抄。答辩常规问题就三个方向BIO 和 NIO 的区别、消息粘包怎么处理、广播时怎么保证并发安全。这三个答案分散在前面的章节里答辩前把第 2 章的对比表、第 3 章的广播代码、第 4 章的并发坑过一遍比背概念有用得多。6. 答辩前自测与两个加分改动心跳保活和批量连接脚本6.1 心跳保活让服务端主动清掉死连接不需要心跳时死连接要等下一次广播才会被发现。一个很小的加分改动是加入心跳机制客户端每 5 秒发一条类型 4 的空内容帧服务端更新该用户的最后心跳时间然后定时清理超过 30 秒没心跳的连接。// 在线用户表的值换成 ClientState 对象带上最后心跳时间 class ClientState { Socket socket; volatile long lastHeartbeat; } // 定时清理线程每秒检查一次超过 30 秒没心跳就断开 ScheduledExecutorService cleaner Executors.newScheduledThreadPool(1); cleaner.scheduleAtFixedRate(() - { for (String key : onlineUsers.keySet().toArray(new String[0])) { ClientState state onlineUsers.get(key); if (state ! null System.currentTimeMillis() - state.lastHeartbeat 30_000) { try { state.socket.close(); } catch (IOException ignored) { } onlineUsers.remove(key); } } }, 1, 1, TimeUnit.SECONDS);参数说明30 秒超时对局域网课设足够宽容也不会让死连接赖太久每秒一轮的清扫开销极小。断开 socket 后handler 的 read 会抛异常自动走 finally 清理路径和第 4 章的断线方案完全闭环。6.2 批量连接脚本一分钟制造 20 个假客户端压测# 用客户端程序循环启动 20 个实例验证并发广播不粘包 for i in $(seq 1 20); do java ChatClient user$i done每个实例都是独立进程彼此没有共享状态正好模拟 20 台电脑同时在线。跑完看服务端控制台有没有异常输出再用两个真实客户端窗口验证能否正常收消息。这个脚本跑出来的结果直接填进测试记录表 T05而且是真实数据。6.3 答辩演示的三步顺序先压测、再功能、最后讲协议答辩时最怕现场翻车我现在的固定顺序是第一步跑批量脚本让老师看到 20 个连接同时存活第二步开两到三个真实窗口演示登录、群聊、私聊、断线第三步翻到报告概要设计那一页拿着帧格式表和架构图讲消息怎么拆、广播怎么并发。三步演示完老师的注意力自然落在协议设计上这时候把第 4 章的踩坑记录往「测试与问题分析」里一带答辩时间刚好。我第一次做聊天室课设时上来就写代码把报告写成流水账答辩被问到「消息边界怎么解决的」当场卡壳。后来再做类似题目我总先把帧格式画在纸上、把测试用例列在前头代码反而是水到渠成的事。聊天室这个题目不大但它是计算机网络里少有的「从协议到并发到文档」全链路训练值得用心做完。希望帮到你。本文还有配套的精品资源点击获取