为什么高延迟网络下git使用ssh传输速度远低于HTTPS，如何彻底修复？

• 专线QoS优先级差异：多数企业商业专线会对不同端口的流量做分级转发，HTTPS（443端口）属于高优先级业务队列，SSH（22端口）常被划入低优先级队列，因此繁忙时段SSH流量被主动限流，非高峰时段也无法跑满带宽，这也符合HTTPS克隆速度远高于SSH的测试现象。
• 长肥管道适配不足：中美专线RTT达150ms，属于典型的长肥网络，默认的TCP窗口大小、SSH内置收发缓冲区配置不足以支撑100Mb带宽的传输速率。走美国侧Squid代理时，端到端TCP连接被拆分为两段：中国客户端到美国Squid的HTTP CONNECT隧道流量、美国Squid到Git服务器的内网TCP连接，后者RTT极短无性能瓶颈，前者HTTP流量享受高优先级QoS，因此速度可以达到专线理论上限。
• BBR优化无效的原因：BBR拥塞控制算法的优势场景是存在丢包的公网环境，你的专线丢包率为0，BBR与默认CUBIC算法表现差异极小，因此看不到提升。而中国侧部署Squid无效是因为流量还是端到端跨专线，没有解决QoS优先级和长肥管道适配的问题。

方案1：调整专线QoS策略（最优解） #

联系专线服务商，将SSH（22端口）流量调整到与HTTPS相同的高优先级转发队列，解除对22端口的带宽限制，调整后SSH克隆速度即可达到与HTTPS一致的11MB/s水平。

方案2：优化TCP与SSH配置 #

如果无法调整专线QoS，可以通过修改两端系统和SSH配置适配长肥网络：

1. 美国Git服务器调整内核参数，编辑/etc/sysctl.conf添加以下配置，执行sysctl -p生效：

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_window_scaling = 1

2. 美国Git服务器调整sshd配置，编辑/etc/ssh/sshd_config添加以下配置，重启sshd服务生效：

TCPKeepAlive yes
RekeyLimit 1G 1h
Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com

3. 中国开发者本地调整SSH配置，编辑~/.ssh/config添加以下配置：

Host git.intranet.com
User git
ControlMaster auto
ControlPath ~/.ssh/ssh_mux_%h_%p_%r
ControlPersist 4h
Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
GSSAPIAuthentication no

方案3：部署中国本地Git镜像站 #

在中国办公室部署Git缓存镜像服务器，定时或按需同步美国Git服务器的仓库代码，中国开发者直接克隆本地镜像站的仓库，速度可达局域网水平，完全不需要跨专线传输，适合团队规模较大的场景长期使用。

方案4：切换为HTTPS协议访问Git #

已验证HTTPS克隆速度可达11MB/s，接近100Mb专线的理论吞吐量上限，不需要额外部署任何服务，只需要将本地Git仓库的remote URL修改为HTTPS格式，配置Git凭证存储缓存账号密码，使用体验与SSH完全一致。

内容的提问来源于stack exchange，提问作者Chapoly1305