开源一个自用的Android IM库，基于Netty+TCP+Protobuf实现(3)

TCP的拆包与粘包

• 
  
• 
  

  什么是TCP拆包？为什么会出现TCP拆包？

  
  

  简单地说，我们都知道TCP是以“流”的形式进行数据传输的，而且TCP为提高性能，发送端会将需要发送的数据刷入缓冲区，等待缓冲区满了之后，再将缓冲区中的数据发送给接收方，同理，接收方也会有缓冲区这样的机制，来接收数据。
  
  拆包就是在socket读取时，没有完整地读取一个数据包，只读取一部分。

  
  
  
• 
  

  什么是TCP粘包？为什么会出现TCP粘包？

  
  

  同上。
  
  粘包就是在socket读取时，读到了实际意义上的两个或多个数据包的内容，同时将其作为一个数据包进行处理。

  
  
  

引用网上一张图片来解释一下在TCP出现拆包、粘包以及正常状态下的三种情况，如侵请联系我删除：

了解了TCP出现拆包/粘包的原因，那么，如何解决呢？通常来说，有以下四种解决方式：

• 
  
• 消息定长
  
• 用回车换行符作为消息结束标志
  
• 用特殊分隔符作为消息结束标志，如\t、\n等，回车换行符其实就是特殊分隔符的一种。
  
• 将消息分为消息头和消息体，在消息头中用字段标识消息总长度。
  

netty针对以上四种场景，给我们封装了以下四种对应的解码器：

• 
  
• FixedLengthFrameDecoder，定长消息解码器
  
• LineBasedFrameDecoder，回车换行符消息解码器
  
• DelimiterBasedFrameDecoder，特殊分隔符消息解码器
  
• LengthFieldBasedFrameDecoder，自定义长度消息解码器。
  

我们用到的就是LengthFieldBasedFrameDecoder自定义长度消息解码器，同时配合LengthFieldPrepender编码器使用，关于参数配置，建议参考netty--最通用TCP黏包解决方案：LengthFieldBasedFrameDecoder和LengthFieldPrepender这篇文章，讲解得比较细致。我们配置的是消息头长度为2个字节，所以消息包的最大长度需要小于65536个字节，netty会把消息内容长度存放消息头的字段里，接收方可以根据消息头的字段拿到此条消息总长度，当然，netty提供的LengthFieldBasedFrameDecoder已经封装好了处理逻辑，我们只需要配置lengthFieldOffset、lengthFieldLength、lengthAdjustment、initialBytesToStrip即可，这样就可以解决TCP的拆包与粘包，这也就是netty相较于原生nio的便捷性，原生nio需要自己处理拆包/粘包等问题。

长连接握手认证

接着，我们来看看LoginAuthHandler和HeartbeatRespHandler：

• 
  
• LoginAuthRespHandler是当客户端与服务端长连接建立成功后，客户端主动向服务端发送一条登录认证消息，带入与当前用户相关的参数，比如token，服务端收到此消息后，到数据库查询该用户信息，如果是合法有效的用户，则返回一条登录成功消息给该客户端，反之，返回一条登录失败消息给该客户端，这里，就是在接收到服务端返回的登录状态后的处理handler，比如：
  

可以看到，当接收到服务端握手消息响应后，会从扩展字段取出status，如果status=1，则代表握手成功，这个时候就先主动向服务端发送一条心跳消息，然后利用Netty的IdleStateHandler读写超时机制，定期向服务端发送心跳消息，维持长连接，以及检测长连接是否还存在等。

• 
  
• HeartbeatRespHandler是当客户端接收到服务端登录成功的消息后，主动向服务端发送一条心跳消息，心跳消息可以是一个空包，消息包体越小越好，服务端收到客户端的心跳包后，原样返回给客户端，这里，就是收到服务端返回的心跳消息响应的处理handler，比如：
  

这个就比较简单，收到心跳消息响应，无需任务处理，直接打印一下方便我们分析即可。

心跳机制及读写超时机制

心跳包是定期发送，也可以自己定义一个周期，比如Android微信智能心跳方案，为了简单，此处规定应用在前台时，8秒发送一个心跳包，切换到后台时，30秒发送一次，根据自己的实际情况修改一下即可。心跳包用于维持长连接以及检测长连接是否断开等。

接着，我们利用Netty的读写超时机制，来实现一个心跳消息管理handler：

可以看到，利用userEventTriggered()方法回调，通过IdleState类型，可以判断读超时/写超时/读写超时，这个在添加IdleStateHandler时可以配置，下面会贴上代码。首先我们可以在READER_IDLE事件里，检测是否在规定时间内没有收到服务端心跳包响应，如果是，那就触发重连操作。在WRITER_IDEL事件可以检测客户端是否在规定时间内没有向服务端发送心跳包，如果是，那就主动发送一个心跳包。发送心跳包是在子线程中执行，我们可以利用之前写的work线程池进行线程管理。

addHeartbeatHandler()代码如下：

从图上可看到，在IdleStateHandler里，配置的读超时为心跳间隔时长的3倍，也就是3次心跳没有响应时，则认为长连接已断开，触发重连操作。写超时则为心跳间隔时长，意味着每隔heartbeatInterval会发送一个心跳包。读写超时没用到，所以配置为0。

onConnectStatusCallback(int connectStatus)为连接状态回调，以及一些公共逻辑处理：

连接成功后，立即发送一条握手消息，再次梳理一下整体流程：

• 
  
• 客户端根据服务端返回的host及port，进行第一次连接。
  
• 连接成功后，客户端向服务端发送一条握手认证消息(1001)
  
• 服务端在收到客户端的握手认证消息后，从扩展字段里取出用户token，到本地数据库校验合法性。
  
• 校验完成后，服务端把校验结果通过1001消息返回给客户端，也就是握手消息响应。
  
• 客户端收到服务端的握手消息响应后，从扩展字段取出校验结果。若校验成功，客户端向服务端发送一条心跳消息(1002)，然后进入心跳发送周期，定期间隔向服务端发送心跳消息，维持长连接以及实时检测链路可用性，若发现链路不可用，等待一段时间触发重连操作，重连成功后，重新开始握手/心跳的逻辑。
  

看看TCPReadHandler收到消息是怎么处理的：


可以看到，在channelInactive()及exceptionCaught()方法都触发了重连，channelInactive()方法在当链路断开时会调用，exceptionCaught()方法在当出现异常时会触发，另外，还有诸如channelUnregistered()、channelReadComplete()等方法可以重写，在这里就不贴了，相信聪明的你一眼就能看出方法的作用。

我们仔细看一下channelRead()方法的逻辑，在if判断里，先判断消息类型，如果是服务端返回的消息发送状态报告类型，则判断消息是否发送成功，如果发送成功，从超时管理器中移除，这个超时管理器是干嘛的呢？下面讲到消息重发机制的时候会详细地讲。在else里，收到其他消息后，会立马给服务端返回一个消息接收状态报告，告诉服务端，这条消息我已经收到了，这个动作，对于后续需要做的离线消息会有作用。如果不需要支持离线消息功能，这一步可以省略。最后，调用消息转发器，把接收到的消息转发到应用层即可。

代码写了这么多，我们先来看看运行后的效果，先贴上缺失的消息发送代码及ims关闭代码以及一些默认配置项的代码。

发送消息：
关闭ims：
ims默认配置：
还有，应用层实现的ims client启动器：

由于代码有点多，不太方便全部贴上，如果有兴趣可以下载demo体验。
额，对了，还有一个简易的服务端代码，如下：