一起学习一起进步~

在 LogEventEncoder 被实现之后，我们就该准备引导该服务器，其包括设置各种各样的 ChannelOption，以及在 ChannelPipeline 中安装所需要的 ChannelHandler，这些都要通过主类 LogEventBroadcaster 完成。类似于在我们先前的类比中的明信片，它包含了接收者（和可选的发送者）的地址以及消息的有效负载本身。下面我们看一下将要广播的信息：我们将展示正在广播的 3 个日志条目，每一个都将通过一个专门的 DatagramPacket进行广播。

TCP：是面向连接的传输，它管理了两个网络端点之间的连接的建立，在连接的生命周期内的有序和可靠的消息传输，以及最后，连接的有序终止。TCP 的消息是有序的，并且会在两个方向上流动。是无连接协议中，并没有持久化连接这样的概念，并且每个消息（一个 UDP 数据报）都是一个单独的传输单元。同时UDP 也没有 TCP 的纠错机制，其中每个节点都将确认它们所接收到的包，而没有被确认的包将会被发送方重新传输。UDP 消息是无序的，并且无法确定是否能到达目的地。UDP的优势和不足：优势：UDP的传输速度远远高于TCP。

如果握手成功，那么所需的 ChannelHandler 将会被添加到ChannelPipeline中，而那些不再需要的ChannelHandler 则将会被移除。下图展示了上面操作完成之后的ChannelPipeline，Netty目前支持 4个版本的WebSocket协议，它们每个都具有自己的实现类。我们对于 initChannel()方法的调用，安装所有必需的 ChannelHandler 来设置该新注册的 Channel 的 ChannelPipeline。ChatServer 添加加密。

WebSocket 协议是完全重新设计的协议，旨在为 Web 上的双向数据传输问题提供一个切实可行的解决方案，使得客户端和服务器之间可以在任意时刻传输消息，因此，这也就要求它们异步地处理消息回执。

基于分隔符的（delimited）消息协议使用定义的字符来标记的消息或者消息段（通常被称为帧）的开头或者结尾。由RFC文档正式定义的许多协议（如SMTP、POP3、IMAP以及Telnet）都是这样的。此外，还有一些自定义的类似协议。下图展示了基于分割符的协议：但无论使用什么样的协议，下表列出的解码器都能帮助我们定义可以提取由任意标记（token）序列分隔的帧的自定义解码器。

注意，无论你使用 JDK 的 SSLEngine 还是使用 Netty 的 OpenSslEngine，SSL API 和数据流都 是一致的。我们可以配置 SslHandler 来修改它的行为，或者在 SSL/TLS握手一旦完成之后提供通知，握手阶段完成之后，所有的数据都将会被加密。如果你正在使用的是 JDK 6 或者更早的版本，那么你需要将 JZlib（www.jcraft.com/jzlib/）添加到CLASSPATH 中以支持压缩功能。然而，需要注意的是，服务器没有义务压缩它所发送的数据。

网络只将数据看作是原始的字节序列。但我们的应用程序则会把这些字节组织成有意义的信息。在数据和网络字节流之间做相互转换是最常见的编程任务之一。例如，我们可能需要处理标准的格式或者协议（如 FTP 或 Telnet）、实现一种由第三方定义的专有二进制协议，或者扩展一种由自己的组织创建的遗留的消息格式。将应用程序的数据转换为网络格式，以及将网络格式转换为应用程序的数据的组件分别叫作编码器和解码器，同时具有这两种功能的单一组件叫作编解码器。

单元测试的基本思想是：以尽可能小的区块测试代码，并且尽可能地和其他的代码模块以及运行时的依赖（如数据库和网络）相隔离。如果应用程序能通过测试验证每个单元本身都能够正常地工作，那么在出了问题时将可以更加容易地找出根本原因。ChannelHandler 是 Netty 应用程序的关键元素，所以彻底地测试它们应该是开发过程的一个标准部分。最佳实践要求你的测试不仅要能够证明实现是正确的，而且还要能够很容易地隔离那些因修改代码而突然出现的问题。这种类型的测试叫作单元测试。

引导一个应用程序是指对它进行配置，并使它运行起来的过程。引导可以简单的认为是将分散的了 ChannelPipeline、ChannelHandler 和 EventLoop组合起来，成为一个完成应用程序的模块。

简单地说，线程模型指定了操作系统、编程语言、框架或者应用程序的上下文中的线程管理的关键方面。在早期的 Java 语言中，我们使用多线程处理的主要方式无非是按需创建和启动新的 Thread 来执行并发的任务单元,这种在高负载下表现得很原始。Java 5 随后引入了 Executor API，其线程池通过缓存和重用Thread 极大地提高了性能。从池的空闲线程列表中选择一个 Thread，并且指派它去运行一个已提交的任务（一个Runnable 的实现）；

可以看到上面两段代码的事件流是一样的，需要注意的是虽然被调用的 Channel 或 ChannelPipeline 上的 write()方法一直传播事件通过整个 ChannelPipeline，但是在 ChannelHandler 的级别上，事件从一个ChannelHandler到下一个 ChannelHandler 的移动是由 ChannelHandlerContext 上的调用完成的。要想处理这种类型的入站异常，你需要在你的 ChannelInboundHandler 实现中重写下面的方法。

我们前面说过，网络数据的基本单位总是字节。Java NIO 提供了 ByteBuffer 作为它的字节容器，但是这个类使用起来过于复杂，而且也有些繁琐。ByteBuffer 替代品是 ByteBuf，一个强大的实现，既解决了 JDK API 的局限性，又为网络应用程序的开发者提供了更好的 API。下面我们将会说明和 JDK 的 ByteBuffer 相比，ByteBuf 的卓越功能性和灵活性。

但是，并不是所有的操作系统都支持这一特性。如果为了用于非阻塞 I/O 而重新实现这个简单的应用程序，都需要一次完全的重写的话，那么不难想象，移植真正复杂的应用程序需要付出什么样的努力。虽然这保证了 Netty 的非阻塞 API 可以在任何平台上使用，但它也包含了相应的限制，因为 JDK为了在所有系统上提供相同的功能，必须做出妥协。ps：Netty 的 Channel 实现是线程安全的，因此你可以存储一个到 Channel 的引用，并且每当你需要向远程节点写数据时，都可以使用它，即使当时许多线程都在使用它。

在这个 ChannelHandler 中，你将需要重写基类的一个或者多个方法，并且获取一个到 ChannelHandlerContext 的引用，这个引用将作为输入参数传递给 ChannelHandler 的所有方法。从应用程序开发人员的角度来看，Netty 的主要组件是 ChannelHandler，它充当了所有处理入站和出站数据的应用程序逻辑的容器。ChannelHandler 是专为支持广泛的用途而设计的，可以将它看作是处理往来 ChannelPipeline 事件（包括数据）的任何代码的通用容器。

即使是对于这么少量的数据，channelRead0()方法也可能会被调用两次，第一次使用一个持有 3 字节的 ByteBuf（Netty 的字节容器），第二次使用一个持有 2 字节的 ByteBuf。如同在 EchoServerHandler（3.1中的代码示例）中所示，记录 Throwable，关闭 Channel，在这个场景下，终止到服务器的连接。引导客户端类似于引导服务器，不同的是，客户端是使用主机和端口参数来连接远程地址，也就是这里的 Echo 服务器的地址，而不是绑定到一个一直被监听的端口。

Netty是由JBOSS提供的一个java开源框架，它提供异步的、事件驱动的网络应用程序框架和工具。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。