摘要：豐富的緩存數(shù)據(jù)結構使用它自己的緩存來表示字節(jié)序列而不是的。針對有一個定義良好的事件模型。有一些協(xié)議是多層的建立在其他低級協(xié)議基礎上。此外，甚至不是完全線程安全的。協(xié)議由標準化為。協(xié)議緩存整合是一個高效二進制協(xié)議的快速實現(xiàn)。

這一節(jié)我們將確認Netty提供的核心功能是什么，以及它們怎么構成一個完整的網(wǎng)絡應用開發(fā)堆棧。

Netty使用它自己的緩存API來表示字節(jié)序列而不是NIO的ByteBuffer。Netty的新緩存類——ChannelBuffer，徹底解決了ByteBuffer的問題，滿足了網(wǎng)絡應用開發(fā)者的日常需求。這里列舉幾個很酷的特點：

需要的話你可以自定義緩存類

通過一個內(nèi)置的組合緩存類實現(xiàn)零拷貝組合

提供開箱即用的動態(tài)緩存，自動擴容，就像StringBuffer一樣

不再需要調(diào)用flip方法

通常比ByteBuffer要快

當在通信層傳輸數(shù)據(jù)時，數(shù)據(jù)經(jīng)常需要被組合或者切分。比如一次裝載被分成多個包，但是經(jīng)常需要組合起來解碼。
傳統(tǒng)方式來說，多個包的數(shù)據(jù)通過復制到一個新的字節(jié)緩存而組合起來。
Netty支持零復制實現(xiàn)，通過讓一個新的ChannelBuffer“指向”所有要求組合的緩存，從而避免了復制操作。

傳統(tǒng)Java的I/O API對不同的傳輸類型提供不同的類和方法。舉個例子，java.net.Socket和java.net.DatagramSocket沒有公共父類因此它們在執(zhí)行socket I/O的方式完全不一樣。

這種不匹配的結果就是使得應用程序從一種傳輸方式移植成另一種變得十分困難。也就是說你需要支持額外的傳輸方式因為應用程序的網(wǎng)絡層經(jīng)常涉及到重寫。邏輯上，許多協(xié)議可以在不只一種傳輸方式，比如TCP/IP、UDO/IP、SCTP和串行通信上運行。

更糟的是，Java的新I/O（NIO）API繼承了老阻塞I/O（OIO）API的不兼容性，并且在下一個版本NIO.2（AIO）繼續(xù)這樣做。因為這些API在設計和表現(xiàn)特點上完全不同，你經(jīng)常被迫在應用程序開始實現(xiàn)之前就需要確定好依賴那種API。

舉個例子，你可能想用OIO方式開始因為你服務的客戶數(shù)量很小且用OIO寫一個socket服務比用NIO要簡單得多。但是，當你的業(yè)務呈指數(shù)級上升然后你需要同時服務成千上萬的客戶時，麻煩就大了。你也可以用NIO方式開始，但是這可能會阻礙開發(fā)速度，畢竟NIO的選擇器API很復雜。

Netty擁有統(tǒng)一的異步I/O接口——Channel，它抽象了點對點通信要求的所有操作。只要你用一種Netty傳輸寫的應用程序，可以在其他Netty傳輸上運行。Nett通過統(tǒng)一的API提供了必要的傳輸方式：

基于NIO的TCP/IP傳輸（見org.jboss.netty.channel.socket.nio）

基于OIO的TCP/IP傳輸（見org.jboss.netty.channel.socket.oio）

基于OIO的UDP/IP傳輸

本地傳輸（見org.jboss.netty.channel.local）

要從一種傳輸方式切換到另一種，只需要改動幾行代碼，比如選擇另一個ChannelFactory實現(xiàn)。

你甚至可以使用還沒發(fā)布的新傳輸方式，比如串行通信傳輸，同樣替換幾行構造器調(diào)用的代碼。再者，你也可以通過繼承核心API實現(xiàn)自己的傳輸方式。

一個定義良好的并可擴展性高的事件模型是一個事件驅(qū)動應用程序的前提。Netty針對I/O有一個定義良好的事件模型。你可以在不破壞已有代碼的情況下實現(xiàn)你自己的事件類，因為每一個事件類都根據(jù)一個嚴格的類層次體系區(qū)別于其他事件類。這是另一個和其他框架的不同點。很多NIO框架都沒有或者很有限的事件模型概念。如果它們提供了擴展，就會經(jīng)常在嘗試增加自定義事件類時破壞已有代碼。

一個ChannelEvent由一個ChannelPipeline里的一列ChannelHandler來處理。這個管道實現(xiàn)了一個過濾鏈模式的高級形式，讓使用者完全控制一個事件如何被處理以及管道內(nèi)的handler如何相互聯(lián)系。舉個例子，你可以規(guī)定數(shù)據(jù)從socket讀取時做點什么：

public class MyReadHandler implements SimpleChannelHandler {
    public void messageReceived(ChannelHandlerContext ctx, MessageEvent evt) {
        Object message = evt.getMessage();
        // Do something with the received message.
        ...
        // And forward the event to the next handler.
        ctx.sendUpstream(evt);
    }
}

你也可以規(guī)定一個handler在接收一個寫請求時做點什么：

public class MyWriteHandler implements SimpleChannelHandler {
    public void writeRequested(ChannelHandlerContext ctx, MessageEvent evt) {
        Object message = evt.getMessage();
        // Do something with the message to be written.
        ...
        // And forward the event to the next handler.
        ctx.sendDownstream(evt);
    }
}

之前“用POJO替代ChannelBuffer”那一節(jié)證實了，把協(xié)議編解碼從業(yè)務邏輯中分離出來通常是一個好主意。但是從零開始實現(xiàn)有一些困難。你需要處理信息分片。有一些協(xié)議是多層的（建立在其他低級協(xié)議基礎上）。還有一些協(xié)議在單機系統(tǒng)上實現(xiàn)特別困難。

因此，一個好的網(wǎng)絡應用框架需要提供一個可擴展的、可重用的、可單元測試的和多層級的編解碼器框架，產(chǎn)生可維護的用戶編解碼器。

Netty提供了一系列基礎和高級的編解碼器，可以解決你在寫一個協(xié)議編解碼器是遭遇的大多數(shù)問題，無論編解碼器是否簡單，是二進制的還是文本的。

不像阻塞I/O，在NIO支持SSL是個值得正視對任務。你不能簡單得包裝一個流對數(shù)據(jù)進行加密解密，你必須要用到javax.net.ssl.SSLEngine。SSLEngine是一個跟SSL本身一樣復雜的狀態(tài)機。你需要處理所有可能的狀態(tài)，如密碼套件、加密密鑰協(xié)商、證書交換以及驗證。此外，SSL甚至不是完全線程安全的。

在Netty，SslHandler負責對外屏蔽SSLEngine所有細枝末節(jié)，你只需要配置SslHandler然后添加到你的ChannelPipeline中。SslHandler同時讓你可以很容易實現(xiàn)類似StartTLS的高級特性。

HTTP絕對是互聯(lián)網(wǎng)最流行的協(xié)議?，F(xiàn)在已經(jīng)有一系列HTTP實現(xiàn)，比如Servlet容器。那么為什么Netty還要自己實現(xiàn)HTTP呢？

Netty的HTTP支持和現(xiàn)有的HTTP庫很不一樣。它讓你可以完全控制HTTP在底層的消息交換。因為從根本上來說，它就是一個HTTP編解碼器和HTTP消息類的結合，沒有類似強制線程模型這樣的限制。也就是說，你可以按照你希望的工作方式來實現(xiàn)HTTP客戶端和服務端。你擁有所有HTTP規(guī)范內(nèi)的控制權，包括線程模型、連接生命周期和分塊編碼。

基于它的高可定制性，你可以寫一個高效的HTTP服務：

要求持續(xù)連接和服務推送技術的聊天服務（如Comet）；

需要保持連接直到整個媒體文件流傳輸完畢的媒體流服務（如兩小時的電影）；

無內(nèi)存壓力上傳大文件的文件服務（如上傳1G文件）；

可以異步連接成千上萬的第三方web服務的可伸縮的混合客戶端

WebSocket在單TCP socket上實現(xiàn)一個雙向全雙工通信通道，用于web瀏覽器和web服務端端數(shù)據(jù)交互。
WebSocket協(xié)議由IETF標準化為RFC 6455。
Netty實現(xiàn)了RFC 6455和一系列舊版本規(guī)范。

Google Protocal Buffers是一個高效二進制協(xié)議的快速實現(xiàn)。憑借ProtobufEncoder和ProtobufDecoder，你可以將Goodgle Protocal Buffers編譯程序生成的信息類轉化為Netty編解碼器。

這一節(jié)，我們從特點出發(fā)回顧了Netty的總體架構。Netty擁有一個簡單且至今仍強大的架構。它由三個組件組成——buffer，channel和事件模型，所有高級特性都是在這三個組件的基礎上建立的。只要你理解了這三個組件是如何一起工作的，你就不難理解這節(jié)簡要提及的那些高級特性。