我们最近将一个远程站点从 10/10Mbps 光纤升级为 20/20Mbps 光纤链路（光纤到地下室，然后是 VDSL 从地下室到办公室，大约 30 米）。此站点和中央站点之间存在常规的大型（多 gig）文件副本，因此理论上将链接增加到 20/20 应该可以将传输时间大致减半。
对于复制文件的传输（例如，robocopy用于在任一方向复制文件，或 Veeam Backup and Recovery 的复制），它们的上限为 10Mbps。
升级前：
升级后（robocopy）：
几乎相同（忽略传输时间长度的差异）。
传输是通过 Cisco ASA5520 和Mikrotik RB2011UiAS-RM之间的 IPSec 隧道完成的。
第一个想法：
- 服务质量 - 不。有 QoS 规则，但没有应该影响此流的规则。无论如何，我禁用了所有规则几分钟来检查，没有任何变化
- 软件定义的限制。大部分流量是 Veeam Backup and Recovery 异地运输，但其中没有定义限制。此外，我只是做了一个直线
robocopy，看到了完全相同的统计数据。 - 硬件能力不行。嗯，5520 公布的性能数据是 225Mbps 的 3DES 数据，而 Mikrotik 没有公布数据，但它会超过 10Mbps。在进行这些传输测试时，Mikrotik 的 CPU 使用率约为 25%-33%。（此外，通过 IPSec 隧道进行 HTTP 传输的速度确实接近 20Mbps）
- 延迟与 TCP 窗口大小相结合？好吧，站点之间的延迟为 15 毫秒，因此即使在最坏的情况下 32KB 窗口大小
32*0.015也是最大 2.1MB/秒。此外，多个并发传输仍然只是加起来 10Mbps，这不支持这个理论 - 也许来源和目的地都是狗屎？好吧，源可以推动 1.6GB/秒的持续顺序读取，所以不是这样。目标可以执行 200MB/秒的持续顺序写入，所以也不是这样。
这是一个非常奇怪的情况。我以前从未见过任何东西以这种方式表现出来。
我还能在哪里看？
在进一步调查中，我有信心指出 IPSec 隧道是问题所在。我做了一个人为的例子，直接在站点上的两个公共 IP 地址之间进行了一些测试，然后使用内部 IP 地址进行了完全相同的测试，我能够在未加密的互联网上复制 20Mbps，而在 IPSec 上只有 10Mbps边。
以前的版本有关于 HTTP 的红鲱鱼。忘记这一点，这是一个错误的测试机制。
根据 Xeon 的建议和我的 ISP 在我向他们寻求支持时的回应，我设置了一个 mangle 规则，将 IPSec 数据的 MSS 降至 1422 -基于此计算：
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
适合 ISP 的 1480 MTU。但这并没有产生任何有效的影响。
在比较了wireshark捕获之后，TCP会话现在在两端协商了一个1380的MSS（在调整了一些东西并添加了一个缓冲区以防我的数学很糟糕。提示：它可能会这样做）。无论如何，1380 也是 ASA 的默认 MSS，因此它可能一直在协商这个问题。
我在 Mikrotik 内的工具中看到一些奇怪的数据，我一直在使用这些数据来测量流量。可能什么都不是。我之前没有注意到这一点，因为我使用的是过滤查询，我只在删除过滤器时才看到这一点。
即使 CPU 是我检查的第三件事，我还是写了这个：
CPU图证实了这一点
我已经通过外部资源（即一堆其他支持论坛和博客）确认大多数 Mikrotik 路由器不能通过 3DES 或 AES 加密推送超过 11Mbps 的 IPSec 流量，除非你得到一个具有硬件加密卸载的模型.
所以看起来这只是一个硬件限制。我应该早点发现它，但由于某种原因，Mikrotik 没有向我表明它受 CPU 限制。
我去购物。
我可以确认罪魁祸首是CPU。 在这里，我对 Mikrotik RB750GL 进行了基准测试，并在 AES-128 流量下测量了 12 Mb/s（在 3DES 下仅为 6.0 Mb/s）。
您的结果似乎与我记录的完全一致。