1. 从“能跑通的Demo”到“能上线的架构”Socket聊天室到底要解决哪些问题“Socket网络聊天室”这个话题很多人写过但实话实说大多数人写出来的东西叫“回显服务”——客户端发一句服务端原样弹回来加几个在线列表就敢叫聊天室。我第一次写Socket聊天室也是这个水平。直到后来接手一个要稳定支撑几百人同时在线的服务端项目我才意识到一个扎心的事实Socket网络聊天室的难点根本不在Socket API本身的用法而在通信原理的掌握和系统架构的设计。前者是三天能学会的东西后者是踩了无数坑才悟出来的东西。这个标题看起来是个“说明文”但实际它是一条贯穿网络编程始终的主线你把一条消息从A机器的键盘敲下来经过网卡、交换机、路由器、服务端的缓冲区、线程调度、业务逻辑、再原路返回最终渲染在B机器的屏幕上——这中间每一个环节掉链子用户感知到的就是“消息丢了”“消息乱序了”“卡了”“服务挂了”。所以这篇博文不是教你怎么调send()和recv()而是把Socket网络聊天室当成一个完整的系统来拆解从TCP协议层的原理到服务端线程模型的设计从消息协议的定义到线上真实出现的坑一层层讲清楚。适合三类人看一是刚学完Socket编程基础、想做项目练手的同学二是已经写了聊天室但总觉得哪里不对劲、想搞明白底层逻辑的后端开发三是准备面试被问到“如果让你设计一个聊天室系统架构你会怎么做”的求职者——这道题几乎年年出现而且面试官真正想听的绝不是API背诵。先给一个核心观念聊天室 通信原理的实践场 系统架构的微缩模型。它麻雀虽小却包含了连接管理、协议设计、并发模型、消息广播、异常处理这五大网络服务端的核心命题。把聊天室做扎实了你再去接触IM系统、推送系统、游戏服务器、物联网网关会发现底层全是同一套东西。1.1 先分清TCP与UDP聊天室应该走哪条路做聊天室首先要选传输层协议这个选择会直接影响后面所有的架构设计。TCP和UDP的差别我放在一张表里直接对比维度TCPUDP连接状态面向连接需三次握手无连接直接发数据报可靠性可靠传输丢包重传有序尽力而为可能丢包、乱序传输单位字节流无消息边界数据报有消息边界速度与开销握手开销、ACK确认相对慢无握手无确认快但易丢适用场景文件传输、网页、聊天、IM视频直播、语音通话、游戏位置同步大多数聊天室场景应该选TCP原因很简单聊天消息不能丢。你和朋友聊到一半突然一句话永远消失了这个体验是不可接受的。丢了一条消息比延迟500毫秒更让人崩溃。但这里有个反直觉的点很多人以为UDP不可靠就不能用于聊天实际上Telegram之类的IM在弱网环境下会混合使用TCP和UDP语音走UDP文本消息走TCP。这是后话初版聊天室老老实实选TCP就好。选TCP之后你才需要去面对字节流带来的最大麻烦——粘包和半包问题这个我后面专门用一节讲。1.2 经典C/S模型下的三个核心部件Socket聊天室最经典的形态是C/S架构客户端/服务端。无论你后面是升级成WebSocket还是上消息队列核心逻辑都逃不出这三个部件客户端Client负责建立连接、发送消息、接收消息、渲染界面。它的核心状态机是连接中 - 已连接 - 断开重连。服务端Server负责监听端口、接受连接、维护在线列表、转发消息。服务端是整个系统的核心所有难点都在这里。协议Protocol连接两端的共同语言决定了消息怎么编码、怎么解析、怎么区分类型。这三者里初学者最喜欢把精力花在客户端界面上搞漂亮的对话框、气泡样式、emoji。但架构设计的真正重心在服务端和协议层。我把这个观念摆在这里客户端做成什么样决定这项目好不好看服务端和通信设计决定它能不能活过100人同时在线。2. 通信原理拆解一条消息从键盘敲下到对方屏幕的完整旅程做聊天室最怕的就是“知其然不知其所以然”——调通了API就以为会了结果消息一多、并发一上来各种诡异问题全冒出来。所以这一节我们认真拆一下底层原理。2.1 三次握手与连接状态这不是打电话而是一封信的确认流程TCP建立连接要经历三次握手这是老生常谈。但聊天室开发中三次握手真正影响你的是什么是连接建立的耗时要心里有数以及服务端到底何时才算“真的连上了”。三次握手的本质是双方确认两件事各自的发送能力正常各自的接收能力正常。类比一下就是你和同事约会议A发消息说“你明天下午有空吗”SYNB回复“有你具体几点”SYNACKA再回“三点就这么定了”ACK。只有这三句话完整双方才敢确定沟通渠道顺畅。写Socket代码时有个细节必须注意客户端的connect()返回成功只代表三次握手完成了不代表服务端业务层已经准备好处理你的消息。我见过很多人刚connect()完就立刻狂发消息结果前几条在服务端还没初始化完时就丢了。这就是TCP层“已连接”和业务层“可服务”之间那道缝隙。成熟的IM设计会在连接后先做一次业务层的握手比如客户端发送一个HELLO包携带用户ID和token服务端回复HELLO_ACK客户端收到之后才允许用户发消息。这个设计能挡掉大量连接建好但认证未完成的脏状态。2.2 字节流、缓冲区和调用时机Socket读写到底发生了什么TCP是字节流协议这是聊天室编程里最核心、最容易被忽略的一句话。什么叫字节流就是你调用send()发送的“一条消息”到了TCP这里根本没有消息边界。TCP把发送方的数据看作一串连续的字节它会按自己的意愿切分、合并再通过网络发出去。接收方同样按自己的意愿收数据一次recv()可能收到半条消息也可能收到两条半。我来画个流程感受一下客户端调用send(你好)这5个字节按UTF-8算进入操作系统的发送缓冲区。TCP协议栈可能在同一个包后面再拼上你紧接着发送的“在吗”4个字节凑成一个9字节的TCP段发出去。对端接收时recv()可能一次性读出9个字节也可能先读出2个字节、再读出7个字节。这就是粘包与半包的来源。所以Socket通信的读操作必须依赖一个“消息分帧”机制。框架没给你分帧你就要自己分。分帧的本质就是收双方约定从哪里开始是一条完整消息到哪里结束。2.3 粘包/半包问题的本质与三种常用解法这是聊天室开发中百分之百会遇到的问题也是面试必考。它的根源就是上面说的——TCP是字节流没有消息边界。解决方案无非是三类方案原理优点缺点固定长度消息每条消息都是N字节不足补齐实现最简单解析快浪费带宽不适合变长文本特殊分隔符用 \n 或 \r\n 做边界实现简单适合文本协议消息内容不能含分隔符需转义长度字段前缀包头固定字段声明消息体长度通用性最强需要处理粘包半包的累积逻辑实际做聊天室绝大多数情况下选第三种包头包体结构。一个常见的格式长这样---------------------------------------------------------- | 魔数 | 版本号 | 消息类型| 包体长度| 扩展字段| 包体 | | 2字节 | 1字节 | 1字节 | 4字节 | 4字节 | N字节 | ----------------------------------------------------------服务端收数据时维护一个接收缓冲区每次recv()到的数据先追加进去然后循环尝试解析先读取包头固定的12字节通过魔数校验是合法包读到包体长度字段判断缓冲区里是否已经有足够长的数据。不够就退出循环等下一批数据够了就按长度取出包体递交给业务层剩下的数据继续解析下一条。这套逻辑就是所有网络框架里“拆包器”的雏形。Python示例大概长这样import struct # 粘包半包处理核心缓冲区累积式解析 class FrameDecoder: HEADER_SIZE 12 def __init__(self): self.buffer bytearray() def feed(self, data: bytes): self.buffer.extend(data) frames [] while True: if len(self.buffer) self.HEADER_SIZE: break # 前4字节是魔数0x12345678接着1字节版本1字节类型4字节包体长度2字节保留 magic, version, msg_type, body_len struct.unpack_from(IBBH, self.buffer, 0) if magic ! 0x12345678: # 魔数不对说明消息流错位了这个情况需要触发重连或丢弃处理 break total_len self.HEADER_SIZE body_len if len(self.buffer) total_len: break # 半包等下一次数据 body bytes(self.buffer[self.HEADER_SIZE:total_len]) frames.append((msg_type, body)) del self.buffer[:total_len] return frames这个类的价值在于无论对方发过来的数据怎么切碎、怎么粘合你只要把每次recv()的原始字节喂给它它永远能稳定地吐出一条条完整的消息。聊天室所有的消息解析逻辑都应该建立在这个基础之上。我当年就是没写这个直接recv(1024)然后按字符串解析上线半小时就乱套了。2.4 心跳、超时与半开连接聊天室最容易被忽略的底层保命机制客户端直接拔网线会发生什么服务端短时间内不会感知到任何异常。TCP有个机制是连接断开时发FIN包但拔网线这个FIN包根本发不出去。服务端的连接就进入“半开状态”——看起来还连着实际对方已经不存在了。如果服务端不去清理这些僵尸连接在线列表会越来越虚线程资源也被白白占着。解决办法就是心跳机制。客户端每隔30秒发一个PING包服务端收到回PONG同时记录这个连接的最后活跃时间。服务端每隔60秒扫描一次所有连接把超过90秒没有任何消息包括心跳的连接强制关闭。这个“三段时间”的设计是有讲究的心跳周期 超时阈值 清理周期留出足够的容错空间避免网络短暂抖动就误杀正常连接。心跳包在设计上要轻量——一条几个字节的消息不走业务逻辑不进消息队列直接在IO层处理掉。这是我见过很多聊天室做错的地方把心跳当成普通业务消息走全链路数据库、消息队列全过一遍等于自己给服务端制造了海量无效负载。3. 系统架构设计从单线程阻塞到高并发多线程的演进路线很多教程教的Socket服务端是这样写的一个accept()循环每来一个连接就new Thread去处理。这个方案在50人以内是能跑的超过100人就开始各种崩溃。真正的架构设计是要说清楚这条路怎么一步步走过来的每一步解决什么问题付出什么代价。3.1 第一版阻塞式单线程串行处理——只配叫作Demo最原始的服务端写法是单线程阻塞模型accept()等待连接有连接进来后recv()等消息处理完再回到accept()继续等下一个。这个模型的问题一眼就能看出来一个客户端连接如果一直不发消息recv()就卡住整个服务端其他所有人发消息都不被处理。聊天室不是一问一答的请求响应模型而是长连接的持续消息流所以阻塞单线程模型在聊天室场景里完全没有可用性。3.2 第二版每连接一线程——简单粗暴但撑不住量阻塞IO多线程来一个连接就开一个线程去阻塞读思路是把“一个连接卡住所有人”变成“一个连接卡住一个线程”。实现很简单几十行代码搞定。但它有两个致命问题第一是线程资源。Java里一个线程默认栈大小1MB300个连接就是300MB内存。线程切换还有额外开销300个线程同时活跃CPU光切换上下文就忙不过来了。第二是连接数的上限。默认配置下一个进程能创建的线程数是有限的即使调到很大线程创建销毁的开销也会在高频连接断开场景下拖垮服务端。这个模型我建议作为学习阶段的练习了解线程怎么处理Socket读写即可不要在任何生产环境中使用。3.3 第三版IO多路复用——用少量线程管理海量连接再往下走聊天室服务端的主流派生模型是IO多路复用 事件驱动。这里的思路转换很关键从“每个连接一个线程”变成“一个线程监视所有连接的事件”。select有1024个文件描述符上限poll解决了数量限制但性能依然线性。真正现代的高并发网络编程Linux下用的都是epollmacOS/BSD下用kqueue。它们的核心机制很像餐厅里的叫号系统几百桌客人谁有需求谁按铃服务员不用挨桌问。对应到Socket就是你把所有连接的文件描述符注册进epoll然后阻塞等待内核告诉你“哪些连接有数据可读了”你再只处理这些活跃连接。用epoll之后单线程就可以管理上万个连接。实际的服务端架构通常是这样主线程Reactor监听新连接accept后注册到epoll IO线程Worker负责已连接的读写事件分发 业务线程池处理接收到的完整消息执行登录、广播、持久化等逻辑每个环节各司其职连接管理不阻塞业务业务不阻塞IO消息吞吐量跟第一个版本相比是一个天上一个地下。3.4 前后端技术选型与整体分层聊完并发模型整体技术选型也要有谱。我做聊天室项目的常用选型和理由列在这层次常见选型选型理由传输层TCP Socket / WebSocket原生Socket适合学习与定制WebSocket适合Web端复用80端口服务端核心Java Netty / Go net / Python asyncio都有成熟的IO多路复用封装和编解码框架消息格式JSON / Protocol BuffersJSON调试方便PB性能好体积小在线状态存储RedisHash结构存在线列表天然支持过期和原子操作消息持久化MySQL / MongoDB / Kafka离线消息、历史记录按场景选型我个人的建议是如果做技术练习用你当前最熟的语言直接基于系统原生API实现一遍不依赖框架把 epoll 模型和编解码器手写出来。这能帮你把底层原理吃透。用Netty这类成熟框架会把很多事情隐形掉调试问题时你反而不知道底层发生了什么。等手写版本跑通了再换框架去对比认知会深刻得多。4. 协议设计与消息广播聊天室架构里的“定海神针”聊完IO模型和并发模型接下来是让架构真正“活”起来的两个核心消息协议怎么定义消息广播怎么传递。4.1 消息协议为什么不能用裸字符串裸奔我见过太多聊天室项目协议就是干巴巴的字符串user123:hello。这种协议有三个问题第一无法可靠分帧粘包问题解决不了第二无法反映消息类型聊天消息、系统通知、上线提醒、心跳包全是同一种格式客户端解析全靠猜第三无法扩展你后面想加个消息ID用于去重、加个时间戳用于显示就得改动所有解析代码。所以协议设计必须提前想清楚。一个实用的聊天消息协议直接这样定义消息类型类型值消息类型说明0x01客户端认证客户端连接后发送token完成登录0x02聊天消息最基本的群聊内容消息0x03系统通知用户上线、下线、被踢下线等0x04心跳PING客户端主动心跳0x05心跳PONG服务端心跳回复0x06错误提示消息格式错误、无权限、被禁言等类型划分清楚之后的好处是服务端的消息分发变得非常优雅收到0x02聊天消息交给广播模块收到0x04心跳只在连接层回一个0x05收到0x06错误提示直接走系统通知通道。各模块互不干扰代码可维护性显著提升。4.2 编解码器与协议版本控制——你迟早会遇到的兼容性难题协议设计出来不是一锤子买卖。聊天室上线几个月后你会改协议字段加新消息类型。这时候客户端和服务端版本不一致就会出问题。老客户端发来的包新服务端无法解析新客户端的功能老服务端不支持。解决思路是给协议加版本号和兼容性原则包头加1字节版本号从0x01开始每次不兼容更新才递增。老版本消息类型永不改变含义只能新增类型值。服务端收到未知消息类型时不能直接断开连接要回一个0x06错误包。字段扩展时用可选字段而不是破坏原有字段顺序。代码层面就是编解码器要和版本判断绑定。比如前面那个struct.unpack_from(IBBH, ...)解析包头的方式如果版本是0x02包体的解析走新的逻辑如果是0x01走老逻辑。这个分支判断看似麻烦但它能救你于水火。4.3 服务端广播模型一条群聊消息怎么送到所有人手里聊天室的核心业务场景是一个人发消息所有在同一个房间的人都能收到。这个“广播”的动作听起来简单做起来有不少门道。最简单的实现是遍历在线用户列表对每个用户的Socket连接调用一次send()。但这种做法的性能是会随着在线人数线性下降的。假设500人在线一条消息要发送500次如果是全员群聊每来一条消息服务端就要做500次系统调用换算一下 QPS 很快就扛不住了。优化手段有两个方向方向一合并写。多个线程要同时给同一个连接发消息时不要各自调用send()而是把待发消息放进这个连接的发送队列由一个专门的写线程或事件循环统一从队列取数据再发送。这样既减少了系统调用次数又避免了多线程同时写同一个Socket导致的数据错乱。方向二批量发送。如果用的是Netty之类的框架writeAndFlush可以合并批量消息。更进一步有共享内存或组播等手段可以做进程级别或机器级别的多播优化但聊天室一般用不到这么重的手段。实际生产里的广播架构通常是服务端维护一个“房间 - 连接集合”的映射表用户加入房间时注册离开时注销。收到聊天消息先查房间里的连接集合通过ChannelGroup一类机制并发广播。注意要加分布式锁或原子操作避免并发修改在线列表导致消息漏发或者错发。4.4 心跳、断线重连与离线消息——客户端不是永远在线前面讲了服务端处理半开连接客户端侧对应的问题就是断线重连。移动端网络环境变化频繁Wi-Fi切4G、地铁隧道断网、锁屏后系统杀掉后台进程连接随时会断。客户端的重连设计有几个要点指数退避策略第一次断开等1秒重连失败等2秒再失败4秒、8秒最大间隔封顶到60秒。避免服务端一秒收到几千个客户端的重连风暴。重连后要重新认证旧连接关闭新连接需要重新发认证包服务端才能把用户重新绑定到房间映射表。本地消息队列重连期间用户发出去的消息先进本地缓冲连接恢复后按序补发。但要注意服务端做消息去重否则同一条消息可能被发送两次。离线消息这块简单做法是服务端把用户离线期间的消息存到Redis列表里用户重连且认证成功后从Redis取出补推。这个功能在系统架构中加入一个消息持久化的模块即可但要控制补推的量和顺序全量补推会把用户手机直接卡死。5. 多次上线实测踩过的坑从端口占到线程假死架构设计讲得再漂亮不如真实故障来得深刻。这里把我做Socket聊天室反复踩过的五个坑原原本本写出来每一个我都给了排查思路和最终解法。5.1 “Address already in use”与TIME_WAIT的恩怨一个让我早期一头雾水的错误服务端程序崩了马上重启报错Address already in use有时要等几分钟才能重启成功。排查过程一步步推下来发现根子在TCP连接的TIME_WAIT状态。TCP主动关闭连接的一方在发送最后一个ACK后要进入TIME_WAIT状态持续2MSL约40秒到2分钟不等。目的是确保最后一个ACK能到达对端以及让网络中残留的旧数据包在网络里消亡。服务端频繁崩溃重启时大量旧连接还挂在TIME_WAIT状态新监听同端口的请求就撞上了。解决方案是设置SO_REUSEADDR这个Socket选项。它允许服务端在TIME_WAIT状态下复用旧端口server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)Java服务端对应的是ServerBootstrap b new ServerBootstrap(); b.option(ChannelOption.SO_REUSEADDR, true);这里要注意SO_REUSEADDR只是允许端口复用不代表你不需要处理连接的优雅关闭。正常停止服务时应该先停止接受新连接然后给已有连接一个等待期最后再强制关闭。这个顺序能大量减少TIME_WAIT的产生。5.2 粘包没解好导致的消息乱码与错位——我的排查链路有一阵子生产环境用户反馈聊天内容经常出现“张冠李戴”A发的话显示在B的对话里消息体还带大量乱码。我第一反应是编码问题查了UTF-8和GBK转换没解决问题。后来抓包对比发现乱码消息的长度总是很规整的倍数才想到去查粘包解析逻辑。重复一遍排查链路先看客户端原始发送的字节数组长度和解析后收到的长度是否一致。如果长度对不上基本就是粘包或半包问题。检查拆包器逻辑重点看缓冲区里“剩余数据”有没有正确保留。用一组固定模式数据本地复现比如连续发送hello和world打印每次feed()收到的帧序列。发现原因我在total_len计算中漏算了包头长度导致缓冲区指针偏移错误每次都从错误位置解出魔数。修复就是那行total_len self.HEADER_SIZE body_len的补全。这个坑提醒我拆包器这种底层基础设施代码必须先写单元测试用真实抓包数据验证不要靠感觉调。5.3 线程爆炸与无界队列导致的服务端假死有一次压测500人并发服务端突然卡死线程数飙到2000内存快照显示大量任务堆积在线程池队列里。分析后发现是线程池使用不当使用了无界队列 无限线程数的组合消息洪峰时线程创建完全失控。修正方案是经典的有界队列 拒绝策略 CallerRunsPolicy。当队列满且线程池达到上限时让提交任务的那个线程自己执行任务相当于一个背压机制让生产者感知到压力从而降低发送速度。这比让线程池无限膨胀优雅得多。另一个相关教训消息广播的任务不能丢进同一个无界队列。要给心跳和系统通知这类高优先级消息单独留一个线程池或队列否则大量聊天消息会把心跳处理也阻塞住服务端整体失去活性。5.4 Nagle算法与套接字延迟——小包消息为什么慢了聊天消息通常是几十字节的小包。有次测试发现客户端发消息后经常有200ms的延迟才收到回复而且只在某些网络条件下出现。排查发现是TCP的Nagle算法与延迟ACK机制互相等待造成的。Nagle算法的存在是为了减少小包数量发送方攒着少量数据等收到之前数据的ACK后再一起发。延迟ACK则是接收方收到数据后不马上回ACK等一小段时间通常40ms看有没有回复数据捎带。这两者相遇就可能出现经典的死等场景。解决方案是设置TCP_NODELAY关闭Nagle算法。聊天室这类小包、要求低延迟的场景默认都应该开client_socket.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)但要注意TCP_NODELAY关闭后如果消息频率非常高会产生大量小包占满网络。实际建议聊天室默认开NODELAY因为消息量远不至于打满带宽。5.5 并发原子性在线列表的竞态条件两个用户同时上线服务端的在线列表ConcurrentHashMap被两个线程同时修改一个用put一个用remove结果出现“明明用户在线却收不到消息”的问题。这个坑的根源是复合操作没有加锁先检查房间是否存在再往房间连接集合里加连接两步之间可能被其他线程打断。方案用互斥锁包裹“检查-添加”复合操作或者直接使用更高级的并发容器比如 Netty 的ChannelGroup已经内部处理了线程安全。实在要与业务数据联动就使用ConcurrentHashMap.compute()这类原子性复合操作。6. 一次真实的压测记录500人在线时服务端表现如何最后分享一次我对自己写的聊天室服务端做的压测记录。这个服务端的架构是 epoll 事件循环 业务线程池消息协议是长度字段前缀式心跳间隔30秒。压测环境一台8核16G的云主机模拟客户端使用Python多进程并发每个进程模拟200个连接合计500个并发连接。测试场景分三个阶段阶段一500个连接全部建立并完成认证观察服务端内存与线程状态。阶段二每个连接每秒发一条聊天消息持续5分钟观察广播延迟与消息丢失率。阶段三突然断开200个连接模拟用户集体退出观察在线列表清理是否及时。结果数据如下指标表现说明连接建立耗时全部500个连接在2秒内完成正常内存占用稳定在1.2GB左右每个连接约2.4MB偏高但可接受消息广播延迟p95在80ms左右基本无感知消息丢失率0%协议层用确认机制保障断线清理耗时200个断连在3秒内全部清理心跳扫描正常这里有个亮点是消息丢失率实际做到0%不容易。我做的保障是客户端发消息后本地缓存等待服务端回一条“消息已确认”的Ack超时未收到就重发。服务端维护最近消息ID集合做去重。这套机制在高并发下多花了一些内存但换来了消息可靠性的确定性。压测后的调优经验500人在线时广播的瓶颈不在CPU而在锁竞争——消息广播时要遍历在线连接并向每个连接写数据这个操作加锁后所有消息串行化。优化方向是把自己的连接列表拆成多个分片各分片独立写锁显著降低竞争。我试过后p95延迟从80ms降到45ms左右。6.1 后续还能怎么扩展聊天室做到这一步已经是一个完整的网络系统了但它离真正的IM还有距离。我自己后续计划中的扩展方向有这么几个多节点部署单机撑不住时引入消息路由层按用户ID哈希分配节点节点之间通过内部消息通道同步在线状态与跨节点消息。消息持久化到MongoDB提供历史消息查询接口。接入WebSocket让浏览器端直接使用复用同一套协议编解码逻辑。文件传输通道独立于文本消息的上传下载服务不占用聊天主链路。这些扩展方向里多节点部署是最值得研究的一个它会把聊天室从单机系统拉进分布式系统的范畴核心问题变成一致性、消息顺序、节点间通信那又是另一座山。回到开头的观点Socket网络聊天室不是一个“练手玩具”它是通信原理和系统架构设计最好的落地载体。我做了这个项目之后再看任何网络中间件、RPC框架、消息队列都感觉底层原理是熟悉的。如果你正在学网络编程我强烈建议你把聊天室做深做透不是跑通Demo就结束而是压测它、拆解它、甚至故意搞挂它这些经历才是真正的收获。最后提一个我每次做类似项目都会坚持的小习惯把协议定义好之后先写协议文档再写代码。很多人跳过这一步直接边写边改协议结果客户端和服务端对不上排查问题的时间和写代码的时间一样多。协议文档不需要多复杂一张表写明字段类型、长度、含义、示例就能省掉相当多无谓的调试成本。这个习惯所有网络程序都适用。
