Что происходит быстрее, протокол ssh или git?

Что эффективнее? SSH: // или Git: // (сжатие файлов)Что происходит быстрее, протокол ssh или git?

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

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

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

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

Я не уверен, имеет ли автор то, что он говорит. Он говорит о том, что протокол git проходит через SSH.

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

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

Ниже приводятся мои проблемы. Когда говорят, что протокол git умный, они означают, что когда вы выполняете git-клон, git-агент сервера сжимает данные, которые отправляются обратно клиенту, поэтому клон должен быть быстрее. Im мой usecase, я буду устанавливать git-сервер в hongkong и использовать его в sanjose и других странах, так что, я хочу быть эффективными по сети из-за проблем с задержкой.

Так что мой вопрос в том, когда я использую git clone ssh: // user @ server/reposloc, я также получаю преимущества протокола git. Согласно книге авторов Orelly, он означает, что git туннелируется поверх ssh, тогда как работает git-протокол, когда у меня нет git daeomon, запущенного на сервере.

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

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

источник

2010-07-14 vengateswaran c

«Итак, используя SSh: // xyz ... это дает как преимущество протоколов ssh, так и git?» ДА –

Я до сих пор не вижу ответа на вопрос. У меня много гигабайт, и я могу использовать либо ssh, либо https, что займет минимум времени? –

Взгляните вторая часть this page

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

источник

2010-07-14 20:20:31 erjiang

Привет, Мазин ... Спасибо. Это отвечает моим опасениям. Спасибо всем за ваш вклад. –

git: // не имеет служебных данных шифрования или аутентификации, которые ssh: // реализует. git: // использует тот же самый быстрый механизм передачи данных, что и ssh: //, но менее интенсивный сервер. – aus

Аккуратно. Я буду придерживаться SSH, потому что это построено с учетом безопасности. –

От Wikipedia:

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

Если вам нужно какое-то ASCII арт представления:

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

источник

2010-07-14 17:33:26

Спасибо за этот ответ, это касается моей озабоченности, но можете ли вы рассказать мне, что такое URL-адрес, используемый для обеспечения того, чтобы запрос фактически был настроен на сервер протокола git. Это какая-то ссылка на ссылку ssh: // user @ host: [git port]/location location ??? pls подтверждают. –

ничто не туннелируется на любой сервер протокола. вы __don't__ хотите использовать голый протокол git, это __not__ оптимальное решение. –

При доступе к Git через SSH это только туннели протокол мерзавца через SSH, намного легче настроить и способ более безопасные, этого предпочтительный способ доступа к удаленным репозиториям.

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

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

источник

2010-07-14 17:34:12

Спасибо. Я не могу полностью согласиться с этим ответом. Потому что вам не нужно запускать демон GIT, если вы используете git push ssh: // user @ server/location. Когда git daemon не работает, как вы говорите, git туннелируется через SSH?Кто обрабатывает протокол git, если сервер протокола git не запущен? –

ssh - это просто транспорт, он по-прежнему говорит о «git protocol» над ssh. Это то, как это работает над ssh, git over ssh - наиболее эффективный метод работы с удаленными репозиториями. Вам все еще нужно git на удаленном компьютере, но он не использует демона, это не так сложно. –

Я уверен, что есть разница между ssh: // и git + ssh: //. – erjiang

Update 2010-2014:

Оба SSH и HTTPS эквивалентны, так как Git 1.6.6+ (2010) и реализация smart http protocol:

smart http

Теперь вы можете использовать ssh или https для доступа для чтения/записи к вашим репозиториям.
Вы можете также detect if your remote server supports smart http.
Добавьте правильную переменную окружения, если вам нужно использовать прокси-сервер.

Q3 2015, а Yousha Aleayoub упоминает in the comments:

GitHub "Which remote URL should I use?"

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

git-http-backend является: простой CGI программа

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

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

От Pro Git Book:

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

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

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

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

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

Он также требует доступа брандмауэра к порту 9418, который ISN» t стандартный порт, который позволяют корпоративные брандмауэры. За крупными корпоративными брандмауэрами этот неясный порт обычно блокируется.

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

источник

2010-07-14 17:35:33 VonC

+1 Убедившись, я считаю, что это должен быть правильный ответ, поскольку он объясняет это лучше даже для noobs. – Val

@Val спасибо. Использование ssh влечет за собой собственную дискуссию об управлении доступом пользователей: см. Комментарии http://stackoverflow.com/a/16184533/6309 – VonC

Примечание для себя: с 25-м номером, серебряный значок «Хороший ответ» для этого ответа - это мой 1000-й (мне потребовалось почти 6 лет). – VonC

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

источник

2011-07-17 18:08:44

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

кажется, что с Git 1.6.6, HTTP не " немой ". Из Git website's blog:

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

источник

2014-01-13 11:42:00 Xavi

Быстрый поиск файлов пакета во время клонирования 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.

источник

2014-06-17 17:04:11

Что происходит быстрее, протокол ssh или git?

ответ

Смежные вопросы