Какой протокол Git умнее, SSH или GIT (через SSH) или HTTPS? - PullRequest
47 голосов
/ 14 июля 2010

Что эффективно? SSH: // или Git: // (сжатие файлов)

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

Из книги О'Рейли Я нашел следующие утверждения.

For secure, authenticated connections, the Git native 
protocol can be tunneled over an SSH connection using
the following URL templates:

ssh: //[user@]example.com[:port]/path/to/repo.git
ssh: //[user@]example.com/path/to/repo.git
ssh: //[user@]example.com/~user2/path/to/repo.git
ssh: //[user@]example.com/~/path/to/repo.git*

Я не уверен, что автор имеет в виду то, что говорит. Он говорит о том, что протокол git становится туннельным по SSH.

С моей точки зрения, если вы не подключитесь к порту git (порту агента), протокол не будет действовать. А SSH - это просто несжатая передача файлов.
Но согласно автору, если мы используем SSH, он говорит, что протокол git поверх него. Так SSH умнее в GIT?

Фон С, Спасибо за Ваш ответ. «Сетевые протоколы (HTTP и Git) обычно доступны только для чтения» Git можно сделать rw, когда вы запускаете deamon с --enable=receive-pack.

Ниже приведены мои опасения.
Когда они говорят, что протокол git умный, они имеют в виду, что когда вы выполняете git clone, агент сервера git сжимает данные, которые отправляются обратно клиенту, поэтому клонирование должно выполняться быстрее. В моем случае я буду устанавливать git-сервер в Гонконге и использовать его в Сан-Хосе и других странах, поэтому я хочу быть эффективным по сети из-за проблем с задержкой.

Итак, мой вопрос: когда я использую git clone ssh://user@server/reposloc, получу ли я также преимущества протокола git? Согласно книге автора О'Рейли, он имеет в виду, что git туннелируется через ssh, тогда как работает протокол git, когда на сервере не работает демон git.

Таким образом, использование SSh: // xyz ... дает ли это преимущество как протоколам ssh, так и git?

Заранее оцените ваши ответы.

Ответы [ 7 ]

51 голосов
/ 14 июля 2010

Обновление 2010-2014:

И ssh, и https эквивалентны, так как Git 1.6.6+ (2010) и реализация протокола smart http :

smart http

Теперь вы можете использовать ssh или https для доступа для чтения / записи к своим репозиториям.
Вы также можете определить, поддерживает ли ваш удаленный сервер интеллектуальный http * 1014.*.
Добавьте правильную переменную среды, если вам необходимо использовать прокси.

3 квартал 2015 года, как Юша Алеауб упоминает в комментариях :

GitHub «Какой удаленный URL-адрес следует использовать?»

Клонированные URL-адреса https:// доступны во всех репозиториях, как публичных, так и частных.
Они умныеТаким образом, они предоставят вам доступ только для чтения или для чтения / записи, в зависимости от ваших прав доступа к хранилищу.

git-http-backend - это:

простая CGI-программа для обслуживания содержимого репозитория Git для клиентов Git, обращающихся к репозиторию через http:// и https:// protпротоколы.
Программа поддерживает выборку клиентов по интеллектуальному протоколу HTTP и обратно-совместимому простому протоколу HTTP, а также передачу клиентов по интеллектуальному протоколу HTTP.


Оригинальный ответ(Июль 2010):

Из Pro Git Book :

Вероятно, наиболее распространенным транспортным протоколом для Git является SSH.
Это потому, что SSHдоступ к серверам уже настроен в большинстве мест - и если это не так, это легко сделать.

SSH также является единственным сетевым протоколом, который вы можете легко читать и записывать в .Два других сетевых протокола (HTTP и Git) обычно доступны только для чтения, поэтому даже если они доступны для немытых масс, вам все равно нужен SSH для ваших собственных команд записи.

SSH также является аутентифицированным сетевым протоколом ;и поскольку он вездесущ, его обычно легко настроить и использовать.

Так что он не "умнее", чем протокол Git, просто дополнительный протокол для определенных функций, не предусмотренных протоколом Git.

Недостатком протокола Git является отсутствие аутентификации.Как правило, нежелательно, чтобы протокол Git был единственным доступом к вашему проекту.
Как правило, вы будете связывать его с доступом по SSH для тех немногих разработчиков, которые имеют доступ с правами на запись (запись) и все остальные используют git:// для чтения.-only access

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

(поэтому в моем магазине мне нужно , чтобы использовать ssh + git, а не просто git, даже для чтениядоступ: 9418 заблокирован ...

38 голосов
/ 15 июля 2010

Взгляните на вторую часть этой страницы

Единственный «тупой» протокол - это прямой HTTP, который не требует особых усилий на сервере. В обоих протоколах git: // и ssh: // процесс git upload-pack (который не является демоном) разветвляется на сервере, который обменивается данными с клиентом, работающим git fetch-pack. И в ssh: //, и в git: // вы получаете "умное" общение.

3 голосов
/ 13 января 2014

(Я хотел добавить комментарий к ответу @erjiang, но мне не разрешили, потому что у меня недостаточно репутации StackOverflow.)

Похоже, что с Git 1.6.6 HTTP не является"тупой" больше.Из блога сайта Git :

Начиная с выпуска версии 1.6.6 в конце прошлого года (2009), однако, Git теперь может использовать протокол HTTP почтитак же эффективно, как версии git или ssh

3 голосов
/ 14 июля 2010

Когда вы обращаетесь к git через ssh, он просто туннелирует протокол git через ssh, намного проще в настройке и более безопасным, это предпочтительный способ доступа к удаленным хранилищам.

Это на самом деле "умнее", чем простой git-протокол, потому что он может обеспечить аутентификацию пользователя с помощью механизмов ssh. git выполняет все сжатие и что не на клиенте, независимо от транспортного уровня, и распаковывает его на сервере.

Сервер "git" этого не делает, все это происходит и при использовании ssh. следует избегать git-сервера, если вы хотите иметь возможность записи в удаленный репозиторий. если вы хотите иметь доступ только для чтения, git или транспорты HTTP - это нормально, но если у вас есть разработчики, которым нужно писать в репозиторий, вам просто нужно использовать ssh. Настройка туннелей для git-сервера просто добавляет сложности и конфигурации, которые будут хрупкими и не принесут вам ничего.

1 голос
/ 17 июня 2014

Быстрый поиск файлов пакета во время git-клона покажет один файл пакета, который отправляется с сервера клиенту. Файл пакета указан в .git / objects / pack / pack-XXXX.pack. Файлы, которые должны быть отправлены с сервера на клиент, сначала упаковываются, сжимаются. Тогда есть одна копия упакованного содержимого. Это можно увидеть при сравнении упакованных файлов с помощью lsof -p на стороне сервера и lsof -p на стороне клиента. В этом примере файлы размером 200 МБ загружаются с сервера на клиент ....

1) Server side 
   lsof -p 8079 | grep pack
   git-uploa 8079  REG  253,2 277896169 5140075 /home/server/work/work0617/.git/objects/pack/pack-492945ae602a975d46df133f6ded9642146fb6a7.pack
   git-uploa 8079  REG  253,2   1703472 5140076 /home/server/work/work0617/.git/objects/pack/pack-492945ae602a975d46df133f6ded9642146fb6a7.idx
   git-uploa 8079  REG  253,2 277896169 5140075 /home/server/work/work0617/.git/objects/pack/pack-492945ae602a975d46df133f6ded9642146fb6a7.pack

2) Client side
   lsof -p 3140 | grep pack
   git     3140  3u   REG    8,1 101031935 3681610 /home/client/work/work0617/work0617/.git/objects/pack/tmp_pack_pRfYPa

 3) The server side pack file 277MB. The file on the client side is 101MB and growing. So a single compressed file is copied over.
1 голос
/ 17 июля 2011

Различные протоколы находятся на разных уровнях (например, модель уровня ISO 7), поэтому вы можете использовать оба протокола, точно так же, как вы можете быть подключены с помощью проводов, беспроводного соединения или оптоволокна.

1 голос
/ 14 июля 2010

Из Википедия :

Чтобы настроить туннель SSH, необходимо настроить клиент SSH для переадресации указанного локального порта порт на удаленной машине. Когда SSH-туннель установлен, пользователь может подключиться к указанному локальному порту для доступа к сетевому сервису. Локальный порт не нужно иметь тот же номер порта, что и удаленный порт.

Если вам нужно художественное представление в формате ASCII:

Git Data ---> [SSH encrypts data] ----- Internet -----> [SSH decrypts data] ----> Git Data
...