dubbo的半包和粘包

若出现粘包，就会根据它的请求长度进行截取；

若出现拆包，数据会不完整，就进入循环重新读取，直到取到完整数据。

一、前言
在客户端与服务端进行通信时候都会约定一个通讯协议，协议一般包含一个header和body，一个header和body组成了一次通讯的内容，一个通讯包。正常情况下客户端通过socket发送一个请求包后，服务端接受后解析请求包，然后进行处理，这看似是一个很简单的问题，但当客户端连续发送多个请求包时就可能会出现半包、粘包现象。

二、什么是粘包与半包问题
在客户端发送数据时，实际是把数据写入到了TCP发送缓存里面的。

如果发送的包的大小比TCP发送缓存的容量大，那么这个数据包就会被分成多个包，通过socket多次发送到服务端，服务端第一次从接受缓存里面获取的数据，实际是整个包的一部分，这时候就产生了半包现象，半包不是说只收到了全包的一半，是说收到了全包的一部分。

如果发送的包的大小比TCP发送缓存容量小，并且TCP缓存可以存放多个包，那么客户端和服务端的一次通信就可能传递了多个包，这时候服务端从接受缓存就可能一下读取了多个包，这时候就出现了粘包现象。

服务端从接受缓存读取数据后一般都是进行解码操作，也就是会把byte流转换了pojo对象，如果出现了粘包或者半包现象，则进行转换时候就会出现异常。

出现粘包和半包的原因是TCP层不知道上层业务的包的概念，它只是简单的传递流，所以需要上层应用层协议来识别读取的数据是不是一个完整的包。

三、如何避免
比较常见方案是应用层设计协议时候协议包分为header和body,header里面记录body长度，当服务端从接受缓冲区读取数据后，如果发现数据大小小于包的长度则说明出现了半包，这时候就回退读取缓存的指针，等待下次读事件到来的时候再次测试。如果发现包长度大于了包长度则看长度是包大小整数倍则说明了出现了粘包，则循环读取多个包，否者就是出现了多个整包+半包。

多个包之间添加分隔符。

包定长，每个包大小固定长度。

四、总结
本文介绍了网络通讯中粘包和半包的概念，出现原因，以及常用的应对策略。

其实在前面几篇网络编程的文章里面，关于粘包和拆包已经讲的差不多了，由于本人这周五准备组内分享——dubbo 的粘包和拆包，这篇博客就把 dubbo 处理粘包和拆包的流程梳理总结一下。

什么是粘包和拆包

TCP 粘包拆包发生的原因

1.应用程序 write 写入的字节大小大于套接口发送缓冲区大小

2.进行 MSS 大小的 TCP 分段

3.以太网帧的 payload(有效数据) 大于 MTU 进行 IP 分片

以往业界时如何解决粘包和拆包的？

1.消息的定长，例如定 1000 个字节

2.就是在包尾增加回车或空格等特殊字符作为切割。典型的 FTP 协议

3.将消息分为消息头消息体，消息头中包含表示消息总长度（或者消息体长度）的字段，通常涉及思路为消息头的第一个字段使用 int32 来表示消息的总长度。例如 dubbo

dubbo 为什么没有选择 netty 原生的粘包和拆包的方法，选择自定义？

因为 dubbo 的协议栈是自定义的，里面包含消息头和消息体两个部分，消息头中包含消息类型、协议版本、协议魔数以及 playload 长度等信息。而 netty 只能处理一些通用简单的协议栈，并不能处理高度自定义的协议栈，所以 dubbo 自定义了属于自己的一套粘包和拆包的解决办法。

消息头和消息体长什么样？

以 provider 给 consumer 发送的数据包为例

ExchangeCodec 类—encodeResponse()

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

Serialization serialization = getSerialization(channel); byte[] header = new byte[HEADER_LENGTH]; // set magic number. Bytes.short2bytes(MAGIC, header); // set request and serialization flag. header[2] = serialization.getContentTypeId();//序列化ID if (res.isHeartbeat()) header[2] |= FLAG_EVENT; // set response status. byte status = res.getStatus(); header[3] = status;//第四个字节为20，代表"ok" // set request id. Bytes.long2bytes(res.getId(), header, 4); int savedWriteIndex = buffer.writerIndex(); buffer.writerIndex(savedWriteIndex + HEADER_LENGTH); ChannelBufferOutputStream bos = new ChannelBufferOutputStream(buffer); ObjectOutput out = serialization.serialize(channel.getUrl(), bos); // encode response data or error message. if (status == Response.OK) { if (res.isHeartbeat()) { encodeHeartbeatData(channel, out, res.getResult()); } else { encodeResponseData(channel, out, res.getResult()); } } else out.writeUTF(res.getErrorMessage()); out.flushBuffer(); bos.flush(); bos.close(); int len = bos.writtenBytes(); checkPayload(channel, len); Bytes.int2bytes(len, header, 12); // write buffer.writerIndex(savedWriteIndex); buffer.writeBytes(header); // write header. buffer.writerIndex(savedWriteIndex + HEADER_LENGTH + len);//写入消息头和消息体总长度

dubbo 的消息头是一个定长的 16 个字节。
第 1-2 个字节：是一个魔数数字：就是一个固定的数字
第 3 个字节：序列号组件类型，它用于和客户端约定的序列号编码号
第四个字节：它是 response 的结果响应码 例如 OK=20
第 5-12 个字节：请求 id：long 型 8 个字节。异步变同步的全局唯一 ID，用来做 consumer 和 provider 的来回通信标记。
第 13-16 个字节：消息体的长度，也就是消息头 + 请求数据的长度。

这样，接着看 consumer 接受到编码后的消息体，是如何处理的

NettyCodecAdapter.InternalDecoder 类

messageReceived()

分两个部分

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

//首先判断当前decoder对象的buffer中是否有可以读取的消息，若有，则合并。并将对象赋值给message局部变量 if (buffer.readable()) { if (buffer instanceof DynamicChannelBuffer) { buffer.writeBytes(input.toByteBuffer()); message = buffer;//message获取当前channel的inbound消息 } else { int size = buffer.readableBytes() + input.readableBytes(); message = com.alibaba.dubbo.remoting.buffer.ChannelBuffers.dynamicBuffer( size > bufferSize ? size : bufferSize); message.writeBytes(buffer, buffer.readableBytes()); message.writeBytes(input.toByteBuffer()); } } else { message = com.alibaba.dubbo.remoting.buffer.ChannelBuffers.wrappedBuffer( input.toByteBuffer()); } NettyChannel channel = NettyChannel.getOrAddChannel(ctx.getChannel(), url, handler); Object msg; int saveReaderIndex;

1 2 3 4 5 6 7 8 9 10

try { // decode object. do { //保存当前message的读索引，用于后期消息回滚 saveReaderIndex = message.readerIndex(); try { //DubboCountCodec的decode每次只会解析出一个完整的dubbo协议栈 msg = codec.decode(channel, message);//debug } }

DubboCountCodec 类

decode()

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public Object (Channel channel, ChannelBuffer buffer) throws IOException { int save = buffer.readerIndex();//保存buffer的读索引 MultiMessage result = MultiMessage.create(); do { Object obj = codec.decode(channel, buffer);//debug if (Codec2.DecodeResult.NEED_MORE_INPUT == obj) {//数据不足 buffer.readerIndex(save);//将buffer读索引回滚 break; } else { result.addMessage(obj); logMessageLength(obj, buffer.readerIndex() - save); save = buffer.readerIndex();//save更新 } } while (true); if (result.isEmpty()) { return Codec2.DecodeResult.NEED_MORE_INPUT; } if (result.size() == 1) { return result.get(0); } return result; }

这里暂存了当前buffer的读索引，同样也是为了后面的回滚。可以看到当 decode 返回的是 NEED_MORE_INPUT 则表示当前的buffer中数据不足，不能完整解析出一个 dubbo 协议栈，同时将 buffer 的读索引回滚到之前暂存的索引并且退出循环，将结果返回。

ExchangeCodec 类

decode()

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

protected Object (Channel channel, ChannelBuffer buffer, int readable, byte[] header) throws IOException { // check magic number. if (readable > 0 && header[0] != MAGIC_HIGH || readable > 1 && header[1] != MAGIC_LOW) { int length = header.length; if (header.length < readable) { header = Bytes.copyOf(header, readable); buffer.readBytes(header, length, readable - length); } for (int i = 1; i < header.length - 1; i++) { if (header[i] == MAGIC_HIGH && header[i + 1] == MAGIC_LOW) { buffer.readerIndex(buffer.readerIndex() - header.length + i); header = Bytes.copyOf(header, i); break; } } return super.decode(channel, buffer, readable, header); } // check length. //1：当前buffer的可读长度还没有消息头长，说明当前buffer连协议栈的头都不完整 if (readable < HEADER_LENGTH) { return DecodeResult.NEED_MORE_INPUT; } // get data length. int len = Bytes.bytes2int(header, 12); checkPayload(channel, len);//payload的长度 int tt = len + HEADER_LENGTH; //2：当前buffer包含了完整的消息头，便可以得到payload的长度，发现它的可读的长度，并没有包含整个协议栈的数据 if (readable < tt) { return DecodeResult.NEED_MORE_INPUT; } // limit input stream. // 3：如果上面两个情况都不符合，那么说明当前的buffer至少包含一个dubbo协议栈的数据，那么从当前buffer中读取一个dubbo协议栈的数据，解析出一个dubbo数据，当然这里可能读取完一个dubbo数据之后还会有剩余的数据。读取一个dubbo协议栈的数据 ChannelBufferInputStream is = new ChannelBufferInputStream(buffer, len); try { return decodeBody(channel, is, header); } finally { if (is.available() > 0) { try { if (logger.isWarnEnabled()) { logger.warn("Skip input stream " + is.available()); } StreamUtils.skipUnusedStream(is); } catch (IOException e) { logger.warn(e.getMessage(), e); } } } }

## 总结

dubbo 在处理 tcp 的粘包和拆包时是借助InternalDecoder的buffer缓存对象来缓存不完整的 dubbo 协议栈数据，等待下次 inbound 事件，合并进去。所以说在 dubbo 中解决 TCP 拆包和粘包的时候是通过buffer变量来解决的

上面的方法就解决了粘包了拆包的问题了

若出现粘包，就会根据它的请求长度进行截取；

若出现拆包，数据会不完整，就进入循环重新读取，直到取到完整数据。