通过 HTTPS 或 SSH 克隆时的带宽差异
Posted
技术标签:
【中文标题】通过 HTTPS 或 SSH 克隆时的带宽差异【英文标题】:Bandwidth difference when cloning via HTTPS or SSH 【发布时间】:2018-10-31 22:18:30 【问题描述】:我凭经验注意到通过 HTTPS (~500 KB/s) 和 SSH (>10 MB/s) 克隆 Github 存储库之间存在显着的带宽差异。
在发布周期中,我经常执行几个git clone
s,默认配置为使用HTTPS(如git clone https://...
),因为它不需要身份验证并且对用户来说更简单。
但是,存储库包含大约 100 MB(由于多个版本、一些二进制文件等),因此由于带宽限制,此命令需要几分钟时间。如果我将git clone
命令更改为使用git://...
,它会以10 MB/s 以上的速度下载,因此只需不到10 秒。
理想情况下,存储库应该更小,但无论如何,我想告知用户这种差异,让他们参考官方文档,但帮助页面Which remote URL should I use? 根本没有提及,this SO question 也没有. rate limit rules 也没有提到带宽(而且我远远低于它们,所以这不太可能是问题)。
所以我想知道:这种行为对每个人来说都是已知且可重现的吗?我是否会看到一些特定的带宽限制(可能在短时间内完成了几次git clone
s 之后)?我想有一个官方来源来推荐用户。
【问题讨论】:
也许这可能会有所帮助:git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols 【参考方案1】:我是否会看到一些特定的带宽限制(可能是在短时间内完成了几次 git 克隆之后)?
是的,尽管 GitHub 支持是正确的,因为它不是 带宽限制。您会看到 CPU 节流。 GitHub 不受网络限制,但它在克隆存储库时受 CPU 限制,因为计算要交付给您的包文件并压缩它以进行交付非常昂贵。
正如 Patrick Reynolds 所讨论的 in his talk at Git Merge 2016,GitHub 对特定用户从特定 IP 到特定存储库的并发 Git 操作数量进行了限制,以避免您对文件服务器进行 DoS 攻击。这可以从您正在做的事情中看出,这是避免“雷声从众问题”。
正如帕特里克所说,“唯一达到这个限制的是脚本......”而经常达到这些限制的是“为持续集成而克隆”。简而言之,GitHub 分析用于克隆该存储库的先前 CPU 时间,并假设未来的克隆将花费类似的时间。当您同时克隆其中几个时,GitHub 会计算这些克隆总数的预期 CPU 时间。如果您超过了给定的配额,其中一些克隆将被延迟。
这可确保您的多个克隆不会影响系统上的其他用户。
那么,为什么您会看到这些影响是 HTTPS 而不是 SSH?因为经过身份验证的用户的配额高于未经身份验证的用户。我怀疑如果您使用 HTTPS 进行身份验证,您会看到两种协议之间的响应时间相似。
【讨论】:
澄清一下,实际上我并没有克隆很多,只是每隔几分钟克隆一次,总共不到 10 个,所以我不确定是否应用了 CPU 节流。事实上,HTTPS 似乎被限制在一个“整数”(500 KB/s),这让我想到了带宽上限。尽管如此,我还是重试了克隆它(上次尝试后的几天),HTTPS 的速度为 223 KB/s,SSH 的速度为 119 KB/s。所以我真的看不到可重复的模式。总体而言,我们的存储库并不那么出名,值得特别考虑。 我明白了;我从您的问题中推断出,当您执行多个clone
s 时,您同时执行了此操作。所以我同意你可能没有触发限制。【参考方案2】:
我最终联系了 Github Support,得到了回复:
我们没有在 HTTPS 和 SSH 之间设置带宽上限。
因此,任何观察到的差异都必须是局部的。
不过,如果性能对用户来说真的很重要,那么告诉他们协议可能有不同的速度可能会很有用,他们应该尝试两种协议,看看哪一种最适合他们。
【讨论】:
以上是关于通过 HTTPS 或 SSH 克隆时的带宽差异的主要内容,如果未能解决你的问题,请参考以下文章
使用或不使用 @transient 序列化惰性 val 时的差异
我们可以使用 lambda 函数克隆一个终止的 emr 集群吗?在新集群中会有任何差异吗?