斯迈尔齿科1. 我为什么重新写了一个TCP聊天室
如果你打开各大代码仓库搜"聊天室"，会看到几乎清一色的WebSocket方案，前端一个Vue页面，后端Node.js或者Spring Boot，几十行代码就能跑通一个"在线聊天"。但我这次做的这个项目，刻意绕开了WebSocket，用原生TCP协议从零写了一个完整的在线聊天室系统。为什么？因为聊天室只是一个载体，我想让人真正理解TCP协议在真实应用中的行为。
很多人在学校学过计算机网络，知道三次握手、四次挥手、滑动窗口这些概念，但一旦面对socket编程，脑子里只剩一团浆糊。原因很简单：书本上讲的是协议机制，而实际项目里你面对的是字节流、半包、粘包、连接意外断开、多线程并发操作Socket这类非常"脏"的问题。这些问题不亲手做一遍，永远只是面试题里的答案。
我做的这个系统技术栈很朴素：C# + WinForms，服务端使用TcpListener监听客户端连接，客户端使用TcpClient建立连接，通信数据通过自定的消息协议在字节流上传输。没有引入任何第三方框架，没有依赖SignalR这类封装好的库，所有连接管理、消息路由、异常恢复逻辑都是自己一行一行写出来的。麻雀虽小，五脏俱全：支持多用户同时登录、公屏广播、私聊、在线人数统计、掉线自动清理、心跳保活。
适合谁看？我觉得最适合两类人：一类是正在学网络编程、想做课程设计或者毕业设计的学生，这个项目能让你把一个"玩具聊天室"写出工程感；另一类是工作中一直在用现成框架、没接触过底层socket的开发者，花一个周末手写一遍，很多"框架为什么这么设计"的困惑会突然解开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 选TCP不选UDP和HTTP：协议机制给出的必然答案
既然要写聊天室，第一步就是要选传输层协议。TCP、UDP、HTTP放在一起对比的时候，很多人会把"HTTP和TCP"放在对立面，其实不对，HTTP跑在TCP之上，它俩不是一层的东西。真正需要做二选一决策的是TCP和UDP。
我先说结论：聊天室必须用TCP，毫无悬念。原因有三点。
第一，消息有序性。TCP是面向字节流的可靠传输协议，它保证数据包的到达顺序和发送顺序一致。UDP是尽力而为的不可靠传输，数据包可能乱序，可能丢失。在聊天场景里，两个人对话，A先说了句"你好"，又说了一句"吃饭了吗"，如果B收到的顺序反了，对话就彻底乱套。你可能会说，UDP可以在应用层做序列号排序补偿，但那是给自己挖坑，所有可靠性逻辑都要自己实现，工作量不比用TCP少。
第二，消息完整性。TCP有确认重传机制，丢包会自动重发，保证数据不丢失。UDP没有这个机制，一个字丢了就丢了，聊天内容缺字少句是用户完全无法接受的。除非你做的是一秒几十帧的语音通话应用——那种场景追求低延迟，容忍个别丢包，才适合UDP。文本聊天对实时性的要求没那么极端，但对可靠性的要求极高。
第三，连接状态管理。TCP是面向连接的协议，客户端和服务端之间存在一条虚拟连接，服务端可以随时感知连接状态。UDP是无连接的，服务端根本不知道一个客户端还在不在线，除非客户端定时发心跳。这意味着如果用UDP，在线用户管理就是一场灾难：你不知道谁走了，只知道谁没说话。
那HTTP行不行？用HTTP做聊天室，技术上有两种路径：轮询和长轮询。轮询就是客户端每隔几秒拼命问服务端"有没有新消息"，没有就等，太浪费资源；长轮询是客户端发一个请求，服务端把连接挂着，等到有新消息才返回，这个能省点资源，但离真正的实时还差得远。HTTP本质上是半双工、请求-响应模型，而聊天是双向的、服务端主动推消息的场景，用HTTP就是拿锤子拧螺丝。
有人可能会说WebSocket也是基于TCP的，为什么不用WebSocket？如果你现在是做一个真实产品，我支持你用WebSocket，因为它把很多底层细节都处理好了。但作为学习TCP协议机制的项目，一点一点自己处理字节流，才能体验到TCP滑窗、粘包拆包、心跳超时这些概念在代码里到底长什么样。这个项目的定位是"弄懂底层"，所以我不走WebSocket那条捷径。
3. 核心架构拆解：连接管理、消息路由和会话生命周期
画架构图的时候大家都会画，真正动手写代码的时候才发现，聊天室的核心就三件事：管住连接、转发消息、处理好生命周期。把这三件事想清楚，代码怎么写都不会乱。
3.1 服务端的连接管理层
我在服务端维护了一个线程安全的在线用户字典，key是用户名，value是对应的客户端会话对象。每来一个新客户端，就给它分配一个独立的线程去处理收发，同时把这个会话对象放进字典。为什么用字典而不用列表？因为聊天室要按用户名找到指定会话做私聊，字典的查找时间复杂度是O(1)，列表是O(n)。用户量大起来，这一点差距就明显了。
这个字典用到了C#的ConcurrentDictionary，这是必须的，不是可选项。因为服务端同时有多个客户端线程在操作这个字典：新用户登录要Add，用户掉线要Remove，私聊要Find，公屏广播要遍历。如果是普通Dictionary，多线程同时读写会产生竞态条件，轻则数据不一致，重则直接抛异常把服务端打崩。我第一版用的普通Dictionary，开三个客户端同时发消息，跑了十分钟服务端就崩