网络应用程序让人与系统之间可以进行通信，当然网络应用程序也可以将大量的数据从一个地方转移到另一个地方。如何做到这一点取决于具体的网络传输，但转移始终是相同的：字节通过线路。传输的概念帮助我们抽象掉的底层数据转移的机制。所有人都需要知道的是，字节在被发送和接收。

1、Channel 类的层次结构

传输 API 的核心是 interface Channel，它被用于所有的 I/O 操作。Channel 类的层次结构如图所示：

1、每个 Channel 都将会被分配一个 ChannelPipeline 和 ChannelConfig。 ChannelConfig 包含了该 Channel 的所有配置设置，并且支持热更新。由于特定的传输可能具有独特的设置，所以它可能会实现一个 ChannelConfig 的子类型。（请参考 ChannelConfig 实现对应的 Javadoc。）

2、每个Channel是独一无二的，所以为了保证顺序将 Channel 声明为 java.lang. Comparable 的一个子接口。因此，如果两个不同的 Channel 实例都返回了相同的散列码，那 么 AbstractChannel 中的 compareTo()方法的实现将会抛出一个 Error。

3、ChannelPipeline 持有所有将应用于入站和出站数据以及事件的 ChannelHandler 实 例，这些 ChannelHandler 实现了应用程序用于处理状态变化以及数据处理的逻辑。

ChannelHandler 的典型用途包括：

1. 将数据从一种格式转换为另一种格式；
2. 提供异常的通知；
3. 提供 Channel 变为活动的或者非活动的通知；
4. 提供当 Channel 注册到 EventLoop 或者从 EventLoop 注销时的通知；
5. 提供有关用户自定义事件的通知。

2、Netty中内置处理协议的包路径

Netty 内置了一些可开箱即用的传输。因为并不是它们所有的传输都支持每一种协议，所以 你必须选择一个和你的应用程序所使用的协议相容的传输。

名 称	包	描 述
NIO	io.netty.channel.socket.nio	使用 java.nio.channels 包作为基础——基于选择器的方式
Epoll①	io.netty.channel.epoll	由 JNI 驱动的 epoll()和非阻塞 IO。这个传输支持只有在Linux上可用的多种特性，如SO_REUSEPORT，比 NIO 传输更快，而且是完全非阻塞的
OIO	io.netty.channel.socket.oio	使用 java.net 包作为基础——使用阻塞流
Local	io.netty.channel.local	可以在 VM 内部通过管道进行通信的本地传输
Embedded	io.netty.channel.embedded	Embedded 传输，允许使用 ChannelHandler 而又不需要一个真正的基于网络的传输。这在测试你的ChannelHandler 实现时非常有用

不同协议不同的阻塞类型的连接都有不同的 Channel 类型与之对应下面是一些常用的 Channel 类型:

• NioSocketChannel, 代表异步的客户端 TCP Socket 连接.

• NioServerSocketChannel, 异步的服务器端 TCP Socket 连接.

• NioDatagramChannel, 异步的 UDP 连接

• NioSctpChannel, 异步的客户端 Sctp 连接.

• NioSctpServerChannel, 异步的 Sctp 服务器端连接.

• OioSocketChannel, 同步的客户端 TCP Socket 连接.

• OioServerSocketChannel, 同步的服务器端 TCP Socket 连接.

• OioDatagramChannel, 同步的 UDP 连接

• OioSctpChannel, 同步的 Sctp 服务器端连接.

• OioSctpServerChannel, 同步的客户端 TCP Socket 连接.

3、Netty中各种传输类型的介绍

具体看下表：

• OIO-在低连接数、需要低延迟时、阻塞时使用
• NIO-在高连接数时使用
• Local-在同一个JVM内通信时使用
• Embedded-测试ChannelHandler时使用

3.1、NIO——非阻塞 I/O

NIO 提供了一个所有 I/O 操作的全异步的实现。它利用了自 NIO 子系统被引入 JDK 1.4 时便 可用的基于选择器的 API。

选择器背后的基本概念是充当一个注册表，在那里你将可以请求在 Channel 的状态发生变 化时得到通知。

可能的状态变化有：

•  新的 Channel 已被接受并且就绪；
•  Channel 连接已经完成；
•  Channel 有已经就绪的可供读取的数据；
•  Channel 可用于写数据。

选择器运行在一个检查状态变化并对其做出相应响应的线程上，在应用程序对状态的改变做 出响应之后，选择器将会被重置，并将重复这个过程。

处理完改变的状态后需重新设置他们的状态，用一个线程来检查是否有已准备好的 Channel，如果有则执行相关事件。在这里可能只同时一个注册的事件而忽略其他的。选择器所支持的操作在 SelectionKey 中定义，具体如下：

Table 3.1 Selection operation bit-set

方法名称	描述
OP_ACCEPT	有新连接时得到通知
OP_CONNECT	连接完成后得到通知
OP_READ	准备好读取数据时得到通知
OP_WRITE	写入更多数据到通道时得到通知，大部分时间

 

3.2、NIO——Epoll—用于 Linux 的本地非阻塞传输

　　Linux作为高性能网络编程的平台，其重要性与日俱增，这催生了大量先进特性的开发，其 中包括epoll——一个高度可扩展的I/O事件通知特性。这个API自Linux内核版本 2.5.44（2002）被 引入，提供了比旧的POSIX select和poll系统调用 更好的性能，同时现在也是Linux上非阻 塞网络编程的事实标准。Linux JDK NIO API使用了这些epoll调用。

　　Netty为Linux提供了一组NIO API，其以一种和它本身的设计更加一致的方式使用epoll，并 且以一种更加轻量的方式使用中断。① 4.3.3 OIO—旧的阻塞 I/O 如果你的应用程序旨在运行于Linux系统，那么请考虑利用 这个版本的传输；你将发现在高负载下它的性能要优于JDK的NIO实现。

3.3、OIO—旧的阻塞 I/O

　　Netty 的 OIO 传输实现代表了一种折中：它可以通过常规的传输 API 使用，但是由于它 是建立在 java.net 包的阻塞实现之上的，所以它不是异步的。但是，它仍然非常适合于某 些用途。

　　例如，你可能需要移植使用了一些进行阻塞调用的库（如JDBC② 有了这个背景，你可能会想，Netty是如何能够使用和用于异步传输相同的API来支持OIO的呢。 答案就是，Netty利用了SO_TIMEOUT这个Socket标志，它指定了等待一个I/O操作完成的最大毫秒 数。如果操作在指定的时间间隔内没有完成，则将会抛出一个SocketTimeout Exception。Netty 将捕获这个异常并继续处理循环。在EventLoop下一次运行时，它将再次尝试。这实际上也是 类似于Netty这样的异步框架能够支持OIO的唯一方式 ）的遗留代码，而将逻辑转 换为非阻塞的可能也是不切实际的。相反，你可以在短期内使用Netty的OIO传输，然后再将你的 代码移植到纯粹的异步传输上。

 

 

 

1.线程分配给 Socket

2.Socket 连接到远程

3.读操作（可能会阻塞）

4.读完成

5.处理可读的字节

6.执行提交到 socket 的其他任务

7.再次尝试读

 

3.4、用于 JVM 内部通信的 Local 传输

　　Netty 提供了一个 Local 传输，用于在同一个 JVM 中运行的客户端和服务器程序之间的异步 通信。同样，这个传输也支持对于所有 Netty 传输实现都共同的 API。

　　在这个传输中，和服务器 Channel 相关联的 SocketAddress 并没有绑定物理网络地址； 相反，只要服务器还在运行，它就会被存储在注册表里，并在 Channel 关闭时注销。因为这个 传输并不接受真正的网络流量，所以它并不能够和其他传输实现进行互操作。因此，客户端希望 连接到（在同一个 JVM 中）使用了这个传输的服务器端时也必须使用它。除了这个限制，它的 使用方式和其他的传输一模一样。

3.5、Embedded 传输

Netty 提供了一种额外的传输，使得你可以将一组 ChannelHandler 作为帮助器类嵌入到 其他的 ChannelHandler 内部。通过这种方式，你将可以扩展一个 ChannelHandler 的功能， 而又不需要修改其内部代码。 不足为奇的是，Embedded 传输的关键是一个被称为 EmbeddedChannel 的具体的 Channel 实现。在第 9 章中，我们将详细地讨论如何使用这个类来为 ChannelHandler 的实现创建单元 测试用例。