Netty實戰四之傳輸

流經網絡的數據老是具備相同的類型：字節（網絡傳輸——一個幫助咱們抽象底層數據傳輸機制的概念）

Netty爲它全部的傳輸實現提供了一個通用的API，即咱們能夠將時間花在其餘更有成效的事情上。

咱們將經過一個案例來對傳輸進行學習，應用程序只簡單地接收鏈接，向客戶端寫 「Hi！」 ，而後關閉鏈接。

一、不經過Netty使用OIO和NIO

先介紹JDK API的應用程序的阻塞（OIO）版本和異步（NIO）版本。

這段代碼徹底能夠處理中等數量的併發客戶端，可是隨着應用程序變得流行起來，你會發現它並不能很好地伸縮到支撐成千上萬的併發連入鏈接。你決定改用異步網絡編程，可是很快就發現異步API是徹底不一樣的，以致於如今你不得不重寫你的應用程序。

雖然這段代碼所作的事情與以前的版本徹底相同，可是代碼卻大相徑庭，若是爲了用於非阻塞I/O而從新實現這個簡單的應用程序，都須要一次徹底重寫的話，那麼不難想象，移植真正複雜的應用程序須要付出什麼樣的努力！

二、經過Netty使用OIO和NIO

三、非阻塞的Netty版本

由於Netty爲每種傳輸的實現都暴露了相同的API，因此不管選用哪種傳輸的實現，你的代碼都仍然幾乎不受影響，在全部的狀況下，傳輸的實現都依賴於interface Channel、ChannelPipeline和ChannelHandler。

四、傳輸API

傳輸API的核心是interface Channel ，它被用於全部的I/O操做。Channel類的層次結構如圖4-1（Channel接口的層次結構）所示。

如圖所示，每一個Channel都將會將分配一個ChannelPipeline和ChannelConfig。ChannelConfig包含了該Channel的全部配置設置，而且支持熱更新。

因爲特定的傳輸可能具備獨特的設置，因此它可能會實現一個ChannelConfig的子類型。

因爲Channel是獨一無二的，因此爲了保證順序將Channel聲明爲java.lang.Comparable的子接口。所以，若是兩個不一樣的Channel實例都返回相同的散列碼，那麼AbstractChannel中的compareTo（）方法的實現將會拋出一個Error。

ChannelPiepeline持有全部將應用於入站和出站數據以及事件的ChannelHandler實例，這些ChannelHandler實現了應用程序用於處理狀態變化以及數據處理的邏輯。

ChannelHandler的典型用途包括：

-將數據從一種格式轉換爲另外一種格式

-提供異常的通知

-提供Channel變爲活動的或者非活動的通知

-提供當Channel註冊到EventLoop或者從EventLoop註銷時的通知

-提供有關用戶自定義事件的通知

攔截過濾器 ChannelPipeline實現了一種常見的設計模式——攔截過濾器（InterceptingFilter）。UNIX管道是另一個熟悉的例子：多個命令被連接在一塊兒，其中一個命令的輸出端將鏈接到命令行中下一個命令的輸入端。

你也能夠根據須要經過添加或者移除ChannelHandler實例來修改ChannelPipeline。經過利用Netty的這項能力能夠構建出高度靈活的應用程序。例如，每當STARTTLS協議被請求時，你能夠簡單地經過向ChannelPipeline添加一個適當的ChannelHandler（SslHandler）來按需地支持STARTTLS協議。

考慮一下寫數據並將其沖刷到遠程節點這樣的常規任務，代碼清單4-5演示了使用Channel.writeAndFlush（）來實現這一目的。

Netty的Channel實現是線程安全的，所以你能夠存儲一個到Channel的引用，而且每當你須要向遠程節點寫數據時，均可以使用它，即便當時許多線程都在使用它。代碼清單4-6展現了一個多線程寫數據的簡單例子，須要注意的是，消息將會被保證按順序發送的。