TCP粘包，拆包及解决方法

【转自】https://blog.csdn.net/scythe666/article/details/51996268

在进行Java NIO学习时，发现，如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况，这就是TCP协议中经常会遇到的粘包以及拆包的问题。

我们都知道TCP属于传输层的协议，传输层除了有TCP协议外还有UDP协议。那么UDP是否会发生粘包或拆包的现象呢？答案是不会。UDP是基于报文发送的，从UDP的帧结构可以看出，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。而TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。

粘包、拆包表现形式

现在假设客户端向服务端连续发送了两个数据包，用packet1和packet2来表示，那么服务端收到的数据可以分为三种，现列举如下：

第一种情况，接收端正常收到两个数据包，即没有发生拆包和粘包的现象，此种情况不在本文的讨论范围内。


image.png

第二种情况，接收端只收到一个数据包，由于TCP是不会出现丢包的，所以这一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限，所以对于接收端来说很难处理。


image.png

第三种情况，这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。


image.png
image.png

粘包、拆包发生原因

发生TCP粘包或拆包有很多原因，现列出常见的几点，可能不全面，欢迎补充，

1、要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。
2、待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。
3、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。
4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。
等等。

粘包、拆包解决办法

通过以上分析，我们清楚了粘包或拆包发生的原因，那么如何解决这个问题呢？解决问题的关键在于如何给每个数据包添加边界信息，常用的方法有如下几个：

1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。

2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。

3、可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

等等。

样例程序

我将在程序中使用两种方法来解决粘包和拆包问题，固定数据包长度和添加长度首部，这两种方法各有优劣。固定数据包长度传输效率一般，尤其是在要发送的数据长度长短差别很大的时候效率会比较低，但是编程实现比较简单；添加长度首部虽然可以获得较高的传输效率，冗余信息少且固定，但是编程实现较为复杂。下面给出的样例程序是基于之前的文章《Java中BIO，NIO和AIO使用样例》中提到的NIO实例的，如果对NIO的使用还不是很熟悉，可以先了解一下Java中NIO编程。

固定数据包长度

这种处理方式的思路很简单，发送端在发送实际数据前先把数据封装为固定长度，然后在发送出去，接收端接收到数据后按照这个固定长度进行拆分即可。发送端程序如下：

// 发送端
String msg = "hello world " + number++;  
socketChannel.write(ByteBuffer.wrap(new FixLengthWrapper(msg).getBytes()));

// 封装固定长度的工具类
public class FixLengthWrapper {

    public static final int MAX_LENGTH = 32;
    private byte[] data;

    public FixLengthWrapper(String msg) {
        ByteBuffer byteBuffer = ByteBuffer.allocate(MAX_LENGTH);
        byteBuffer.put(msg.getBytes());
        byte[] fillData = new byte[MAX_LENGTH - msg.length()];
        byteBuffer.put(fillData);
        data = byteBuffer.array();
    }

    public FixLengthWrapper(byte[] msg) {
        ByteBuffer byteBuffer = ByteBuffer.allocate(MAX_LENGTH);
        byteBuffer.put(msg);
        byte[] fillData = new byte[MAX_LENGTH - msg.length];
        byteBuffer.put(fillData);
        data = byteBuffer.array();
    }

    public byte[] getBytes() {
        return data;
    }

    public String toString() {
        StringBuilder sb = new StringBuilder();
        for (byte b : getBytes()) {
            sb.append(String.format("0x%02X ", b));
        }
        return sb.toString();
    }
}

可以看到客户端在发送数据前首先把数据封装为长度为32bytes的数据包，这个长度是根据目前实际数据包长度来规定的，这个长度必须要大于所有可能出现的数据包的长度，这样才不会出现把数据“截断”的情况。接收端程序如下：

private static void processByFixLength(SocketChannel socketChannel) throws IOException {  
    while (socketChannel.read(byteBuffer) > 0) {

        byteBuffer.flip();
        while (byteBuffer.remaining() >= FixLengthWrapper.MAX_LENGTH) {
            byte[] data = new byte[FixLengthWrapper.MAX_LENGTH];
            byteBuffer.get(data, 0, FixLengthWrapper.MAX_LENGTH);
            System.out.println(new String(data) + " <---> " + number++);
        }
        byteBuffer.compact();
    }
}

可以看出接收端的处理很简单，只需要每次读取固定的长度即可区分出来不同的数据包。

添加长度首部

这种方式的处理较上面提到的方式稍微复杂一点。在发送端需要给待发送的数据添加固定的首部，然后再发送出去，然后在接收端需要根据这个首部的长度信息进行数据包的组合或拆分，发送端程序如下：

// 发送端
String msg = "hello world " + number++;  
// add the head represent the data length
socketChannel.write(ByteBuffer.wrap(new PacketWrapper(msg).getBytes()));

// 添加长度首部的工具类
public class PacketWrapper {

    private int length;
    private byte[] payload;

    public PacketWrapper(String payload) {
        this.payload = payload.getBytes();
        this.length = this.payload.length;
    }

    public PacketWrapper(byte[] payload) {
        this.payload = payload;
        this.length = this.payload.length;
    }

    public byte[] getBytes() {
        ByteBuffer byteBuffer = ByteBuffer.allocate(this.length + 4);
        byteBuffer.putInt(this.length);
        byteBuffer.put(payload);
        return byteBuffer.array();
    }

    public String toString() {
        StringBuilder sb = new StringBuilder();
        for (byte b : getBytes()) {
            sb.append(String.format("0x%02X ", b));
        }
        return sb.toString();
    }
}

从程序可以看到，发送端在发送数据前首先给待发送数据添加了代表长度的首部，首部长为4bytes（即int型长度），这样接收端在收到这个数据之后，首先需要读取首部，拿到实际数据长度，然后再继续读取实际长度的数据，即实现了组包和拆包的操作。程序如下：

private static void processByHead(SocketChannel socketChannel) throws IOException {

    while (socketChannel.read(byteBuffer) > 0) {
        // 保存bytebuffer状态
        int position = byteBuffer.position();
        int limit = byteBuffer.limit();
        byteBuffer.flip();
        // 判断数据长度是否够首部长度
        if (byteBuffer.remaining() < 4) {
            byteBuffer.position(position);
            byteBuffer.limit(limit);
            continue;
        }
        // 判断bytebuffer中剩余数据是否足够一个包
        int length = byteBuffer.getInt();
        if (byteBuffer.remaining() < length) {
            byteBuffer.position(position);
            byteBuffer.limit(limit);
            continue;
        }
        // 拿到实际数据包
        byte[] data = new byte[length];

        byteBuffer.get(data, 0, length);
        System.out.println(new String(data) + " <---> " + number++);
        byteBuffer.compact();
    }
}

关键信息已经在程序中做了注释，可以很明显的感觉到这种方法的处理难度相对于固定长度要大一些，不过这种方式可以获取更大的传输效率。

这里需要提醒各位同学一个问题，由于我在测试的时候采用的是一台机器连续发送数据来模拟高并发的场景，所以在测试的时候会发现服务器端收到的数据包的个数经常会小于包的序号，好像发生了丢包。但经过仔细分析可以发现，这种情况是因为TCP发送缓存溢出导致的丢包，也就是这个数据包根本没有发出来。也就是说，发送端发送数据过快，导致接收端缓存很快被填满，这个时候接收端会把通知窗口设置为0从而控制发送端的流量，这样新到的数据只能暂存在发送端的发送缓存中，当发送缓存溢出后，就出现了我上面提到的丢包，这个问题可以通过增大发送端缓存来缓解这个问题，

socketChannel.socket().setSendBufferSize(102400);

当然这个话题不在本文的讨论范围，如果有兴趣的同学可以参阅《TCP/IP详解卷一》中的拥塞窗口一章。

关于源码说明，源码默认是把粘包和拆包处理这一部分注释掉了，分别位于NIOTcpServer和NIOTcpClient文件中，需要测试粘包和拆包处理程序的同学需要把这一段注释给去掉。

最后给出源码下载地址

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,324评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,303评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,192评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,555评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,569评论 5赞 365
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,566评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,927评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,583评论 0赞 257
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,827评论 1赞 297
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2赞 320
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,365评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,941评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2赞 342