关于Github可连接时长问题的实验

众所周知,由于一些不可说、不可说的原因,国内对Github的连接是一种“朦胧”状态,对git clone等命令造成了极大困扰。但是它又不是完全不可访问,运气好了还感觉连接是正常的。今天我做了一个实验来探究Github可连接/不可连接时长的情况。

我的实验环境是在北京的一个服务器,运营商未知(所以仅供参考)。

首先,两个很显然的观察是:(1) 连接是时断时续的,连不上的时间区间内无论如何都连不上,能连上的区间内一定能连上;(2) 能连上的区间内网速是正常的。下面进行实验:

实验方法:对一个仓库不断使用git pull,直到命令成功为止。成功后1s开始下一次尝试。若成功后6s内又成功一次,则视这一段时间区间为可以连接的;若等待6s以上才成功下一次,则视这两次的间隔中为断开状态。总实验时长13小时以上。

实验结果:一共出现了51次能连接-断开的轮回:

  • 平均每次能连接时长6.7±5.2min左右,最长27min(真是慷慨啊(大嘘)),最短仅8s;
  • 平均每次断开时长9.6±6.6min左右,最长43min(无语,碰上了就倒大霉),最短2.2min。

后来我还发现了一个不得了的事情:每次能连接的时长基本集中在3min的倍数左右,断开的时长集中在200s的倍数左右。这也太刻意了吧?

实验程序的完整输出如下:

Connection Start Time | Lasting Period
2025/06/17 14:24:04 | 0:00:00
2025/06/17 14:30:49 | 0:02:59
2025/06/17 14:47:14 | 0:09:02
2025/06/17 15:03:00 | 0:12:03
2025/06/17 15:21:46 | 0:06:00
2025/06/17 15:34:30 | 0:02:59
2025/06/17 15:50:55 | 0:06:02
2025/06/17 16:10:23 | 0:15:06
2025/06/17 16:32:09 | 0:02:59
2025/06/17 16:48:34 | 0:02:59
2025/06/17 17:05:00 | 0:09:01
2025/06/17 17:20:46 | 0:02:58
2025/06/17 17:30:29 | 0:02:58
2025/06/17 17:53:34 | 0:03:00
2025/06/17 18:40:03 | 0:03:00
2025/06/17 18:53:04 | 0:02:57
2025/06/17 19:02:45 | 0:02:59
2025/06/17 19:25:52 | 0:09:04
2025/06/17 19:43:55 | 0:00:08
2025/06/17 19:46:15 | 0:03:40
2025/06/17 20:03:22 | 0:06:01
2025/06/17 20:16:06 | 0:02:59
2025/06/17 20:25:50 | 0:06:01
2025/06/17 20:35:11 | 0:09:01
2025/06/17 20:47:35 | 0:06:00
2025/06/17 21:00:18 | 0:03:00
2025/06/17 21:10:02 | 0:27:08
2025/06/17 21:43:54 | 0:21:05
2025/06/17 22:21:43 | 0:02:59
2025/06/17 22:31:27 | 0:06:00
2025/06/17 22:47:29 | 0:02:59
2025/06/17 22:57:13 | 0:03:00
2025/06/17 23:13:38 | 0:09:01
2025/06/17 23:29:22 | 0:06:02
2025/06/17 23:38:43 | 0:21:06
2025/06/18 00:06:32 | 0:09:03
2025/06/18 00:18:54 | 0:02:59
2025/06/18 00:28:37 | 0:03:00
2025/06/18 00:38:17 | 0:05:59
2025/06/18 00:51:01 | 0:09:00
2025/06/18 01:06:45 | 0:12:02
2025/06/18 01:32:13 | 0:05:59
2025/06/18 01:44:57 | 0:06:00
2025/06/18 02:11:04 | 0:09:00
2025/06/18 02:33:29 | 0:06:00
2025/06/18 02:42:50 | 0:09:01
2025/06/18 02:58:34 | 0:02:59
2025/06/18 03:14:59 | 0:02:58
2025/06/18 03:24:41 | 0:03:00
2025/06/18 03:41:04 | 0:06:00
2025/06/18 03:50:23 | 0:09:01
Total test period: 13:35:20 | Total connections: 51
Connected: 0:06:41 +- 311s | max=0:27:08 min=0:00:08 
Disconnected: 0:09:37 +- 396s | max=0:43:29 min=0:02:12

经统计,每次断开的时长为:

405s    806s    404s    403s    404s    806s    806s    
400s    806s    807s    405s    405s    1207s   2609s   
601s    404s    1208s   539s    132s    807s    403s    
405s    200s    203s    403s    404s    404s    1004s   
405s    602s    405s    805s    403s    199s    403s     
199s    404s    400s    405s    404s    806s    405s    
1207s   805s    201s    403s    806s    404s    803s    
199s    1206s

基本上都是200s、400s、800s等200的倍数左右为主,其中400s左右最多。

所以本质上Github访问是一种原神抽卡(bushi)?


关于如何提升Github的clone/pull效率:参见https://gitclone.com/


最后我实在不理解把Github搞成这样的意义是什么,这不是自断武艺吗。。。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值