為什麼我在使用 Site-to-Site VPN 時應用程式會出現延遲和效能問題？

解決方法

如果您在使用 Site-to-Site VPN 存取資源時遇到效能或延遲問題，請依照下列疑難排解步驟：

• 一次隔離一個來源和目標系統。
• 檢查網路路徑，確定是否有可能造成延遲的問題。
• 檢查您的應用程式，確定是否有造成延遲問題的常見錯誤。

隔離您的來源和目標系統

若要緩解內部部署應用程式和 AWS 之間的效能問題，請先隔離來源和目標系統。然後，使用網路工具檢查應用程式外部是否有可能會直接影響效能的遺失和延遲。

1.    變更來源和目標。使用不同的來源，接著再使用不同的目標，並檢查每次變更後是否仍有問題。然後，檢查裝置確定是否有作業系統 (OS) 組態問題或其他問題。

2.    執行 UDP 頻寬功能測試。出現效能問題可能代表出現了輸送量問題，因此請使用 iperf3 工具來檢查佈建的頻寬。雙向執行此測試。下列範例 UDP 測試會使用 iperf3 工具。

注意：****-i 是指間隔、-u 是指 UDP、-b 是指頻寬 (視情況調整)、-p 是指 UDP 端口，而 -v 是指較詳細。

Server: sudo iperf -s -u [-p 5001]
client: sudo iperf3 -i 1 -u -p 33344 -b 1.2G -c <private IP> -V

**注意：**確認您的頻寬積分可用於您正在使用的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。或者，嘗試使用較大的執行個體大小，然後再測試一次。

3.    使用 iperf3 在您的 Site-to-Site VPN 上執行 TCP 輸送量測試。雙向執行此測試。請參閱以下範例：

**注意：**為了獲得最佳效能，增加執行個體大小時，請嘗試使用不同的 TCP 接收視窗大小來測試來源和目標的記憶體緩衝區。

Server : iperf3 -s [-p 5001]
Client:
sudo iperf3 -c <Private IP> -P 10 -w 128K -V
sudo iperf3 -c <Private IP> -P 10 -w 512K -V
sudo iperf3 -c <Private IP> -P 10 -w 1024K -V  

檢查網路路徑是否有問題

檢查網路修補程式，識別造成網路問題的特定躍點或裝置：

• 檢查 Site-to-Site VPN 對等項之間路徑上的封包遺失情況。
• 檢查 Site-to-Site VPN 通道輸送量。
• 檢查客戶閘道路由器組態。
• 檢查路徑的最低 MTU。

檢查 Site-to-Site VPN 對等項之間路徑上的封包遺失情況

您的 Site-to-Site VPN 通道是對等項之間的加密通訊。但是，底層網路可能會造成損失，這會影響加密通訊的品質。封包遺失會增加延遲並直接影響輸送量。

請參閱下列方程式與範例：

Mathis Equation: Throughput = (MSS/RTT)*(1 / sqrt{p}):

Eg. 1375 MSS, 33ms latency, 0.001%= (1375B / 0.033 sec) * (1/𝑠𝑞𝑟𝑡{0.001})=  (41,666.6 * 31.6227)*8 <<< To go from Bps to bps= 10,540,925.5 bps (10.5 Mbps)

輸送量的計算公式是 [TCP 視窗大小 (以位元為單位)] / [延遲 (RTT) (以秒為單位)]。請參閱以下範例：

Eg.  64K in receive Window, 33ms latency= 524288 bits / 0.033 = 15,887,515 = 15.8 Mbps MAX Possible Throughput

若要檢查 Site-to-Site VPN 對等項之間公用路徑上的封包遺失情況，請使用 ICMP 測試 (例如 MTR)。如需 MTR 安裝和使用的詳細資訊，請參閱如何透過網際網路閘道對 VPC 中的 EC2 Linux 或 Windows 執行個體與內部部署主機之間的網路效能問題進行疑難排解？

請參閱以下範例：

**注意：**此範例中的 MTR 輸出包含沒有資料或 100% 損失的值。這表示裝置捨棄 TTL 為 0 的封包，但未回覆超過 ICMP 時間 (類型 11、代碼 0) 訊息。因此，出現這些值並不表示有問題。

 [ec2-user@ip-10-7-10-67 ~]$ sudo mtr --no-dns --report --report-cycles 20 18.189.121.166Start: 2023-04-07T16:28:28+0000HOST: ip-10-7-10-67.ec2.internalr Loss%   Snt   Last   Avg  Best  Wrst StDev  1.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  2.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  3.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  4.|-- 241.0.12.14                0.0%    20    0.4   0.4   0.3   0.8   0.1  5.|-- 240.0.204.2                0.0%    20    0.4   0.4   0.3   0.5   0.0  6.|-- 240.0.204.17               0.0%    20    0.4   0.4   0.3   0.5   0.0  7.|-- 240.0.204.5                0.0%    20    0.4   0.4   0.4   0.5   0.0  8.|-- 242.2.74.145               0.0%    20    1.2   4.0   0.4  23.9   5.7  9.|-- 52.93.29.71                0.0%    20    0.8   2.3   0.7   9.2   2.8 10.|-- 100.100.8.66               0.0%    20   10.8   2.5   0.7  12.8   4.0 11.|-- 100.92.53.85               0.0%    20   26.0  13.3  11.0  26.0   4.4 12.|-- 52.93.239.5                0.0%    20   11.6  12.8  11.4  23.7   2.7 13.|-- 52.95.1.159                0.0%    20   11.0  12.0  11.0  18.3   1.7 14.|-- 52.95.1.186                0.0%    20   11.5  14.1  11.2  32.6   5.9 15.|-- 15.230.39.135              0.0%    20   11.6  11.9  11.1  15.5   1.1 16.|-- 15.230.39.124              0.0%    20   11.7  12.8  11.2  27.2   3.6 17.|-- 108.166.252.38             0.0%    20   11.2  11.2  11.1  11.3   0.0 18.|-- 242.0.102.17               0.0%    20   12.1  12.4  11.2  23.9   2.8 19.|-- 108.166.252.35             0.0%    20   11.3  11.3  11.2  12.3   0.2 20.|-- 241.0.12.207               0.0%    20   11.2  11.3  11.1  13.2   0.5 21.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 22.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 23.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 24.|-- 100.65.30.129              0.0%    20   57.2  24.9  11.6  76.4  17.9 25.|-- 18.189.121.166             0.0%    20   11.3  11.8  11.2  17.6   1.6[ec2-user@ip-10-7-10-67 ~]$

檢查 Site-to-Site VPN 通道輸送量

檢查您的輸送量是否違反了 1.2 Gbps 的限制：

1.    開啟 Amazon CloudWatch 主控台以檢視 Site-to-Site VPN 指標。

2.    針對 TunnelDataIn 和 TunnelDataOut 選擇指標。

3.    在統計數字中，選擇總和，然後在期間中選擇 5 分鐘。

4.    將以下計算套用至峰值時的資料點中。在此等式中，m1 = TunnelDataIn，以及 m2 = TunnelDataOut。

**注意：**如果持續時間內輸送量超過 1.2 Gbps，則使用 ECMP 和傳輸閘道實作兩個 BGP 通道。

(((m1+m2)/300)*8)/1000000

檢查客戶閘道路由器組態

檢查您的客戶閘道裝置是否有下列設定：

• 確定沒有任何限制輸送量的管制或制定政策限制輸送量。
• 重設 IP 封包中的 Don't Fragment (DF) 標記。
• 在加密 IPSec 封包之前，請確定您已將其分段。
• 確認客戶閘道具有 MSS 組態，讓 IP、TCP、UDP 或 ESP 標頭和資料承載不超過 1500 個。請遵循您正在使用的加密演算法的 MTU 準則。如需詳細資訊，請參閱客戶閘道裝置的最佳實務。

檢查路徑的最低 MTU

測試路徑，確保路徑的最低 MTU 符合預期：

若要完成此操作，請以 Ping 偵測 -s 1460 <DESTINATION> -M do：

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1460 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1460(1488) bytes of data.1468 bytes from 1.1.1.1: icmp_seq=1 ttl=51 time=1.06 ms1468 bytes from 1.1.1.1: icmp_seq=2 ttl=51 time=1.04 ms1468 bytes from 1.1.1.1: icmp_seq=3 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=4 ttl=51 time=1.07 ms1468 bytes from 1.1.1.1: icmp_seq=5 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=6 ttl=51 time=1.06 ms

如果沿路徑的裝置無法傳輸有效負載，則會回傳 ICMP 路徑 MTU 超過限制訊息：

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1480 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1480(1508) bytes of data.From 10.7.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500

檢查您的應用程式，確定是否有常見錯誤

檢查內部部署應用程式，確定是否有常見問題：

• 應用程式設定問題。
• 在資料傳輸中使用平行執行緒。如果您觀察的 Site-to-Site VPN 輸送量似乎比預期的慢，請使用平行執行緒來確認應用程式以外的輸送量。
• 實作具有指數退避的重試演算法。如果您在呼叫 AWS 服務時看到逾時，請使用具有指數退避的重試演算法。

相關資訊

Linux 上的增強型網路

AWS VPN 常見問答集