ssh 会在快速连接时偶尔挂起

Mat*_*eck 9 ssh routing remote vpn tcp

我在笔记本电脑上使用 Ubuntu 13.04,连接到家里的路由器。在家工作时,我将通过 vpn SSH 连接到校园内的服务器,并使用 X11 转发。

ssh -X server.address.on.campus
Run Code Online (Sandbox Code Playgroud)

我的连接速度通常约为 40 Mb/s,而且我住在几英里外,因此终端的响应速度就像我在校园网络上使用 ssh 一样。但是,不同之处在于家中的连接在恢复之前每隔几分钟就会“挂起”大约 10-15 秒(我在挂起期间所做的所有按键都清楚地发送,因为我的屏幕在挂起后更新了它们) . 挂起没有明显的模式。当我输入一些东西时,它通常会发生(或最明显)。

有没有人有任何想法我可以如何缓解这个问题或可能导致它的原因?在互联网上阅读,ssh 挂起有各种问题(通常是永久性的),但没有针对我的具体问题的解决方案。

更新:我仍然有这个问题。正如@Anthon 所建议的,我ping一直在运行,直到 ssh 再次挂起。我已经绘制了下面的结果,很清楚临时挂起的位置。在 serval 秒内没有收到任何数据包,然后大约 6 个数据包被快速连续发回。

在此处输入图片说明

另外:我从未注意到在同一台机器上的 Windows 分区上使用 PuTTY 时发生的问题。

msw*_*msw 10

几秒钟内没有收到任何数据包,然后快速连续发回约 6 个数据包。

这是两种相似现象的征兆:网络拥塞或网络丢弃(通常是由于拥塞)。

在第一种情况下,这里和那里之间的路由器有与您的活动无关的流量突发,导致您的流量在某个中间路由器中缓冲。他们将等待轮到他们,直到带宽开放以将他们发送出去。像这样的拥塞可能是由于 YouTube 流量突然激增(新的小猫视频!!!)甚至是尝试 SYN_ACK 攻击之类的事情造成的。在实践中,恶意攻击的企图比我们希望的要多得多,因为有大量受感染的机器会自发地向地球上某处的随机设备发送流量。尽管 SYN_ACK 和类似的攻击现在在检测后不久就被消除了,即使是检测和消除也会使路由器忙碌几秒钟。

第二种情况是您的流量遇到了过载的设备并且它不会缓冲流量。要么是因为它没有额外的缓冲存储器,要么是因为缓冲通常会导致其自身的问题。例如,“我已经缓冲了流量,因为经过一跳的路由器现在太忙,所以一旦它可用,我就会用我存储的流量命中它,从而使其过度忙碌......”无限期。在这种情况下,您的 TCP 连接将开始其指数退避,这将导致您的(发送方)出现延迟。从历史上看,这是应对突发互联网的绝佳方法。还有的大把这个核心部分问题的传输协议,但没有很大的解决方案。

不幸的是,如果没有您的 ISP、电信公司和各种系统管理员的专门帮助,这种延迟峰值几乎不可能被诊断出来。很有可能,由于其高峰流量而超额订阅的设备位于您完全无法访问的地方,其运营商甚至可能不知道它已过载或不在乎。

互联网协议是为尽力交付而设计的,不保证数据包会到达目的地。在我从未想象过的负载下,它的工作效果和它一样好,对我来说,这是一个小奇迹。如果您需要比公共互联网所能提供的更好的服务,有人可能很乐意以任意高价向您出售从您到目的地的专线。否则,就像高速公路交通或杂货店随机排长队一样,这可能只是现代生活的不便,你不得不忍受。

作为旁注,物理邻近度与拓扑邻近度的相关性很差。在一段美好的时光里,试着traceroute destination-host惊叹一下你的流量在这里和那里之间穿越了多少设备。1 公里的传输经过一兆米和 20 台设备才能到达目的地,这并不罕见。

添加以回应评论:

我从未注意到在同一台机器上的 Windows 分区上使用 PuTTY 时发生的问题。

您的声明“在 Windows 分区上”是否意味着“在 Windows 上运行”?我会假设它确实如此。

如果没有更精确的数据,我首先假设您没有注意到它很可能是您没有注意到它,但我不确定这一点。另一种假设是,PuTTY 不会发生延迟峰值,而 PuTTY 显然确实使用了不同的 SSH 实现。如果您可以像在上面的 ping 图中那样量化没有延迟峰值,这将有助于区分网络和客户端问题。

为了获得更多传输数据,我会使用 PuTTYscp在您的机器和相关主机之间复制大文件。您可以使用wireshark来记录数据包间的时间。

您的图表中的 ping 测试存在一些缺陷。第一个是 ping 使用与 TCP/IP 完全不同的 ICMP 数据包,并且其优先级经常低于 IP 流量,并且更有可能被中间路由器丢弃。作为快速检查,这些数据很有用,但如果您想跟踪 TCP/IP 连接,最好使用 IP 数据包,这就是我推荐 scp 的原因。您也可以在 unix 下使用相同的 scp/wireshark 组合进行比较。

ping 测试的另一个问题是 60 秒太短,无法很好地了解周期性行为。由于您手头似乎已经有了总结工具,因此 10 分钟比 1 分钟要好,1 小时还要好。

测试时,我会改变我在机器之间传递的数据。这是一个非常快速和肮脏的脚本,用于生成具有很多熵但几乎没有熵的文件:

#!/usr/bin/env python2.7

import random

def data_bytes(outf, ordered=False):
    """write a series of ordered or random octets to outf"""
    for block in range(1024):
        for char in range(1024):
            if ordered:
                c = char % 0x100
            else:
                c = random.randint(0, 0xff)
            outf.write(chr(c))

def main():
    with open('random.dat', 'wb') as outf:
        data_bytes(outf, ordered=False)
    with open('sequen.dat', 'wb') as outf:
        data_bytes(outf, ordered=True)

if __name__ == '__main__':
    main()
Run Code Online (Sandbox Code Playgroud)

如果这一点很明显,请原谅我。

你的轶事观察使这是一个有趣的问题。它确实需要硬数据才能走得更远。