简介这份课程设计文档面向计算机、软件工程等专业学生围绕计算机网络课程设计中的局域网聊天程序展开核心是基于P2P点对点思想、借助服务器转发实现任意多点之间的数据共享与交换可用于课程作业参考、Socket编程入门练手以及答辩前的方案梳理。文档完整覆盖需求分析、总体设计、详细设计、编码实现与运行结果、总结等章节具体给出用户注册登录、聊天、文件传输、好友管理四大功能模块的划分表示层、应用层、业务逻辑层、数据访问层的层次模型以及客户端、服务器端与数据库的架构组织并包含数据流程图、服务器与客户端程序实现和功能函数说明便于对照理解 TCP/UDP 协议与 Winsock 编程脉络。压缩包共1个文件为 doc 格式的课程设计说明书整体约161KB篇幅紧凑便于通读与打印。该资料已有562人浏览学习适合作网络编程初学者的参考范例与写作模板。1. 标称 P2P实现是星型转发局域网聊天程序的第一跳为何必须经过中心一份课程设计文档的封面写着“点对点数据交换P2P”翻开代码没有一行是对等的。每个客户端只跟一个地址建连所有聊天内容先写到服务器再由服务器逐个println扇出给其余 Socket。这个反差恰好是理解局域网聊天程序最好的入口所谓“多点间的数据共享”在网络层落地的形态往往是一张星型拓扑图中心节点同时承担了寻址、扇出和状态维护三件事。真正值得搞懂的是这三件事怎么被一条 TCP 长连接加一张Hashtable撑起来以及中心节点一旦成为单点后面所有的坑是不是都从“谁维护状态”这个决定里长出来的。2. TCP 长连接与 accept 循环一个 ServerSocket 怎么同时“看着”几十个客户端一个ServerSocket只能监听一个端口而几十个客户端各自持有一条独立的连接。这中间的落差是靠accept()和线程模型填平的监听套接字不传输数据它只负责把“新连接到达”这件事变成一个新对象。理解了这个分工后面所有关于“为什么用户列表会错乱”的疑问才有解。2.1 accept() 的阻塞语义和“每连接一线程”这个朴素解ServerSocket.accept()是一个同步阻塞调用。在没有客户端连上来的时候调用它的线程会一直停在那里不消耗 CPU也不返回。一旦三次握手完成内核把连接放进 accept 队列accept()立刻返回一个全新的Socket对象——注意这个新 Socket 的本地端口和监听端口是同一个但对端地址是具体的某个客户端它才代表一条真正的数据通道。服务器主循环的全部工作就是阻塞等、拿到 Socket、把它登记进全局表、甩给一个工作线程然后继续回去阻塞。这种“每连接一线程”thread-per-connection的做法今天看很奢侈但在这类几十人规模的局域网场景里它是最省心的选择——每个连接的读写状态天然隔离在线程栈里不用手动管理状态机。public class Server extends Thread { ServerSocket server null; // 监听套接字只负责 accept不传数据 ArrayList onLineUsers new ArrayList(); // 在线 Socket 集合被所有工作线程共享 Hashtable ip2nickname new Hashtable(); // IP - 昵称全局路由表 ArrayList allService new ArrayList(); // 每个连接对应一个 Service 工作线程 public Server(int port, List onLineUsersList, List chatContentList) throws IOException { this.server new ServerSocket(port); // 绑定端口后立即进入监听状态队列长度用默认值 this.onLineUsersList onLineUsersList; this.chatContentList chatContentList; this.start(); // 构造完成即启动accept 循环跑在子线程里 } public void run() { while (!isClosed) { Socket client server.accept(); // 阻塞点没有新连接时线程停在这里 String clientIP client.getInetAddress().getHostAddress(); if (ip2nickname.get(clientIP) ! null) { // 同一 IP 只允许一条连接 ChatTookit.sendInfo(client, 已经有客户端从该 ip 地址连接服务器本次连接将退出); break; // 注意退的是整个 accept 循环不只是这条连接 } onLineUsers.add(client); ip2nickname.put(clientIP, clientIP); // 用户还没起昵称先用 IP 兜底 this.onLineUsersList.add(clientIP); this.chatContentList.add(clientIP 来了); ChatTookit.sendInfoToAll(onLineUsers, ChatTookit.getAllNickname(ip2nickname)); ChatTookit.sendInfoToAll(onLineUsers, clientIP 来了); Service service new Service(client, ip2nickname, onLineUsersList, chatContentList, onLineUsers); allService.add(service); // Service 构造器内部 start()连接即刻被接管 } } }参数上只有port是外部输入其余几个List和Hashtable都是被多个线程共享的引用——它们从主线程传进每一个Service这是这套设计里最需要警惕的地方。break那一行也值得盯住本意是拒绝重复 IP 的连接实际效果是让服务器彻底停止接受新连接一个错误客户端就能把整个聊天室锁死。这个坑在第 5 章会展开。2.2 为什么选 TCP有序、可靠以及 readLine 的隐含契约UDP 也能做聊天室局域网丢包率低看起来更“轻”。但一旦选 UDP就得自己处理消息重排、丢失重传、以及最麻烦的“一条消息被切成两段到达”。TCP 把这些问题挡在传输层应用层拿到的是一条有序、可靠、但不保留边界的字节流。不保留边界这一点常被忽略。TCP 只保证字节顺序不保证一次read就对应一次write。所以聊天程序必须自己在字节流上切出消息边界。这份实现选了最省事的一种以换行符为界。写入端用PrintStream.println自动补一个行分隔符读取端用BufferedReader.readLine()读到换行就返回一条完整消息。换行符在这里承担的角色等价于二进制协议里的长度字段——它是一条隐式的帧定界符。代价是消息内容里不能出现裸换行否则一条消息会被拆成两条。文本聊天场景里这个约束几乎无害但如果哪天要传多行文本或者带换行的 JSON协议立刻崩掉。常见的补救思路是在发送前对内容做转义或 Base64 编码把“帧定界”和“内容”彻底解耦。2.3 Hashtable 而不是 HashMap一个被忽略的并发细节代码里用的是Hashtable而不是更常见的HashMap。这个选择在当时多半不是随手写的Hashtable的方法全部带了synchronized多个Service线程同时get/put时不会把内部结构写坏。而同一份代码里的ArrayList onLineUsers和allService没有任何同步保护两个线程同时add或者一边遍历一边删除轻则数据错乱重则抛ConcurrentModificationException。同样的共享状态一个加了锁一个没加说明作者大概率只是“知道 Hashtable 是老的、稳的”而没有建立“哪些对象会被多线程同时碰”的完整图景。判断方法很简单凡是构造时传进来、又被存成成员变量的容器就默认它是并发访问点。这条直觉一旦建立读别人的 Socket 代码时能立刻嗅出问题在哪。3. 应用层协议用 println 和前缀标记拼出的最小自定义协议TCP 只负责把字节送到对面至于“这条消息是聊天内容、还是改名指令、还是私聊”TCP 一无所知。协议设计的全部工作就是在一行文本里塞进足够的语义让接收方知道该怎么处理。这份实现用了一个极简的办法给消息加前缀用前缀做分派。3.1 前缀路由一条连接如何承载多种语义先看服务端维护昵称列表的函数。它把整张表的 value 拼成一个空格分隔的字符串前面挂一个固定标记// 从 IP-昵称对照表里取出所有昵称拼成一条协议消息 public static String getAllNickname(Hashtable ip2nickname) { String allNickname NICKNAME:; // 类型标记接收方据此判断这是用户列表 Enumeration e ip2nickname.elements(); while (e.hasMoreElements()) { allNickname (String) e.nextElement() ; // 昵称之间用空格分隔 } return allNickname; // 形如 NICKNAME:张三 李四 10.0.0.7 }这条消息发出去之后客户端拿到的是NICKNAME:开头的一整行。客户端只要判断开头是不是这个标记就能决定“是刷新在线列表还是往聊天区追加一行”。标记本身不参与显示是纯粹的协议控制信息。私聊走的是另一套标记而且用了两个// 服务端处理管理员发来的消息可能是群发也可能是指定昵称的私聊 public void send(String word) throws IOException { if (word.startsWith(SPECIAL:)) { // 私聊分支 word word.substring(8); // 掐掉 SPECIAL: 这 8 个字符 String toNickname word.substring(0, word.indexOf($SPECIAL$)); // $之前是目标昵称 word word.substring(word.indexOf($SPECIAL$) 9); // $之后是正文 Socket client ChatTookit.getSocketByIP(onLineUsers, ChatTookit.getIP(ip2nickname, toNickname)); // 昵称 - IP - Socket ChatTookit.sendInfo(client, 系统管理员 悄悄对你说 word); } else { // 群发分支 chatContentList.add(系统管理员 word); ChatTookit.sendInfoToAll(onLineUsers, 系统管理员 word); } }这里用$SPECIAL$作为昵称和正文之间的分隔符思路是“用一个几乎不会出现在正文里的字符串当分隔符”。风险也很直白如果正文里恰好含有这个串解析就会错位。工程上更稳的做法是把分隔符换成不可打印字符、或者干脆改成“首个空格前是目标、其余全是正文”让切分位置只依赖第一个分隔点。协议的分层其实很清楚NICKNAME:是状态同步类消息一条就代表整个列表的完整快照SPECIAL:是路由指令只在服务端内部解析不发给客户端普通文本是内容类消息直接落到聊天区。三类消息共用一条 TCP 连接靠前缀区分——这就是最朴素的应用层复用。3.2 客户端为什么要两条线程轮询发送与阻塞接收客户端的结构比服务端更别扭一点。它把发送和接收拆成了两个线程Listener线程阻塞在readLine()上收消息主线程则在一个循环里检查有没有待发内容public void run() { BufferedReader br new BufferedReader(new InputStreamReader(client.getInputStream())); PrintStream ps new PrintStream(client.getOutputStream(), true); // true 每行自动 flush listener new Listener(br, this.onLineUsersList, this.chatContentList); // 接收线程 while (!isClosed) { if (this.word.length() 0) { // word 是界面通过 send() 塞进来的待发内容 ps.println(this.word); this.word ; } else { sleep(100); // 没东西可发就睡 100ms典型的忙等轮询 } } listener.destroy(); client.close(); } public void send(String s) { this.word s; } // 界面线程调用跨线程写一个非 volatile 字段PrintStream构造时第二个参数传true意思是每次println之后自动 flush——不加这个消息会卡在缓冲区里界面上看起来就是“发出去了但对面半天没反应”。这是 Socket 编程里最经典的玄学故障之一。轮询的代价是消息最多延迟 100ms 才真正上线而且空闲时每秒醒 10 次。更干净的解法是用BlockingQueue把界面线程和发送线程解耦take()阻塞等待有消息立刻发没消息彻底休眠。word这个字段同时被界面线程写、被发送线程读没有volatile也没有锁严格来说是可见性问题实测中因为轮询频繁反而“看起来正常”——这类靠运气工作的代码是后期最难排查的那一类。4. 身份映射表ip2nickname 如何成为整个系统的路由表服务器要发消息给“张三”手里却只有一堆Socket。中间缺的那一环就是昵称到连接的映射。整份代码用一张Hashtable把这件事解决掉键是 IP 字符串值 是昵称。谁在线、谁叫什么、消息该发给谁全都从这张表推出来。4.1 用 IP 当主键一个看起来偷懒、实际很稳的选择Socket对象本身不稳定——连接断了重建就是新对象。IP 在局域网内相对稳定而且client.getInetAddress().getHostAddress()一行就能拿到。把 IP 当主键等于选了一个“连接生命周期之外还成立”的标识。代价写在两个地方。第一同一个 IP 上开两个客户端会被拒绝ip2nickname.get(clientIP) ! null那个判断。在单人单机的实验室环境没问题但在一台机器多开、或者经过 NAT 之后这个限制会变成真实的功能缺陷。第二反向查找只能遍历// 已知昵称反查 IPHashtable 没有 value - key 的索引只能全表扫 public static String getIP(Hashtable ip2nickname, String nickname) { String ip null; if (nickname.indexOf() 0) { // 服务端列表里显示成 昵称IP先截断 nickname nickname.substring(0, nickname.indexOf()); } Enumeration e ip2nickname.keys(); while (e.hasMoreElements()) { ip (String) e.nextElement(); // 先把当前 key 赋给 ip if (((String) ip2nickname.get(ip)).equals(nickname)) { break; // 命中此时 ip 就是答案 } } return ip; // 没命中时返回的是最后一个 key而不是 null }这个函数的返回值语义是模糊的找到就返回对应 IP找不到则返回遍历到的最后一个键。调用方getSocketByIP(onLineUsers, ip)拿到一个错误 IP 后会返回null再往下client.getOutputStream()就抛空指针。正确写法是在循环前把ip置 null、命中才赋值循环结束直接返回。这种“找不到时返回垃圾值而不是空”的写法是null语义缺失时最常见的血泪经验。4.2 一次改名要扇出几次状态变更的传播链改昵称看起来是个小功能实际上要同时更新四五个地方漏一个就出现“服务端显示新名字、客户端还显示旧名字”的错位public void changeNickname(String oldName, String newName) { if (ip2nickname.contains(newName)) { // 注意contains 查的是 keyIP不是 value昵称 chatContent.add(该昵称已经有人使用所以不做任何更改); return; } String ip ChatTookit.getIP(ip2nickname, oldName); // 昵称 - IP ip2nickname.put(ip, newName); // 1. 更新路由表 Service service ChatTookit.getServiceByIP(allService, ip); service.changeNickname(newName); // 2. 更新工作线程里的昵称副本 chatContentList.add(系统管理员 将 oldName 的昵称改为 newName); // 3. 本机日志 ChatTookit.updateOnLineUsersList(onLineUsersList, ip2nickname); // 4. 本机列表 ChatTookit.sendInfoToAll(onLineUsers, 系统管理员 将 oldName 的昵称改为 newName); ChatTookit.sendInfoToAll(onLineUsers, ChatTookit.getAllNickname(ip2nickname)); // 5. 广播新快照 }第 1 步是数据源第 2 步是缓存副本第 3、4 步是本机 UI第 5 步是远端 UI——五个位置少同步一个就产生不一致。这类“一次写多处”的模式在分布式系统里有个名字叫扇出写工程上通常收敛成“只维护一份真源其余地方都从真源推导”。这里Service里存昵称副本就是多余的完全可以每次从ip2nickname查。contains(newName)那一行是另一个典型误用Hashtable.contains判断的是值是否存在而containsKey判断的是键。这里的键是 IP、值是昵称作者的意图显然是“查这个昵称有没有被占用”正确写法应该是ip2nickname.containsValue(newName)。写成contains的后果是永远返回 falseIP 不会等于一个中文昵称重名检查形同虚设——两个人都能叫“张三”然后getIP随机命中一个私聊就发错人了。4.3 踢人把“关闭连接”也当成一条协议消息踢人的顺序很讲究。先发提示再关连接最后清理全局状态public void tickSocket(String nickname) { String ip ChatTookit.getIP(ip2nickname, nickname); Socket client ChatTookit.getSocketByIP(onLineUsers, ip); Service service ChatTookit.getServiceByIP(allService, ip); this.allService.remove(service); // 先摘出全局表防止新消息再投给它 this.onLineUsers.remove(client); this.ip2nickname.remove(ip); // 路由表最后删此时已无人能定位到它 try { ChatTookit.sendInfo(client, 你已经被系统管理员踢出聊天室); // 让对端知道是被踢不是掉线 client.close(); // 关连接对端 readLine 会立刻返回 null } catch (IOException ex) { /* 对端可能已经自己断了 */ } ChatTookit.updateOnLineUsersList(onLineUsersList, ip2nickname); ChatTookit.sendInfoToAll(onLineUsers, 系统管理员 将 nickname 踢出聊天室); ChatTookit.sendInfoToAll(onLineUsers, ChatTookit.getAllNickname(ip2nickname)); }顺序反了会出问题如果先close()再发提示getOutputStream()已经不可用如果先删表再关连接中间那一瞬间别的线程可能正拿着旧 Socket 往里写。先摘表、再通知、最后关闭这个顺序本质上是把“可见性”排在“资源释放”前面是一个可以复用到很多地方的模式。5. 排查与避坑这套 Socket 聊天室最容易翻车的五个点5.1 一个重复 IP 的连接把整个服务器锁死现象某人手滑开了第二个客户端或者前一个客户端异常退出后立刻重连服务器就不再接受任何新连接了界面上毫无提示。原因if (ip2nickname.get(clientIP) ! null)分支里写的是break跳出的不是while循环的一次迭代而是整个while (!isClosed)。accept 循环一停后面所有连接都堆在操作系统的 accept 队列里直到队列满。解决把break换成continue并且先client.close()再 continue否则被拒绝的 Socket 会一直占着文件描述符。更彻底的做法是把判断挪到Service线程里主线程只负责 accept。5.2 用户一多就抛 ConcurrentModificationException现象在线人数上来之后某次上线或下线服务端控制台突然刷出一片异常之后部分用户收不到消息。原因sendInfoToAll在for循环里遍历onLineUsers而另一个Service线程可能正在onLineUsers.remove(client)。ArrayList的迭代器检测到结构变更就抛异常。解决最省事的是换成CopyOnWriteArrayList遍历时拿的是快照代价是写操作复制整个数组——几十人的规模完全无所谓。或者把“增删在线用户”和“广播”都收敛到单一线程里做用队列串行化。别用synchronized把整个广播包起来那会让一个慢客户端卡住所有人。5.3 重名检查永远返回 false私聊发给了错误的人现象两个人可以起同名昵称管理员发私聊消息偶尔发给了不相干的人偶尔直接报空指针。原因ip2nickname.contains(newName)判断的是键IP里有没有这个字符串而不是值昵称。判断永远为 false重名从来就没被拦住。之后getIP全表扫描时同名两人谁先被枚举到就返回谁。解决改成containsValue或者values().contains(newName)。同时给getIP补上“找不到返回 null”的明确语义调用方必须判空——这是把“运气”换回“确定性”的最小改动。5.4 拔网线之后人还挂在在线列表里现象客户端直接断网、或者进程被强杀服务端和其余客户端的在线列表里那个名字一直亮着要等很久才消失甚至一直不消失。原因这套实现只在客户端“正常关闭”时才会主动发下线消息。TCP 连接在没有心跳、没有数据往来的情况下服务端根本不知道对端已经没了。onLineUsers里那个Socket对象看起来完好往里写还会“成功”其实是写进了本地发送缓冲区。解决两条路。一是在应用层加心跳服务端定时给每个连接发一条PING:超过 N 个周期没收到PONG就主动清理二是给Socket设setSoTimeout让阻塞的readLine定期抛超时异常客户端超时即退出。生产环境两者常一起用。5.5 中文昵称在某台机器上变成问号现象同一个程序在自己电脑上昵称显示正常拷到同学机器上全是???。原因new PrintStream(socket.getOutputStream())和new InputStreamReader(inputStream)都没指定字符集用的是平台默认编码。一边是 GBK、一边是 UTF-8字节流对不上。解决两端都显式指定StandardCharsets.UTF_8。这类问题在局域网内反而更隐蔽因为开发时往往两台机器编码一致一旦环境稍有差别问题就冒出来了。规矩是只要跨进程传文本就不许依赖默认编码。6. 从“能跑”到“能扛”线程模型与协议分层的取舍把这份实现拆到这个程度会发现它的每一处选择背后都有个明确的取舍只是当初未必是“选”出来的。线程模型上thread-per-connection 换来的是极简的心智负担每个连接的读循环天然串行不用考虑状态机、不用处理半包。代价是连接数和线程数一比一切线程的开销和栈内存默认 1MB 量级会随人数线性涨。几十人的局域网教室完全够用几百人就会开始难受。再往上一层的做法是引入线程池把“连接”和“线程”解耦再往上是 NIO 的 Reactor 模式一个线程用 Selector 轮询成百上千个 Channel——但那时“读一行处理一行”的直觉就没了得自己维护每个连接的读缓冲区。方案连接上限量级代码复杂度适合场景每连接一线程本实现数百低局域网小规模、教学演示线程池 阻塞 IO数千中中小型内部服务NIO / Reactor数万高高并发网关、长连接推送协议层面行文本加前缀的方案可读性极好——抓包工具里直接就能看懂谁说了什么调试成本几乎为零。代价是解析脆弱正文含换行或分隔符就错位没有版本号也没有校验两端必须严格同版本。如果要往前推一步我会加一个协议版本字段放在行首让服务端能同时兼容老客户端再给每条消息一个自增序号客户端据此去重——虽然 TCP 本身可靠但重连之后的消息补发场景里序号是唯一的后悔药。验证上别只靠“开两个窗口互相发一句”来判断程序对不对。几个真正能暴露问题的动作同时开五个客户端然后随机强杀其中两个看在线列表多久收敛用抓包工具看一条中文消息在链路上一共几个字节、有没有被拆成两次read把一个客户端的系统编码改成和服务器不同看乱码出现在哪一端以及最狠的一招——在发送循环里sleep十秒再发模拟网络卡顿观察消息会不会丢、顺序会不会乱。从那以后我每次写这类“先跑通再优化”的样例程序都会强制自己先把“断线检测”和“共享集合的并发保护”这两件事补上再谈 UI 和功能——因为这两处一旦出问题表现是随机的、偶发的、无法复现的排查成本远高于一开始就写对。希望帮到你。本文还有配套的精品资源点击获取
