repositorio - ¿Cuál es el protocolo más rápido, ssh o git?

servidor git linux (7)

¿Cuál es eficiente? SSH: // o Git: // (Compresión de archivos)

Entiendo en Git, el protocolo git es inteligente porque hay un agente de protocolo en ambos lados de la comunicación para comprimir la transferencia de archivos, lo que da como resultado una clonación más rápida al usar eficientemente el ancho de banda de la red.

De un libro de O''Reilly encontré las siguientes afirmaciones.

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*

No estoy seguro si el autor quiere decir lo que dice. Él habla de que el protocolo git se canaliza a través de SSH.

Desde mi punto de vista, a menos que te conectes al puerto git (puerto del agente), el protocolo no está en vigencia. Y SSH es una mera transferencia de archivos sin comprimir.
Pero según el autor, si usamos SSH él dice que el protocolo git está en el túnel. Entonces, ¿es SSH más inteligente en GIT?

Von C, gracias por tu respuesta. "Los protocolos de red (HTTP y Git) generalmente son de solo lectura". Git se puede hacer rw cuando ejecuta el comando deamon con --enable = receive-pack.

Las siguientes son mis preocupaciones. Cuando dicen que el protocolo git es inteligente, quieren decir que cuando ejecutas git clone, el agente de servidor git comprime los datos que se envían al cliente, por lo que el clon debe ser más rápido. En mi caso de uso, voy a configurar el servidor de git en Hong Kong y usarlo en sanjose y otros países, así que quiero ser eficiente en la red debido a preocupaciones de latencia.

Entonces mi pregunta es cuando uso git clone ssh: // usuario @ server / reposloc también obtengo los beneficios del protocolo git. Según el libro de autor de Orelly, quiere decir que git tiene un túnel sobre ssh, entonces, ¿cómo funciona el protocolo de git cuando no tengo git daeomon ejecutándose en el servidor?

Entonces, usar SSh: // xyz ... ¿le da tanto el beneficio de los protocolos ssh y git?

aprecia tus respuestas por adelantado.

(Quería agregar un comentario a @erjiang answer, pero no estoy autorizado porque no tengo suficiente reputación de ).

Parece que desde Git 1.6.6, HTTP ya no es "tonto". Desde el blog del sitio web de Git :

Sin embargo, a partir del lanzamiento de la versión 1.6.6 a fines del año pasado (2009), Git ahora puede usar el protocolo HTTP con la misma eficiencia que las versiones de git o ssh

Actualización 2010-2014:

Tanto ssh como https son equivalentes, desde Git 1.6.6+ (2010) y la implementación del protocolo http inteligente :

Ahora puede usar ssh o https para el acceso de lectura / escritura a sus repositorios.
También puede detectar si su servidor remoto es compatible con http inteligente .
Agregue la variable de entorno correcta si tiene que usar un proxy.

Q3 2015, como menciona Yousha Aleayoub en los comentarios :

GitHub "¿Qué URL remota debo usar?"

Las URL de clonación https:// están disponibles en todos los repositorios, públicos y privados.
Son inteligentes, por lo que le proporcionarán acceso de solo lectura o de lectura / escritura, según sus permisos para el repositorio.

El git-http-backend es el:

programa CGI simple para servir los contenidos de un repositorio de Git a los clientes de Git que acceden al repositorio a través de protocolos http:// y https:// .
El programa admite la captación de clientes utilizando tanto el protocolo inteligente HTTP como el protocolo HTTP tonto compatible con versiones anteriores, así como los clientes que utilizan el protocolo inteligente HTTP.

Respuesta original (julio de 2010):

Del libro Pro Git :

Probablemente, el protocolo de transporte más común para Git es SSH.
Esto se debe a que el acceso SSH a los servidores ya está configurado en la mayoría de los lugares, y si no es así, es fácil de hacer.
SSH es también el único protocolo basado en red que puede leer y escribir fácilmente . Los otros dos protocolos de red (HTTP y Git) generalmente son de solo lectura, por lo tanto, aunque los tenga disponibles para las masas sin lavar, aún necesita SSH para sus propios comandos de escritura.
SSH es también un protocolo de red autenticado ; y debido a que es ubicuo, generalmente es fácil de configurar y usar.

Por lo tanto, no es "más inteligente" que el protocolo de Git, solo un protocolo complementario para ciertas características no abordadas por el protocolo de Git.

La desventaja del protocolo de Git es la falta de autenticación. En general, no es deseable que el protocolo Git sea el único acceso a su proyecto.
En general, lo vinculará con acceso SSH para los pocos desarrolladores que tienen acceso de inserción (escritura) y todos los demás usarán git:// para obtener acceso de solo lectura
También requiere acceso de firewall al puerto 9418, que no es un puerto estándar que los firewalls corporativos siempre permiten. Detrás de los grandes cortafuegos corporativos, este puerto oscuro suele estar bloqueado.

(Es por eso que en mi tienda, necesito usar ssh + git y no solo git, incluso para acceso de lectura: 9418 está bloqueado ...)

Cuando accedes a git sobre ssh, simplemente tuneliza el protocolo git en ssh, es mucho más fácil de configurar y mucho más seguro, esta es la forma preferida de acceder a los repositorios remotos.

Esto es en realidad "más inteligente" que el protocolo bare git, porque puede imponer la autenticación del usuario a través de mecanismos ssh. git hace toda la compresión y lo que no está en el cliente, independientemente de la capa de transporte, y lo descomprime en el servidor.

El servidor "git" no hace esto, todo esto sucede cuando se usa ssh también. el servidor de git debe evitarse si desea poder escribir en el repositorio remoto. si solo quieres leer, git o los transportes HTTP están "OK", pero si tienes desarrolladores que necesitan escribir en el repositorio, solo debes usar ssh. La configuración de túneles para el servidor de git solo está agregando complejidad y configuración que será frágil y no te hará ganar nada.

De la Wikipedia :

Para configurar un túnel SSH, uno configura un cliente SSH para reenviar un puerto local especificado a un puerto en la máquina remota. Una vez que se ha establecido el túnel SSH, el usuario puede conectarse al puerto local especificado para acceder al servicio de red. El puerto local no necesita tener el mismo número de puerto que el puerto remoto.

Si necesita algún tipo de representación de arte ASCII:

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

Echa un vistazo a la segunda parte de esta página

El único protocolo "tonto" es el HTTP directo, que no requiere ningún esfuerzo especial en el servidor. En los protocolos git: // y ssh: //, se bifurca un proceso git upload-pack (que no es un daemon) en el servidor que se comunica con el cliente que ejecuta git fetch-pack . Tanto en ssh: // como en git: //, obtienes comunicación "inteligente".

Los diversos protocolos están en diferentes niveles (por ejemplo, el modelo de capa ISO 7), por lo que puede tener ambos, del mismo modo que podría estar conectado por cables o de forma inalámbrica, o de fibra.

Una búsqueda rápida de los archivos del paquete durante un clon de git mostrará un archivo de un solo paquete que se envía desde el servidor al cliente. El archivo del paquete se encuentra en .git / objects / pack / pack-XXXX.pack. Los archivos que se enviarán desde el servidor al cliente se empaquetan primero y se comprimen. Luego hay una copia única del contenido empaquetado. Esto se puede ver al comparar los archivos empaquetados utilizando lsof -p en el lado del servidor y lsof -p en el lado del cliente. En el caso de muestra, un archivo de 200 MB se carga desde el servidor al cliente ...

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.