Который является более умным протоколом мерзавца, ssh или мерзавцем (по ssh) или https протоколом?
Который эффективен? SSH://или Git://(Сжатие файла)
Я понимаю в Мерзавце, протокол мерзавца умен, потому что существует агент протокола на обоих концах коммуникации для сжатия передачи файлов, приводящей к более быстрому клону путем эффективного использования сетевой пропускной способности.
Из книги O'Reilly я нашел следующие утверждения.
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*
Я не уверен, имеет ли автор в виду то, что он говорит. Он говорит о протоколе мерзавца, туннелируемом по SSH.
С моей точки зрения, если Вы не соединяетесь с портом мерзавца (порт агентов), протокол не в действительности. И SSH является простой несжатой передачей файлов.
Но согласно автору, если мы используем SSH, он говорит, что протокол мерзавца туннелирован по нему. Так SSH более умный в МЕРЗАВЦЕ?
Von C, спасибо за Ваш ответ. "Сетевые протоколы (HTTP и Мерзавец) являются" Мерзавцем обычно только для чтения, может быть сделан rw когда Вы выполняете deamon с --enable=receive-pack.
Следующее является моими проблемами.
Когда они говорят, что протокол мерзавца умен, они имеют в виду, когда Вы выполняете клон мерзавца, агент сервера мерзавца сжимает данные, которые передают обратно клиенту, таким образом, клон должен быть быстрее. В моем варианте использования я буду устанавливать сервер мерзавца в Гонконге и использовать его на Сан-Хосе и других странах также, Таким образом, я захочу быть эффективным по сети из-за проблем задержки.
Таким образом, мой вопрос состоит в том, когда я использую git clone ssh://user@server/reposloc я извлекаю пользу из протокола мерзавца также? Согласно O'Reilly, которого заказывает автор, он подразумевает, что мерзавец туннелирован по ssh, затем как протокол мерзавца работает, когда у меня нет демона мерзавца, работающего на сервере.
Так с помощью SSh://xyz... это приносит и пользу ssh и протоколы мерзавца?
Цените свои ответы заранее.
4 ответа
Посмотрите на вторую часть этой страницы
Единственный "тупой" протокол - это прямой HTTP, который не требует особых усилий со стороны сервера. В протоколах git:// и ssh:// на сервере форкнут процесс git upload-pack (который не является демоном), который взаимодействует с клиентом, запускающим git fetch-pack. Как в ssh://, так и в git://, вы получаете "умную" коммуникацию.
Когда вы обращаетесь к git через ssh, он просто туннелирует протокол git через ssh, что намного проще в настройке и намного безопаснее, это предпочтительный способ доступа к удаленным репозиториям.
Это на самом деле «умнее», чем простой протокол git, потому что он может принудительно выполнять аутентификацию пользователя через механизмы ssh. git выполняет все сжатие, а все остальное не на клиенте, независимо от транспортного уровня, и распаковывает его на сервере.
Сервер "git" этого не делает, все это происходит и при использовании ssh. следует избегать сервера git, если вы хотите иметь возможность писать в удаленный репозиторий. если вам нужен доступ только для чтения, git или HTTP-транспорты - «ОК», но если у вас есть разработчики, которым нужно писать в репозиторий, вы должны просто использовать ssh. Настройка туннелей для сервера git - это просто добавление сложности и конфигурации, которые будут хрупкими и ничего вам не дадут.
Обновление 2010-2014:
И ssh, и https эквивалентны, поскольку Git 1.6.6+ (2010) и реализация smart http протокола :
Теперь вы можете использовать ssh или https для чтения / записи ваших репозиториев.
Вы также можете определить, поддерживает ли ваш удаленный сервер smart http .
Добавьте правильную переменную среды, если вам нужно использовать прокси.
Q3 2015, поскольку Yousha Aleayoub упоминает в комментариях :
GitHub «Какой удаленный URL-адрес мне следует использовать?»
The
https: //URL-адреса клонов доступны во всех публичных и частных репозиториях.
Они умны, поэтому они предоставят вам доступ только для чтения или чтения / записи, в зависимости от ваших прав доступа к репозиторию.
git-http-backend - это:
простая программа CGI для обслуживания содержимого репозитория Git клиентам Git, обращающимся к репозиторию через
http: //иhttps: //протоколы.
Программа поддерживает выборку клиентов с использованием как интеллектуального протокола HTTP, так и обратно совместимого немого протокола HTTP, а также клиентов, отправляющих запросы с использованием интеллектуального протокола HTTP.
Исходный ответ (июль 2010 г.):
Из Pro Git Book :
Вероятно, наиболее распространенным транспортным протоколом для Git является SSH.
Это связано с тем, что SSH-доступ к серверам уже настроен в большинстве мест, а если это не так, это легко сделать.SSH также является единственным сетевым протоколом, который можно легко читать и записывать в . Два других сетевых протокола (HTTP и Git) обычно доступны только для чтения, поэтому даже если они доступны для немытых масс, вам все равно понадобится SSH для ваших собственных команд записи.
SSH также является аутентифицированным сетевым протоколом ; и, поскольку он повсеместен, его легко настроить и использовать.
Таким образом, он не «умнее» протокола Git, а просто дополнительный протокол для определенных функций, не решаемых протоколом Git.
Обратной стороной протокола Git является отсутствие аутентификации. Обычно нежелательно, чтобы протокол Git был единственным доступом к вашему проекту.
Как правило, вы объединяете его с доступом SSH для тех немногих разработчиков, у которых есть доступ на push (запись), и пусть все остальные используютgit: //для доступа только для чтения. Также требуется доступ к брандмауэру для порт 9418, который не является стандартным портом, который всегда разрешен корпоративными брандмауэрами. Этот непонятный порт обычно заблокирован за большими корпоративными брандмауэрами.
(поэтому в моем магазине мне нужно , чтобы использовать ssh + git, а не только git, даже для доступа на чтение: 9418 заблокировано ...)
Из Википедии:
Чтобы создать SSH-туннель, нужно настроить SSH-клиент на перенаправление указанного локального порта на порт на удаленной машине. После создания SSH-туннеля пользователь может подключиться к указанному локальному порту для доступа к сетевой службе. Локальный порт не обязательно должен иметь тот же номер порта, что и удаленный порт.
Если вам нужно какое-то представление в формате ASCII:
Git Data ---> [SSH encrypts data] ----- Internet -----> [SSH decrypts data] ----> Git Data