为什么SSH / SFTP失败的命令具有较大的回报?

我们有一个SFTP服务器工作正常,直到我们添加了另一个ISP。 到SFTP服务器的连接没有经过新的ISP,我用tracert确认了它。 服务器上也没有改变。 但是从那以后,如果执行的命令有较大的回报,一些用户的SFTP或者SSH连接超时/挂起。 这是一个场景:

  1. 我可以继续ping,即使SSH / SFTP超时,ping也会一直返回
  2. 我可以连接到服务器,它要求authentication,让我login。
  3. 如果我的根目录的ls命令正在返回less量的文件或文件夹,则会显示文件和文件夹的列表
  4. 如果我的根目录的ls命令大于5或6个文件或文件夹,那么它挂起/超时。
  5. 在尝试这样做的时候,我尝试了对服务器运行一个ping,并且它一直在返回。
  6. 这不会发生在每个人身上,但似乎发生在另一个城市的用户身上。

  7. 我尝试了不同的SFTP客户端(FileZilla和WinSCP)。 两者都有同样的问题。

我在我的PC上运行WireShark(在我们的networking之外,在城市之外),当SFTP / SSH超时的时候,我看到重传和部分段没有捕获到错误,这使我相信可能有一些数据包在啤酒花之间的某处丢失。

 Expert Info (Note/Sequence): Retransmission (suspected) Previous segment not captured (common at capture start) 

SFTP / SSH是否对数据包丢失敏感? SSH / SFTP不会重传/重传,以避免这些丢包错误? 有什么服务器设置,我可以调整,以使这项工作?

我相信这位评论者头痛目眩,这是一个MTU问题的典型例子(并且pathMTU没有正确地检测到那个失败的特定path所需的较小MTU)。 您应该检查发生故障的path中的中间设备是否正确地允许MTUpath发现数据包通过,并且没有任何中间路由器具有不必要的小MTU。 你可以通过发送大的icmp包到MTU的大小来逐步缩小它的范围,从而发现它失败的地方(尽pipe这并不总是奏效)。