Netty到底是什么
從HTTP說(shuō)起
有了Netty国裳，你可以實(shí)現(xiàn)自己的HTTP服務(wù)器，F(xiàn)TP服務(wù)器全跨，UDP服務(wù)器缝左，RPC服務(wù)器，WebSocket服務(wù)器浓若，Redis的Proxy服務(wù)器盒使，MySQL的Proxy服務(wù)器等等。
我們回顧一下傳統(tǒng)的HTTP服務(wù)器的原理
1七嫌、創(chuàng)建一個(gè)ServerSocket少办，監(jiān)聽(tīng)并綁定一個(gè)端口
2、一系列客戶端來(lái)請(qǐng)求這個(gè)端口
3诵原、服務(wù)器使用Accept英妓，獲得一個(gè)來(lái)自客戶端的Socket連接對(duì)象
4、啟動(dòng)一個(gè)新線程處理連接
4.1绍赛、讀Socket蔓纠，得到字節(jié)流
4.2、解碼協(xié)議吗蚌，得到Http請(qǐng)求對(duì)象
4.3腿倚、處理Http請(qǐng)求，得到一個(gè)結(jié)果蚯妇，封裝成一個(gè)HttpResponse對(duì)象
4.4敷燎、編碼協(xié)議暂筝，將結(jié)果序列化字節(jié)流
寫Socket，將字節(jié)流發(fā)給客戶端
5硬贯、繼續(xù)循環(huán)步驟3
HTTP服務(wù)器之所以稱為HTTP服務(wù)器焕襟，是因?yàn)榫幋a解碼協(xié)議是HTTP協(xié)議，如果協(xié)議是Redis協(xié)議饭豹，那它就成了Redis服務(wù)器鸵赖，如果協(xié)議是WebSocket，那它就成了WebSocket服務(wù)器拄衰，等等它褪。
使用Netty你就可以定制編解碼協(xié)議，實(shí)現(xiàn)自己的特定協(xié)議的服務(wù)器翘悉。
NIO
上面是一個(gè)傳統(tǒng)處理http的服務(wù)器列赎，但是在高并發(fā)的環(huán)境下，線程數(shù)量會(huì)比較多镐确，System load也會(huì)比較高包吝，于是就有了NIO。
他并不是Java獨(dú)有的概念源葫，NIO代表的一個(gè)詞匯叫著IO多路復(fù)用诗越。它是由操作系統(tǒng)提供的系統(tǒng)調(diào)用，早期這個(gè)操作系統(tǒng)調(diào)用的名字是select息堂，但是性能低下嚷狞，后來(lái)漸漸演化成了Linux下的epoll和Mac里的kqueue。我們一般就說(shuō)是epoll荣堰，因?yàn)闆](méi)有人拿蘋果電腦作為服務(wù)器使用對(duì)外提供服務(wù)床未。而Netty就是基于Java NIO技術(shù)封裝的一套框架。為什么要封裝振坚，因?yàn)樵腏ava NIO使用起來(lái)沒(méi)那么方便薇搁，而且還有臭名昭著的bug，Netty把它封裝之后渡八，提供了一個(gè)易于操作的使用模式和接口啃洋，用戶使用起來(lái)也就便捷多了。
說(shuō)NIO之前先說(shuō)一下BIO（Blocking IO）,如何理解這個(gè)Blocking呢屎鳍？
- 客戶端監(jiān)聽(tīng)（Listen）時(shí)宏娄，Accept是阻塞的，只有新連接來(lái)了逮壁，Accept才會(huì)返回孵坚，主線程才能繼
- 讀寫socket時(shí)，Read是阻塞的，只有請(qǐng)求消息來(lái)了卖宠，Read才能返回巍杈，子線程才能繼續(xù)處理
- 讀寫socket時(shí)，Write是阻塞的逗堵，只有客戶端把消息收了秉氧，Write才能返回眷昆，子線程才能繼續(xù)讀取下一個(gè)請(qǐng)求
傳統(tǒng)的BIO模式下蜒秤，從頭到尾的所有線程都是阻塞的，這些線程就干等著亚斋，占用系統(tǒng)的資源作媚，什么事也不干。
那么NIO是怎么做到非阻塞的呢帅刊。它用的是事件機(jī)制纸泡。它可以用一個(gè)線程把Accept，讀寫操作赖瞒，請(qǐng)求處理的邏輯全干了女揭。如果什么事都沒(méi)得做，它也不會(huì)死循環(huán)栏饮，它會(huì)將線程休眠起來(lái)吧兔，直到下一個(gè)事件來(lái)了再繼續(xù)干活，這樣的一個(gè)線程稱之為NIO線程袍嬉。用偽代碼表示：
while true {
events = takeEvents(fds) // 獲取事件境蔼，如果沒(méi)有事件，線程就休眠
for event in events {
if event.isAcceptable {
doAccept() // 新鏈接來(lái)了
} elif event.isReadable {
request = doRead() // 讀消息
if request.isComplete() {
doProcess()
}
} elif event.isWriteable {
doWrite() // 寫消息
}
}
}
Reactor線程模型
Reactor單線程模型
一個(gè)NIO線程+一個(gè)accept線程：
Reactor主從模型
主從Reactor多線程：多個(gè)acceptor的NIO線程池用于接受客戶端的連接
Netty可以基于如上三種模型進(jìn)行靈活的配置伺通。
總結(jié)
Netty是建立在NIO基礎(chǔ)之上箍土，Netty在NIO之上又提供了更高層次的抽象。
在Netty里面罐监，Accept連接可以使用單獨(dú)的線程池去處理吴藻，讀寫操作又是另外的線程池來(lái)處理。
Accept連接和讀寫操作也可以使用同一個(gè)線程池來(lái)進(jìn)行處理弓柱。而請(qǐng)求處理邏輯既可以使用單獨(dú)的線程池進(jìn)行處理调缨，也可以跟放在讀寫線程一塊處理。線程池中的每一個(gè)線程都是NIO線程吆你。用戶可以根據(jù)實(shí)際情況進(jìn)行組裝弦叶，構(gòu)造出滿足系統(tǒng)需求的高性能并發(fā)模型。
為什么選擇Netty
如果不用netty妇多，使用原生JDK的話伤哺，有如下問(wèn)題：
1、API復(fù)雜
2、對(duì)多線程很熟悉：因?yàn)镹IO涉及到Reactor模式
3立莉、高可用的話：需要出路斷連重連绢彤、半包讀寫、失敗緩存等問(wèn)題
4蜓耻、JDK NIO的bug
而Netty來(lái)說(shuō)茫舶，他的api簡(jiǎn)單、性能高而且社區(qū)活躍（dubbo刹淌、rocketmq等都使用了它）
什么是TCP 粘包/拆包
現(xiàn)象
先看如下代碼饶氏，這個(gè)代碼是使用netty在client端重復(fù)寫100次數(shù)據(jù)給server端，ByteBuf是netty的一個(gè)字節(jié)容器有勾，里面存放是的需要發(fā)送的數(shù)據(jù)
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端讀取到的數(shù)據(jù)為：
從服務(wù)端的控制臺(tái)輸出可以看出，存在三種類型的輸出
- 一種是正常的字符串輸出蔼卡。
- 一種是多個(gè)字符串“粘”在了一起喊崖，我們定義這種 ByteBuf 為粘包。
- 一種是一個(gè)字符串被“拆”開(kāi)雇逞，形成一個(gè)破碎的包荤懂，我們定義這種 ByteBuf 為半包。
透過(guò)現(xiàn)象分析原因
應(yīng)用層面使用了Netty塘砸，但是對(duì)于操作系統(tǒng)來(lái)說(shuō)节仿，只認(rèn)TCP協(xié)議，盡管我們的應(yīng)用層是按照 ByteBuf 為 單位來(lái)發(fā)送數(shù)據(jù)谣蠢，server按照Bytebuf讀取粟耻，但是到了底層操作系統(tǒng)仍然是按照字節(jié)流發(fā)送數(shù)據(jù)，因此眉踱，數(shù)據(jù)到了服務(wù)端挤忙，也是按照字節(jié)流的方式讀入，然后到了 Netty 應(yīng)用層面谈喳，重新拼裝成 ByteBuf册烈，而這里的 ByteBuf 與客戶端按順序發(fā)送的 ByteBuf 可能是不對(duì)等的。因此婿禽，我們需要在客戶端根據(jù)自定義協(xié)議來(lái)組裝我們應(yīng)用層的數(shù)據(jù)包赏僧，然后在服務(wù)端根據(jù)我們的應(yīng)用層的協(xié)議來(lái)組裝數(shù)據(jù)包，這個(gè)過(guò)程通常在服務(wù)端稱為拆包扭倾，而在客戶端稱為粘包淀零。
拆包和粘包是相對(duì)的，一端粘了包膛壹，另外一端就需要將粘過(guò)的包拆開(kāi)驾中，發(fā)送端將三個(gè)數(shù)據(jù)包粘成兩個(gè) TCP 數(shù)據(jù)包發(fā)送到接收端唉堪，接收端就需要根據(jù)應(yīng)用協(xié)議將兩個(gè)數(shù)據(jù)包重新組裝成三個(gè)數(shù)據(jù)包。
如何解決
在沒(méi)有 Netty 的情況下肩民，用戶如果自己需要拆包唠亚，基本原理就是不斷從 TCP 緩沖區(qū)中讀取數(shù)據(jù)，每次讀取完都需要判斷是否是一個(gè)完整的數(shù)據(jù)包 如果當(dāng)前讀取的數(shù)據(jù)不足以拼接成一個(gè)完整的業(yè)務(wù)數(shù)據(jù)包持痰，那就保留該數(shù)據(jù)灶搜，繼續(xù)從 TCP 緩沖區(qū)中讀取，直到得到一個(gè)完整的數(shù)據(jù)包工窍。 如果當(dāng)前讀到的數(shù)據(jù)加上已經(jīng)讀取的數(shù)據(jù)足夠拼接成一個(gè)數(shù)據(jù)包割卖，那就將已經(jīng)讀取的數(shù)據(jù)拼接上本次讀取的數(shù)據(jù)，構(gòu)成一個(gè)完整的業(yè)務(wù)數(shù)據(jù)包傳遞到業(yè)務(wù)邏輯移剪，多余的數(shù)據(jù)仍然保留究珊，以便和下次讀到的數(shù)據(jù)嘗試拼接薪者。
而在Netty中纵苛，已經(jīng)造好了許多類型的拆包器，我們直接用就好：
選好拆包器后言津，在代碼中client段和server端將拆包器加入到chanelPipeline之中就好了:
如上實(shí)例中：
客戶端：
ch.pipeline().addLast(new FixedLengthFrameDecoder(31));
服務(wù)端：
ch.pipeline().addLast(new FixedLengthFrameDecoder(31));
Netty 的零拷貝
傳統(tǒng)意義的拷貝
是在發(fā)送數(shù)據(jù)的時(shí)候攻人，傳統(tǒng)的實(shí)現(xiàn)方式是：
File.read(bytes)Socket.send(bytes)
這種方式需要四次數(shù)據(jù)拷貝和四次上下文切換：
- 數(shù)據(jù)從磁盤讀取到內(nèi)核的read buffer
- 數(shù)據(jù)從內(nèi)核緩沖區(qū)拷貝到用戶緩沖區(qū)
- 數(shù)據(jù)從用戶緩沖區(qū)拷貝到內(nèi)核的socket buffer
- 數(shù)據(jù)從內(nèi)核的socket buffer拷貝到網(wǎng)卡接口（硬件）的緩沖區(qū)
零拷貝的概念
明顯上面的第二步和第三步是沒(méi)有必要的，通過(guò)java的FileChannel.transferTo方法悬槽，可以避免上面兩次多余的拷貝（當(dāng)然這需要底層操作系統(tǒng)支持）
- 調(diào)用transferTo,數(shù)據(jù)從文件由DMA引擎拷貝到內(nèi)核read buffer
- 接著DMA從內(nèi)核read buffer將數(shù)據(jù)拷貝到網(wǎng)卡接口buffer上面的兩次操作都不需要CPU參與怀吻，所以就達(dá)到了零拷貝。
Netty中的零拷貝
主要體現(xiàn)在三個(gè)方面：
1初婆、bytebuffer
Netty發(fā)送和接收消息主要使用bytebuffer蓬坡，bytebuffer使用對(duì)外內(nèi)存（DirectMemory）直接進(jìn)行Socket讀寫。原因：如果使用傳統(tǒng)的堆內(nèi)存進(jìn)行Socket讀寫磅叛，JVM會(huì)將堆內(nèi)存buffer拷貝一份到直接內(nèi)存中然后再寫入socket屑咳，多了一次緩沖區(qū)的內(nèi)存拷貝。DirectMemory中可以直接通過(guò)DMA發(fā)送到網(wǎng)卡接口
2弊琴、Composite Buffers
傳統(tǒng)的ByteBuffer兆龙，如果需要將兩個(gè)ByteBuffer中的數(shù)據(jù)組合到一起，我們需要首先創(chuàng)建一個(gè)size=size1+size2大小的新的數(shù)組敲董，然后將兩個(gè)數(shù)組中的數(shù)據(jù)拷貝到新的數(shù)組中紫皇。但是使用Netty提供的組合ByteBuf，就可以避免這樣的操作腋寨，因?yàn)镃ompositeByteBuf并沒(méi)有真正將多個(gè)Buffer組合起來(lái)聪铺，而是保存了它們的引用，從而避免了數(shù)據(jù)的拷貝萄窜，實(shí)現(xiàn)了零拷貝铃剔。
3锣杂、對(duì)于FileChannel.transferTo的使用
Netty中使用了FileChannel的transferTo方法，該方法依賴于操作系統(tǒng)實(shí)現(xiàn)零拷貝番宁。
Netty 內(nèi)部執(zhí)行流程
服務(wù)端：
1元莫、創(chuàng)建ServerBootStrap實(shí)例
2、設(shè)置并綁定Reactor線程池：EventLoopGroup蝶押，EventLoop就是處理所有注冊(cè)到本線程的Selector上面的Channel
3踱蠢、設(shè)置并綁定服務(wù)端的channel
4、創(chuàng)建處理網(wǎng)絡(luò)事件的ChannelPipeline和handler棋电，網(wǎng)絡(luò)時(shí)間以流的形式在其中流轉(zhuǎn)茎截，handler完成多數(shù)的功能定制：比如編解碼 SSl安全認(rèn)證
5、綁定并啟動(dòng)監(jiān)聽(tīng)端口
6赶盔、當(dāng)輪訓(xùn)到準(zhǔn)備就緒的channel后企锌，由Reactor線程：NioEventLoop執(zhí)行pipline中的方法，最終調(diào)度并執(zhí)行channelHandler
客戶端
總結(jié)
以上就是我對(duì)Netty相關(guān)知識(shí)整理于未，如果有不同的見(jiàn)解撕攒，歡迎討論！
