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

¿Qué es eficiente? SSH: // o Git: // (compresión de archivos)¿Cuál es el protocolo más rápido, ssh o git?

Entiendo que 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 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: ///[[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*

No estoy seguro de si el autor dice 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 se conecta al puerto Git (puerto agente), el protocolo no está en vigor. 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 sobre él. Entonces, ¿es SSH más inteligente en GIT?

Von C, Gracias por su 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 se ejecuta 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.

Así que mi pregunta es cuando se utiliza git clone ssh: // usuario @ servidor/reposloc puedo obtener los beneficios del protocolo git también. 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?

Así que usando ssh: // XYZ ... ¿proporciona tanto el beneficio de los protocolos SSH y git?

agradecemos sus respuestas con anticipación.

Fuente

2010-07-14 vengateswaran c

"Entonces, usando ssh: // XYZ ... ¿proporciona tanto el beneficio de los protocolos SSH y git" SÍ –

Todavía no puedo ver una respuesta a la pregunta. Tengo muchos gigabytes para extraer y puedo usar ssh o https, ¿cuál tomará menos tiempo? –

Tome un vistazo a la segunda parte de this page

El único protocolo "tonto" es 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".

Fuente

2010-07-14 20:20:31 erjiang

Hola Mazin ... Gracias. Esto responde mis preocupaciones. Gracias a todos por su contribución. –

git: // no tiene la sobrecarga de cifrado o autenticación que ssh: // implementa. git: // usa el mismo mecanismo rápido de transferencia de datos que ssh: //, pero es menos intensivo en el lado del servidor. – aus

aseado. Me apegaré a SSH porque está construido teniendo en cuenta la seguridad. –

De Wikipedia:

Para configurar un túnel SSH, se 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 tiene el mismo número de puerto que el puerto remoto.

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

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

Fuente

2010-07-14 17:33:26

Gracias por esta respuesta, soluciona mi problema, pero ¿puede decirme cuál es la URL utilizada para asegurarse de que la solicitud esté realmente conectada al servidor de protocolo git? ¿Hay alguna cosa que enlace ssh: // usuario @ host: [puerto git]/ubicación del repositorio ??? Por favor confirma. –

nada se tuneliza a ningún servidor de protocolo. no quieres usar el protocolo bare git, es __not__ una solución óptima. –

Al acceder a git sobre ssh sólo los túneles del protocolo git sobre ssh, forma más fácil de configurar y de forma más segura, esta la forma preferida de acceder a repositorios remotos.

Esto es en realidad "más inteligentes" que el protocolo git al descubierto, ya que puede aplicar la autenticación de usuario a través de mecanismos de 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 utiliza 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.

Fuente

2010-07-14 17:34:12

Gracias. No soy capaz de estar completamente de acuerdo con esta respuesta. Debido a que no tiene que tener el daemon GIT en ejecución si usa git push ssh: // usuario @ servidor/ubicación. Cuando git daemon no se está ejecutando, ¿cómo se dice que git se tuneliza a través de SSH?¿Quién maneja el protocolo git, si el servidor de protocolo git no se está ejecutando? –

ssh es solo el transporte, todavía habla el "protocolo git" en ssh. Así es como funciona en ssh, git over ssh es el método más eficiente para trabajar con repositorios remotos. Todavía necesitas git en la máquina remota, pero no usa un daemon, esto no es tan complicado. –

Estoy bastante seguro de que hay una diferencia entre ssh: // y git + ssh: //. – erjiang

Actualización 2010-2014:

Tanto ssh y https son equivalentes, ya que Git 1.6.6+ (2010) y la implementación de smart http protocol:

smart http

Ahora puede utilizar ssh o https para acceso de lectura/escritura a sus repositorios.
También puede detect if your remote server supports smart http.
Agregue la variable de entorno correcta si tiene que usar un proxy.

Q3 2015, como se menciona Yousha Aleayoub in the comments:

GitHub "Which remote URL should I use?"

Los https:// URL clon están disponibles en todos los repositorios, pública y privada.
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 sencilla

para servir el contenido de un repositorio Git Git a los clientes accedan al registro de más de http:// y https:// protocolos.
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):

Desde el Pro Git Book:

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 en. 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 Git, solo un protocolo complementario para ciertas características no tratadas por el protocolo 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.
Generalmente, podrás sincronizarlo con acceso SSH para los pocos desarrolladores que tienen acceso empuje (escritura) y que tienen todos los demás utilización git:// para acceso de sólo lectura

También requiere el acceso firewall para el puerto 9418, que ISN' t un puerto estándar que los firewalls corporativos siempre permiten. Detrás de los grandes cortafuegos corporativos, este puerto oscuro suele estar bloqueado.

(por eso en mi tienda, necesito usar ssh + git y no sólo git, incluso para el acceso de lectura: 9418 está bloqueada ...)

Fuente

2010-07-14 17:35:33 VonC

+1 Convencido, reconozco que esta debería ser la respuesta correcta, ya que lo explica mejor incluso para los noobs. – Val

@Val gracias. El uso de ssh implica su propio debate sobre la administración del acceso de los usuarios: vea los comentarios de http://stackoverflow.com/a/16184533/6309 – VonC

Nota para mí: con el vigesimoquinto votaciones, la insignia de plata "Buena respuesta" para esta respuesta es mi 1000a (me llevó casi 6 años también). – VonC

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

Fuente

2011-07-17 18:08:44

(que quería añadir un comentario a @erjiang respuesta, pero no se me permite, porque no tengo la reputación suficiente StackOverflow.)

Parece que desde Git 1.6.6, HTTP no es " tonto "más. De Git website's blog:

A partir del lanzamiento de la versión 1.6.6 a finales del año pasado (2009), sin embargo, Git puede ahora utilizar el protocolo HTTP casi tan eficientemente como los git o ssh versiones

Fuente

2014-01-13 11:42:00 Xavi

Una búsqueda rápida de los archivos del paquete durante un clon de git listará un único archivo de 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 la muestra de 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.

Fuente

2014-06-17 17:04:11

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

Respuesta

Cuestiones relacionadas