![ssh 在快速连接时偶尔会暂时挂起](https://linux22.com/image/31925/ssh%20%E5%9C%A8%E5%BF%AB%E9%80%9F%E8%BF%9E%E6%8E%A5%E6%97%B6%E5%81%B6%E5%B0%94%E4%BC%9A%E6%9A%82%E6%97%B6%E6%8C%82%E8%B5%B7.png)
我在笔记本电脑上使用 Ubuntu 13.04,连接到家里的路由器。在家工作时,我将通过 VPN、X11 转发 ssh 进入校园服务器。
ssh -X server.address.on.campus
我的连接速度通常约为 40 Mb/s,而且我住的地方只有几英里远,因此终端的响应速度就像我在校园网络上使用 ssh 一样。然而,不同之处在于,来自家庭的连接在恢复之前每隔几分钟就会“挂起”大约 10-15 秒(我在挂起期间进行的所有击键都会清楚地发送,因为挂起后我的屏幕会更新它们) 。悬挂没有明显的图案。当我输入内容时,它通常会发生(或者最明显)。
有谁知道我如何缓解这个问题或可能导致这个问题的原因是什么?在互联网上阅读,有各种 ssh 挂起的问题(通常是永久性的),但没有针对我的具体问题的解决方案。
更新:我仍然有这个问题。正如 @Anthon 所建议的,我继续ping
运行,直到 ssh 再次挂起。我在下面绘制了结果,很清楚临时挂起的位置。几秒钟内没有收到任何数据包,然后快速连续发回约 6 个数据包。
另外:我从未注意到当我在同一台计算机上的 Windows 分区上使用 PuTTY 时发生的问题。
答案1
几秒钟内没有收到任何数据包,然后快速连续发回大约 6 个数据包。
这是两种类似现象的症状:网络拥塞或网络丢弃(通常由于拥塞)。
在第一种情况下,这里和那里之间的路由器有与您的活动无关的流量突发,导致您的流量在某个中间路由器中缓冲。他们会等待轮到他们,直到有可用的带宽来送他们上路。像这样的拥塞可能是由于 YouTube 流量突然激增(新的小猫视频!!!)甚至尝试 SYN_ACK 攻击之类的原因造成的。实际上,恶意攻击的尝试比我们想象的要多得多,因为有大量受感染的机器会自发地向地球上某个地方的随机设备发送流量。尽管 SYN_ACK 和类似的攻击现在在检测后不久就被取消,但即使是检测和取消也可以使路由器忙碌几秒钟。
第二种情况是您的流量到达过载的设备,并且它才不是缓冲流量。要么是因为它没有额外的缓冲存储器,要么是因为缓冲经常会导致其自身的问题。例如,“我已经缓冲了流量,因为一跳的路由器现在太忙了,所以一旦它可用,我就会用我存储的流量来命中它,从而使其过度繁忙......”无限期。在这种情况下,您的 TCP 连接将开始指数退避这将导致您(发送方)的延迟。从历史上看,这是应对突发性互联网的绝佳方法。有一大把这个核心部分的问题传输协议,但没有很好的解决方案。
不幸的是,如果没有 ISP、电信公司和各种系统管理员的热心帮助,这种滞后峰值几乎无法诊断。很可能,因峰值流量而超额订阅的设备位于您完全无法访问的地方,并且其运营商甚至可能不知道它已超载也不关心。
互联网协议的设计目的是尽最大努力交付不保证数据包能够到达目的地。它在从未想象过的负载下仍能正常工作,对我来说,这是一个小小的奇迹。如果您需要比公共互联网所能提供的更好的服务,有人可能会很乐意以任意高的价格向您出售从您到目的地的专用线路。否则,就像高速公路交通或杂货店里随机的超长队列一样,这可能只是现代生活中的不便,您只能忍受。
顺便说一句,物理接近度与拓扑接近度的相关性很低。在闲暇时,试着traceroute destination-host
想想你的流量从这里到那里要经过多少设备。1 公里的传输需要经过 1 兆米和 20 台设备才能到达目的地,这并不罕见。
添加回应评论:
我从来没有注意到当我在同一台计算机上的 Windows 分区上使用 PuTTY 时发生的问题。
您的声明“在 Windows 分区上”是否意味着“在 Windows 上运行”?我假设确实如此。
如果没有更精确的数据,我首先假设您没有注意到它很可能您没有注意到它,但我不确定这一点。另一种假设是,PuTTY 不会出现延迟峰值,因为它显然使用了不同的 SSH 实现。如果您可以像上面的 ping 图表中那样量化延迟峰值的缺失,这将有助于区分网络问题和客户端问题。
为了获得更多传输数据,我会使用 PuTTYscp
在您的计算机和相关主机之间复制大文件。您可以使用线鲨记录数据包间时间。
您的图表中的 ping 测试存在一些缺陷。第一个是 ping 使用 ICMP 数据包,该数据包与 TCP/IP 完全不同,并且通常给予的优先级低于 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()
如果这一点是显而易见的,请原谅我。
你的轶事观察使这个问题变得有趣。它确实需要硬数据才能走得更远。
答案2
如果您还没有尝试过此操作,您可以尝试为您的 ssh 客户端添加保持活动状态。只需添加
ServerAliveInterval 30
某处~/.ssh/config
并重新启动 ssh。
答案3
在不知道实际网络拓扑的情况下,我认为它可能与具有巨型帧的千兆位网络有关。 ssh 不喜欢巨型帧。它针对标准 1500 字节大小的数据包进行了优化,如果数据包大于此大小,它就会变得疯狂。 (例如6000字节)
您可以通过两个都启用巨型帧的工作站在 Intranet 上检查这一点。 (当然,它们之间还有千兆位网络!)
如果您从远处连接到服务器,并且数据包传递不均匀,则可能会发生(取决于网络设置)路由器优化数据包并且服务器将获得巨型帧,并且通信将失败。
您应该检查服务器的配置是否启用了巨型帧。
答案4
我让 ping 继续运行,直到 ssh 再次挂起。几秒钟内没有收到任何数据包,然后快速连续发回约 6 个数据包。
我在 vmware 上有 2 个虚拟服务器。它们都不在 DNS 中。两个虚拟服务器位于同一 ESX 上。腻子冻结到只有一个。 vmware 虚拟机控制台没有冻结。
因此,我从 Windows 客户端 TRACERT 到服务器。机器冻结了,显示早期的 DNS 名称。我只是更改服务器 IP 地址,问题就解决了。