2. 程式人生 > >Netty解決粘包和拆包問題的四種方案

Netty解決粘包和拆包問題的四種方案

阿新 • • 發佈：2019-03-21
兩個 json反序列 obj 合並 間隔 分享圖片 發送數據 返回 想是

在RPC框架中，粘包和拆包問題是必須解決一個問題，因為RPC框架中，各個微服務相互之間都是維系了一個TCP長連接，比如dubbo就是一個全雙工的長連接。由於微服務往對方發送信息的時候，所有的請求都是使用的同一個連接，這樣就會產生粘包和拆包的問題。本文首先會對粘包和拆包問題進行描述，然後介紹其常用的解決方案，最後會對Netty提供的幾種解決方案進行講解。這裏說明一下，由於oschina將“jie ma qi”認定為敏感文字，因而本文統一使用“解碼一器”表示該含義

  1. 粘包和拆包
    產生粘包和拆包問題的主要原因是，操作系統在發送TCP數據的時候，底層會有一個緩沖區，例如1024個字節大小，如果一次請求發送的數據量比較小，沒達到緩沖區大小，TCP則會將多個請求合並為同一個請求進行發送，這就形成了粘包問題；如果一次請求發送的數據量比較大，超過了緩沖區大小，TCP就會將其拆分為多次發送，這就是拆包，也就是將一個大的包拆分為多個小包進行發送。如下圖展示了粘包和拆包的一個示意圖：
    技術分享圖片
    上圖中演示了粘包和拆包的三種情況：

A和B兩個包都剛好滿足TCP緩沖區的大小，或者說其等待時間已經達到TCP等待時長，從而還是使用兩個獨立的包進行發送；
A和B兩次請求間隔時間內較短，並且數據包較小，因而合並為同一個包發送給服務端；
B包比較大，因而將其拆分為兩個包B_1和B_2進行發送，而這裏由於拆分後的B_2比較小，其又與A包合並在一起發送。

  1. 常見解決方案
    對於粘包和拆包問題，常見的解決方案有四種：

客戶端在發送數據包的時候，每個包都固定長度，比如1024個字節大小，如果客戶端發送的數據長度不足1024個字節，則通過補充空格的方式補全到指定長度；
客戶端在每個包的末尾使用固定的分隔符，例如\r\n，如果一個包被拆分了，則等待下一個包發送過來之後找到其中的\r\n，然後對其拆分後的頭部部分與前一個包的剩余部分進行合並，這樣就得到了一個完整的包；

將消息分為頭部和消息體，在頭部中保存有當前整個消息的長度，只有在讀取到足夠長度的消息之後才算是讀到了一個完整的消息；
通過自定義協議進行粘包和拆包的處理。

  1. Netty提供的粘包拆包解決方案
    3.1 FixedLengthFrameDecoder
    對於使用固定長度的粘包和拆包場景，可以使用FixedLengthFrameDecoder，該解碼一器會每次讀取固定長度的消息，如果當前讀取到的消息不足指定長度，那麽就會等待下一個消息到達後進行補足。其使用也比較簡單，只需要在構造函數中指定每個消息的長度即可。這裏需要註意的是，FixedLengthFrameDecoder只是一個解碼一器，Netty也只提供了一個解碼一器，這是因為對於解碼是需要等待下一個包的進行補全的，代碼相對復雜，而對於編碼器，用戶可以自行編寫，因為編碼時只需要將不足指定長度的部分進行補全即可。下面的示例中展示了如何使用FixedLengthFrameDecoder來進行粘包和拆包處理：

    public class EchoServer {

public void bind(int port) 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)
    .handler(new LoggingHandler(LogLevel.INFO))
    .childHandler(new ChannelInitializer<SocketChannel>() {
      @Override
      protected void initChannel(SocketChannel ch) throws Exception {
        // 這裏將FixedLengthFrameDecoder添加到pipeline中，指定長度為20
        ch.pipeline().addLast(new FixedLengthFrameDecoder(20));
        // 將前一步解碼得到的數據轉碼為字符串
        ch.pipeline().addLast(new StringDecoder());
        // 這裏FixedLengthFrameEncoder是我們自定義的，用於將長度不足20的消息進行補全空格
        ch.pipeline().addLast(new FixedLengthFrameEncoder(20));
        // 最終的數據處理
        ch.pipeline().addLast(new EchoServerHandler());
      }
    });

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

public static void main(String[] args) throws InterruptedException {
new EchoServer().bind(8080);
}
}

    上面的pipeline中，對於入棧數據，這裏主要添加了FixedLengthFrameDecoder和StringDecoder，前面一個用於處理固定長度的消息的粘包和拆包問題，第二個則是將處理之後的消息轉換為字符串。最後由EchoServerHandler處理最終得到的數據，處理完成後，將處理得到的數據交由FixedLengthFrameEncoder處理，該編碼器是我們自定義的實現，主要作用是將長度不足20的消息進行空格補全。下面是FixedLengthFrameEncoder的實現代碼：

    public class FixedLengthFrameEncoder extends MessageToByteEncoder<String> {
private int length;

public FixedLengthFrameEncoder(int length) {
this.length = length;
}

@Override
protected void encode(ChannelHandlerContext ctx, String msg, ByteBuf out)
  throws Exception {
// 對於超過指定長度的消息，這裏直接拋出異常
if (msg.length() > length) {
  throw new UnsupportedOperationException(
      "message length is too large, it‘s limited " + length);
}

// 如果長度不足，則進行補全
if (msg.length() < length) {
  msg = addSpace(msg);
}

ctx.writeAndFlush(Unpooled.wrappedBuffer(msg.getBytes()));
}

// 進行空格補全
private String addSpace(String msg) {
StringBuilder builder = new StringBuilder(msg);
for (int i = 0; i < length - msg.length(); i++) {
  builder.append(" ");
}

return builder.toString();
}
}

    這裏FixedLengthFrameEncoder實現了decode()方法，在該方法中，主要是將消息長度不足20的消息進行空格補全。EchoServerHandler的作用主要是打印接收到的消息，然後發送響應給客戶端：

    public class EchoServerHandler extends SimpleChannelInboundHandler<String> {

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

    對於客戶端，其實現方式基本與服務端的使用方式類似，只是在最後進行消息發送的時候與服務端的處理方式不同。如下是客戶端EchoClient的代碼：

    public class EchoClient {

public void connect(String host, int port) 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 {
        // 對服務端發送的消息進行粘包和拆包處理，由於服務端發送的消息已經進行了空格補全，
        // 並且長度為20，因而這裏指定的長度也為20
        ch.pipeline().addLast(new FixedLengthFrameDecoder(20));
        // 將粘包和拆包處理得到的消息轉換為字符串
        ch.pipeline().addLast(new StringDecoder());
        // 對客戶端發送的消息進行空格補全，保證其長度為20
        ch.pipeline().addLast(new FixedLengthFrameEncoder(20));
        // 客戶端發送消息給服務端，並且處理服務端響應的消息
        ch.pipeline().addLast(new EchoClientHandler());
      }
    });

  ChannelFuture future = bootstrap.connect(host, port).sync();
  future.channel().closeFuture().sync();
} finally {
  group.shutdownGracefully();
}
}

public static void main(String[] args) throws InterruptedException {
new EchoClient().connect("127.0.0.1", 8080);
}
}

    對於客戶端而言，其消息的處理流程其實與服務端是相似的，對於入站消息，需要對其進行粘包和拆包處理，然後將其轉碼為字符串，對於出站消息，則需要將長度不足20的消息進行空格補全。客戶端與服務端處理的主要區別在於最後的消息處理handler不一樣，也即這裏的EchoClientHandler，如下是該handler的源碼：

    public class EchoClientHandler extends SimpleChannelInboundHandler<String> {

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

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

    這裏客戶端的處理主要是重寫了channelActive()和channelRead0()兩個方法，這兩個方法的主要作用在於，channelActive()會在客戶端連接上服務器時執行，也就是說，其連上服務器之後就會往服務器發送消息。而channelRead0()主要是在服務器發送響應給客戶端時執行，這裏主要是打印服務器的響應消息。對於服務端而言，前面我們我們可以看到，EchoServerHandler只重寫了channelRead0()方法，這是因為服務器只需要等待客戶端發送消息過來，然後在該方法中進行處理，處理完成後直接將響應發送給客戶端。如下是分別啟動服務端和客戶端之後控制臺打印的數據：

    // server
server receives message: hello server!
    // client
client receives message: hello client!

    3.2 LineBasedFrameDecoder與DelimiterBasedFrameDecoder
    對於通過分隔符進行粘包和拆包問題的處理，Netty提供了兩個編解碼的類，LineBasedFrameDecoder和DelimiterBasedFrameDecoder。這裏LineBasedFrameDecoder的作用主要是通過換行符，即\n或者\r\n對數據進行處理；而DelimiterBasedFrameDecoder的作用則是通過用戶指定的分隔符對數據進行粘包和拆包處理。同樣的，這兩個類都是解碼一器類，而對於數據的編碼，也即在每個數據包最後添加換行符或者指定分割符的部分需要用戶自行進行處理。這裏以DelimiterBasedFrameDecoder為例進行講解，如下是EchoServer中使用該類的代碼片段，其余部分與前面的例子中的完全一致：

    @Override
protected void initChannel(SocketChannel ch) throws Exception {
String delimiter = "_$";
// 將delimiter設置到DelimiterBasedFrameDecoder中，經過該解碼一器進行處理之後，源數據將會
// 被按照_$進行分隔，這裏1024指的是分隔的最大長度，即當讀取到1024個字節的數據之後，若還是未
// 讀取到分隔符，則舍棄當前數據段，因為其很有可能是由於碼流紊亂造成的
ch.pipeline().addLast(new DelimiterBasedFrameDecoder(1024,
    Unpooled.wrappedBuffer(delimiter.getBytes())));
// 將分隔之後的字節數據轉換為字符串數據
ch.pipeline().addLast(new StringDecoder());
// 這是我們自定義的一個編碼器，主要作用是在返回的響應數據最後添加分隔符
ch.pipeline().addLast(new DelimiterBasedFrameEncoder(delimiter));
// 最終處理數據並且返回響應的handler
ch.pipeline().addLast(new EchoServerHandler());
}

    上面pipeline的設置中，添加的解碼一器主要有DelimiterBasedFrameDecoder和StringDecoder，經過這兩個處理器處理之後，接收到的字節流就會被分隔，並且轉換為字符串數據，最終交由EchoServerHandler處理。這裏DelimiterBasedFrameEncoder是我們自定義的編碼器，其主要作用是在返回的響應數據之後添加分隔符。如下是該編碼器的源碼：

    public class DelimiterBasedFrameEncoder extends MessageToByteEncoder<String> {

private String delimiter;

public DelimiterBasedFrameEncoder(String delimiter) {
this.delimiter = delimiter;
}

@Override
protected void encode(ChannelHandlerContext ctx, String msg, ByteBuf out) 
  throws Exception {
// 在響應的數據後面添加分隔符
ctx.writeAndFlush(Unpooled.wrappedBuffer((msg + delimiter).getBytes()));
}
}

    對於客戶端而言，這裏的處理方式與服務端類似，其pipeline的添加方式如下：

    @Override
protected void initChannel(SocketChannel ch) throws Exception {
String delimiter = "_$";
// 對服務端返回的消息通過_$進行分隔，並且每次查找的最大大小為1024字節
ch.pipeline().addLast(new DelimiterBasedFrameDecoder(1024, 
    Unpooled.wrappedBuffer(delimiter.getBytes())));
// 將分隔之後的字節數據轉換為字符串
ch.pipeline().addLast(new StringDecoder());
// 對客戶端發送的數據進行編碼，這裏主要是在客戶端發送的數據最後添加分隔符
ch.pipeline().addLast(new DelimiterBasedFrameEncoder(delimiter));
// 客戶端發送數據給服務端，並且處理從服務端響應的數據
ch.pipeline().addLast(new EchoClientHandler());
}

    這裏客戶端的處理方式與服務端基本一致，關於這裏沒展示的代碼，其與示例一中的代碼完全一致，這裏則不予展示。

3.3 LengthFieldBasedFrameDecoder與LengthFieldPrepender
這裏LengthFieldBasedFrameDecoder與LengthFieldPrepender需要配合起來使用，其實本質上來講，這兩者一個是解碼，一個是編碼的關系。它們處理粘拆包的主要思想是在生成的數據包中添加一個長度字段，用於記錄當前數據包的長度。LengthFieldBasedFrameDecoder會按照參數指定的包長度偏移量數據對接收到的數據進行解碼，從而得到目標消息體數據；而LengthFieldPrepender則會在響應的數據前面添加指定的字節數據，這個字節數據中保存了當前消息體的整體字節數據長度。LengthFieldBasedFrameDecoder的解碼過程如下圖所示：
技術分享圖片
關於LengthFieldBasedFrameDecoder，這裏需要對其構造函數參數進行介紹：

maxFrameLength：指定了每個包所能傳遞的最大數據包大小；
lengthFieldOffset：指定了長度字段在字節碼中的偏移量；
lengthFieldLength：指定了長度字段所占用的字節長度；
lengthAdjustment：對一些不僅包含有消息頭和消息體的數據進行消息頭的長度的調整，這樣就可以只得到消息體的數據，這裏的lengthAdjustment指定的就是消息頭的長度；
initialBytesToStrip：對於長度字段在消息頭中間的情況，可以通過initialBytesToStrip忽略掉消息頭以及長度字段占用的字節。
這裏我們以json序列化為例對LengthFieldBasedFrameDecoder和LengthFieldPrepender的使用方式進行講解。如下是EchoServer的源碼：

public class EchoServer {

  public void bind(int port) 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)
        .handler(new LoggingHandler(LogLevel.INFO))
        .childHandler(new ChannelInitializer<SocketChannel>() {
          @Override
          protected void initChannel(SocketChannel ch) throws Exception {
            // 這裏將LengthFieldBasedFrameDecoder添加到pipeline的首位，因為其需要對接收到的數據
            // 進行長度字段解碼，這裏也會對數據進行粘包和拆包處理
            ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(1024, 0, 2, 0, 2));
            // LengthFieldPrepender是一個編碼器，主要是在響應字節數據前面添加字節長度字段
            ch.pipeline().addLast(new LengthFieldPrepender(2));
            // 對經過粘包和拆包處理之後的數據進行json反序列化，從而得到User對象
            ch.pipeline().addLast(new JsonDecoder());
            // 對響應數據進行編碼，主要是將User對象序列化為json
            ch.pipeline().addLast(new JsonEncoder());
            // 處理客戶端的請求的數據，並且進行響應
            ch.pipeline().addLast(new EchoServerHandler());
          }
        });

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

  public static void main(String[] args) throws InterruptedException {
    new EchoServer().bind(8080);
  }
}

這裏EchoServer主要是在pipeline中添加了兩個編碼器和兩個解碼一器，編碼器主要是負責將響應的User對象序列化為json對象，然後在其字節數組前面添加一個長度字段的字節數組；解碼一器主要是對接收到的數據進行長度字段的解碼，然後將其反序列化為一個User對象。下面是JsonDecoder的源碼：

public class JsonDecoder extends MessageToMessageDecoder<ByteBuf> {

  @Override
  protected void decode(ChannelHandlerContext ctx, ByteBuf buf, List<Object> out) 
      throws Exception {
    byte[] bytes = new byte[buf.readableBytes()];
    buf.readBytes(bytes);
    User user = JSON.parseObject(new String(bytes, CharsetUtil.UTF_8), User.class);
    out.add(user);
  }
}

JsonDecoder首先從接收到的數據流中讀取字節數組，然後將其反序列化為一個User對象。下面我們看看JsonEncoder的源碼：

public class JsonEncoder extends MessageToByteEncoder<User> {

  @Override
  protected void encode(ChannelHandlerContext ctx, User user, ByteBuf buf)
      throws Exception {
    String json = JSON.toJSONString(user);
    ctx.writeAndFlush(Unpooled.wrappedBuffer(json.getBytes()));
  }
}

JsonEncoder將響應得到的User對象轉換為一個json對象，然後寫入響應中。對於EchoServerHandler，其主要作用就是接收客戶端數據，並且進行響應，如下是其源碼：

public class EchoServerHandler extends SimpleChannelInboundHandler<User> {

  @Override
  protected void channelRead0(ChannelHandlerContext ctx, User user) throws Exception {
    System.out.println("receive from client: " + user);
    ctx.write(user);
  }
}

對於客戶端，其主要邏輯與服務端的基本類似，這裏主要展示其pipeline的添加方式，以及最後發送請求，並且對服務器響應進行處理的過程：

@Override
protected void initChannel(SocketChannel ch) throws Exception {
    ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(1024, 0, 2, 0, 2));
    ch.pipeline().addLast(new LengthFieldPrepender(2));
    ch.pipeline().addLast(new JsonDecoder());
    ch.pipeline().addLast(new JsonEncoder());
    ch.pipeline().addLast(new EchoClientHandler());
}
public class EchoClientHandler extends SimpleChannelInboundHandler<User> {

  @Override
  public void channelActive(ChannelHandlerContext ctx) throws Exception {
    ctx.write(getUser());
  }

  private User getUser() {
    User user = new User();
    user.setAge(27);
    user.setName("zhangxufeng");
    return user;
  }

  @Override
  protected void channelRead0(ChannelHandlerContext ctx, User user) throws Exception {
    System.out.println("receive message from server: " + user);
  }
}

這裏客戶端首先會在連接上服務器時，往服務器發送一個User對象數據，然後在接收到服務器響應之後，會打印服務器響應的數據。

3.4 自定義粘包與拆包器
對於粘包與拆包問題，其實前面三種基本上已經能夠滿足大多數情形了，但是對於一些更加復雜的協議，可能有一些定制化的需求。對於這些場景，其實本質上，我們也不需要手動從頭開始寫一份粘包與拆包處理器，而是通過繼承LengthFieldBasedFrameDecoder和LengthFieldPrepender來實現粘包和拆包的處理。

   如果用戶確實需要不通過繼承的方式實現自己的粘包和拆包處理器，這裏可以通過實現MessageToByteEncoder和ByteToMessageDecoder來實現。這裏MessageToByteEncoder的作用是將響應數據編碼為一個ByteBuf對象，而ByteToMessageDecoder則是將接收到的ByteBuf數據轉換為某個對象數據。通過實現這兩個抽象類，用戶就可以達到實現自定義粘包和拆包處理的目的。如下是這兩個類及其抽象方法的聲明：
public abstract class ByteToMessageDecoder extends ChannelInboundHandlerAdapter {
    protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) 
        throws Exception;
}
public abstract class MessageToByteEncoder<I> extends ChannelOutboundHandlerAdapter {
    protected abstract void encode(ChannelHandlerContext ctx, I msg, ByteBuf out) 
        throws Exception;
}
  1. 小結
    本文首先對粘包和拆包的問題原理進行描述，幫助讀者理解粘包和拆包問題所在。然後對處理粘包和拆包的幾種常用解決方案進行講解。接著通過輔以示例的方式對Netty提供的幾種解決粘包和拆包問題的解決方案進行了詳細講解。

Netty解決粘包和拆包問題的四種方案

相關推薦

Netty解決粘包和拆包問題的四種方案

兩個 json反序列 obj 合並 間隔 分享圖片 發送數據 返回 想是 在RPC框架中，粘包和拆包問題是必須解決一個問題，因為RPC框架中，各個微服務相互之間都是維系了一個TCP長連接，比如dubbo就是一個全雙工的長連接。由於微服務往對方發送信息的時候，所有的請求都是使

Netty入門系列(2) --使用Netty解決粘包和拆包問題

前言 上一篇我們介紹瞭如果使用Netty來開發一個簡單的服務端和客戶端，接下來我們來討論如何使用解碼器來解決TCP的粘包和拆包問題 TCP為什麼會粘包/拆包 我們知道，TCP是以一種流的方式來進行網路轉播的，當tcp三次握手簡歷通訊後，客戶端服務端之間就建立了一種通訊管道，我們可以想象成自來水管道，流出來的水

Netty中粘包和拆包的解決方案

粘包和拆包是TCP網路程式設計中不可避免的，無論是服務端還是客戶端，當我們讀取或者傳送訊息的時候，都需要考慮TCP底層的粘包/拆包

Netty學習10-粘包和拆包

1 粘包拆包基本概念 TPC是一個面向流的協議。所謂流就是沒有邊界的一串資料，如同河水般連成一片，其中並沒有分界線。TCP底層並不瞭解上層業務資料的具體含義，它會根據TCP緩衝區的具體情況進行包的劃分，所以在業務上認為，一個完整的包可能會被TCP拆成多個包傳送，也有可能

Netty中處理TCP粘包和拆包

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

Unity Socket傳輸 TCP粘包和拆包原因以及解決策略

3. 乙太網的payload大於MTU進行IP分片。MTU指：一種通訊協議的某一層上面所能通過的最大資料包大小。如果IP層有一個數據包要傳，而且資料的長度比鏈路層的MTU大，那麼IP層就會進行分片，把資料包分成若干片，讓每一片都不超過MTU。注意，IP分片可以發生在原始傳送端主機上，也可以發生在中間路由器上

Tcp粘包和拆包的原因

最近研究Netty網路程式設計，以前專案中也遇到過資料接收過程中資料質量太差問題，很可能是TCP傳輸過程中問題，特此記錄。 問題產生 一個完整的業務可能會被TCP拆分成多個包進行傳送，也有可能把多個小的包封裝成一個大的資料包傳送，這個就是TCP的拆包和封包問

tcp粘包和拆包、斷包

    while (1) {       var packLen = _.unpack('packLen', tcpBuffer.slice(0, 2));       len = packLen.len;       // console.log('pack len------:' + len);    

tcp粘包和拆包的處理方案

隨著智慧硬體越來越流行，很多後端開發人員都有可能接觸到socket程式設計。而很多情況下，伺服器與端上需要保證資料的有序，穩定到達，自然而然就會選擇基於tcp/ip協議的socekt開發。開發過程中，經常會遇到tcp粘包，拆包的問題，本文將從產生原因，和解決方案以及work

CocoaAsyncSocket + Protobuf 處理粘包和拆包問題

 在上一篇文章《iOS之ProtocolBuffer搭建和示例demo》分享環境的搭建, 我們和伺服器進行IM通訊用了github有名的框架CocoaAsynSocket, 然後和伺服器之間的資料媒介是ProtoBuf。然後後面在開發的過程中也碰到了拆包和粘包問題，這方面

SOCKET 封包和拆包

資源 isl 個數 遊戲服務器 指正 長度 num 部分 程序開發 對於基於TCP開發的通訊程序,有個很重要的問題需要解決,就是封包和拆包.自從我從事網絡通訊編程工作以來(大概有三年的時間了),我一直在思索和改進封包和拆包的方法.下面就針對這個問題談談我的想法,拋磚引玉.若

描述在IPSec傳輸模式下ESP報文裝包和拆包過程

        AH(Authentication Header)：提供資料完整性驗證，通過Hash實現；資料來源身份認證，在計算驗證碼時加入共享金鑰；防止重放攻擊，AH包頭的序列號可防止重放攻擊。ESP(Encapsulating Security Payload)：ESP的協議號是50，提供AH的三種服務

《netty權威指南》之拆包粘包問題及解決方案1

客戶端和服務端程式碼 package com.lyzx.netty.netty02; import io.netty.bootstrap.Bootstrap; import io.netty.bootstrap.ServerBootstrap; import io.net

3、netty粘包、拆包（二）

list ride int 簡化 iter getclass null message som 上篇博客留了個尾巴“而且LineBasedFrameDecoder據說還有一種不要求攜帶結束符的解碼方式”，今天就從源碼來看看是怎麽回事。 一、基本原理 如果沒有netty，

3.Netty的粘包、拆包（二）

length coder 解碼器 generate trac main med con ++ Netty提供的TCP數據拆包、粘包解決方案 1.前言 關於TCP的數據拆包、粘包的介紹，我在上一篇文章裏面已經有過介紹。 想要了解一下的，請點擊這裏 Chick Here！ 今天

2.Netty的粘包、拆包（一）

Netty粘包、拆包 1.什麼是拆包、粘包 （1）拆包、粘包介紹 TCP是個“流”協議，所謂流，就是沒有界限的一串資料。大家可以想想河裡的流水，是連成一片的，其間並沒有分界線。TCP底層並不瞭解上層業務資料的具體含義，它會根據TCP緩衝區的實際情況進行包的劃分，所以在業務上認為，一個完整的包可能會被TCP拆

關於TCP粘包，拆包及解決方法

在進行Java NIO學習時，發現，如果客戶端連續不斷的向服務端傳送資料包時，服務端接收的資料會出現兩個資料包粘在一起的情況，這就是TCP協議中經常會遇到的粘包以及拆包的問題。 我們都知道TCP屬於傳輸層的協議，傳輸層除了有TCP協議外還有UDP協議。那麼UDP是否會發生粘包或拆包的現象呢？答案

TCP粘包，拆包及解決方法

在進行Java NIO學習時，發現，如果客戶端連續不斷的向服務端傳送資料包時，服務端接收的資料會出現兩個資料包粘在一起的情況，這就是TCP協議中經常會遇到的粘包以及拆包的問題。 我們都知道TCP屬於傳輸層的協議，傳輸層除了有TCP協議外還有UDP協議。那麼UDP

Java網路程式設計之Netty拆包和黏包-yellowcong

Netty中，解決拆包和黏包中，解決方式有三種 1、在每個包尾部，定義分隔符，通過回車符號，或者其他符號來解決 2、通過定義每個包的大小，如果包不夠就空格填充 3、自定義協議的方式，將訊息分為訊息頭和訊息體，在訊息頭中表示出訊息的總長度，

tcp和upd粘包、拆包、ip分片問題

我們都知道TCP屬於傳輸層的協議，傳輸層除了有TCP協議外還有UDP協議。那麼UDP是否會發生粘包或拆包的現象呢？答案是不會。UDP是基於報文傳送的，從UDP的幀結構可以看出，在UDP首部採用了16bit來指示UDP資料報文的長度，因此在應用層能很好的將不同的資料報文區分開，