Quale è il protocollo più veloce, ssh o git?

Quale è l'efficacia? SSH: // o Git: // (compressione file)Quale è il protocollo più veloce, ssh o git?

Capisco in Git, il protocollo git è intelligente perché c'è un agente di protocollo su entrambe le estremità del commumnication per comprimere il trasferimento del file risultante in un clone più veloce utilizzando effecamente il larghezza di banda della rete.

Da un libro di O'Reilly ho trovato le seguenti dichiarazioni.

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*

Non sono sicuro se l'autore intende ciò che dice. Parla del protocollo git che viene scavato nel tunnel su SSH.

Dal mio punto di vista, a meno che non si connetta alla porta git (porta agente), il protocollo non è in vigore. E SSH è un semplice trasferimento di file non compresso.
Ma secondo l'autore, se usiamo SSH, dice che il protocollo git è scavalcato. Quindi SSH è più intelligente in GIT?

Von C, Grazie per la risposta. "I protocolli di rete (HTTP e Git) sono generalmente di sola lettura" Git può essere creato rw quando si esegue il demone con --enable = receive-pack.

Di seguito sono le mie preoccupazioni. Quando dicono che il protocollo git è intelligente, significano quando si esegue git clone, git server agent comprime i dati che vengono inviati al client, quindi il clone dovrebbe essere più veloce. Im my usecase imposterò il server git in hongkong e lo useremo su sanjose e in altri paesi, quindi voglio essere efficiente sulla rete a causa di problemi di latenza.

Quindi la mia domanda è quando uso git clone ssh: // utente @ server/reposloc ottengo anche i vantaggi del protocollo git. Come per il libro dell'autore di Orelly, intende git è scavato nel tunnel su ssh, quindi come funziona il protocollo git quando non ho git daeomon in esecuzione sul server.

Quindi utilizzare SSh: // xyz ... offre sia il vantaggio dei protocolli ssh e git?

apprezzare le vostre risposte in anticipo.

fonte

2010-07-14 vengateswaran c

"Quindi utilizzare SSh: // xyz ... offre entrambi i vantaggi dei protocolli ssh e git?" Sì –

Non riesco ancora a vedere una risposta alla domanda. Ho molti gigabytes da tirare e posso usare ssh o https, il che richiederà meno tempo? –

Date un'occhiata a la seconda parte di this page

L'unico protocollo "stupido" è HTTP diritto, che non richiede uno sforzo particolare sul server. In entrambi i protocolli git: // e ssh: //, un processo git upload-pack (che non è un daemon) è biforcato sul server che comunica con il client che esegue git fetch-pack. In entrambi ssh: // e git: //, si ottiene una comunicazione "intelligente".

fonte

2010-07-14 20:20:31 erjiang

Ciao Mazin ... Grazie. Questo risponde alle mie preoccupazioni. Grazie a tutti per il vostro contributo. –

git: // non ha il sovraccarico di autenticazione o crittografia che ssh: // implementa. git: // utilizza lo stesso veloce meccanismo di trasferimento dei dati di ssh: // ma è meno intenso sul lato server. – aus

Neat. Mi limiterò a SSH perché è costruito pensando alla sicurezza. –

Da Wikipedia:

Per impostare un tunnel SSH, si configura un client SSH per inoltrare una porta locale specificata una porta sulla macchina remota. Una volta stabilito il tunnel SSH, l'utente può connettersi alla porta locale specificata per accedere al servizio di rete. . La porta locale non è necessario che lo abbia lo stesso numero di porta della porta remota.

Se avete bisogno di un qualche tipo di rappresentazione ASCII art:

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

fonte

2010-07-14 17:33:26

Grazie per questa risposta, risponde alla mia preoccupazione, ma puoi dirmi qual è l'url utilizzato per garantire che la richiesta sia effettivamente sintonizzata su git protocol server. È una cosa che collega ssh: // user @ host: [git port]/repository location ??? i pls confermano –

non viene eseguito il tunneling su alcun server di protocollo. tu non vuoi usare il protocollo git nudo, non è una soluzione ottimale. –

Quando si accede a git tramite ssh solo il tunneling del protocollo git tramite ssh, modo più semplice per impostare e il modo più sicuro, questo il modo preferito per accedere ai repository remoti.

Questo è in realtà "più intelligente" rispetto al protocollo git nudo, perché può imporre l'autenticazione dell'utente tramite i meccanismi ssh. git esegue tutta la compressione e ciò che non è sul client indipendentemente dal livello di trasporto e lo decomprime sul server.

Il server "git" non esegue questa operazione, tutto ciò accade anche quando si utilizza ssh.il server git dovrebbe essere evitato se si vuole essere in grado di scrivere sul repository remoto. se vuoi leggere solo l'accesso git o i trasporti HTTP sono "OK", ma se hai sviluppatori che devono scrivere sul repository devi semplicemente usare ssh. La configurazione dei tunnel per il server Git sta solo aggiungendo complessità e configurazione che saranno fragili e non ti faranno guadagnare nulla.

fonte

2010-07-14 17:34:12

Grazie. Non sono in grado di essere completamente d'accordo con questa risposta. Perché non è necessario che il daemon GIT sia in esecuzione se si utilizza git push ssh: // utente @ server/posizione. Quando git daemon non è in esecuzione, come si dice git viene scavalcato tramite SSH?Chi gestisce il protocollo git, se il server del protocollo git non è in esecuzione? –

ssh è solo il trasporto, parla ancora del "protocollo git" su ssh. Questo è il modo in cui funziona su ssh, git su ssh è il metodo più efficiente per lavorare con i repository remoti. Hai ancora bisogno di git sul computer remoto, ma non usa un demone, non è così complicato. –

Sono abbastanza sicuro che c'è una differenza tra ssh: // e git + ssh: //. – erjiang

Aggiornamento 2010-2014:

Sia ssh e https sono equivalenti, dal momento che Git 1.6.6+ (2010) e la realizzazione di smart http protocol:

smart http

È ora possibile utilizzare ssh o https per l'accesso in lettura/scrittura ai tuoi repository.
È inoltre possibile detect if your remote server supports smart http.
Aggiungere la giusta variabile di ambiente se è necessario utilizzare un proxy.

Q3 2015, come Yousha Aleayoub menzioni in the comments:

GitHub "Which remote URL should I use?"

I https:// URL clone sono disponibili su tutti i repository, pubblici e privati.
Sono intelligenti, quindi forniranno accesso in sola lettura o in lettura/scrittura, a seconda delle autorizzazioni al repository.

Il git-http-backend è il: semplice programma

CGI per servire il contenuto di un repository Git Git ai clienti accesso a repository su http:// e https:// protocolli.
Il programma supporta il recupero dei client utilizzando sia il protocollo HTTP intelligente e il protocollo dumb HTTP compatibile con le versioni precedenti, sia i client che utilizzano il protocollo HTTP intelligente.

risposta Originale (luglio 2010):

Dal Pro Git Book:

Probabilmente il protocollo di trasporto più comune per Git è SSH.
Questo perché l'accesso SSH ai server è già impostato nella maggior parte dei casi e, in caso contrario, è facile.

SSH è anche l'unico protocollo basato su rete che è possibile leggere e scrivere su. Gli altri due protocolli di rete (HTTP e Git) sono generalmente di sola lettura, quindi, anche se li hai disponibili per le masse non lavate, hai ancora bisogno di SSH per i tuoi comandi di scrittura.

SSH è anche un protocollo di rete autenticato; e poiché è onnipresente, è generalmente facile da configurare e utilizzare.

Quindi non è "più intelligente" del protocollo Git, solo un protocollo complementare per alcune funzionalità non affrontate dal protocollo Git.

Lo svantaggio del protocollo Git è la mancanza di autenticazione. In genere non è auspicabile che il protocollo Git sia l'unico accesso al tuo progetto.
In generale, si associa con accesso SSH per i pochi sviluppatori che hanno spinta (scrittura) l'accesso e hanno tutti gli altri uso git:// per accesso in sola lettura

Si richiede inoltre l'accesso firewall per port 9418, che isn' t una porta standard che i firewall aziendali consentono sempre. Dietro i grandi firewall aziendali, questa porta oscura è comunemente bloccata.

(è per questo che nel mio negozio, ho bisogno per usare ssh + git e non solo git, anche per l'accesso in lettura: 9418 è bloccato ...)

fonte

2010-07-14 17:35:33 VonC

+1 Convinto, ritengo che questa dovrebbe essere la risposta giusta in quanto la spiega meglio anche per i noobs. – Val

@Val grazie. L'uso di ssh comporta il proprio dibattito sulla gestione degli accessi degli utenti: vedere i commenti di http://stackoverflow.com/a/16184533/6309 – VonC

Nota per sé: con il 25esimo voto positivo, il distintivo d'argento "Buona risposta" per questa risposta è il mio 1000 (mi ci sono voluti quasi 6 anni). – VonC

I vari protocolli sono a diversi livelli (ad esempio il modello a livello di ISO 7), quindi è possibile avere entrambi, proprio come si potrebbe essere connessi tramite fili o wireless o fibra ottica.

fonte

2011-07-17 18:08:44

(ho voluto aggiungere un commento a @erjiang risposta, ma non mi è permesso perché non ho abbastanza reputazione StackOverflow.)

Sembra che da Git 1.6.6, HTTP non è " stupido "più. Da Git website's blog:

Come del rilascio della versione 1.6.6 alla fine dello scorso anno (2009), tuttavia, Git possono ora utilizzare il protocollo HTTP quasi nel modo più efficiente le git o ssh versioni

fonte

2014-01-13 11:42:00 Xavi

Una ricerca rapida dei file del pacchetto durante un clone git elencherà un singolo file del pacchetto che viene inviato dal server al client. Il file del pacchetto è elencato in .git/objects/pack/pack-XXXX.pack. I file da inviare dal server al client vengono prima compressi e compressi. Poi c'è una singola copia del contenuto imballato. Questo può essere visto quando si confrontano i file compressi usando lsof -p sul lato server e lsof -p sul lato client. Nel caso di esempio, un file da 200 MB viene caricato dal server al client ....

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.

fonte

2014-06-17 17:04:11

Quale è il protocollo più veloce, ssh o git?

risposta

Problemi correlati