甲骨云圣何塞的服务器。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
1
weiqk 2023-05-28 22:43:19 +08:00
丢包 2%,能连上算你运气不错了,ssh 是 tcp 协议,有握手机制
顺便提一嘴,做任何互联网的程序,都必须模拟 2%丢包正常使用才算合格 |
2
nyxsonsleep OP @weiqk #1 ping 也是 tcp 协议,那么为什么 ping 是 200ms ,ssh 是 600ms 呢?
|
3
mieq 2023-05-28 22:53:19 +08:00 via iPhone 2
@nyxsonsleep ping 是 tcp ?你先查查吧
|
4
yyzh 2023-05-28 22:55:22 +08:00 via Android
延迟不重要,丢包是最为致命的
|
5
blankmiss 2023-05-28 23:10:43 +08:00
@nyxsonsleep 那 icmp 协议是什么
|
6
ncepuzs 2023-05-28 23:16:06 +08:00
@nyxsonsleep 计网怎么学的
|
7
proxychains 2023-05-28 23:16:54 +08:00 via Android 3
@nyxsonsleep ping 是 tcp !
|
8
ixiumu 2023-05-28 23:35:45 +08:00
tcp udp icmp 是同级 都属于 tcp/ip
但是 ping 不是 op 理解的 tcp |
9
tool2d 2023-05-28 23:37:14 +08:00 via Android
我 ssh 也卡,后来发现可以用代理,速度就好一些了。
|
10
totoro52 2023-05-28 23:54:27 +08:00
@mieq Ping 是工作在 TCP/IP 网络体系结构中 应用层 的一个服务命令, 主要是向特定的目的主机发送 ICMP ( Internet Control Message Protocol 因特网报文控制协议) Echo 请求报文,测试目的站是否可达及了解其有关状态
|
11
nyxsonsleep OP @tool2d #9 我用代理似乎没效果。是这条指令吗,我看服务器的 ssh 登录日志里 ip 信息已经发生变化了。但是延迟没有改变。
ssh -o ProxyCommand="nc -X 5 -x localhost:7890 %h %p" username@cloudhost |
12
akira 2023-05-29 00:21:59 +08:00
单程 200 ,来回 400 ,测出来 500 左右,这没啥问题啊。。
|
13
HeyEvan 2023-05-29 00:52:07 +08:00
试试 Cloudflare 的 Zero Trust ,作为备用方案
|
14
weiqk 2023-05-29 00:59:04 +08:00 2
@nyxsonsleep ip 和 icmp(ping)工作在网络层,udp 和 tcp 工作在传输层,除了 tcp 外另外三个是无状态不可靠协议,tcp 是可靠协议,有重传机制,所以你网络有丢包会特别慢
@akira icmp 没有时间戳,我猜 ping 的时间是往返时间,如果有时间戳两台机器时间不同步似乎要悲剧 |
15
bao3 2023-05-29 01:21:10 +08:00
居然有人说 Ping 是 tcp…… 自己拿 tcpdump 抓一下 ping 包,2 秒钟就验证出对错了……
|
16
nyxsonsleep OP @akira #12 可以了解一下什么是 RTT
|
17
nyxsonsleep OP @ncepuzs #6 我记得 icmp 在 ip 层,就是 tcp/udp 的下层。既然 ip 走的 tcp/udp ,那我就记成网络层都要走传输层的协议,不然这个网络层级的意义何在。。。谁知道这个 icmp 还要单独走。
|
18
leido 2023-05-29 01:37:21 +08:00
@nyxsonsleep icmp 和 tcp 同一层的
|
19
leaflxh 2023-05-29 01:37:42 +08:00 via Android
可以试试 tcping
|
20
flyqie 2023-05-29 02:32:22 +08:00 via Android
@nyxsonsleep #17
网络层都要走传输层的协议?你说反了吧。 不是传输层需要往下走网络层吗。。 tcp/ip 一共有四层,osi 有七层,无论在哪个模型里 icmp 都跟 ip 是同一层(网络 /网际)啊。。 |
21
Soo0 2023-05-29 02:41:45 +08:00 via iPhone 1
ping 和 tcp 有的时候走的路径都不一样,tcping 看看 丢包 延迟高 受不了找个代理或者中转吧
|
22
kokutou 2023-05-29 07:31:38 +08:00 via Android
装个 mosh 。。。
|
23
mrzx 2023-05-29 08:52:31 +08:00 1
@nyxsonsleep 你确定 ping 是 tcp 协议?明明是 ICMP
我是网络专业的出生,别骗我。 网络最大的危害不是延迟,也不是丢高,而是网络抖动 而且很多 VPS 提供商,对 ping 做了单独特殊 qos 优化(让你感觉延迟不高,无抖动,不丢包)。。。而对任何 TCP 协议进行流量整形。 |
24
mrzx 2023-05-29 08:53:42 +08:00
19 楼的哥们是对的,用 tcping 就立刻得知真相了。
|
25
salmon5 2023-05-29 10:38:15 +08:00
ssh https 应该都有干扰
|
26
feedcode 2023-05-29 11:12:18 +08:00 1
1 楼已经给了答案了,了解下
https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment https://news.ycombinator.com/item?id=34179426 以及 tcp_autocorking (default true) ssh 在交互状态下会关掉 Nagle’s algorithm ,但是你的代理默认不会关,所以延迟会增加 |
27
feedcode 2023-05-29 11:14:38 +08:00
|
28
dayudayupao 2023-05-29 11:18:42 +08:00
@weiqk 丢包 tcp 不是有自动重发功能吗,也没有不合格吧,有点危言耸听的感觉,想听听你更详细的见解,纯交流
|
29
tmux123 2023-05-29 11:27:41 +08:00 1
不得不说这是 v2 上见过的最低质量的讨论……
|
30
nyxsonsleep OP @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 |
31
nyxsonsleep OP @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 |
32
nyxsonsleep OP |
33
nyxsonsleep OP @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 |
34
nyxsonsleep OP @Soo0 #21 问下如果架设成一个网站再套在 cfcdn 能加速 ssh 吗?(不了解这方面)
|
35
nyxsonsleep OP @salmon5 #25 应该和 https 没什么关系吧
|
36
leaflxh 2023-05-29 12:42:29 +08:00 1
可能一条命令回显的耗时不仅需要一个 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 左右 |
37
Actrace 2023-05-29 13:05:38 +08:00
主要是怕丢包。不丢包的情况下,实际的延迟应该还行。丢一个包翻倍,基本没得玩。
话说这种情况可以用微林的服务来改善的。 |
38
Masoud2023 2023-05-29 13:52:56 +08:00 1
海外机子别指望有什么正常的 SSH 体验了,基本 GFW 都在干扰。我韩国日本甲骨文,ping 也就 100 上下,ssh 上去要么卡死要么几秒断,导致我现在只能拿美国机器当跳板连上去,能 ping 通只代表这个链路可能是通的,不代表上层协议没有被重点关照。
|
40
nyxsonsleep OP @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 |
41
xinleibird 2023-05-29 14:39:35 +08:00 1
过墙的机器不要直接 ssh ,ssh 协议不单干扰而且重点关照,丢包劣化就不提了,有可能短暂的封端口,甚至有可能 ip 进狗洞几天。打个隧道,在隧道里登录,或者如楼上找个跳板机登录。
|
42
cnevil 2023-05-29 14:50:34 +08:00
同意 29#。。
承认自己错了回头学一下不就完事了,到处找补只会显得更蠢,比如网络层级意义何在 tcp 是要保证你或者我一定要收到这个包的,丢了就得重传,重传就涉及到里面的各种计数器什么的,而 icmp 不一样,延时高我都算你丢了,丢了也没什么影响 不管怎么说,基于 tcp 的业务需要多次来回的交互,而且再涉及到封包解包、应用本身处理响应等等环节,应用层的反应一定是比 icmp 看到的数值要慢的,丢不丢包都会慢,丢包只会更甚 |
43
nyxsonsleep OP @cnevil #42
在了解到 ping 不是 tcp 之后我就测试了 tcp ping 的延迟,仍然是 200ms ,所以 icmp 真的就比 tcp 延迟高多少倍吗? 本质上就是我要的是解决问题,但某些人是为了在智力上得到优越感而开始指责别人。 tcp 是 icmp 协议然后呢,解决问题了吗?在#1 后面再回复的除了#1 本人之外十个有九个在歪楼,甚至在贴出 tcp ping 延迟之后依然如此。正如#42 这确实可以被认为是 v 站最低质量的讨论,但有部分人的发言也是最低质量的回复。 #36 用自己的行动来帮助别人解决问题,也拓宽的视野。 #29 用低质量的回复来给低质量的 v 站添砖加瓦? |
44
nyxsonsleep OP |
45
nyxsonsleep OP @nyxsonsleep #43 纠错“所以 icmp 真的就比 tcp 延迟高多少倍吗?”所以 tcp 真的就比 icmp 延迟高多少倍吗?
|
46
nyxsonsleep OP @flyqie #20
这段是我判断的错误的原因 [我的意思是,我根据 HTTP-TCP ( ssh )-IP 的链路,然后误以为存在 TCP ( ping )-ICMP 。] 回答: 《网络层都要走传输层的协议?你说反了吧。 不是传输层需要往下走网络层吗。。》 发送消息的阶段是从应用层一层一层向下的,传输层在网络层之上,所以传输层协议—经过—>网络层,传输层的协议要经过网络层<=等价=>网络层要走传输层的协议。 但是 ICMP 这种协议是可以直接从网络层走数据链路层的。 |
47
nyxsonsleep OP @leido #18 icmp 与 ip 同一层。
|
48
nyxsonsleep OP @mrzx #23 确实不是 tcp
|
49
cnevil 2023-05-29 15:49:50 +08:00
@nyxsonsleep 你并没看明白我的意思,实际的应用体验由于丢包等等原因会更慢
你也只是做了 tcping 一个测试,也没考虑这个结果代表了什么,tcping 也是对网络进行简单的探测,反映了 tcp 建链的情况,跟实际的业务的 RTT 会有差别 解决?所有问题就一定能解决么,再说,你标题也没说解决就是问为什么吧?那我觉得换个香港日本的服务器?换个好点的机房?丢包是跟线路有关系的 |
50
cnbatch 2023-05-29 16:06:46 +08:00 1
显然 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 也许没有参考价值。 |
51
cnbatch 2023-05-29 16:09:38 +08:00 1
在公网测试 TCP 和 ICMP ,尤其是三大运营商,受到的影响因素实在太多,不仅仅单纯是 TCP 的拥塞算法会影响体验,运营商的配置也会有影响。
|
52
SingeeKing 2023-05-29 16:14:54 +08:00
17h 过去了,OP 为啥至今不抓个包传个 pcap ?没有实际抓包数据天知道到底是什么原因
|
53
nyxsonsleep OP |
54
cnbatch 2023-05-29 16:33:28 +08:00 1
跨墙 SSH 肯定会遇到各种奇奇怪怪的问题的,因为 SSH 早就被墙重点关注过了。
在十几年前,墙还没现在这么精密,利用 SSH 通道爬墙曾经流行过一段时间。就从那时起,SSH 被重点照顾。 换句话说,SSH 早就能被墙识别出来并区别对待了。主要感知就是“限速”。 关于墙相关的话题,“宽带症候群”和“云计算”都会遇得到。 《求助 阿里云国际的香港节点 上传好慢好慢》 /t/448177 6 楼:如果你知道 ssh -D 能做什么,就知道某墙为什么会干扰(故意制造丢包 /限速)这样的 SSH 连接。 《 sftp 跨国传输速度永远只有 1MB/s ,HTTPS 单线程可以轻松稳定跑满 100Mbps 本地带宽,问题出在哪?》 /t/904221 14 楼:SSH 特征太明显,被限速了吧 在此贴的 24 楼,我给出了一段相关的文章介绍,OP 有兴趣的话可以打开看一看 |
55
lambdaq 2023-05-29 16:37:59 +08:00 1
1. 应用层传输和回显,比起单独一个 tcp 包去 ping 有更多成本,耗时更高
2. 网关可能单独针对协议进行 QoS 3. ssh 协议本身就是为内网设计的。要说公网效果好的还得是 mosh 。。。。 |
56
zhangsanfeng2012 2023-05-29 16:50:22 +08:00
因为不是一个 RTT ,是多个 RTT
|
57
nothingistrue 2023-05-29 17:14:12 +08:00
已经有人手把手解释得那么清楚了,到了 51 楼的时候楼主还在说 「 tcp 模式的 ping 」。看来这要是加上 「 SSH 是应用层协议,不是 TCP 」,楼主会更犟。
|
58
1423 2023-05-29 17:21:46 +08:00
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 的 |
59
Pantheoon 2023-05-29 17:22:53 +08:00
tcp 有端口哇,ping 没有端口,基于 icmp 协议的,不属于 tcp
|
60
Jame00001 2023-05-29 17:28:54 +08:00
之前用 bitvise 延迟高的飞起,换了其他的完全没有延迟
|
61
1423 2023-05-29 17:44:43 +08:00
似乎猜到原因了。。OP 自己证实下吧
exec_command 太重了,想低延迟应该考虑 invoke_shell ,自己在 channel 做读写 |
62
ljsh093 2023-05-29 18:06:01 +08:00
@proxychains #7 你这个叹号是认真的吗
|
63
nyxsonsleep OP @nothingistrue #57 了解一下 tcping 和 ping 的区别行吗?还有 udp 的 ping 呢。。。
|
64
nyxsonsleep OP @Pantheoon #59 我认为我贴文很清楚了。
但似乎有人还是没搞懂: 1. ssh 是 tcp ,ping 是 icmp 。 [我说 ping 是 tcp 是错的] 2. 有一些工具通过一些方法实现了 tcp 或者 udp 连接的 ping 工具,比如 tcping 、hping3 。 |
65
nyxsonsleep OP @zhangsanfeng2012 #56 这是我没有考虑到的问题,有相关的资料吗。非常感谢。
|
66
1423 2023-05-29 18:25:01 +08:00 1
|
67
nyxsonsleep OP @lambdaq #55
1. 我特意做了 hping3 、tcping 、WinMTR 的测试,这三个软件都是可以用 tcp 协议进行延迟测试的,所以我将其称之为了 [tcp 的 ping 延迟] ,但以 tcp 协议和 icmp 协议来说他们的延迟差距不大。 [但是确实有可能是因为回显导致的延迟问题。] |
68
nyxsonsleep OP @SingeeKing #52 已上传 base64:aHR0cHM6Ly93d3cud2Vuc2h1c2h1LmNuL2YvYmJyNGV4MGpzbGY=
|
69
cnbatch 2023-05-29 18:31:53 +08:00
想要准确测试 SSH 的 RTT 带来的延时,最好在无干扰的情况下测试,比如纯内网。
哪怕是跨国内网也行(专线更佳),都比公网直接测好得多。 |
70
nyxsonsleep OP @1423 #66 能给完整代码吗?谢谢。
|
71
nyxsonsleep OP @lambdaq #55 3. 关于 mosh 我想问一下,如果打一连串指令再删除的时候,有时候会删掉命令提示符(类似: username@machinename$这部分)的部分内容,然后再回显重新回显显示出来,这个是 mosh 的特性吗?还是配置不对,或者是网络原因。
|
72
Greatshu 2023-05-29 18:38:53 +08:00
谢希仁的《计算机网络》,点击章节目录可以下载 PPT
https://yx.51zhy.cn/net.jsp Windows 下更推荐 psping ,udp ,tcp ,icmp 都支持 https://learn.microsoft.com/zh-cn/sysinternals/downloads/psping |
73
lambdaq 2023-05-29 18:39:22 +08:00
@nyxsonsleep 我没仔细研究。它号称有优化,那么肯定相比 ssh 有它的独到之处。用就完事了。
|
74
nyxsonsleep OP @cnbatch #54 非常感谢,提到这么多信息之后,我想确实有可能是被 gfw 干扰了。
|
75
lambdaq 2023-05-29 18:43:07 +08:00
@nyxsonsleep 它提到一个优化点。比如你 cat xxx 结果是一个 10G 的日志,发现一直不停输出,你按下 Ctrl+C 没反应。ssh 得等到 10G 文本传输展示完毕了,才会响应你的 Ctrl+C 。
mosh 的处理方式不同,它可以立刻响应。 |
76
ncepuzs 2023-05-29 19:05:48 +08:00
居然这么多楼了……
1. 本地代理 2. 跳板机 3. Cloudflare Access https://developers.cloudflare.com/cloudflare-one/identity/users/short-lived-certificates/ |
77
zhangsanfeng2012 2023-05-29 19:19:36 +08:00
@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() ``` |