4.4 什么时候使用

现在，您已经详细了解了所有传输方式，您可能会问何时应该选择一种传输方式。如前所述，并非所有传输都支持所有核心协议。这也会限制您可以选择的运输方式。表4.6列出了每种传输支持的协议。

传输	TCP	UDP	SCTP*
NIO	X	X	X
OIO	X	X	X
Local
Embedded

*目前只支持Linux。 这在将来可能会改变。。 该表的内容反映了出版时所支持的内容。

在Linux上启用SCTP

请注意，对于SCTP，您
需要安装用户空间库以及支持它的内核。

For Ubuntu, use the following command:

\# sudo apt-get install libsctp1

For Fedora, you use yum:

\# sudo yum install kernel-modules-extra.x86_64 lksctp-tools.x86_64

Please refer to the documentation of each Linux distribution for more information about how to enable SCTP.

除了SCTP项目外，没有任何硬性规定，但是由于运输的性质，有一些建议。在实现服务器时，您也
可能需要处理比实现客户端时更多的并发连接。

让我们来看看你可能经历的用例。

• 低并发连接数

对于您希望并发连接数量很少的应用程序，请从OIO传输开始。与低并发连接一样，您不必担心每个连接分配一个线程的限制。在这种情况下，资源使用不会成为问题。您可能想知道什么构成低连接数？这很难说，但是请记住，使用NIO传输可以服务于成千上万的并发连接。我将低于1,000个并发连接的任何内容标记为低并发连接数。

在这种特定的用例中，您只会从OIO传输提供的低延迟中受益，因此您也可能会看到更好的吞吐量。

例如，如果您的连接非常活跃，则OIO所需的上下文切换可能会产生太大影响。与往常一样，在这里很难给出硬性规定，因为这完全取决于您的应用程序和需求。

• 高并发连接数

如果您希望应用程序同时处理许多并发连接，请选择NIO传输。这些传输处理多个并发连接，因为它们每个连接不使用一个线程，而是使用几个线程并在连接之间共享它们。

• 低延迟（Low latency）

如果您需要极低的延迟，则可能需要先使用OIO。如前两个要点所述，由于其内部设计，OIO的延迟比NIO少得多。但是，与往常一样，这是一个折衷，因为您将不得不以较高的线程数来交换较低的延迟。

• 阻塞代码库

如果您将旧的代码库（主要是基于阻止网络和应用程序的设计）转换为Netty，那么您很可能会有一些操作会阻塞I / O线程太长时间而无法通过NIO等异步传输进行有效扩展。您可以通过重写整个堆栈来解决此问题，但这可能无法在目标时间内完成。在这种情况下，请从OIO开始，当您认为需要更多扩展时，请转到NIO。

• 在同一个JVM中进行通信

如果您只需要在同一VM中进行通信，而无需通过网络公开服务，那么您将拥有本地传输的完美用例。这是因为您将消除实际网络操作的所有开销，但仍然能够重用Netty代码库。这也使以后在需要时通过网络公开服务变得容易。

在这种情况下，唯一需要做的就是用NIO或OIO替换传输，并可能添加一个额外的编码器/解码器，以将Java对象转换为ByteBuf，反之亦然。

• 测试您的ChannelHandler实现

如果要为不是集成测试的ChannelHandler实现编写测试，请尝试一下嵌入式传输。它使测试ChannelHandlers变得容易，而无需创建许多模拟，同时仍符合所有传输中相同的事件流。这样可以保证ChannelHandler在将其与某些实际传输一起使用后也能正常工作。

第7章为您提供了有关测试ChannelHandlers的更多详细信息。

如您现在所知，了解您的应用程序具有什么样的用例/特性很重要的，并且总是选择能够给您最好结果的传输。 表4.6总结了常见的 用例。

Application needs	Recommended transport
Low concurrent connection count	OIO
High concurrent connection count	NIO
Low latency	OIO
Blocking code base	OIO
Communication within the same JVM	Local
Testing your ChannelHandler implementations	Embedded