快捷導(dǎo)航

Netty粘包問題的常見解決方案

更新時間：2024年06月04日 08:37:57 作者：Java中文社群

粘包和拆包問題也叫做粘包和半包問題,它是指在數(shù)據(jù)傳輸時,接收方未能正常讀取到一條完整數(shù)據(jù)的情況（只讀取了部分?jǐn)?shù)據(jù),或多讀取到了另一條數(shù)據(jù)的情況）就叫做粘包或拆包問題,本文介紹了Netty如何解決粘包問題,需要的朋友可以參考下

引言

粘包和拆包問題也叫做粘包和半包問題，它是指在數(shù)據(jù)傳輸時，接收方未能正常讀取到一條完整數(shù)據(jù)的情況（只讀取了部分?jǐn)?shù)據(jù)，或多讀取到了另一條數(shù)據(jù)的情況）就叫做粘包或拆包問題。

從嚴(yán)格意義上來說，粘包問題和拆包問題屬于兩個不同的問題，接下來我們分別來看。

1.粘包問題

粘包問題是指在網(wǎng)絡(luò)通信中，發(fā)送方連續(xù)發(fā)送的多個小數(shù)據(jù)包被接收方一次性接收的現(xiàn)象。這可能是因?yàn)榈讓觽鬏攲訁f(xié)議（如 TCP）會將多個小數(shù)據(jù)包合并成一個大的數(shù)據(jù)塊進(jìn)行傳輸，導(dǎo)致接收方在接收數(shù)據(jù)時一次性接收了多個數(shù)據(jù)包，造成粘連。

例如以下案例，正常情況下客戶端發(fā)送了兩條消息，分別為“ABC”和“DEF”，那么接收端也應(yīng)該收到兩條消息“ABC”和“DEF”才對，但是接收端卻收到了“ABCD”這樣的消息，這種情況就叫做粘包，如下圖所示：

2.拆包/半包問題

拆包問題是指發(fā)送方發(fā)送的一個大數(shù)據(jù)包被接收方拆分成多個小數(shù)據(jù)包進(jìn)行接收的現(xiàn)象。這可能是因?yàn)榈讓觽鬏攲訁f(xié)議（如 TCP）將一個大數(shù)據(jù)包拆分成多個小的數(shù)據(jù)塊進(jìn)行傳輸，導(dǎo)致接收方在接收數(shù)據(jù)時分別接收了多個小數(shù)據(jù)包，造成拆開。

例如以下案例，客戶端發(fā)送了一條消息“ABC”，而接收端卻收到了“AB”和“C”兩條信息，這種情況就叫做半包，如下圖所示：

PS：大部分情況下我們都把粘包問題和拆包問題看成同一個問題，所以下文就用粘包問題來替代粘包和拆包問題。

3.為什么會有粘包問題？

粘包問題通常發(fā)生在 TCP/IP 協(xié)議中，因?yàn)?TCP 是面向連接的傳輸協(xié)議，它是以“流”的形式傳輸數(shù)據(jù)的，而“流”數(shù)據(jù)是沒有明確的開始和結(jié)尾邊界的，所以就會出現(xiàn)粘包問題。

4.常見解決方案

粘包問題的常見解決方案有以下 3 種：

固定大小方法：發(fā)送方和接收方固定發(fā)送數(shù)據(jù)大小，當(dāng)字符長度不夠時用空字符彌補(bǔ)，有了固定大小之后就知道每條消息的具體邊界了，這樣就沒有粘包的問題了。
自定義數(shù)據(jù)協(xié)議（定義數(shù)據(jù)長度）：在 TCP 協(xié)議的基礎(chǔ)上封裝一層自定義數(shù)據(jù)協(xié)議，在自定義數(shù)據(jù)協(xié)議中，包含數(shù)據(jù)頭（存儲數(shù)據(jù)的大小）和數(shù)據(jù)的具體內(nèi)容，這樣服務(wù)端得到數(shù)據(jù)之后，通過解析數(shù)據(jù)頭就可以知道數(shù)據(jù)的具體長度了，也就沒有粘包的問題了。
特殊分割符：以特殊的字符結(jié)尾，比如以“\n”結(jié)尾，這樣我們就知道數(shù)據(jù)的具體邊界了，從而避免了粘包問題。

以上三種方案中，第一種固定大小的方法可能會造成網(wǎng)絡(luò)流量的浪費(fèi)，以及傳輸性能慢的問題；第二種解決方案實(shí)現(xiàn)難度大，且不利于維護(hù)，所以比較推薦的是第三種方案，使用特殊分隔符來區(qū)分消息的邊界，從而避免粘包問題。

5.Netty解決方案

Netty 解決方案也延續(xù)了上面的常見解決方案，它的解決方案有以下幾個：

使用定長解碼器（FixedLengthFrameDecoder）：每個數(shù)據(jù)包都擁有固定的長度，接收端根據(jù)固定長度對數(shù)據(jù)進(jìn)行切分，從而解決了粘包問題。
使用行分隔符解碼器（LineBasedFrameDecoder）：以行為單位進(jìn)行數(shù)據(jù)包的解碼，從而解決粘包問題。
使用分隔符解碼器（DelimiterBasedFrameDecoder）：使用特定的分隔符來標(biāo)識消息邊界，這樣接收端可以根據(jù)分隔符正確切分消息。
使用長度字段解碼器（LengthFieldBasedFrameDecoder）：在消息頭部加入表示消息長度的字段，接收端根據(jù)長度字段來確定消息的邊界，而從解決粘包問題。

PS：在 Netty 中，解碼器（Decoder）起著非常重要的作用。解碼器主要負(fù)責(zé)將從網(wǎng)絡(luò)中接收到的原始字節(jié)流數(shù)據(jù)轉(zhuǎn)換為應(yīng)用程序能夠理解的 Java 對象或消息格式。使用解碼器可以解決粘包和拆包問題、協(xié)議轉(zhuǎn)換問題、消息編碼（如文本轉(zhuǎn)換為字節(jié)流）等問題。

這些解碼器的使用如下。

5.1 定長解碼器

定長解碼器（FixedLengthFrameDecoder）使用示例如下：

ChannelPipeline pipeline = ch.pipeline();
// 假設(shè)每條消息長度為 5
pipeline.addLast(new FixedLengthFrameDecoder(5)); 
pipeline.addLast(new StringDecoder());
pipeline.addLast(new YourBusinessLogicHandler());

5.2 行分隔符解碼器

行分隔符解碼器（LineBasedFrameDecoder）使用示例如下：

ChannelPipeline pipeline = ch.pipeline();
// 設(shè)置行分隔符解碼器最大(幀)長度為 8192 字節(jié)
pipeline.addLast(new LineBasedFrameDecoder(8192)); 
pipeline.addLast(new StringDecoder()); // 添加字符串解碼器
pipeline.addLast(new SimpleChannelInboundHandler<String>() {
    @Override
    protected void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {
        System.out.println("接收到消息：" + msg);
    }
});

5.3 分隔符解碼器

分隔符解碼器（DelimiterBasedFrameDecoder）使用示例如下：

ChannelPipeline pipeline = ch.pipeline();
// 使用 \r\n 來進(jìn)行分隔
ByteBuf delimiter = Unpooled.copiedBuffer("\r\n".getBytes());
pipeline.addLast(new DelimiterBasedFrameDecoder(1024, delimiter));
pipeline.addLast(new StringDecoder());
pipeline.addLast(new YourBusinessLogicHandler());

5.4 長度字段解碼器

長度字段解碼器（LengthFieldBasedFrameDecoder）使用示例如下：

ChannelPipeline pipeline = ch.pipeline();
// 設(shè)置最大幀長度為 1024 字節(jié)，長度字段位于第 0 個字節(jié)，長度字段占用 4 個字節(jié)
pipeline.addLast(new LengthFieldBasedFrameDecoder(1024, 0, 4, 0, 4));
pipeline.addLast(new LengthFieldPrepender(4));
pipeline.addLast(new StringDecoder());
pipeline.addLast(new StringEncoder());
pipeline.addLast(new LengthFieldServerHandler());