为什么 ssh 的延迟能有 ping 的 3 倍？

[nyxsonsleep]

甲骨云圣何塞的服务器。ssh 打字有延迟，快要到 0.7s 的程度。基本上都是在盲打了。

ssh 192.*.*.*@username 用的 rsa 验证登录的。

ping 出来的延迟在 200ms 左右，丢包 2%。

在 powershell 中登录，然后录屏，利用一个屏幕显示按键的软件结合进行计算延迟，延迟大概在 0.6s 的样子。

用 xshell 连接之后，延迟相同，根据右下的上传下载标志符号进行录像，延迟大致在 0.5s 的样子。

试了用代理登录，延迟基本不变，甚至可能变高了。查看 ssh 日志，登录 ip 已经发生变化。

然后用了 python 的 paramiko 模块进行 ssh 登录，计算延迟，每条指令大概在 0.5-0.7s 之间的样子。都是几乎不消耗资源的指令。

import paramiko
import time
key = paramiko.RSAKey.from_private_key_file(r'C:\Users\username\.ssh\id_rsa')
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('hostname', username='username', pkey=key)

t1=time.time()
# ssh.exec_command('cd ..')
stdin, stdout, stderr = ssh.exec_command('ls -l')
t2=time.time()
print(t2-t1)
print(stdout.readlines())

ssh.close()

usedns no #GSSAPIAuthentication no

[xinleibird]

过墙的机器不要直接 ssh ，ssh 协议不单干扰而且重点关照，丢包劣化就不提了，有可能短暂的封端口，甚至有可能 ip 进狗洞几天。打个隧道，在隧道里登录，或者如楼上找个跳板机登录。

[cnevil]

同意 29#。。
承认自己错了回头学一下不就完事了，到处找补只会显得更蠢，比如网络层级意义何在
tcp 是要保证你或者我一定要收到这个包的，丢了就得重传，重传就涉及到里面的各种计数器什么的，而 icmp 不一样，延时高我都算你丢了，丢了也没什么影响
不管怎么说，基于 tcp 的业务需要多次来回的交互，而且再涉及到封包解包、应用本身处理响应等等环节，应用层的反应一定是比 icmp 看到的数值要慢的，丢不丢包都会慢，丢包只会更甚

[nyxsonsleep]

@cnevil #42
在了解到 ping 不是 tcp 之后我就测试了 tcp ping 的延迟，仍然是 200ms ，所以 icmp 真的就比 tcp 延迟高多少倍吗？

本质上就是我要的是解决问题，但某些人是为了在智力上得到优越感而开始指责别人。

tcp 是 icmp 协议然后呢，解决问题了吗？在#1 后面再回复的除了#1 本人之外十个有九个在歪楼，甚至在贴出 tcp ping 延迟之后依然如此。正如#42

这确实可以被认为是 v 站最低质量的讨论，但有部分人的发言也是最低质量的回复。

#36 用自己的行动来帮助别人解决问题，也拓宽的视野。
#29 用低质量的回复来给低质量的 v 站添砖加瓦？

[nyxsonsleep]

@leaflxh #36 这是我没想到的方面。之后我也抓包看看什么情况。

为了实现回显，每个字符可能都要发一个包。但是整串字符的话就不清楚了。

不确定这个客户端的实现。

[nyxsonsleep]

@nyxsonsleep #43 纠错“所以 icmp 真的就比 tcp 延迟高多少倍吗？”所以 tcp 真的就比 icmp 延迟高多少倍吗？

[nyxsonsleep]

@flyqie #20
这段是我判断的错误的原因 [我的意思是，我根据 HTTP-TCP （ ssh ）-IP 的链路，然后误以为存在 TCP （ ping ）-ICMP 。]

回答：
《网络层都要走传输层的协议？你说反了吧。 不是传输层需要往下走网络层吗。。》
发送消息的阶段是从应用层一层一层向下的，传输层在网络层之上，所以传输层协议—经过—>网络层，传输层的协议要经过网络层<=等价=>网络层要走传输层的协议。 但是 ICMP 这种协议是可以直接从网络层走数据链路层的。

[nyxsonsleep]

@leido #18 icmp 与 ip 同一层。

[nyxsonsleep]

@mrzx #23 确实不是 tcp

[cnevil]

@nyxsonsleep 你并没看明白我的意思，实际的应用体验由于丢包等等原因会更慢
你也只是做了 tcping 一个测试，也没考虑这个结果代表了什么，tcping 也是对网络进行简单的探测，反映了 tcp 建链的情况，跟实际的业务的 RTT 会有差别
解决？所有问题就一定能解决么，再说，你标题也没说解决就是问为什么吧？那我觉得换个香港日本的服务器？换个好点的机房？丢包是跟线路有关系的

[cnbatch]

显然 OP 并不怎么看 V 站的“宽带症候群”节点。

楼上各位已经讲得很详细了，中间线路的不同、运营商的路由配置，关系都不小。

另外，运营商甚至可以针对 TCP 、UDP 、ICMP 作出不同的调整。UDP 就不用多说，各种 QoS 已经是许多人都体会过。

关于 TCP 和 ICMP ，v2ex 曾经就有人发过相关的帖：
《 icmp 和 tcp 的跟踪路由 路径不一样》
/t/749790

《忘记了宽带通有劫持了》
/t/291506
1 楼就直接提到：小运营商为了延时好看可能会让 icmp 走高速线路

《电信移动的 QOS 级别》
/t/341092
2 楼：估计移动给了你假的 qos ，只优化了 icmp 吧。第三层的通信有问题，露馅了。
4 楼：ipsec 协议不同走的路由可能不一样，tcp / udp 可能都不同，你 ping 出来的 icmp 也许没有参考价值。

[cnbatch]

在公网测试 TCP 和 ICMP ，尤其是三大运营商，受到的影响因素实在太多，不仅仅单纯是 TCP 的拥塞算法会影响体验，运营商的配置也会有影响。

[SingeeKing]

17h 过去了，OP 为啥至今不抓个包传个 pcap ？没有实际抓包数据天知道到底是什么原因

[nyxsonsleep]

@cnbatch #50 @cnbatch #50 确实少看，因为平时业务用不上。感谢你的帮助。

不知道你是否了解 ssh 的细节，目前我不能理解的问题是为什么 ssh 会和 tcp 模式的 ping 延迟有那么大的区别。ssh 的数据量很小，不用于翻墙、传输文件等用途，我想还不至于遭到 tcp 拥塞的问题，甚至于稍稍加大 tcp 的数据量延迟也不会有太大的变化。

[cnbatch]

跨墙 SSH 肯定会遇到各种奇奇怪怪的问题的，因为 SSH 早就被墙重点关注过了。
在十几年前，墙还没现在这么精密，利用 SSH 通道爬墙曾经流行过一段时间。就从那时起，SSH 被重点照顾。
换句话说，SSH 早就能被墙识别出来并区别对待了。主要感知就是“限速”。

关于墙相关的话题，“宽带症候群”和“云计算”都会遇得到。
《求助 阿里云国际的香港节点 上传好慢好慢》
/t/448177
6 楼：如果你知道 ssh -D 能做什么，就知道某墙为什么会干扰(故意制造丢包 /限速)这样的 SSH 连接。

《 sftp 跨国传输速度永远只有 1MB/s ，HTTPS 单线程可以轻松稳定跑满 100Mbps 本地带宽，问题出在哪？》
/t/904221
14 楼：SSH 特征太明显，被限速了吧
在此贴的 24 楼，我给出了一段相关的文章介绍，OP 有兴趣的话可以打开看一看

[lambdaq]

1. 应用层传输和回显，比起单独一个 tcp 包去 ping 有更多成本，耗时更高
2. 网关可能单独针对协议进行 QoS
3. ssh 协议本身就是为内网设计的。要说公网效果好的还得是 mosh 。。。。

[zhangsanfeng2012]

因为不是一个 RTT ，是多个 RTT

[nothingistrue]

已经有人手把手解释得那么清楚了，到了 51 楼的时候楼主还在说 「 tcp 模式的 ping 」。看来这要是加上 「 SSH 是应用层协议，不是 TCP 」，楼主会更犟。

[1423]

ssh.exec_command('ls -l')
ssh.exec_command('ls -l')
t1=time.time()
stdin, stdout, stderr = ssh.exec_command('ls -l')

warm 一下好一点，我这里大概是 2x rtt 。但我觉得应该能做到 1x rrt 的

[Pantheoon]

tcp 有端口哇,ping 没有端口,基于 icmp 协议的,不属于 tcp

[Jame00001]

之前用 bitvise 延迟高的飞起，换了其他的完全没有延迟