tcp是一個“流”的協議,一個完整的包可能會被TCP拆分成多個包進行發送,也可能把小的封裝成一個大的數據包發送,這就是所謂的TCP粘包和拆包問題。
假設客戶端分別發送數據包D1和D2給服務端,由于服務端一次性讀取到的字節數是不確定的,所以可能存在以下4種情況。
如果此時服務端TCP接收滑動窗非常小,而數據包D1和D2都很大,很有可能發送第五種可能,即服務端多次才能把D1和D2接收完全,期間多次發生拆包情況。(TCP接收滑動窗:是接收端的大小,隨著流量大小而變化,如果我的解釋還不明確,請讀者自行百度,或者查閱《計算機網絡》、《TCP/ip》中TCP的內容)
由于底層的TCP無法理解上層的業務邏輯,所以在底層是無法確保數據包不被拆分和重組的,這個問題只能通過上層的應用協議棧設計來解決,根據業界的主流協議的解決方案,歸納如下:
為了解決TCP粘包拆包的問題,Netty默認提供了多種編碼器來處理,以下通過代碼來說明;
服務端:
1 public class TimeServer { 2 /* -------- 和Netty入門章節一樣的代碼 -------- */ 3 PRivate class ChildChannelHandler extends ChannelInitializer<SocketChannel>{ 4 @Override 5 protected void initChannel(SocketChannel arg0)throws Exception{ 6 // 增加 LineBasedFrameDecoder 和StringDecoder編碼器 7 arg0.pipeline().addLast(new LineBasedFrameDecoder(1024)); 8 arg0.pipeline().addLast(new StringDecoder()); 9 arg0.pipeline().addLast(new TimeServerHandler());10 }11 }12 13 /* -------- 和Netty入門章節一樣的代碼 -------- */14 }
1 public class TimeServerHandler extends ChannelHandlerAdapter{ 2 3 private int counter; 4 5 // 用于網絡的讀寫操作 6 @Override 7 public void channelRead(ChannelHandlerContext ctx,Object msg) 8 throws Exception{ 9 10 String body = (String)msg;11 System.out.println("the time server order : " + body+";the counter is :"+ (++counter));12 13 String currentTime = "QUERY TIME ORDER".equalsIgnoreCase(body)?new Date(14 System.currentTimeMillis()).toString():"BAD ORDER";15 currentTime +=System.getProperty("line.separator"); // System.getProperty("line.separator"),獲取/n的作用16 ByteBuf resp = Unpooled.copiedBuffer(currentTime.getBytes());17 ctx.writeAndFlush(resp);18 19 // 當客戶端和服務端建立tcp成功之后,Netty的NIO線程會調用channelActive20 // 發送查詢時間的指令給服務端。21 // 調用ChannelHandlerContext的writeAndFlush方法,將請求消息發送給服務端22 // 當服務端應答時,channelRead方法被調用23 }24 25 @Override26 public void exceptionCaught(ChannelHandlerContext ctx,Throwable cause){27 ctx.close();28 }29 }
客服端
1 public class TimeClient { 2 public void connect(String host,int port)throws Exception{ 3 // 配置服務端的NIO線程組 4 EventLoopGroup group = new NioEventLoopGroup(); 5 6 try { 7 // Bootstrap 類,是啟動NIO服務器的輔助啟動類 8 Bootstrap b = new Bootstrap(); 9 b.group(group).channel(NioSocketChannel.class)10 .option(ChannelOption.TCP_NODELAY,true)11 .handler(new ChannelInitializer<SocketChannel>() {12 @Override13 public void initChannel(SocketChannel ch)14 throws Exception{15 // 增加 LineBasedFrameDecoder 和StringDecoder編碼器16 ch.pipeline().addLast(new LineBasedFrameDecoder(1024));17 ch.pipeline().addLast(new StringDecoder());18 ch.pipeline().addLast(new TimeClientHandler());19 }20 });21 22 // 發起異步連接操作23 ChannelFuture f= b.connect(host,port).sync();24 25 // 等待客服端鏈路關閉26 f.channel().closeFuture().sync();27 }finally {28 group.shutdownGracefully();29 }30 }31 32 public static void main(String[]args)throws Exception{33 int port = 8080;34 if(args!=null && args.length>0){35 try {36 port = Integer.valueOf(args[0]);37 }38 catch (NumberFormatException ex){}39 }40 new TimeClient().connect("127.0.0.1",port);41 }42 }
以上的代碼,主要就是增加 LineBasedFrameDecoder 和StringDecoder編碼器來處理粘包、拆包問題。全部項目代碼,源碼在src/main/java/NettyStickyPacket下,分為客戶端和服務端,他們的代碼基本和Netty入門章節的代碼類似,只是增加了解碼器。
LineBasedFrameDecoder 工作原理:依次編譯bytebuf中的可讀字符,判斷看是否有“/n”或者“/r/n”,如果有,就以此位置為結束位置,從可讀索引到結束位置區間的字節就組成了一行。它是以換行符為結束標志的解碼器,支持攜帶結束符或者不攜帶結束符兩種解碼方式,同時支持單行的最大長度。如果連續讀取到最大長度后,仍然沒有發現換行符,就會拋出異常,同時忽略掉之前讀到的異常碼流。
StringDecoder功能:將接收到的對象轉成字符串,然后繼續調用后面的handler。 LineBasedFrameDecoder + StringDecoder組成就是按行切換的文本解碼器,它被設計用來支持TCP的粘包和拆包。
可能讀者會提出新的疑問:如果發送的消息不是以換行符結束怎么辦?或者沒有回車換行符,靠消息頭中的長度字段來分包怎么辦?是不是需要自己寫半包解碼器?答案是否定的,Netty提供了多種支持TCP粘包/拆包的解碼器。
關于“分隔符解碼器”,下一章單獨講解說明。
新聞熱點
疑難解答