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

有了Netty，你可以實現自己的HTTP伺服器，FTP伺服器，UDP伺服器，RPC伺服器，Socket/">WebSocket伺服器，Redis的Proxy伺服器，SQL/">MySQL的Proxy伺服器等等。

我們回顧一下傳統的HTTP伺服器的原理

1、建立一個ServerSocket，監聽並繫結一個埠

2、一系列客戶端來請求這個埠

3、伺服器使用Accept，獲得一個來自客戶端的Socket連線物件

4、啟動一個新執行緒處理連線

4.1、讀Socket，得到位元組流

4.2、解碼協議，得到Http請求物件

4.3、處理Http請求，得到一個結果，封裝成一個HttpResponse物件

4.4、編碼協議，將結果序列化位元組流 寫Socket，將位元組流發給客戶端

5、繼續迴圈步驟3

HTTP伺服器之所以稱為HTTP伺服器，是因為編碼解碼協議是HTTP協議，如果協議是Redis協議，那它就成了Redis伺服器，如果協議是WebSocket，那它就成了WebSocket伺服器，等等。 使用Netty你就可以定製編解碼協議，實現自己的特定協議的伺服器。

IO/">NIO

上面是一個傳統處理http的伺服器，但是在高併發的環境下，執行緒數量會比較多，System load也會比較高，於是就有了NIO。

while true {
events = takeEvents(fds)// 獲取事件，如果沒有事件，執行緒就休眠
for event in events {
if event.isAcceptable {
doAccept() // 新連結來了
} elif event.isReadable {
request = doRead() // 讀訊息
if request.isComplete() {
doProcess()
}
} elif event.isWriteable {
doWrite()// 寫訊息
}
}
}複製程式碼

Reactor執行緒模型

Reactor單執行緒模型

一個NIO執行緒+一個accept執行緒：

Reactor多執行緒模型

Reactor主從模型

主從Reactor多執行緒：多個acceptor的NIO執行緒池用於接受客戶端的連線

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

總結

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

在Netty裡面，Accept連線可以使用單獨的執行緒池去處理，讀寫操作又是另外的執行緒池來處理。

Accept連線和讀寫操作也可以使用同一個執行緒池來進行處理。而請求處理邏輯既可以使用單獨的執行緒池進行處理，也可以跟放在讀寫執行緒一塊處理。執行緒池中的每一個執行緒都是NIO執行緒。使用者可以根據實際情況進行組裝，構造出滿足系統需求的高效能併發模型。

為什麼選擇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端讀取到的資料為：

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

1. 一種是正常的字串輸出。
2. 一種是多個字串“粘”在了一起，我們定義這種 ByteBuf 為粘包。
3. 一種是一個字串被“拆”開，形成一個破碎的包，我們定義這種 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));複製程式碼