主体所说的基本内容。当客户端通过发送到同一nats服务器的消息进行通信时，我想知道使用相同的加密/解密机制在性能方面是否有好处。
如果有人感兴趣，我在这里提出了同样的问题：
https://github.com/nats-io/nats-server/discussions/2740
例如，考虑以下两种基于nats的通信场景：
- 场景#1：
一个出版商(p(正在就主题"；foo.bar"；，使用加密-解密方案(A(和他自己的加密密钥(A(
消费者(C(订阅nats subject"；foo.bar"；，使用加密-解密方案(B(和他自己的加密密钥(B(
在这种情况下，我假设nats服务器将使用解密方案(A(对(p(发布的消息进行解密；foo.bar"；在已经使用加密方案(B(对这些消息进行了重新加密之后，将消息传送到消费者(C(。
- 场景#2：
一个出版商(p(正在就主题"；foo.bar"；，使用加密-解密方案(A(和他自己的加密密钥(A(
消费者(C(订阅nats subject"；foo.bar"；，使用与发行商完全相同的加密-解密方案(A(
在这种情况下，我假设nats服务器只需要使用解密方案(A(解密(p(发布的消息的主题；foo.bar"；通过"发送"到消费者(C(的消息；复制粘贴"；消息"的有效载荷(数据(；"照原样"；因为加密-解密机制是完全相同的。
我想加密-解密中的这种对称性应该在负载较高时提供更好的性能。
我的这些假设是对的吗？还是我错过了什么？我还没有看到任何人指出场景#2是提高性能和减少延迟的一种手段(可能还会降低错误率(。
想法？见解？相关文档的链接？
收到用户的响应"Todd Beets"；在这个线程中：
https://github.com/nats-io/nats-server/discussions/2740#discussioncomment-1799935
<lt；NATS不会像您假设的那样在NATS协议[1](第7层(级别进行加密/解密。
"在电线上"；NATS完全支持NATS客户端的TLS[2]。
当TLS在NATS服务器上终止时，实际上，NATS正在扮演场景1中的模式(即1..N订阅NATS客户端具有独立的TLS连接和密钥(。
[1]https://docs.nats.io/reference/reference-protocols/nats-protocol#client-协议
[2]https://docs.nats.io/using-nats/developer/security/tls>gt；
(重点矿井(