像GTP这样的隧道协议是否成为限制吞吐量的瓶颈？

Question

当隧道协议如IPSec(处于隧道模式)或GTP正在使用时，它们会将多个IP流放入一个流中。既然只有一个流程，我们如何扩大吞吐量？分配更多的处理器核心不会有帮助，因为来自一个流的数据包只能分配到一个核心。不管怎么说，这个问题有什么可以回避的吗？在我的例子中，问题在于GTP。eNodeBs将从UEs到GTP隧道的所有IP流都是相同的。由于我们只有5到10个eNodeB，这导致了相同数量的IP流。因此，当岩心利用率超过80%时，岩心利用率变得非常不均匀，有些岩心利用率低于10%。每个流都由单个核心处理，这样就不会有数据包重新排序。由于数千个IP流被隧道化成5到10个IP流，RSS散列函数的随机性变得不均匀，导致几个核被重载，而少数内核仍然处于空闲状态。

将其称为任何隧道协议的固有问题是否正确？有办法解决这个问题吗？此外，单流可达到的最大吞吐量是多少？我只是在寻找任何硬件的基准数字。您甚至可以在隧道模式下共享IPSec的结果。使用单个IPSec隧道可以实现多少吞吐量，管理员通常如何提高吞吐量？

Answer 1

您描述的问题不是隧道协议的固有问题。相反，它更多地与加密的存在有关，而不是与隧道的存在有关。

ECMP实现在更高的协议层上检查字段的优先级高于它正在操作的级别。例如，在IP层工作的ECMP经常检查UDP和TCP端口号。ECMP实现检查隧道包的内部IP报头中的IP地址也没有什么不同。

但是，由于加密，如果不对数据包进行解密，则不容易获得此信息。而且，在不知道加密密钥的情况下能够区分流通常会被认为是加密算法中的一个安全缺陷。这是需要记住的重要一点，因为您可能需要在性能和安全性之间做出妥协。

我能想到的可能的解决办法包括：

• 在加密时将流标签从内部IP报头复制到外部IP报头。这显然会泄露关于流标签内容的信息。
• 配置多个隧道并跨隧道执行ECMP。连接的发送端上的ECMP实现将尝试在隧道间平均分配通信量。然而，根据交通模式的不同，可能不可能在隧道之间平均分配车辆。这种在隧道中的不均匀分布是有问题的，这不仅是因为它可能导致底层网络的次优使用，而且还因为它泄露了一些关于未加密通信量的特性的信息。但是，在这种情况下，泄漏要比公开内部IP报头的部分要小得多。
• 允许对任意数据包并行解密，但解密后将它们按原来的顺序放回。一个非常简单的实现有一个线程，负责以循环的方式向许多解密线程发送数据包。解密后，另一个线程将从解密线程中以循环方式接收解密后的数据包，并将它们恢复到原来的顺序。只有当您认为所有线程都是单个故障域，并且线程之间的通信不受数据包丢失的影响时，这种方法才是可能的。换句话说，使用这种方法在不同的网络设备之间以循环方式分发数据包是行不通的。
• 解密为中间未加密格式，其中包含未加密的有效负载和IPSec序列号。解密可以并行完成，在此之后，数据包被传递给一个组件，该组件缓冲有限数量的数据包，并试图在最大努力的基础上以原始顺序返回数据包。
• 重新设计更高层的协议，使其对重新排序更加宽容。

Answer 2

不管有没有隧道协议，网络都可能是瓶颈。在某种程度上，背板传输速率无法跟上网络传输速率。通常，所有通信量都通过一个网络接口路由，该接口聚合多个连接。

应该可以并行地对单个流进行加密/解密。除了额外的背板流量外，使用加密的隧道不应该在多个网络流中显着地限制网络思想。

硬件加密加速器可以帮助如果加密开销是一个问题。然而，看起来您确实有足够的CPU，这不应该是一个问题。

如果您的应用程序正在饱和网络链路，则可以将多个接口连接起来以提高吞吐量。您的服务器连接到的交换机将需要支持通道连接。

使用更快的网卡可以帮助，但最终你会达到一个速度，你的背板无法跟上。

网络设备也有容量限制，而且您的需求超过了该容量。在这种情况下，网络基础设施成为瓶颈。

由于内存缓存，在多个CPU之间平衡负载可能是不合理的。如果一个应用程序继续在单个CPU上运行，那么它的运行速度通常会比在不同CPU上频繁调度的情况下运行得更快。