我们最近将一个远程站点从 10/10Mbps 光纤升级为 20/20Mbps 光纤链路（先将光纤连接到地下室，然后从地下室使用 VDSL 连接到办公室，大约 30 米）。此站点与中心站点之间经常会有大型（多千兆）文件复制，因此理论上将链路增加到 20/20 应该可以将传输时间缩短一半。
对于复制文件的传输（例如，用于robocopy在任一方向复制文件，或Veeam Backup and Recovery的复制），它们的速度上限为10Mbps。
升级前：
升级后 ( robocopy)：
几乎相同（忽略传输时间长度的差异）。
传输是通过 Cisco ASA5520 和Mikrotik RB2011UiAS-RM。
首先想到的是：
- QoS - 没有。有 QoS 规则，但没有一个应该影响此流程。我禁用了所有规则几分钟来检查，但没有任何变化
- 软件定义的限制。大部分流量都是 Veeam Backup and Recovery 异地传输的，但其中没有定义限制。此外，我刚刚做了一个直接测试
robocopy，看到了完全相同的统计数据。 - 硬件不支持。5520 公布的性能数据是 3DES 数据 225Mbps，而 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 会话现在在两端协商 MSS 1380（在调整了一些东西并添加了一个缓冲区以防我的数学不好之后。提示：它可能确实如此）。无论如何，1380 也是 ASA 的默认 MSS，所以它可能一直在协商这个。
我看到了一些奇怪的数据在 Mikrotik 内部的工具中我一直用它来测量流量。这可能没什么。我之前没有注意到这一点，因为我使用的是过滤查询，只有当我删除过滤器时我才看到这一点。
答案1
尽管 CPU 是我检查的第三个项目，但我写了以下内容：
进行这些传输测试时，Mikrotik 的 CPU 使用率约为 25%-33%
CPU 图表证实了这一点
我已经通过外部资源（即许多其他支持论坛）确认了这一点和博客) 大多数 Mikrotik 路由器无法使用 3DES 或 AES 加密推送超过 11Mbps 的 IPSec 流量，除非您获得具有硬件加密卸载功能的型号。
所以看起来这只是一个硬件限制。我应该早点发现它，但出于某种原因，Mikrotik 没有向我指出它受到 CPU 限制。
我去购物了。
答案2
我可以确认罪魁祸首是 CPU。 这里我对 Mikrotik RB750GL 进行了基准测试，测得 AES-128 流量为 12 Mb/s（而 3DES 流量仅为 6.0 Mb/s）。
您的结果似乎与我记录的完全一致。