tcp是一個“流”的協議,一個完整的包可能會被TCP拆分成多個包進行發送,也可能把小的封裝成一個大的數據包發送,這就是所謂的TCP粘包和拆包問題。
粘包、拆包問題說明
假設客戶端分別發送數據包D1和D2給服務端,由於服務端一次性讀取到的字節數是不確定的,所以可能存在以下4種情況。
- 1.服務端分2次讀取到了兩個獨立的包,分別是D1,D2,沒有粘包和拆包;
- 2.服務端一次性接收了兩個包,D1和D2粘在一起了,被成為TCP粘包;
- 3.服務端分2次讀取到了兩個數據包,第一次讀取到了完整的D1和D2包的部分內容,第二次讀取到了D2包的剩余內容,這被稱為拆包;
- 4.服務端分2次讀取到了兩個數據包,第一次讀取到了部分D1,第二次讀取D1剩余的部分和完整的D2包;
如果此時服務端TCP接收滑動窗非常小,而數據包D1和D2都很大,很有可能發送第五種可能,即服務端多次才能把D1和D2接收完全,期間多次發生拆包情況。(TCP接收滑動窗:是接收端的大小,隨着流量大小而變化,如果我的解釋還不明確,請讀者自行百度,或者查閱《計算機網絡》、《TCP/IP》中TCP的內容)
粘包問題的解決策略
由於底層的TCP無法理解上層的業務邏輯,所以在底層是無法確保數據包不被拆分和重組的,這個問題只能通過上層的應用協議棧設計來解決,根據業界的主流協議的解決方案,歸納如下:
- 1.消息定長,例如每個報文的大小為固定長度200字節,如果不夠,空位補空格;
- 2.在包尾增加回車換行符進行分割,例如FTP協議;
- 3.將消息分為消息頭和消息體,消息頭中包含表示消息總長度(或者消息體長度)的字段,通常設計思路是消息頭的第一個字段用int來表示消息的總長度;(我之前linux C開發,就用的這種)。
- 4.更復雜的應用層協議;
為了解決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線程會調用channelActive 20 // 發送查詢時間的指令給服務端。 21 // 調用ChannelHandlerContext的writeAndFlush方法,將請求消息發送給服務端 22 // 當服務端應答時,channelRead方法被調用 23 } 24 25 @Override 26 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 @Override 13 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 和StringDecoder編碼器說明
LineBasedFrameDecoder 工作原理:依次編譯bytebuf中的可讀字符,判斷看是否有“\n”或者“\r\n”,如果有,就以此位置為結束位置,從可讀索引到結束位置區間的字節就組成了一行。它是以換行符為結束標志的解碼器,支持攜帶結束符或者不攜帶結束符兩種解碼方式,同時支持單行的最大長度。如果連續讀取到最大長度后,仍然沒有發現換行符,就會拋出異常,同時忽略掉之前讀到的異常碼流。
StringDecoder功能:將接收到的對象轉成字符串,然后繼續調用后面的handler。 LineBasedFrameDecoder + StringDecoder組成就是按行切換的文本解碼器,它被設計用來支持TCP的粘包和拆包。
可能讀者會提出新的疑問:如果發送的消息不是以換行符結束怎么辦?或者沒有回車換行符,靠消息頭中的長度字段來分包怎么辦?是不是需要自己寫半包解碼器?答案是否定的,Netty提供了多種支持TCP粘包/拆包的解碼器。
關於“分隔符解碼器”,下一章單獨講解說明。
源碼下載
GitHub地址:https://github.com/orange1438/Netty_Course
作者:orange1438 出處:http://www.cnblogs.com/orange1438/ 本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。