Разница в полосе пропускания при клонировании через HTTPS или SSH

Question

Я эмпирически заметил значительную разницу в полосе пропускания между клонированием репозиториев Github через HTTPS (~ 500 КБ / с) и SSH (> 10 МБ / с).

Во время цикла выпуска я часто выполняю несколько git clone s, которые по умолчанию настроены на использование HTTPS (например, git clone https://...), поскольку он не требует проверки подлинности и проще для пользователя.

Однако хранилище содержит около 100 МБ (из-занесколько версий, некоторые двоичные файлы и т. д.), поэтому эта команда занимает несколько минут из-за ограничения пропускной способности.Если я изменю команду git clone на использование git://..., она загружается со скоростью выше 10 МБ / с, поэтому это занимает менее 10 секунд.

В идеале хранилище должно быть меньше, но в любом случае,Я хотел бы проинформировать пользователей об этой разнице, сославшись на официальную документацию, но на странице справки Какой удаленный URL я должен использовать? вообще не упоминает об этом, равно как и этот ТАК вопрос .В правилах ограничения скорости также не упоминается пропускная способность (и я намного ниже их, так что это вряд ли проблема).

Поэтому я задаюсь вопросом: это поведение известно и воспроизводимо для всех?Могу ли я видеть некоторое удушение полосы пропускания (возможно, после нескольких git clone с за короткий промежуток времени)?Я хотел бы иметь официальный источник для направления пользователей.

Answer 1

Могу ли я увидеть некоторое удушение полосы пропускания (возможно, после нескольких клонов git за короткий промежуток времени)?

Да , хотя поддержка GitHubправильно, в том, что это не регулирование пропускной способности .Вы видите дросселирование процессора .GitHub не связан с сетью, но он связан с процессором при клонировании репозиториев, так как вычисление пакетного файла для доставки и сжатие его для доставки обходятся дорого.

Как Патрик Рейнольдс обсуждает в своем выступлении наGit Merge 2016 , GitHub накладывает ограничения на количество одновременных операций Git для конкретного пользователя с определенного IP-адреса в конкретный репозиторий, чтобы вы не делали файловый сервер.Это видно по тому, что вы делаете, что позволяет избежать «громовой проблемы со стадом».

Как отмечает Патрик, «единственное, что достигает этого предела, это сценарии ...» и то, чточасто попадает в эти пределы «клонирование для непрерывной интеграции».Вкратце, GitHub анализирует предыдущее процессорное время, использованное для клонирования этого хранилища, и предполагает, что для будущих клонов потребуется аналогичное время.Когда вы клонируете несколько из них одновременно, GitHub вычисляет ожидаемое время ЦП для общего количества этих клонов.И если вы превысили заданную квоту, некоторые из этих клонов будут задержаны.

Это гарантирует, что ваши несколько клонов не повлияют на других пользователей системы.

Так почему вы видите этивлияет на HTTPS, а не на SSH?Поскольку аутентифицированные пользователи имеют более высокую квоту, чем неаутентифицированные пользователи.Я подозреваю, что если бы вы проходили аутентификацию по протоколу HTTPS, вы бы увидели одинаковое время отклика между двумя протоколами.

Answer 2

Я в итоге связался со службой поддержки Github, который ответил:

Мы не установили ограничения пропускной способности между HTTPS и SSH.

Поэтому любые наблюдаемые различия должны быть локальными.

Тем не менее, если производительность действительно важна для пользователей, может быть полезно сообщить им, что протоколы могут иметь разную скорость, и что им следует попробовать оба варианта и посмотреть, какой из них лучше для них работает.