Netty簡介:
Netty是建立在NIO基礎之上,Netty在NIO之上又提供了更高層次的抽象。
在Netty裏面,Accept連接可以使用單獨的線程池去處理,讀寫操作又是另外的線程池來處理。
Accept連接和讀寫操作也可以使用同一個線程池來進行處理。而請求處理邏輯既可以使用單獨的線程池進行處理,也可以跟放在讀寫線程一塊處理。線程池中的每一個線程都是NIO線程。用戶可以根據實際情況進行組裝,構造出滿足系統需求的高性能併發模型。
特點:
設計
針對多種傳輸類型的統一接口 - 阻塞和非阻塞
簡單但更強大的線程模型
真正的無連接的數據報套接字支持
鏈接邏輯支持複用
易用性
大量的 Javadoc 和 代碼實例
除了在 JDK 1.6 + 額外的限制。(一些特徵是隻支持在Java 1.7 +。可選的功能可能有額外的限制。)
性能
比核心 Java API 更好的吞吐量,較低的延時
資源消耗更少,這個得益於共享池和重用
減少內存拷貝
健壯性
消除由於慢,快,或重載連接產生的 OutOfMemoryError
消除經常發現在 NIO 在高速網絡中的應用中的不公平的讀/寫比
安全
完整的 SSL / TLS 和 StartTLS 的支持
運行在受限的環境例如 Applet 或 OSGI
社區
發佈的更早和更頻繁
社區驅動
爲什麼選擇Netty
如果不用netty,使用原生JDK的話,有如下問題:
1、API複雜
2、對多線程很熟悉:因爲NIO涉及到Reactor模式
3、高可用的話:需要出路斷連重連、半包讀寫、失敗緩存等問題
4、JDK NIO的bug
而Netty來說,他的api簡單、性能高而且社區活躍(dubbo、rocketmq等都使用了它)
什麼是TCP 粘包/拆包
現象
先看如下代碼,這個代碼是使用netty在client端重複寫100次數據給server端,ByteBuf是netty的一個字節容器,裏面存放是的需要發送的數據
public class FirstClientHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelActive(ChannelHandlerContext ctx) {
for (int i = 0; i < 1000; i++) {
ByteBuf buffer = getByteBuf(ctx);
ctx.channel().writeAndFlush(buffer);
}
}
private ByteBuf getByteBuf(ChannelHandlerContext ctx) {
byte[] bytes = "你好,我的名字是1234567!".getBytes(Charset.forName("utf-8"));
ByteBuf buffer = ctx.alloc().buffer();
buffer.writeBytes(bytes);
return buffer;
}
}複製代碼
從client端讀取到的數據爲:
從服務端的控制檯輸出可以看出,存在三種類型的輸出
- 一種是正常的字符串輸出。
- 一種是多個字符串“粘”在了一起,我們定義這種 ByteBuf 爲粘包。
- 一種是一個字符串被“拆”開,形成一個破碎的包,我們定義這種 ByteBuf 爲半包。
透過現象分析原因
應用層面使用了Netty,但是對於操作系統來說,只認TCP協議,儘管我們的應用層是按照 ByteBuf 爲 單位來發送數據,server按照Bytebuf讀取,但是到了底層操作系統仍然是按照字節流發送數據,因此,數據到了服務端,也是按照字節流的方式讀入,然後到了 Netty 應用層面,重新拼裝成 ByteBuf,而這裏的 ByteBuf 與客戶端按順序發送的 ByteBuf 可能是不對等的。因此,我們需要在客戶端根據自定義協議來組裝我們應用層的數據包,然後在服務端根據我們的應用層的協議來組裝數據包,這個過程通常在服務端稱爲拆包,而在客戶端稱爲粘包。
拆包和粘包是相對的,一端粘了包,另外一端就需要將粘過的包拆開,發送端將三個數據包粘成兩個 TCP 數據包發送到接收端,接收端就需要根據應用協議將兩個數據包重新組裝成三個數據包。
如何解決
在沒有 Netty 的情況下,用戶如果自己需要拆包,基本原理就是不斷從 TCP 緩衝區中讀取數據,每次讀取完都需要判斷是否是一個完整的數據包 如果當前讀取的數據不足以拼接成一個完整的業務數據包,那就保留該數據,繼續從 TCP 緩衝區中讀取,直到得到一個完整的數據包。 如果當前讀到的數據加上已經讀取的數據足夠拼接成一個數據包,那就將已經讀取的數據拼接上本次讀取的數據,構成一個完整的業務數據包傳遞到業務邏輯,多餘的數據仍然保留,以便和下次讀到的數據嘗試拼接。
而在Netty中,已經造好了許多類型的拆包器,我們直接用就好:
選好拆包器後,在代碼中client段和server端將拆包器加入到chanelPipeline之中就好了:
如上實例中:
客戶端:
ch.pipeline().addLast(new FixedLengthFrameDecoder(31));複製代碼
服務端:
ch.pipeline().addLast(new FixedLengthFrameDecoder(31));複製代碼
Netty 的零拷貝
傳統意義的拷貝
是在發送數據的時候,傳統的實現方式是:
1. `File.read(bytes)`
2. `Socket.send(bytes)`
這種方式需要四次數據拷貝和四次上下文切換:
1. 數據從磁盤讀取到內核的read buffer
2. 數據從內核緩衝區拷貝到用戶緩衝區
3. 數據從用戶緩衝區拷貝到內核的socket buffer
4. 數據從內核的socket buffer拷貝到網卡接口(硬件)的緩衝區
零拷貝的概念
明顯上面的第二步和第三步是沒有必要的,通過java的FileChannel.transferTo方法,可以避免上面兩次多餘的拷貝(當然這需要底層操作系統支持)
1. 調用transferTo,數據從文件由DMA引擎拷貝到內核read buffer
2. 接着DMA從內核read buffer將數據拷貝到網卡接口buffer
上面的兩次操作都不需要CPU參與,所以就達到了零拷貝。
Netty中的零拷貝
主要體現在三個方面:
1、bytebuffer
Netty發送和接收消息主要使用bytebuffer,bytebuffer使用對外內存(DirectMemory)直接進行Socket讀寫。
原因:如果使用傳統的堆內存進行Socket讀寫,JVM會將堆內存buffer拷貝一份到直接內存中然後再寫入socket,多了一次緩衝區的內存拷貝。DirectMemory中可以直接通過DMA發送到網卡接口
2、Composite Buffers
傳統的ByteBuffer,如果需要將兩個ByteBuffer中的數據組合到一起,我們需要首先創建一個size=size1+size2大小的新的數組,然後將兩個數組中的數據拷貝到新的數組中。但是使用Netty提供的組合ByteBuf,就可以避免這樣的操作,因爲CompositeByteBuf並沒有真正將多個Buffer組合起來,而是保存了它們的引用,從而避免了數據的拷貝,實現了零拷貝。
3、對於FileChannel.transferTo的使用
Netty中使用了FileChannel的transferTo方法,該方法依賴於操作系統實現零拷貝。
Netty 內部執行流程
服務端:
1、創建ServerBootStrap實例
2、設置並綁定Reactor線程池:EventLoopGroup,EventLoop就是處理所有註冊到本線程的Selector上面的Channel
3、設置並綁定服務端的channel
4、5、創建處理網絡事件的ChannelPipeline和handler,網絡時間以流的形式在其中流轉,handler完成多數的功能定製:比如編解碼 SSl安全認證
6、綁定並啓動監聽端口
7、當輪訓到準備就緒的channel後,由Reactor線程:NioEventLoop執行pipline中的方法,最終調度並執行channelHandler
客戶端