消息粘包 和 消息不完整 问题

消息粘包和消息不完整问题

消息粘包和消息不完整问题其实都是应用层会带来的问题，和TCP 没关系，TCP 是能够保证消息的顺序和完整性的
本篇只是简单说明一下什么是消息粘包和消息不完整问题

1.复现消息粘包和消息不完成问题

先来看看出现了什么问题导致需要去处理消息粘包和消息完整问题，前面通过NIO改造了聊天室的案例中，我们开复现一下消息粘包和消息不完整

1.1 复现消息粘包问题

Client端发送多条数据

代码还是原来的Client端代码，只是在发送数据的时候一次性发了100条

public static void connectServer(ServerInfo serverInfo) {
        try {
            // 开启 tcp 连接
            socket = new Socket(Inet4Address.getByName(serverInfo.getIp()), serverInfo.getPort());
            // 开启 线程 异步 读取 server message
            clientReadHandler =
                    new ClientReadHandler(socket.getInputStream(), ClientConnectTcp::close);
            clientReadHandler.start();
            // 监听 键盘写入 system.in
            systemInReader = new BufferedReader(new InputStreamReader(System.in));
            clientWriteHandler = new ClientWriteHandler(socket.getOutputStream());
            do {
                String message = systemInReader.readLine();
                // 异步发送 到 server
                if (message != null) {
                     //把读取到的message 发送100次 并且后面添加上i标识
                    for (int i = 0; i < 100; i++) {
                        clientWriteHandler.sendMsg(message + ":" + i);
                    }
                }
                if (CommonConstants.BYE_FLAG.equals(message)) {
                    close();
                }
            } while (!doReadFlag);
        } catch (IOException e) {
            log.error("【建立tcp 连接异常：{}】", e.getMessage());
        } finally {
            close();
        }
    }

Server端接受到的消息

可以看到出现了严重的粘包问题，原本我们希望消息是一条一条处理，如下：
receiveAsync message:abcdefg:0
receiveAsync message:abcdefg:1
receiveAsync message:abcdefg:2

10:12:21.721 [read-io-executors1] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:abcdefg:0
abcdefg:1
abcdefg:2
abcdefg:3
abcdefg:4
abcdefg:5
abcdefg:6
abcdefg:7
abcdefg:8
abcdefg:9
abcdefg:10
abcdefg:11
abcdefg:12
abcdefg:13
abcdefg:14
abcdefg:15
abcdefg:16
abcdefg:17
abcdefg:18
abcdefg:19
abcdefg:20
abcdefg:21
abcdefg:22
abcdefg:23
a
10:12:21.722 [read-io-executors2] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:cdefg:24
abcdefg:25
abcdefg:26

1.2 复现消息不完整问题

修改Server 服务器端的 IoArgs 的 ByteBuffer的缓冲区大小

@Slf4j
@Data
public class IoArgs {
  //缓冲区大小 从 256个字节  改成 4 个字节
  private ByteBuffer byteBuffer = ByteBuffer.allocate(4);
  其他代码省略...
}

Client客户端还是如下发送100条数据

do {
       String message = systemInReader.readLine();
       // 异步发送 到 server
       if (message != null) {
           for (int i = 0; i < 100; i++) {
              clientWriteHandler.sendMsg(message + ":" + i);
          }
       }
       if (CommonConstants.BYE_FLAG.equals(message)) {
           close();
       }
 } while (!doReadFlag);

Server端接受到的消息

可以看到原本一条消息 abcdefg 被拆开成了很多子消息了。。出现了严重的消息不完整问题

10:19:38.754 [read-io-executors1] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:abc
10:19:38.754 [read-io-executors2] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:efg
10:19:38.755 [read-io-executors3] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:0
a
10:19:38.755 [read-io-executors4] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:cde
10:19:38.756 [read-io-executors1] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:g:1
10:19:38.756 [read-io-executors2] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:abc
10:19:38.756 [read-io-executors3] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:efg
10:19:38.756 [read-io-executors4] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:2
a
10:19:38.756 [read-io-executors1] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:cde
10:19:38.757 [read-io-executors2] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:g:3
10:19:38.757 [read-io-executors3] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:abc
10:19:38.757 [read-io-executors4] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:efg
10:19:38.757 [read-io-executors1] INFO com.johnny.chatroom.lib.nio.Connector - receiveAsync message:4

2. 消息粘包和消息不完成问题概述

在socket网络编程中，都是端到端通信，由客户端端口+服务端端口+客户端IP+服务端IP+传输协议组成的五元组可以明确的标识一条连接。在TCP的socket编程中，发送端和接收端都有成对的socket。发送端为了将多个发往接收端的包，更加高效的的发给接收端，于是采用了优化算法（Nagle算法），将多次间隔较小、数据量较小的数据，合并成一个数据量大的数据块，然后进行封包。那么这样一来，接收端就必须使用高效科学的拆包机制来分辨这些数据。

2.1 什么是TCP粘包问题？

TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。

2.2 造成TCP粘包的原因

发送方原因
TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事：
只有上一个分组得到确认，才会发送下一个分组
收集多个小分组，在一个确认到来时一起发送
Nagle算法造成了发送方可能会出现粘包问题

接收方原因
TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

什么时候需要处理粘包现象？
如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象
如果多个分组毫不相干，甚至是并列关系，那么这个时候就一定要处理粘包现象了

2.3 如何处理粘包现象？

发送方
对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法
接收方
接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。
应用层
应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。
1.固定包长度的数据包
2.以指定字符（串）为包的结束标志如换行符 \n
3.包头 + 包体格式这种格式的包一般分为两部分，即包头和包体，包头是固定大小的，且包头中必须含有一个字段来说明接下来的包体有多大。

总结

本篇简单概述了一下什么是消息粘包和消息不完整问题，并且通过代码复现了一下出现的问题，那么具体的处理粘包等问题，后面再写，核心思想就是通过读取包头获取要读取的数据包的长度，然后根据长度去读取后面的数据，不够就先缓存等待下一个包来，足够了长度就丢给上层处理，既解决了消息粘包也能解决消息不完整问题，具体代码演示下一篇再述

欢迎大家访问个人博客 Johnny小屋

消息粘包和消息不完整问题