徹底理解Netty邪媳，這一篇文章就夠了

轉(zhuǎn)載?https://juejin.im/post/5bdaf8ea6fb9a0227b02275a

Netty到底是什么

從HTTP說起

有了Netty章钾，你可以實現(xiàn)自己的HTTP服務器墙贱，F(xiàn)TP服務器，UDP服務器伍玖，RPC服務器嫩痰，WebSocket服務器，Redis的Proxy服務器窍箍，MySQL的Proxy服務器等等串纺。

我們回顧一下傳統(tǒng)的HTTP服務器的原理

1、創(chuàng)建一個ServerSocket椰棘，監(jiān)聽并綁定一個端口

2纺棺、一系列客戶端來請求這個端口

3、服務器使用Accept邪狞，獲得一個來自客戶端的Socket連接對象

4祷蝌、啟動一個新線程處理連接

4.1、讀Socket帆卓，得到字節(jié)流4.2巨朦、解碼協(xié)議，得到Http請求對象 4.3剑令、處理Http請求糊啡，得到一個結果，封裝成一個HttpResponse對象 4.4吁津、編碼協(xié)議棚蓄，將結果序列化字節(jié)流寫Socket，將字節(jié)流發(fā)給客戶端

5、繼續(xù)循環(huán)步驟3

HTTP服務器之所以稱為HTTP服務器梭依，是因為編碼解碼協(xié)議是HTTP協(xié)議稍算，如果協(xié)議是Redis協(xié)議，那它就成了Redis服務器役拴，如果協(xié)議是WebSocket糊探，那它就成了WebSocket服務器，等等扎狱。使用Netty你就可以定制編解碼協(xié)議侧到，實現(xiàn)自己的特定協(xié)議的服務器。

NIO

上面是一個傳統(tǒng)處理http的服務器淤击，但是在高并發(fā)的環(huán)境下，線程數(shù)量會比較多故源，System load也會比較高污抬，于是就有了NIO。

他并不是Java獨有的概念绳军，NIO代表的一個詞匯叫著IO多路復用印机。它是由操作系統(tǒng)提供的系統(tǒng)調(diào)用，早期這個操作系統(tǒng)調(diào)用的名字是select门驾，但是性能低下射赛，后來漸漸演化成了Linux下的epoll和Mac里的kqueue。我們一般就說是epoll奶是，因為沒有人拿蘋果電腦作為服務器使用對外提供服務楣责。而Netty就是基于Java NIO技術封裝的一套框架。為什么要封裝聂沙，因為原生的Java NIO使用起來沒那么方便秆麸，而且還有臭名昭著的bug，Netty把它封裝之后及汉，提供了一個易于操作的使用模式和接口沮趣，用戶使用起來也就便捷多了。

說NIO之前先說一下BIO（Blocking IO）,如何理解這個Blocking呢坷随？

客戶端監(jiān)聽（Listen）時房铭，Accept是阻塞的，只有新連接來了温眉，Accept才會返回缸匪，主線程才能繼

讀寫socket時，Read是阻塞的芍殖，只有請求消息來了豪嗽，Read才能返回，子線程才能繼續(xù)處理

讀寫socket時，Write是阻塞的龟梦，只有客戶端把消息收了隐锭，Write才能返回，子線程才能繼續(xù)讀取下一個請求

傳統(tǒng)的BIO模式下计贰，從頭到尾的所有線程都是阻塞的钦睡，這些線程就干等著，占用系統(tǒng)的資源躁倒，什么事也不干荞怒。

那么NIO是怎么做到非阻塞的呢。它用的是事件機制秧秉。它可以用一個線程把Accept褐桌，讀寫操作，請求處理的邏輯全干了象迎。如果什么事都沒得做荧嵌，它也不會死循環(huán)，它會將線程休眠起來砾淌，直到下一個事件來了再繼續(xù)干活啦撮，這樣的一個線程稱之為NIO線程。用偽代碼表示：

whiletrue{events=takeEvents(fds)// 獲取事件汪厨，如果沒有事件赃春，線程就休眠foreventinevents{ifevent.isAcceptable{doAccept()// 新鏈接來了}elifevent.isReadable{request=doRead()// 讀消息ifrequest.isComplete(){doProcess()}}elifevent.isWriteable{doWrite()// 寫消息}}}

Reactor線程模型

Reactor單線程模型

一個NIO線程+一個accept線程：

Reactor多線程模型

Reactor主從模型

主從Reactor多線程：多個acceptor的NIO線程池用于接受客戶端的連接

Netty可以基于如上三種模型進行靈活的配置。

總結

Netty是建立在NIO基礎之上劫乱，Netty在NIO之上又提供了更高層次的抽象织中。

在Netty里面，Accept連接可以使用單獨的線程池去處理要拂，讀寫操作又是另外的線程池來處理抠璃。

Accept連接和讀寫操作也可以使用同一個線程池來進行處理。而請求處理邏輯既可以使用單獨的線程池進行處理脱惰，也可以跟放在讀寫線程一塊處理搏嗡。線程池中的每一個線程都是NIO線程。用戶可以根據(jù)實際情況進行組裝拉一，構造出滿足系統(tǒng)需求的高性能并發(fā)模型采盒。

為什么選擇Netty

如果不用netty，使用原生JDK的話蔚润，有如下問題：

1磅氨、API復雜

2、對多線程很熟悉：因為NIO涉及到Reactor模式

3嫡纠、高可用的話：需要出路斷連重連烦租、半包讀寫延赌、失敗緩存等問題

4、JDK NIO的bug

而Netty來說叉橱，他的api簡單挫以、性能高而且社區(qū)活躍（dubbo、rocketmq等都使用了它）

什么是TCP 粘包/拆包

現(xiàn)象

先看如下代碼窃祝，這個代碼是使用netty在client端重復寫100次數(shù)據(jù)給server端掐松，ByteBuf是netty的一個字節(jié)容器，里面存放是的需要發(fā)送的數(shù)據(jù)

publicclassFirstClientHandlerextendsChannelInboundHandlerAdapter{@OverridepublicvoidchannelActive(ChannelHandlerContextctx){for(inti=0;i<1000;i++){ByteBufbuffer=getByteBuf(ctx);ctx.channel().writeAndFlush(buffer);}}privateByteBufgetByteBuf(ChannelHandlerContextctx){byte[]bytes="你好粪小，我的名字是1234567!".getBytes(Charset.forName("utf-8"));ByteBufbuffer=ctx.alloc().buffer();buffer.writeBytes(bytes);returnbuffer;}}

從client端讀取到的數(shù)據(jù)為：

從服務端的控制臺輸出可以看出大磺，存在三種類型的輸出

一種是正常的字符串輸出。

一種是多個字符串“粘”在了一起探膊，我們定義這種 ByteBuf 為粘包杠愧。

一種是一個字符串被“拆”開，形成一個破碎的包突想，我們定義這種 ByteBuf 為半包殴蹄。

透過現(xiàn)象分析原因

應用層面使用了Netty，但是對于操作系統(tǒng)來說猾担，只認TCP協(xié)議，盡管我們的應用層是按照 ByteBuf 為單位來發(fā)送數(shù)據(jù)刺下，server按照Bytebuf讀取绑嘹，但是到了底層操作系統(tǒng)仍然是按照字節(jié)流發(fā)送數(shù)據(jù)，因此橘茉，數(shù)據(jù)到了服務端工腋，也是按照字節(jié)流的方式讀入，然后到了 Netty 應用層面畅卓，重新拼裝成 ByteBuf擅腰，而這里的 ByteBuf 與客戶端按順序發(fā)送的 ByteBuf 可能是不對等的。因此翁潘，我們需要在客戶端根據(jù)自定義協(xié)議來組裝我們應用層的數(shù)據(jù)包趁冈，然后在服務端根據(jù)我們的應用層的協(xié)議來組裝數(shù)據(jù)包，這個過程通常在服務端稱為拆包拜马，而在客戶端稱為粘包渗勘。

拆包和粘包是相對的，一端粘了包俩莽，另外一端就需要將粘過的包拆開旺坠，發(fā)送端將三個數(shù)據(jù)包粘成兩個 TCP 數(shù)據(jù)包發(fā)送到接收端，接收端就需要根據(jù)應用協(xié)議將兩個數(shù)據(jù)包重新組裝成三個數(shù)據(jù)包扮超。

如何解決

在沒有 Netty 的情況下取刃，用戶如果自己需要拆包蹋肮，基本原理就是不斷從 TCP 緩沖區(qū)中讀取數(shù)據(jù)，每次讀取完都需要判斷是否是一個完整的數(shù)據(jù)包如果當前讀取的數(shù)據(jù)不足以拼接成一個完整的業(yè)務數(shù)據(jù)包璧疗，那就保留該數(shù)據(jù)坯辩，繼續(xù)從 TCP 緩沖區(qū)中讀取，直到得到一個完整的數(shù)據(jù)包病毡。如果當前讀到的數(shù)據(jù)加上已經(jīng)讀取的數(shù)據(jù)足夠拼接成一個數(shù)據(jù)包濒翻，那就將已經(jīng)讀取的數(shù)據(jù)拼接上本次讀取的數(shù)據(jù)，構成一個完整的業(yè)務數(shù)據(jù)包傳遞到業(yè)務邏輯啦膜，多余的數(shù)據(jù)仍然保留有送，以便和下次讀到的數(shù)據(jù)嘗試拼接。

而在Netty中僧家，已經(jīng)造好了許多類型的拆包器雀摘，我們直接用就好：

選好拆包器后，在代碼中client段和server端將拆包器加入到chanelPipeline之中就好了:

如上實例中：

客戶端：

ch.pipeline().addLast(newFixedLengthFrameDecoder(31));

服務端：

ch.pipeline().addLast(newFixedLengthFrameDecoder(31));

Netty 的零拷貝

傳統(tǒng)意義的拷貝

是在發(fā)送數(shù)據(jù)的時候八拱，傳統(tǒng)的實現(xiàn)方式是：

1.?File.read(bytes)

2.?Socket.send(bytes)

這種方式需要四次數(shù)據(jù)拷貝和四次上下文切換：

1. 數(shù)據(jù)從磁盤讀取到內(nèi)核的read buffer

2. 數(shù)據(jù)從內(nèi)核緩沖區(qū)拷貝到用戶緩沖區(qū)

3. 數(shù)據(jù)從用戶緩沖區(qū)拷貝到內(nèi)核的socket buffer

4. 數(shù)據(jù)從內(nèi)核的socket buffer拷貝到網(wǎng)卡接口（硬件）的緩沖區(qū)

零拷貝的概念

明顯上面的第二步和第三步是沒有必要的阵赠，通過java的FileChannel.transferTo方法，可以避免上面兩次多余的拷貝（當然這需要底層操作系統(tǒng)支持）

1. 調(diào)用transferTo,數(shù)據(jù)從文件由DMA引擎拷貝到內(nèi)核read buffer

2. 接著DMA從內(nèi)核read buffer將數(shù)據(jù)拷貝到網(wǎng)卡接口buffer

上面的兩次操作都不需要CPU參與肌稻，所以就達到了零拷貝清蚀。

Netty中的零拷貝

主要體現(xiàn)在三個方面：

1、bytebuffer

Netty發(fā)送和接收消息主要使用bytebuffer爹谭，bytebuffer使用對外內(nèi)存（DirectMemory）直接進行Socket讀寫枷邪。

原因：如果使用傳統(tǒng)的堆內(nèi)存進行Socket讀寫，JVM會將堆內(nèi)存buffer拷貝一份到直接內(nèi)存中然后再寫入socket诺凡，多了一次緩沖區(qū)的內(nèi)存拷貝东揣。DirectMemory中可以直接通過DMA發(fā)送到網(wǎng)卡接口

2、Composite Buffers

傳統(tǒng)的ByteBuffer腹泌，如果需要將兩個ByteBuffer中的數(shù)據(jù)組合到一起嘶卧，我們需要首先創(chuàng)建一個size=size1+size2大小的新的數(shù)組，然后將兩個數(shù)組中的數(shù)據(jù)拷貝到新的數(shù)組中凉袱。但是使用Netty提供的組合ByteBuf芥吟，就可以避免這樣的操作，因為CompositeByteBuf并沒有真正將多個Buffer組合起來绑蔫，而是保存了它們的引用运沦，從而避免了數(shù)據(jù)的拷貝，實現(xiàn)了零拷貝配深。

3携添、對于FileChannel.transferTo的使用

Netty中使用了FileChannel的transferTo方法，該方法依賴于操作系統(tǒng)實現(xiàn)零拷貝篓叶。

Netty 內(nèi)部執(zhí)行流程

服務端：