对于复制文件的传输(例如,使用robocopy以任意方向复制文件,或Veeam Backup and Recovery的复制),它们的上限为10Mbps.

升级前：

升级后(robocopy)：

几乎完全相同(忽略转移时间的差异).

传输通过Cisco ASA5520和Mikrotik RB2011UiAS-RM之间的IPSec隧道完成.

初步想法：

> QoS – 不.有QoS规则,但没有一个应该影响这个流程.无论如何我禁用所有规则几分钟检查,没有变化
>软件定义的限制.大部分流量都是异地备份和恢复运输,但没有定义限制.另外,我刚做了一个直的robocopy,看到了完全相同的统计数据.
>硬件无法使用.嗯,5520发布的性能数据是225Mbps的3DES数据,而Mikrotik没有发布数字,但它将超过10Mbps.在进行这些传输测试时,Mikrotik的cpu使用率约为25％-33％. (另外,通过IPSec隧道进行HTTP传输确实接近20Mbps)
>延迟与TCP窗口大小相结合？那么站点之间的延迟是15ms,因此即使是最坏的情况,32 * 0.015的32KB窗口大小也是最大2.1MB /秒.此外,多个并发传输仍然只能达到10Mbps,这不支持这一理论
>也许源头和目的地都是狗屎？那么源可以推动1.6GB /秒的持续顺序读取,所以不是这样.目标可以执行200MB /秒的持续顺序写入,因此也不是这样.

这是一个非常奇怪的情况.我以前从未见过以这种方式表现出来的东西.

我还能在哪儿看？

在进一步调查中,我有信心将IPSec隧道指向问题.我做了一个人为的例子和两个公共IP地址之间没有直接一些测试的网站,然后使用内部IP地址做了完全相同的测试,我能够通过未加密的网络复制20Mbps的,只有10Mbps的上的IPSec侧.

以前的版本有一个关于HTTP的红色鲱鱼.忘记这一点,这是一个错误的测试机制.

根据Xeon的建议并在我向他们寻求支持时我的ISP回应,我已经设置了一个规则来将IPSec数据的MSS丢弃到1422 – based on this calculation：

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,所以无论如何它可能一直在谈判这个问题.

我看到一些我用来测量流量的奇怪数据in the tool inside the Mikrotik.它可能没什么.之前我没有注意到这一点,因为我使用的是过滤后的查询,而我只是在删除过滤器时看到了这一点.