★ FEATURED ARTICLE 先说我第一次做socket联调的场景一个服务端一个客户端收发数据用的是最朴素的read(buffer)/write(buffer)结果客户端发了一万条报文服务端确实全收到了但解析出来一半是乱码。查到最后发现根本不是字符集问题而是对方把一条报文拆成了两段发而read()一次又恰好读到了两条报文的前半截。从那天起我才真正明白socket客户端和服务端以报文方式收发数据这件事远不是写个 write/read 这么简单。这篇文章就把我当时踩过的坑、最后沉淀下来的报文协议设计、服务端分帧解析、客户端并发发送的完整套路都写出来。目标是让正准备做网络通信的同学以及维护IM、设备网关、物联网采集这类项目的朋友能直接照抄一套“能处理粘包、能处理半包、能防非法报文”的收发方案。1. 先把“字节流”和“报文”的区别说透1.1 一次read读到的东西不是一条报文很多人第一次写TCP通信都会默认一个错误模型发送端调一次send()接收端read()就应该返回完整的一条数据。真实情况完全不是这样。TCP是流式协议操作系统眼里没有“消息”这个单位只有连续不断的字节。发送端调用三次write()接收端可能一次read()就把三段数据全读走发送端只调一次write()接收端也可能分三次read()才读完。前者叫粘包后者叫半包。我当时联调遇到的乱码就是典型的粘包加半包混在一起读取缓冲区里有第一条报文的后半截、第二条报文的完整内容、第三条报文的前半截我按“读到多少算多少”的业务代码去解析结果一个包都拼不完整还把一个包的尾部当成了另一个包的头部。这里有个很容易被忽略的点应用层必须在字节流上自己划出消息边界。报文方式收发数据的核心不是用什么高级API而是你能不能在自己代码里把一个完整的“消息”从流中准确切出来。1.2 边界方案对比定长、分隔符、长度前缀既然要在字节流上切报文业界常用的无非三种方案我直接对比一下方案原理优点缺点典型场景定长报文所有报文固定 N 字节不足补零实现最简单像素级切包浪费带宽业务字段变长后很难扩展老旧设备协议、指令固定的小型系统分隔符报文用\n、\r\n、特殊字符作为报文结束标志人类可读打印日志方便body里不能出现该字符否则要转义拆包性能差文本行协议、Redis RESP、HTTP头部空格分割长度前缀报文头部固定几个字节存body长度边界精确、读写干脆、二进制友好需要处理半个报头、半个body等边界细节绝大多数业务协议、RPC框架、IM私有协议绝大多数生产环境都会选长度前缀。它的核心思路很直观先读固定长度的头部从头部里拿到“这条报文有多长”再按这个长度把body读完整。只要头部本身是定长的分帧逻辑就永远不会找不到边界。1.3 长度前缀方案里协议头应该放哪些字段协议头决定了报文自描述能力我建议至少包含这几个字段magic魔数固定两三个字节比如0x5A5A用来快速识别“这是不是我们协议的起始位置”。version版本号一个字节协议变更时用来兼容新旧两端。type类型一个字节区分是业务数据、心跳、还是回执确认。length长度四个字节表示body字节数不含头部本身。body真正的业务负载。这么设计的原因很实际magic让你在错位时能重新同步version让你未来敢改协议length是整个分帧的锚点。type在排查问题时尤其有用——收到一条报文看type就知道该在哪套逻辑里处理。2. 报文协议设计字节序、长度字段与序列化一个都不能错2.1 长度字段到底存的是什么用什么字节序长度字段是分帧的关键这里有两个细节必须提前定死不然后患无穷。第一个是存的是什么长度。我见过两种约定一种存“整个包从头部开始到body结束的总长度”一种存“body长度”。两种都能工作但建议统一用后者因为解析时你只需要为body分配空间头部各字段本来就是固定长度。如果存总长度算body长度还要做一次totalLength - headerLength多一步不说还容易在协议演进时算错。第二个是字节序。TCP/IP协议族默认使用大端字节序Big-EndianJava的DataInputStream.readInt()、ByteBuffer.getInt()默认也都是大端配合得天衣无缝。但如果你用C/C在x86上直接把int变量memcpy进缓冲区再发走那是小端序另一端按大端解读数值就会变成完全不同的东西。字节序不一致造成的bug极其隐蔽找半天都发现不了最后拿抓包工具一字节一字节对比才看得出来。我的习惯是所有多字节字段显式用大端编码并写死在协议文档里绝不依赖某个语言的默认行为。2.2 body选JSON还是二进制不同场景的取舍body用什么格式决定了协议的可读性、性能和扩展成本。我把两种选择的结论直接说出来JSON文本字段自描述、加字段不影响旧版本解析、调试时日志一目了然。代价是体积大、序列化慢。适合上报类业务、设备接入、脚本联调。二进制编码体积小、编解码快但字段全靠schema约束加字段要配套处理。适合高频交易、游戏同步、大流量数据采集。MessagePack / Protobuf介于两者之间的紧凑编码二进制格式但带字段名或字段号。适合RPC、内部服务通信。做Demo或内部工具时明确推荐JSON因为你在联调阶段会不停看报文内容JSON能直接看到问题。等流量大了、确定瓶颈在编解码或带宽上再往二进制迁移不迟。2.3 一个可直接落地的Packet结构我用的报文结构是这样的字段字节数说明magic2固定0x5A5A用于同步和校验version1当前为0x01type10x01业务0x02心跳0x03回执length4body长度大端序不含头部字段body可变业务数据头部总计8字节。这样一个最小报文的开销只有8字节体量在大多数业务里都可以接受。Java里对应的数据类大致是这样public class DataPacket { public static final short MAGIC (short) 0x5A5A; public static final int HEADER_LEN 8; private byte version; private byte type; private byte[] body; // 从头部字节解析长度和基本字段 public static int parseBodyLength(byte[] header) { ByteBuffer buf ByteBuffer.wrap(header).order(ByteOrder.BIG_ENDIAN); short magic buf.getShort(); if (magic ! MAGIC) { throw new IllegalArgumentException(magic mismatch: Integer.toHexString(magic 0xffff)); } buf.get(); // version buf.get(); // type return buf.getInt(); // body length } public byte[] toBytes() { ByteBuffer buf ByteBuffer.allocate(HEADER_LEN body.length).order(ByteOrder.BIG_ENDIAN); buf.putShort(MAGIC); buf.put(version); buf.put(type); buf.putInt(body.length); buf.put(body); return buf.array(); } }parseBodyLength只处理头部8字节返回body长度这一步是后面所有分帧逻辑的基础。3. 服务端实现readFully 循环分帧就够了但要注意这几处3.1 服务端接收主流程先读定长头再读body服务端接收报文最直白的写法是用Java的DataInputStream。它的readFully()会一直阻塞直到读满指定字节数天然帮我们兜住了半包问题。核心接收循环是这样的public void handleClient(Socket socket) { try (DataInputStream in new DataInputStream(socket.getInputStream())) { while (true) { // 1. 先读完整8字节头部 byte[] header new byte[DataPacket.HEADER_LEN]; in.readFully(header); // 2. 从头部解析出body长度 int bodyLen DataPacket.parseBodyLength(header); if (bodyLen 0 || bodyLen MAX_BODY_LEN) { // 记录异常关闭连接或重同步防止恶意大长度 break; } // 3. 再读完整body byte[] body new byte[bodyLen]; in.readFully(body); // 4. 这里就是一条完整报文交给业务处理 dispatch(socket, header, body); } } catch (EOFException e) { // 对端正常关闭连接结束 } catch (IOException e) { // 网络异常记录日志 } }这里的要点是先读定长头部从头部解析长度再按长度读body然后循环。只要一直做“读头→读体→读头→读体”这个循环粘包就无从谈起——因为每次处理都明确消费掉一条完整报文不会把多条报文混在一个解析逻辑里。3.2 readFully为什么能自动解决半包半包指的是网络层把一条报文拆成多次到达。很多人对readFully有误解以为它就是个普通的read()读不完就算了。实际上它的内部逻辑是循环调用read()直到凑满目标字节数才返回。比如一条body长度是1000字节的报文网络只先到了300字节readFully(body)会一直阻塞在输入流上等剩下的700字节而不是返回一个只有300字节的“半截body”。这就是半包问题的最终解法——不要用read()的返回值去判断一条报文是否结束而是用“是否读满所需字节数”来判断。类似的行为在C/C里没有现成封装需要自己包一层循环ssize_t read_full(int fd, void* buf, size_t n) { size_t done 0; while (done n) { ssize_t r read(fd, (char*)buf done, n - done); if (r 0) { // 返回0是EOF返回负数是错误都要交给上层处理 return -1; } done r; } return (ssize_t)done; }凡是用到socket开发的语言自己实现这样一个read_full都是基本功。3.3 粘包拆包循环读取时如何保证一条一条报文解析粘包的表现是一次底层read()返回的数据里包含两条甚至更多条完整报文。用上面handleClient的循环写法粘包问题实际上已经被“循环消费”化解了底层输入流里虽然堆了很多数据但业务解析始终一次只处理一条读完第一条的body之后第二条的头部正好排在流的下一个位置下一次循环把它读走周而复始。如果用的是NIO或Netty这类非阻塞模型没有DataInputStream帮你挡半包就必须自己维护一个接收缓冲区把所有落进来的字节先追加到缓冲再尝试从中解析出一个完整报文。逻辑拆开就是四个动作缓冲区里不足8字节头部时继续等数据够8字节后解析出body长度缓冲区里不足body长度时继续等数据够body长度后从缓冲区切出一个完整包交给业务然后回到第2步继续看缓冲区里还有没有下一个包。这个逻辑我再熟悉不过写成一个可复用的Framer类放到了内部工具库里核心结构是public class Framer { private final ByteBuffer buffer ByteBuffer.allocate(1024 * 1024); // 单连接缓冲区 public ListDataPacket feed(byte[] chunk, int len) { ListDataPacket packets new ArrayList(); buffer.put(chunk, 0, len); buffer.flip(); while (true) { if (buffer.remaining() DataPacket.HEADER_LEN) { break; // 头部都不完整等下一次数据 } byte[] header new byte[DataPacket.HEADER_LEN]; buffer.get(header); int bodyLen DataPacket.parseBodyLength(header); if (bodyLen MAX_BODY_LEN) { // 非法长度需要重新同步 break; } if (buffer.remaining() bodyLen) { // body还没到齐把已读出的header“退回”缓冲区再由系统缓存 break; } byte[] body new byte[bodyLen]; buffer.get(body); packets.add(new DataPacket(header, body)); } // 把剩余未处理的数据移到缓冲区头部留到下次继续拼 buffer.compact(); return packets; } }这种方式的好处是无论对方怎么拆分TCP段最终每个业务线程拿到手的都是一条边界清晰的完整报文后续处理逻辑可以完全不用关心网络细节。3.4 非法报文识别与magic错位恢复分帧逻辑最怕的事情是流错位对端发的数据不是从协议头部开始的或者中间丢了一两个字节导致解析出来的magic不对。遇到这种情况我见过不少人直接关闭连接这在重连成本低的场景可以接受但在长连接设备网关上动辄断连上万台设备最好的做法是先尝试重新同步。重新同步的思路是当发现头部magic不是0x5A5A时不立即放弃而是一字节一字节往后扫描找到下一个可能是协议起始的位置把该位置之前的字节丢弃再继续按正常流程解析。private void resync(ByteBuffer buffer) { buffer.mark(); while (buffer.hasRemaining()) { if (buffer.get() (byte) 0x5A) { buffer.reset(); // 回到mark然后从找到的0x5A处重新开始 // 这里判断再下一个字节是否0x5A确认真正对齐 if (buffer.remaining() 2 buffer.getShort() DataPacket.MAGIC) { buffer.reset(); return; } } buffer.mark(); } // 如果扫描完都没找到magic清空缓冲区等新数据 buffer.clear(); }这个resync逻辑在线上救过很多次。比如客户端某个报文body里恰好包含0x5A5A开头的字节序列而服务端因为某种原因多读了几个字节magic错位扫描后能立刻找回正确位置而不是把整个长连接砍掉重连。4. 客户端发送组包、flush时机、并发下的write原子性4.1 组包发送的标准写法服务端负责拆包客户端就负责组包。组包的本质是把“业务对象”转成上面定义的协议字节然后原样写入socket输出流。最朴素也最可靠的客户端发送方法长这样public class TcpClient { private Socket socket; private final Object writeLock new Object(); public void sendPacket(byte type, byte[] body) throws IOException { byte[] frame new DataPacket(type, body).toBytes(); synchronized (writeLock) { OutputStream out socket.getOutputStream(); out.write(frame); out.flush(); } } }这里有两个容易被新手跳过、却极其关键的细节。第一个是先把完整帧拼成byte数组再一次write而不是分别write头部和body。如果拆成两次write中间发生网络中断或者对端快速读取对端可能先收到头部后阻塞等待body造成不必要的超时。第二个是flush时机调用方要求实时发送时就必须flush否则数据会积在本地发送缓冲里。4.2 多线程共用socket时的三个坑客户端常常是多线程的多个业务线程同时调sendPacket这时候socket输出流就成了共享资源至少有三个坑要避开write不是原子的Java里两个线程同时write()不一定报错但数据可能交错穿插对端收到的就是两个报文头部和body混合在一起的垃圾。解决办法就是给整个发送动作加锁保证“头部body”作为一个整体不被拆散。在锁内做网络IO要控制范围锁只保护write本身不要在锁里做业务计算、序列化、日志打印。序列化在锁外先做好锁内只做write flush减少持锁时间。关闭socket不能和发送并发一个线程在发数据另一个线程调用close()常见结果是发送线程拿到一个莫名的socket异常甚至对端收到半包。建议在客户端对象里定义一个volatile boolean closed发送前检查关闭时先置位再close。这里最值得记住的经验是发送侧一定要有一个明确的“单包原子性”保证否则并发一上来粘包问题就会从发送端先冒出来。4.3 发送成功不等于对端处理成功RST与半关闭现象还有一个必须提前打预防针的认知write()返回成功只代表数据成功写入本机内核发送缓冲区不代表对端应用层已经把报文解析完。TCP是异步的除非收到应用层回执否则任何“我发了它就一定收到了”的假设都是危险的。我在实测中遇到过这样的事服务端程序崩溃后异常退出客户端不知道还在继续发数据。第一次write居然成功第二次write直接抛Connection reset异常。原因是对端内核收到数据后发现没有应用进程处理发送了RST复位报文。这种场景下客户端正确的做法是捕获到RST后主动重连同时把发送失败前未确认的报文缓存起来等连接恢复后补发。如果你需要严格的可靠性最简单有效的办法是在协议里加一个回执类型type0x03客户端发一条业务报文后服务端处理完回一条ack客户端在超时时间内没收到就重发或者标记失败。别依赖TCP的传输可靠性那只能保证字节到达对端内核不能保证业务处理成功。5. 完整Demo与实测中遇到的三个意外情况5.1 可运行的Demo带seq的收发互相印证为了验证前面这些设计我写了一个代码量很小但能完整跑通的Demo客户端启动后按顺序发送1000条业务报文每条报文带一个自增seq和一段固定文本服务端解析出seq后立即回一条ack报文客户端收到ack就打印成功。这样一发一回能直观看到粘包、半包有没有被正确处理。服务端主要代码public class PacketServer { private final int port 9100; public void start() throws IOException { try (ServerSocket server new ServerSocket(port)) { System.out.println(server started at port); while (true) { Socket socket server.accept(); new Thread(() - handle(socket)).start(); } } } private void handle(Socket socket) { try (DataInputStream in new DataInputStream(socket.getInputStream()); OutputStream out socket.getOutputStream()) { while (true) { byte[] header new byte[DataPacket.HEADER_LEN]; in.readFully(header); int bodyLen DataPacket.parseBodyLength(header); byte[] body new byte[bodyLen]; in.readFully(body); // 假设body前4字节是seq回一条ack int seq ByteBuffer.wrap(body).order(ByteOrder.BIG_ENDIAN).getInt(); byte[] ack new DataPacket((byte) 0x03, body).toBytes(); out.write(ack); out.flush(); } } catch (EOFException ignored) { // 客户端断开 } catch (IOException e) { e.printStackTrace(); } } }客户端主要代码public class PacketClient { public static void main(String[] args) throws Exception { try (Socket socket new Socket(127.0.0.1, 9100)) { Object writeLock new Object(); for (int i 0; i 1000; i) { byte[] body ByteBuffer.allocate(4 32) .order(ByteOrder.BIG_ENDIAN) .putInt(i) .put(hello-packet-demo.getBytes(StandardCharsets.UTF_8)) .array(); byte[] frame new DataPacket((byte) 0x01, body).toBytes(); synchronized (writeLock) { socket.getOutputStream().write(frame); socket.getOutputStream().flush(); } Thread.sleep(2); } } } }不用担心性能问题这个Demo的目标是把协议、分帧、回执的闭环走通。实际测试跑完1000条服务端日志里seq无跳号、无乱序说明报文边界处理是稳的。5.2 意外一客户端快速连发服务端粘包严重有次我为了测试吞吐把客户端的Thread.sleep(2)去掉瞬间连续写几千条。服务端日志立刻开始出现一种有趣的现象多条报文在极短时间内连续到达readFully(header)每次都能秒回仿佛完全没有等待。这就是粘包的典型表现——底层一次read可能就把几十条报文的数据全部搬了进来。但因为代码是“读头→读体→读头→读体”的循环分帧最终日志里seq依然完全连续。这次实测让我彻底确认了一件事粘包不是bug是TCP的正常聚合现象你只要不断开数据边界它永远不会真正干扰业务。不过这也带来一个教训如果服务端处理单条报文的速度跟不上客户端发送速度socket缓冲区会被填满发送端write会开始阻塞或超时。这种流控压力靠协议本身解决不了需要在应用层做背压比如客户端发送队列设置上限满了就丢弃或降速。5.3 意外二读头阻塞导致新连接进不来Demo跑多线程时还遇到过一次连接饥饿问题。服务端每个连接分配一个线程但某个客户端建立连接后不发数据处理线程就永久阻塞在readFully(header)上占着一个线程不释放。连接一多线程池被打满新的连接accept了也没线程处理表现就是整个服务端假死。解决这个问题有两个方向。一是给socket设置读超时socket.setSoTimeout(30_000); // 30秒没有数据就抛SocketTimeoutException超时后可以主动关闭该空闲连接让线程回到池子里。二是坚决不用“每连接一线程”的模型改用一个固定大小的线程池任务排队执行。对于报文收发这种瓶颈在网络IO的场景线程池大小不需要很大但要把“阻塞读”和“业务处理”分开避免一个空闲连接拖垮整个服务端。5.4 意外三服务端重启后客户端还在写收到RST异常联调中最狼狈的一次是服务端代码改完重启客户端忘记停掉还在一个劲儿发数据。结果客户端第二次write直接抛java.net.SocketException: Connection reset服务端日志里则出现Connection reset by peer。这个问题的本质是服务端正常关闭socket时内核会先完成四次挥手但如果服务端进程是强制kill或者有未读完的数据就close内核会发RST。客户端拿到RST后这个socket就已经废了任何读写都会异常。这也是为什么我在4.3说“发送成功不等于对方收到”——在进程崩溃这种场景下TCP的可靠传输外部保障完全失效唯一靠谱的确认机制必须是应用层回执。经历过这次之后我给客户端加了三处防御发送前检查连接状态捕获IOException后主动清理旧socket并重连所有未收ack的报文进入重发队列。后来再遇到服务端重启客户端最多就是短暂闪断几秒钟然后自动恢复数据一条不少。6. 写在最后协议先行编解码独立成层做了几年socket相关的东西我最深的体会是任何应用层网络协议本质上都在回答“数据从哪里开始、到哪里结束”这一个问题。TCP把传输这件事做得再可靠也不会替你划分业务消息边界报文方式的代码写得再花哨核心也不过是“定长的头、明确的长度、循环的分帧”。如果你打算在自己的项目里落地这套方案我最后给一个非常实用的建议先把协议和编解码独立成一层不要散落在业务代码里。定义好DataPacket之后所有的发送方只跟DataPacket打交道服务端只接收DataPacket业务层永远看不到半包和粘包的存在。这一步看起来只是代码组织上的小调整但等协议改版、需要做兼容的时候你会发现当初把编解码和业务拆开是你做过的最正确的决定之一。
阅读完成 · 觉得有帮助？
