像 GTP 這樣的隧道協議是限制吞吐量的瓶頸嗎？
當使用IPSec（隧道模式）或GTP等隧道協議時，它們會將多個IP流合併到一個流中。由於只有一個流，我們如何擴大吞吐量？分配更多的處理器核心將無濟於事，因為來自一個流的數據包只能到達一個核心。有沒有辦法解決這個問題？就我而言，問題在於 GTP。eNodeB 將來自 UE 的所有 IP 流放入 GTP 隧道中，其中 5 元組將全部相同。由於我們只有 5 到 10 個 eNodeB，這會導致相同數量的 IP 流。因此，核心使用率變得非常不均衡，核心使用率 > 80%，而一些核心使用率 <10%。每個流都由單個核心處理，因此不會有數據包重新排序。由於數千個 IP 流被隧道化為 5 到 10 個 IP 流，
將其稱為任何隧道協議的固有問題是否正確？有什麼辦法可以解決這個問題？此外，單個流可實現的最大吞吐量是多少？我只是在這裡尋找任何硬體上的一些基準數據。您甚至可以在隧道模式下共享 IPSec 的結果。使用單個 IPSec 隧道可以實現多少吞吐量？管理員通常會做什麼來擴大吞吐量？
您描述的問題不是隧道協議的固有問題。相反，它與加密的存在比與隧道更相關。
ECMP 實現優先於檢查高於其操作的協議層的欄位。例如，在 IP 層執行的 ECMP 經常檢查 UDP 和 TCP 埠號。對於 ECMP 實現來說，檢查隧道數據包的內部 IP 標頭中的 IP 地址並沒有什麼不同。
然而，由於加密，此資訊在不解密數據包的情況下不容易獲得。並且能夠在不知道加密密鑰的情況下區分流通常被認為是加密算法中的安全漏洞。這是需要牢記的重要一點，因為您可能必須在性能和安全性之間做出妥協。
我能想到的可能解決方案包括：
- 在加密時將流標籤從內部 IP 標頭複製到外部 IP 標頭。這顯然會洩漏有關流標籤內容的資訊。
- 配置多個隧道並跨隧道執行 ECMP。連接發送端的 ECMP 實現將嘗試將流量均勻地分佈在隧道之間。但是，根據流量模式，可能無法將流量均勻分佈在隧道中。這種跨隧道的不均勻分佈是有問題的，不僅因為它可能導致底層網路的次優利用，而且因為它洩露了一些關於未加密流量特徵的資訊。然而，這種情況下的洩漏將比暴露內部 IP 標頭的部分要小得多。
- 允許並行解密任意數據包，但在解密後將它們放回原始順序。一個非常簡單的實現有一個執行緒負責以循環方式將數據包分派給多個解密執行緒。解密後，另一個執行緒將以循環方式從解密執行緒中提取解密的數據包，將它們恢復到原始順序。
僅當您將所有執行緒視為單個故障域並且執行緒之間的通信不會失去數據包時，這種方法才可能實現。換句話說，使用這種方法在不同的網路設備之間循環分發數據包是行不通的。
- 解密為中間未加密格式，其中包含未加密的有效負載和 IPSec 序列號。解密可以並行完成，然後將數據包傳遞給一個組件，該組件緩衝有限數量的數據包並嘗試盡最大努力以原始順序將數據包帶回。
- 重新設計更高層的協議以更容忍重新排序。