为什么 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

ping 是 icmp 协议，不过似乎并不影响这里的结果？


sudo tcptraceroute -n hostip port
Selected device ens33, address 192.168.233.133, port 57767 for outgoing packets
Tracing the path to hostip on TCP port port, 30 hops max
1 192.168.233.2 0.169 ms 0.292 ms 0.168 ms
2 hostip [open] 199.087 ms 215.821 ms 219.983 ms

第二行的延迟应该不至于是 3 个加起来吧。

[weiqk]

丢包 2%，能连上算你运气不错了，ssh 是 tcp 协议，有握手机制

顺便提一嘴，做任何互联网的程序，都必须模拟 2%丢包正常使用才算合格

[nyxsonsleep]

@weiqk #1 ping 也是 tcp 协议，那么为什么 ping 是 200ms ，ssh 是 600ms 呢？

[mieq]

@nyxsonsleep ping 是 tcp ？你先查查吧

[yyzh]

延迟不重要，丢包是最为致命的

[blankmiss]

@nyxsonsleep 那 icmp 协议是什么

[ncepuzs]

@nyxsonsleep 计网怎么学的

[proxychains]

@nyxsonsleep ping 是 tcp ！

[ixiumu]

tcp udp icmp 是同级 都属于 tcp/ip
但是 ping 不是 op 理解的 tcp

[tool2d]

我 ssh 也卡，后来发现可以用代理，速度就好一些了。

[totoro52]

@mieq Ping 是工作在 TCP/IP 网络体系结构中 应用层 的一个服务命令， 主要是向特定的目的主机发送 ICMP （ Internet Control Message Protocol 因特网报文控制协议） Echo 请求报文，测试目的站是否可达及了解其有关状态

[nyxsonsleep]

@tool2d #9 我用代理似乎没效果。是这条指令吗，我看服务器的 ssh 登录日志里 ip 信息已经发生变化了。但是延迟没有改变。
ssh -o ProxyCommand="nc -X 5 -x localhost:7890 %h %p" username@cloudhost

[akira]

单程 200 ，来回 400 ，测出来 500 左右，这没啥问题啊。。

[HeyEvan]

试试 Cloudflare 的 Zero Trust ，作为备用方案

[weiqk]

@nyxsonsleep ip 和 icmp(ping)工作在网络层，udp 和 tcp 工作在传输层，除了 tcp 外另外三个是无状态不可靠协议，tcp 是可靠协议，有重传机制，所以你网络有丢包会特别慢


@akira icmp 没有时间戳，我猜 ping 的时间是往返时间，如果有时间戳两台机器时间不同步似乎要悲剧

[bao3]

居然有人说 Ping 是 tcp…… 自己拿 tcpdump 抓一下 ping 包，2 秒钟就验证出对错了……

[nyxsonsleep]

@akira #12 可以了解一下什么是 RTT

[nyxsonsleep]

@ncepuzs #6 我记得 icmp 在 ip 层，就是 tcp/udp 的下层。既然 ip 走的 tcp/udp ，那我就记成网络层都要走传输层的协议，不然这个网络层级的意义何在。。。谁知道这个 icmp 还要单独走。

[leido]

@nyxsonsleep icmp 和 tcp 同一层的

[leaflxh]

可以试试 tcping

[flyqie]

@nyxsonsleep #17

网络层都要走传输层的协议？你说反了吧。

不是传输层需要往下走网络层吗。。

tcp/ip 一共有四层，osi 有七层，无论在哪个模型里 icmp 都跟 ip 是同一层(网络 /网际)啊。。

[Soo0]

ping 和 tcp 有的时候走的路径都不一样，tcping 看看 丢包 延迟高 受不了找个代理或者中转吧

[kokutou]

装个 mosh 。。。

[mrzx]

@nyxsonsleep 你确定 ping 是 tcp 协议？明明是 ICMP

我是网络专业的出生，别骗我。

网络最大的危害不是延迟，也不是丢高，而是网络抖动

而且很多 VPS 提供商，对 ping 做了单独特殊 qos 优化(让你感觉延迟不高,无抖动，不丢包)。。。而对任何 TCP 协议进行流量整形。

[mrzx]

19 楼的哥们是对的，用 tcping 就立刻得知真相了。

[salmon5]

ssh https 应该都有干扰

[feedcode]

1 楼已经给了答案了，了解下
https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment
https://news.ycombinator.com/item?id=34179426
以及 tcp_autocorking (default true)
ssh 在交互状态下会关掉 Nagle’s algorithm ，但是你的代理默认不会关，所以延迟会增加

[feedcode]

https://news.ycombinator.com/item?id=9048947

[dayudayupao]

@weiqk 丢包 tcp 不是有自动重发功能吗，也没有不合格吧，有点危言耸听的感觉，想听听你更详细的见解，纯交流

[tmux123]

不得不说这是 v2 上见过的最低质量的讨论……

[nyxsonsleep]

@leaflxh #19 依然是 200ms 的延迟


sudo hping3 -c 4 -S -p port hostip
HPING hostip (ens33 hostip): S set, 40 headers + 0 data bytes
len=46 ip=hostip ttl=128 id=19791 sport=port flags=SA seq=0 win=64240 rtt=192.4 ms
len=46 ip=hostip ttl=128 id=19792 sport=port flags=SA seq=1 win=64240 rtt=215.1 ms
len=46 ip=hostip ttl=128 id=19793 sport=port flags=SA seq=2 win=64240 rtt=190.0 ms
len=46 ip=hostip ttl=128 id=19794 sport=port flags=SA seq=3 win=64240 rtt=197.9 ms

[nyxsonsleep]

@mrzx #24

依然是 200ms 的延迟


sudo hping3 -c 4 -S -p port hostip
HPING hostip (ens33 hostip): S set, 40 headers + 0 data bytes
len=46 ip=hostip ttl=128 id=19791 sport=port flags=SA seq=0 win=64240 rtt=192.4 ms
len=46 ip=hostip ttl=128 id=19792 sport=port flags=SA seq=1 win=64240 rtt=215.1 ms
len=46 ip=hostip ttl=128 id=19793 sport=port flags=SA seq=2 win=64240 rtt=190.0 ms
len=46 ip=hostip ttl=128 id=19794 sport=port flags=SA seq=3 win=64240 rtt=197.9 ms

[nyxsonsleep]

@kokutou #22 装了 mosh ，udp 延迟似乎低一些？体验接近正常了。

不过为什么命令提示符号之前的部分有时候能被删掉，然后又重新显示出来，这正常吗？

[nyxsonsleep]

@Soo0 #21 依然是 200ms 的延迟


sudo hping3 -c 4 -S -p port hostip
HPING hostip (ens33 hostip): S set, 40 headers + 0 data bytes
len=46 ip=hostip ttl=128 id=19791 sport=port flags=SA seq=0 win=64240 rtt=192.4 ms
len=46 ip=hostip ttl=128 id=19792 sport=port flags=SA seq=1 win=64240 rtt=215.1 ms
len=46 ip=hostip ttl=128 id=19793 sport=port flags=SA seq=2 win=64240 rtt=190.0 ms
len=46 ip=hostip ttl=128 id=19794 sport=port flags=SA seq=3 win=64240 rtt=197.9 ms

[nyxsonsleep]

@Soo0 #21 问下如果架设成一个网站再套在 cfcdn 能加速 ssh 吗？（不了解这方面）

[nyxsonsleep]

@salmon5 #25 应该和 https 没什么关系吧

[leaflxh]

可能一条命令回显的耗时不仅需要一个 RTT

尝试抓了下包，发现一条命令执行的时候会有好几个 TCP 包

ssh.exec_command('ls -l')
ssh.exec_command('ls -l')
ssh.exec_command('ls -l')
ssh.exec_command('ls -l')
ssh.exec_command('ls -l')

#方便抓包，设置 sleep
print("wating...")
time.sleep(5)
t1=time.time()
ssh.exec_command('echo dick')
t2=time.time()
print(t2-t1)
time.sleep(5)

ssh.close()

输出 0.358 秒，服务器 ping 延迟在 180ms 左右

[Actrace]

主要是怕丢包。不丢包的情况下，实际的延迟应该还行。丢一个包翻倍，基本没得玩。
话说这种情况可以用微林的服务来改善的。

[Masoud2023]

海外机子别指望有什么正常的 SSH 体验了，基本 GFW 都在干扰。我韩国日本甲骨文，ping 也就 100 上下，ssh 上去要么卡死要么几秒断，导致我现在只能拿美国机器当跳板连上去，能 ping 通只代表这个链路可能是通的，不代表上层协议没有被重点关照。

[AreYou0k]

@weiqk #1 顺便问一嘴, 怎么模拟 2%丢包啊.

[nyxsonsleep]

@weiqk #14 用 hping 尝试了一下 tcp 的延迟，依然是 200ms 的延迟

sudo hping3 -c 4 -S -p port hostip
HPING hostip (ens33 hostip): S set, 40 headers + 0 data bytes
len=46 ip=hostip ttl=128 id=19791 sport=port flags=SA seq=0 win=64240 rtt=192.4 ms
len=46 ip=hostip ttl=128 id=19792 sport=port flags=SA seq=1 win=64240 rtt=215.1 ms
len=46 ip=hostip ttl=128 id=19793 sport=port flags=SA seq=2 win=64240 rtt=190.0 ms
len=46 ip=hostip ttl=128 id=19794 sport=port flags=SA seq=3 win=64240 rtt=197.9 ms

[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 延迟高的飞起，换了其他的完全没有延迟

[1423]

似乎猜到原因了。。OP 自己证实下吧
exec_command 太重了，想低延迟应该考虑 invoke_shell ，自己在 channel 做读写

[ljsh093]

@proxychains #7 你这个叹号是认真的吗

[nyxsonsleep]

@nothingistrue #57 了解一下 tcping 和 ping 的区别行吗？还有 udp 的 ping 呢。。。

[nyxsonsleep]

@Pantheoon #59 我认为我贴文很清楚了。
但似乎有人还是没搞懂：
1. ssh 是 tcp ，ping 是 icmp 。 [我说 ping 是 tcp 是错的]
2. 有一些工具通过一些方法实现了 tcp 或者 udp 连接的 ping 工具，比如 tcping 、hping3 。

[nyxsonsleep]

@zhangsanfeng2012 #56 这是我没有考虑到的问题，有相关的资料吗。非常感谢。

[1423]

测了下猜想正确，是一个 rtt

[nyxsonsleep]

@lambdaq #55
1. 我特意做了 hping3 、tcping 、WinMTR 的测试，这三个软件都是可以用 tcp 协议进行延迟测试的，所以我将其称之为了 [tcp 的 ping 延迟] ，但以 tcp 协议和 icmp 协议来说他们的延迟差距不大。 [但是确实有可能是因为回显导致的延迟问题。]

[nyxsonsleep]

@SingeeKing #52 已上传 base64：aHR0cHM6Ly93d3cud2Vuc2h1c2h1LmNuL2YvYmJyNGV4MGpzbGY=

[cnbatch]

想要准确测试 SSH 的 RTT 带来的延时，最好在无干扰的情况下测试，比如纯内网。
哪怕是跨国内网也行（专线更佳），都比公网直接测好得多。

[nyxsonsleep]

@1423 #66 能给完整代码吗？谢谢。

[nyxsonsleep]

@lambdaq #55 3. 关于 mosh 我想问一下，如果打一连串指令再删除的时候，有时候会删掉命令提示符（类似： username@machinename$这部分）的部分内容，然后再回显重新回显显示出来，这个是 mosh 的特性吗？还是配置不对，或者是网络原因。

[Greatshu]

谢希仁的《计算机网络》，点击章节目录可以下载 PPT
https://yx.51zhy.cn/net.jsp

Windows 下更推荐 psping ，udp ，tcp ，icmp 都支持
https://learn.microsoft.com/zh-cn/sysinternals/downloads/psping

[lambdaq]

@nyxsonsleep 我没仔细研究。它号称有优化，那么肯定相比 ssh 有它的独到之处。用就完事了。

[nyxsonsleep]

@cnbatch #54 非常感谢，提到这么多信息之后，我想确实有可能是被 gfw 干扰了。

[lambdaq]

@nyxsonsleep 它提到一个优化点。比如你 cat xxx 结果是一个 10G 的日志，发现一直不停输出，你按下 Ctrl+C 没反应。ssh 得等到 10G 文本传输展示完毕了，才会响应你的 Ctrl+C 。

mosh 的处理方式不同，它可以立刻响应。

[ncepuzs]

居然这么多楼了……
1. 本地代理
2. 跳板机
3. Cloudflare Access https://developers.cloudflare.com/cloudflare-one/identity/users/short-lived-certificates/

[zhangsanfeng2012]

@nyxsonsleep

```python
import paramiko
import time

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('hostip', username='user', password="passwd")

# get shell
shell= ssh.invoke_shell()
# read all banner
time.sleep(2)
shell.recv(9999)

t1=time.time()
shell.send("l")
print(shell.recv(1))
t2 = time.time()
print(t2-t1)
ssh.close()
```

[weiqk]

@AreYou0k

>> 顺便问一嘴, 怎么模拟 2%丢包啊.
放狗：Linux 模拟丢包