当我使用 Site-to-Site VPN 时,为什么我的应用程序会出现延迟和性能问题?

4 分钟阅读
0

当我使用 AWS Site-to-Site VPN 访问 AWS 中的资源时,我的本地应用程序出现延迟问题。

解决方法

如果您在使用 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.    选择 TunnelDataInTunnelDataOut 的指标。

3.    对于统计数据,选择总和,然后为周期选择 5 分钟

4.    将以下计算应用于处于峰值的数据点。在这个等式中,m1 = TunnelDataInm2 = TunnelDataOut

**注意:**如果吞吐量持续超过 1.2 Gbps,则使用 ECMP 和中转网关实施两个 BGP 隧道。

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

检查您的客户网关路由器配置

检查您的客户网关设备是否有以下配置:

  • 确保不存在限制吞吐量的监管或调整策略。
  • 重置 IP 数据包中的“不分段”(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 常见问题

AWS 官方
AWS 官方已更新 1 年前