我们最近将一个远程站点从10 / 10Mbps光纤升级到20 / 20Mbps光纤链路（从光纤到地下室，然后从VDSL从地下室到办公室，大约30米）。在此站点和中心站点之间有规则的大文件副本（多gig），因此从理论上讲，将链接增加到20/20应该可以使传输时间缩短一半。
对于用于复制文件的传输（例如robocopy用于双向复制文件或Veeam Backup and Recovery的复制），传输速度上限为10Mbps。
升级前：
升级后（robocopy）：
几乎相同（忽略传输时间长度的差异）。
传输通过Cisco ASA5520和Mikrotik RB2011UiAS-RM之间的IPSec隧道进行。
首先的想法：
- QoS-不。有QoS规则，但没有一个规则会影响此流程。我禁用了所有规则几分钟后仍然无法检查，也没有任何更改
- 软件定义的限制。其中大部分流量是通过Veeam Backup and Recovery现场交付的，但其中没有定义任何限制。另外，我只是进行了一次平直的比赛
robocopy，看到的统计数据完全相同。 - 硬件无法使用。嗯，一台5520的已发布性能数据是3DES数据为225Mbps，而Mikrotik并没有发布数字，但它将超过10Mbps。在进行这些传输测试时，Mikrotik的CPU使用率约为25％-33％。（此外，通过IPSec隧道进行HTTP传输确实达到了接近20Mbps的速度）
- 延迟与TCP窗口大小相结合？站点之间的延迟为15
32*0.015毫秒，因此，即使是最坏的情况，32 KB窗口大小的最大值也最多为2.1 MB /秒。此外，多个并发传输仍只能达到10Mbps，不支持该理论 - 也许源头和目的地都是狗屎？好了，该源可以推动1.6GB /秒的持续顺序读取，所以不是那样。目标可以执行200MB /秒的连续顺序写入，因此也不是。
这是一个非常奇怪的情况。我以前从未见过如此明显的表现。
我还能去哪里？
在进一步调查中，我有信心指出IPSec隧道是问题所在。我做了一个人为的示例，并在站点上的两个公共IP地址之间直接进行了一些测试，然后使用内部IP地址进行了完全相同的测试，并且我能够在未加密的Internet上复制20Mbps，在IPSec上仅复制10Mbps侧。
以前的版本在HTTP方面有一些麻烦。忘了这个，这是一个错误的测试机制。
根据Xeon的建议，并在我要求ISP支持时由我的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内部的工具中看到一些奇怪的数据，这些数据一直用于衡量流量。可能什么都没有。我之前使用过滤查询时没有注意到这一点，并且只有在删除过滤器后才看到此消息。
1394是我能够通过的最大MTU。
