2. 程式人生 > 實用技巧 >Netty筆記(6) - 粘包拆包問題及解決方案

Netty筆記(6) - 粘包拆包問題及解決方案

阿新 • • 發佈：2020-08-27

Netty 中 TCP 粘包拆包問題

資訊通過tcp傳輸過程中出現的狀況 .

TCP是個“流”協議，所謂流，就是沒有界限的一串資料。TCP底層並不瞭解上層業務資料的具體含義，它會根據TCP緩衝區的實際情況進行包的劃分，所以在業務上認為，一個完整的包可能會被TCP拆分成多個包進行傳送，也有可能把多個小的包封裝成一個大的資料包傳送

產生粘包和拆包問題的主要原因是，作業系統在傳送TCP資料的時候，底層會有一個緩衝區，例如1024個位元組大小，如果一次請求傳送的資料量比較小，沒達到緩衝區大小，TCP則會將多個請求合併為同一個請求進行傳送，這就形成了粘包問題；如果一次請求傳送的資料量比較大，超過了緩衝區大小，TCP就會將其拆分為多次傳送，這就是拆包，也就是將一個大的包拆分為多個小包進行傳送。

入圖所示:

上圖中演示了粘包和拆包的三種情況：

  • D1和D2兩個包都剛好滿足TCP緩衝區的大小，或者說其等待時間已經達到TCP等待時長，從而還是使用兩個獨立的包進行傳送；
  • D1和D2兩次請求間隔時間內較短，並且資料包較小，因而合併為同一個包傳送給服務端；
  • 某一個包比較大，因而將其拆分為兩個包D*_1和D*_2進行傳送，而這裡由於拆分後的某一個包比較小，其又與另一個包合併在一起傳送。

發生這種情況的程式碼:

客戶端傳送資料 快速的傳送 10條資料 :

public class MyClientHandler extends SimpleChannelInboundHandler<ByteBuf> {

    private int count;
    @Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {
        //使用客戶端傳送10條資料 hello,server 編號
        for(int i= 0; i< 10; ++i) {
            ByteBuf buffer = Unpooled.copiedBuffer("hello,server " +i, Charset.forName("utf-8"));
            ctx.writeAndFlush(buffer);
        }
    }

}

服務端接受列印:

伺服器接收到資料 hello,server 0
伺服器接收到資料 hello,server 1
伺服器接收到資料 hello,server 2hello,server 3
伺服器接收到資料 hello,server 4hello,server 5
伺服器接收到資料 hello,server 6
伺服器接收到資料 hello,server 7hello,server 8
伺服器接收到資料 hello,server 9

很明顯 其中有三條記錄被粘在其他資料上,這就是TCP的粘包拆包現象

怎麼解決:

  1. Netty自帶的 解決方案:

    • 固定長度的拆包器 FixedLengthFrameDecoder，每個應用層資料包的都拆分成都是固定長度的大小

    • 行拆包器 LineBasedFrameDecoder，每個應用層資料包，都以換行符作為分隔符，進行分割拆分

    • 分隔符拆包器 DelimiterBasedFrameDecoder，每個應用層資料包，都通過自定義的分隔符，進行分割拆分

    • 基於資料包長度的拆包器 LengthFieldBasedFrameDecoder，將應用層資料包的長度，作為接收端應用層資料包的拆分依據。按照應用層資料包的大小，拆包。這個拆包器，有一個要求，就是應用層協議中包含資料包的長度

FixedLengthFrameDecoder 解碼器

服務端 新增 FixedLengthFrameDecoder 解碼器 並指定長度

public class EchoServer {



  public static void main(String[] args) throws InterruptedException {

      EventLoopGroup bossGroup = new NioEventLoopGroup();
      EventLoopGroup workerGroup = new NioEventLoopGroup();
      try {
          ServerBootstrap bootstrap = new ServerBootstrap();
          bootstrap.group(bossGroup, workerGroup)
                  .channel(NioServerSocketChannel.class)
                  .option(ChannelOption.SO_BACKLOG, 1024)
                  .childHandler(new ChannelInitializer<SocketChannel>() {
                      @Override
                      protected void initChannel(SocketChannel ch) throws Exception {
                          //指定長度為9 則每次擷取長度為9的位元組 
                          ch.pipeline().addLast(new FixedLengthFrameDecoder(9));
                         // 將 每次擷取的位元組編碼為字串
                          ch.pipeline().addLast(new StringDecoder());
						//自定義處理類列印
                          ch.pipeline().addLast(new EchoServerHandler());
                      }
                  });

          ChannelFuture future = bootstrap.bind(8000).sync();
          future.channel().closeFuture().sync();
      } finally {
          bossGroup.shutdownGracefully();
          workerGroup.shutdownGracefully();
      }
  }
}

自定義服務端Handler 列印字串:

public class EchoServerHandler extends SimpleChannelInboundHandler<String> {

    @Override
  protected void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {
    System.out.println("message: " + msg.trim());
  }
}

客戶端傳送資訊 並新增字串編碼器 將資訊已字串的形式編碼:

public class EchoClient {



  public static void main(String[] args) throws InterruptedException {
      EventLoopGroup group = new NioEventLoopGroup();
      try {
          Bootstrap bootstrap = new Bootstrap();
          bootstrap.group(group)
                  .channel(NioSocketChannel.class)
                  .option(ChannelOption.TCP_NODELAY, true)
                  .handler(new ChannelInitializer<SocketChannel>() {
                      @Override
                      protected void initChannel(SocketChannel ch) throws Exception {
                          
                          ch.pipeline().addLast(new StringEncoder());
                          ch.pipeline().addLast(new EchoClientHandler());
                      }
                  });

          ChannelFuture future = bootstrap.connect("127.0.0.1", 8000).sync();
          future.channel().closeFuture().sync();
      } finally {
          group.shutdownGracefully();
      }
  }
}

客戶端Handler 傳送資訊 剛好長度為9 :

public class EchoClientHandler extends SimpleChannelInboundHandler<String> {

  @Override
  public void channelActive(ChannelHandlerContext ctx) throws Exception {
    ctx.writeAndFlush("123456789");
  }
}

總結: FixedLengthFrameDecoder 解碼器 將按照指定長度擷取位元組 並新增到List中向後傳遞 , 以本案例為例,如果位元組數剛好為9,則全部列印,如果 位元組數為18, 則拆分列印兩次,如果為19 則最後一個位元組不列印,如果不足9 則什麼都不列印.

LineBasedFrameDecoder 行拆分器

通過行換行符 \n 或者 \r\n 進行分割,

將上面案例的FixedLengthFrameDecoder 解碼器 換成 LineBasedFrameDecoder

並指定 擷取每段的最大長度 (超過報錯 不往後傳遞)

...
    
.childHandler(new ChannelInitializer<SocketChannel>() {
                      @Override
                      protected void initChannel(SocketChannel ch) throws Exception {

//                          ch.pipeline().addLast(new FixedLengthFrameDecoder(20));
                          ch.pipeline().addLast(new                       LineBasedFrameDecoder(5));
                          // 將前一步解碼得到的資料轉碼為字串
                          ch.pipeline().addLast(new StringDecoder());
//                           最終的資料處理
                          ch.pipeline().addLast(new EchoServerHandler());
                      }
                  });

...

客戶端Handler 傳送字串, 最後的"1234" 不會列印,,

@Override
  public void channelActive(ChannelHandlerContext ctx) throws Exception {
    ctx.writeAndFlush("1\n123456\r\n1234");
  }

服務端接收並列印結果 分別列印了 "1" 和 "1234" 而超過位元組長度5 的 "123456"則報出TooLongFrameException錯誤

server receives message: 1

An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.handler.codec.TooLongFrameException: frame length (6) exceeds the allowed maximum (5)

server receives message: 1234

DelimiterBasedFrameDecoder 自定義分割符

和行分割符類似, 此解碼器可以自定義分割符,常用構造方法:

 public DelimiterBasedFrameDecoder(int maxFrameLength, ByteBuf... delimiters)

接收一個最大長度,和 任意個數的 分隔符(用ByteBuf的形式傳入),解碼器識別到任意一個 分割符 都會進行拆分

註冊解碼器:

傳入 "$" 和 "*" 作為分割符,並指定最大長度為 5個位元組

.childHandler(new ChannelInitializer<SocketChannel>() {
                      @Override
                      protected void initChannel(SocketChannel ch) throws Exception {

                          ch.pipeline().addLast(new DelimiterBasedFrameDecoder(5,
                              Unpooled.wrappedBuffer("$".getBytes()),Unpooled.wrappedBuffer("*".getBytes())));
                          // 將前一步解碼得到的資料轉碼為字串
                          ch.pipeline().addLast(new StringDecoder());
                          
//                           最終的資料處理
                          ch.pipeline().addLast(new EchoServerHandler());
                      }
                  });

客戶端 傳送資料:

@Override
  public void channelActive(ChannelHandlerContext ctx) throws Exception {
          ctx.writeAndFlush("1$123456*1234$789$");
  }

服務端只打印了 "1" 當解析到 "123456" 時 就報錯了 後面就沒有再解析了,會快取著 等到該通道關閉 或者有後續資料傳送過來時 才繼續解析

LengthFieldBasedFrameDecoder

自定義資料長度,傳送的 位元組陣列中 包含 描述 資料長度的欄位 和 資料本身,

解碼過程

常用欄位:

  • maxFrameLength：指定了每個包所能傳遞的最大資料包大小,(上圖中的最大長度為11)
  • lengthFieldOffset：指定了長度欄位在位元組碼中的偏移量；(11這個描述長度的資料是在陣列的第幾位開始)
  • lengthFieldLength：指定了長度欄位所佔用的位元組長度；(11 佔 1個位元組)
  • lengthAdjustment: 長度域的偏移量矯正。 如果長度域的值，除了包含有效資料域的長度外，還包含了其他域（如長度域自身）長度，那麼，就需要進行矯正。矯正的值為：包長 - 長度域的值 – 長度域偏移 – 長度域長。 ( 11 這個域 不光光描述 Hello,world, 一般設定為0,)
  • initialBytesToStrip : 丟棄的起始位元組數。丟棄處於有效資料前面的位元組數量。比如前面有1個節點的長度域，則它的值為1. ( 如果為0代表不丟棄,則將長度域也向後傳遞)

服務端新增 解碼器:

  • 最大長度 為 長度描述域 的值11 + 長度描述域本身佔用的長度 1 = 12
  • 長度描述域放在資料包的第一位, 沒有偏移 為0
  • 長度描述域 長度為1
  • 無需矯正
  • 一個位元組也不丟棄
.childHandler(new ChannelInitializer<SocketChannel>() {
          @Override
          protected void initChannel(SocketChannel ch) throws Exception {
            // 這裡將FixedLengthFrameDecoder新增到pipeline中，指定長度為20
            ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(12,0,1,0,0));
            // 將前一步解碼得到的資料轉碼為字串

            ch.pipeline().addLast(new StringDecoder());
            // 最終的資料處理
            ch.pipeline().addLast(new EchoServerHandler());
          }
        });

客戶端傳送資料 傳送最Netty 底層操作 的ByteBuf物件 傳送時 無需任何編碼:

 @Override
  public void channelActive(ChannelHandlerContext ctx) throws Exception {
    ByteBuf buffer = Unpooled.buffer();
    buffer.writeByte(11);
    buffer.writeBytes("Hello,World".getBytes());
    ctx.writeAndFlush(buffer);
  }

服務端接收資料為 (11代表的製表符)Hello,World

這樣傳送 每次都要計算 資料長度,並手動新增到 資料的前面,很不方便 配合LengthFieldPrepender 使用,這個編碼碼器可以計算 長度,並自動新增到 資料的前面

改造客戶端 先攔截資料按字串編碼,再計算位元組長度 新增 長度描述欄位 並佔用一個位元組 (這個長度要與客戶端的解碼器 lengthFieldLength引數 值保持一致) :

 .handler(new ChannelInitializer<SocketChannel>() {
          @Override
          protected void initChannel(SocketChannel ch) throws Exception {

            ch.pipeline().addLast(new LengthFieldPrepender(1));
            ch.pipeline().addLast(new StringEncoder());
            // 客戶端傳送訊息給服務端，並且處理服務端響應的訊息
            ch.pipeline().addLast(new EchoClientHandler());
          }
        });

客戶端傳送 有字串編碼器 可以直接傳送字串:

  @Override
  public void channelActive(ChannelHandlerContext ctx) throws Exception {
    ctx.writeAndFlush("Hello,World");
  }

自定義協議

上面介紹的 各種解碼器 已經可以應付絕大多數場景, 如果遇到 特殊的狀況 我們也可以自定義協議

定義 協議物件:

//協議包
public class MessageProtocol {
    private int len; //關鍵
    private byte[] content;

    public int getLen() {
        return len;
    }

    public void setLen(int len) {
        this.len = len;
    }

    public byte[] getContent() {
        return content;
    }

    public void setContent(byte[] content) {
        this.content = content;
    }
}

客戶端傳送:

    @Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {
       
        for(int i = 0; i< 5; i++) {
            String mes = "Hello,World";
            byte[] content = mes.getBytes(Charset.forName("utf-8"));
            int length = mes.getBytes(Charset.forName("utf-8")).length;

            //建立協議包物件
            MessageProtocol messageProtocol = new MessageProtocol();
            messageProtocol.setLen(length);
            messageProtocol.setContent(content);
            ctx.writeAndFlush(messageProtocol);

        }
    }

該協議的 自定義 編碼器 將協議包傳送出去:

public class MyMessageEncoder extends MessageToByteEncoder<MessageProtocol> {
    @Override
    protected void encode(ChannelHandlerContext ctx, MessageProtocol msg, ByteBuf out) throws Exception {
        System.out.println("MyMessageEncoder encode 方法被呼叫");
        out.writeInt(msg.getLen());
        out.writeBytes(msg.getContent());
    }
}

將客戶端 傳送資料的Handler 和 編碼器 註冊 這裡就不寫了

服務端解碼器 讀取長度 並 判斷可讀資料的長度是否足夠 :

public class MyMessageDecoder extends ReplayingDecoder<Void> {
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
        
        in.markReaderIndex();
        
        //讀取長度
        int length = in.readInt();
        //如果可讀長度大於 資料長度 說明資料完整
        if (in.readableBytes()>length){
            byte[] content = new byte[length];
            in.readBytes(content);
            //封裝成 MessageProtocol 物件，放入 out， 傳遞下一個handler業務處理
            MessageProtocol messageProtocol = new MessageProtocol();
            messageProtocol.setLen(length);
            messageProtocol.setContent(content);
            out.add(messageProtocol);
        }else{
            //如果資料不夠長 將已經讀過的的int 資料還原回去 留下次讀取
            in.resetReaderIndex();
        }
    }
}

服務端成功讀取:

本例中存在很多問題, 明白這個意思就行, 感興趣的話 可以 自己動手優化

相關推薦

Netty筆記(6) - 粘包拆包問題及解決方案

Netty 中 TCP 粘包拆包問題 資訊通過tcp傳輸過程中出現的狀況 . TCP是個“流”協議，所謂流，就是沒有界限的一串資料。TCP底層並不瞭解上層業務資料的具體含義，它會根據TCP緩衝區的實際情況進行包的劃分，所以在業務

Maven Jar包下載失敗及解決方案

我是阿福，公眾號「阿福聊程式設計」作者，一個在後端技術路上摸盤滾打的程式設計師，在進階的路上，共勉！

IDEA 程式包不存在,找不到符號但是明明存在對應的jar包(問題分析及解決方案)

環境 IntelliJ IDEA 2020.1 JDK1.8 前提概要 問題1和問題2其實是同一個問題，但是表現上有一點不一樣

Jar包衝突問題及解決方案（轉載）

Jar包衝突是老生常談的問題，幾乎每一個Java程式猿都不可避免地遇到過，並且也都能想到通常的原因一般是同一個Jar包由於maven傳遞依賴等原因被引進了多個不同的版本而導致，可採用依賴排除、依賴管理等常規方式來嘗

Netty應用之粘包拆包及編碼解碼

前言 為什麼要把編碼解碼和粘包拆包放在一起呢？原因是粘包拆包的解決方案就是利用編碼解碼。 當 Netty 傳送或者接受一個訊息的時候，就將會發生一次資料轉換。入站訊息會被解碼：從位元組轉換為另一種 格式

深入瞭解Netty【八】TCP拆包、粘包和解決方案

1、TCP協議傳輸過程 TCP協議是面向流的協議，是流式的，沒有業務上的分段，只會根據當前套接字緩衝區的情況進行拆包或者粘包：

Netty的粘包/拆包

1、正常包 2、粘包 3、拆包 出現的原因 1、write寫入的位元組大小大於socket傳送緩衝區的大小

Netty粘包拆包問題解決方案

TCP黏包拆包 TCP是一個流協議，就是沒有界限的一長串二進位制資料。TCP作為傳輸層協議並不不瞭解上層業務資料的具體含義，它會根據TCP緩衝區的實際情況進行資料包的劃分，所以在業務上認為是一個完整的包，可能會被

Netty 是如何解決 TCP 粘包拆包的？

作者：rickiyang 出處：www.cnblogs.com/rickiyang/p/11074235.html 我們都知道TCP是基於位元組流的傳輸協議。

Netty編解碼器&TCP粘包拆包

一、Netty編解碼器 （一）Netty編解碼器概述 　　1、Java的編解碼 　　　　在Java中編碼（Encode）稱為序列化， 它將物件序列化為位元組陣列，⽤於⽹絡傳輸、資料持久化或者其它⽤途。解碼（Decode）稱為反序列化，

TCP 粘包 - 拆包問題及解決方案

目錄TCP粘包拆包問題什麼是粘包 - 拆包問題為什麼存在粘包 - 拆包問題粘包 - 拆包 演示粘包 - 拆包 解決方案方式一: 固定緩衝區大小方式二: 封裝請求協議方式三: 特殊字元結尾 - 按行讀取

tcp自動粘包拆包和自定義協議

TCP是面向連線的，面向流的，提供高可靠性服務。收發兩端都要有一一成對的socket，因此，傳送端為了將多個發給接收端的包，更有效的發給對方，使用了優化方法，將多次間隔較小且資料量小的資料，合併成一個大的資料塊

soket粘包問題及解決方案

一、粘包問題 問題1: 無法確認對方傳送過來資料的大小。 import socket client = socket.socket()

socket網路程式設計（五）——粘包拆包問題

今天和大家講一下socket網路程式設計中粘包和拆包的問題。 1、出現粘包拆包的原因

tcp粘包拆包問題

客戶端像服務端傳送訊息，服務端不知道客戶端每次傳送訊息的資料大小，服務端可能出現把一個數據包拆成兩個資料包進行讀取這種被稱為拆包，也有可能把兩個資料包當成一個數據包讀取這種被稱為粘包

TCP粘包/拆包問題

轉自https://www.cnblogs.com/wade-luffy/p/6165671.html#_label0 無論是服務端還是客戶端，當我們讀取或者傳送訊息的時候，都需要考慮TCP底層的粘包/拆包機制。

TCP粘包原理及解決方案

一、粘包是什麼 ​ 兩個程式能夠互相通訊是採用了套接字（socket）技術，socket在傳送端和接收端都有個快取機制，傳送端在把需要傳送的資料先放在快取上，等資料超過快取大小時，就會打包發給接收端；接收端接到資料

粘包問題及解決方案

目錄粘包問題及解決方案一 什麼是粘包問題二 為何麼會有粘包問題1 socket收發訊息的原理之流式協議2 TCP與UDP的訊息邊界3 兩種發生粘包的情況4 拆包發生的情況5 補充知識兩則三 如何解決粘包問題1 解決方法之low版本

從零開始實現簡單 RPC 框架 7：網路通訊之自定義協議(粘包拆包、編解碼)

TCP 是一個“流”協議，所謂流，就是沒有界限的一長串二進位制資料。TCP 作為傳輸層協議，並不瞭解上層業務資料的具體含義，它會根據 TCP 緩衝區的實際情況進行資料包的劃分，所以在業務上認為是一個完整包的，可能

TCP粘"包"問題淺析及解決方案Golang程式碼實現

一、粘“包”問題簡介 在socket網路程式設計中，都是端到端通訊，客戶端埠+客戶端IP+服務端埠+服務端IP+傳輸協議就組成一個可以唯一可以明確的標識一條連線。在TCP的socket程式設計中，傳送端和接收端也同樣遵循這樣