multithreading - 在连接开始时将 SSL 与 Netty 结合使用，然后将其禁用

Question

我正在编写一个服务器应用程序及其对应的客户端，它们都将 Netty 用于网络层。我发现自己面临着从客户端向服务器发送密码的典型安全问题，因此我认为 SSL 是执行此操作的最安全方式。

我知道 securechat示例并将使用它相应地修改我的管道。但是，我还想在密码传输后禁用 SSL 并确认在服务器端节省一些宝贵的 CPU 周期，这可能会忙于许多其他客户端。 ChannelPipeline文件指出:

"Once attached, the coupling between the channel and the pipeline is permanent; the channel cannot attach another pipeline to it nor detach the current pipeline from it."

然后我们的想法是不要即时更改管道，这是被禁止的，而是以某种方式告诉管道中的 SslHandler 它应该在某个时候停止加密消息。我正在考虑创建一个继承自 SslHandler 的类，覆盖其 handleDownstream 函数以在通信中的某个点后调用 context.sendDownstream(evt) .

问题 1:这是不是一个坏主意，也就是说，在某个时候禁用 SSL？

为了允许管道中的一个 block (比如一个解码器)告诉另一个 block (比如SslHandler)它应该从现在开始改变它的行为，我想我可以例如，在我的 ChannelPipelineFactory 的 getPipeline() 中创建一个 AtomicBoolean 并将其传递给 Decoder 的构造函数em> 和 SslHandler。

问题 2:这是一个坏主意，即在管道 block 之间共享状态吗？我担心我可能会在这里搞砸 Netty 的多线程:管道的 block 是否一次处理一条消息？即:第一个 block 是否在拉取下一条消息之前等待最后一个 block 的完成？

编辑:

哦，天哪，这是来自 ChannelPipeline我访问过很多次并在这个问题中引用的页面:

"A ChannelHandler can be added or removed at any time because a ChannelPipeline is thread safe. For example, you can insert a SslHandler when sensitive information is about to be exchanged, and remove it after the exchange."

因此这回答了关于即时修改管道的内容的问题 2，而不是管道引用本身。

Answer 1

我不确定在建立 SSL 后关闭 SSL 的效果，但我认为您误解了管道的可变性。一旦给定 channel 与管道相关联，该关联就是不可变的。但是，可以安全地修改管道中的处理程序。也就是说，您可以根据协议(protocol)的要求添加和删除处理程序。因此，您应该能够在 SSL 处理程序达到其目的后将其删除。