当使用隧道协议（例如 IPSec（隧道模式）或 GTP）时，它们会将多个 IP 流放入一个流中。由于只有一个流，我们如何扩大吞吐量？分配更多处理器核心不会有帮助，因为来自一个流的数据包只能进入一个核心。有没有什么办法可以解决这个问题？就我而言，问题出在 GTP 上。eNodeB 将来自 UE 的所有 IP 流放入 GTP 隧道中，该隧道的 5 元组将全部相同。由于我们只有 5 到 10 个 eNodeB，因此 IP 流数量相同。因此，核心利用率变得非常不均衡，一些核心的利用率 >80%，而一些核心的使用率 <10%。每个流都由一个核心处理，因此不会出现数据包重新排序。由于数千个 IP 流被隧道化为仅 5 到 10 个 IP 流，RSS 哈希函数的随机性不知何故变得不均衡，导致一些核心过载，而少数核心仍然处于空闲状态。
将其称为任何隧道协议的固有问题是否正确？有什么办法可以解决这个问题？另外，单个流可以实现的最大吞吐量是多少？我只是在这里寻找任何硬件上的一些基准数据。您甚至可以分享隧道模式下 IPSec 的结果。使用单个 IPSec 隧道可以实现多少吞吐量，管理员通常会做什么来扩大吞吐量？
答案1
您所描述的问题不是隧道协议的固有问题。它与加密的存在关系比与隧道的关系更大。
ECMP 实现检查比其运行的更高协议层的字段具有优先权。例如，在 IP 层运行的 ECMP 通常会检查 UDP 和 TCP 端口号。ECMP 实现检查隧道数据包内部 IP 标头中的 IP 地址也没什么不同。
然而，由于加密，如果不解密数据包，这些信息就无法轻易获得。而且，在不知道加密密钥的情况下区分流通常被认为是加密算法的安全漏洞。这是需要牢记的一点，因为您可能必须在性能和安全性之间做出妥协。
我能想到的可能的解决方案包括：
在加密时将流标签从内部 IP 报头复制到外部 IP 报头。这显然会泄露有关流标签内容的信息。
配置多个隧道并在隧道间执行 ECMP。连接发送端的 ECMP 实现将尝试在隧道间均匀分布流量。但是，根据流量模式，可能无法在隧道间均匀分布流量。隧道间不均匀分布不仅会造成底层网络利用率不理想，还会泄露一些有关未加密流量特征的信息。但是，在这种情况下，泄露比暴露部分内部 IP 标头要小得多。
允许并行解密任意数据包，但在解密后将其恢复到原始顺序。一个非常简单的实现是，一个线程负责以循环方式将数据包分派到多个解密线程。解密后，另一个线程将从解密线程中以循环方式拾取解密的数据包，并将它们恢复到原始顺序。
仅当您将所有线程视为单个故障域并且线程之间的通信不受数据包丢失的影响时，此方法才可行。换句话说，使用此方法在不同网络设备之间循环分发数据包是行不通的。
解密为中间未加密格式，其中包含未加密的有效负载和 IPSec 序列号。解密可以并行进行，之后数据包将传递到缓冲有限数量数据包的组件，并尽力尝试将数据包恢复到原始顺序。
重新设计高层协议，使其对重新排序更加宽容。
答案2
无论有没有隧道协议，网络都可能成为瓶颈。在某些时候，背板传输速率无法跟上网络传输速率。通常，所有流量都通过单个网络接口路由，从而聚合多个连接。
应该可以并行加密/解密各个流。除了额外的背板流量外，使用加密隧道不会因多个网络流而显著限制网络吞吐量。
如果加密开销是个问题，硬件加密加速器可以提供帮助。不过，看来您的 CPU 足够，这应该不是问题。
如果您的应用程序占用了网络链路，则可能需要绑定多个接口来提高吞吐量。您的服务器所连接的交换机需要支持通道绑定。
使用更快的网卡可能会有所帮助，但最终您将达到背板无法跟上的速度。
网络设备也有容量限制，而您的需求超出了容量。在这种情况下，您的网络基础设施就成了瓶颈。
由于内存缓存，在多个 CPU 之间均衡负载可能毫无意义。如果应用程序持续在单个 CPU 上运行，其运行速度通常会比频繁在不同 CPU 上调度运行更快。