Quel est le protocole plus intelligent git, ssh ou git (over ssh) ou https?
Lequel est efficace? SSH: // ou Git: // (compression de fichier)
Je comprends que dans Git, le protocole Git soit intelligent, car il existe un agent de protocole aux deux extrémités de la communication pour compresser le transfert de fichier, ce qui permet un clonage plus rapide en utilisant efficacement la bande passante du réseau.
De un livre d’O'Reilly j’ai trouvé les affirmations suivantes.
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*
Je ne suis pas sûr si l'auteur veut dire ce qu'il dit. Il parle du fait que le protocole Git soit tunnelisé sur SSH.
De mon point de vue, à moins que vous ne vous connectiez au port git (port de l'agent), le protocole n'est pas en vigueur. Et SSH est un simple transfert de fichier non compressé.
Mais selon l’auteur, si nous utilisons SSH, il dit que le protocole git est tunnellisé. Alors, SSH est-il plus intelligent dans GIT?
Von C, .__ Merci pour votre réponse. "Les protocoles réseau (HTTP et Git) sont généralement en lecture seule" Git peut être rendu rw lorsque vous exécutez le démon avec --enable=receive-pack.
Voici mes préoccupations.
Quand ils disent que le protocole git est intelligent, ils veulent dire que lorsque vous exécutez git clone, l'agent de serveur git compresse les données qui sont renvoyées au client, le clone devrait donc être plus rapide. Dans mon cas d'utilisation, je vais configurer le serveur git à Hong Kong et l'utiliser également à San José et dans d'autres pays. Je souhaite donc être efficace sur le réseau en raison de problèmes de latence.
Donc, ma question est la suivante: quand est-ce que j'utilise git clone ssh://user@server/reposloc, bénéficie-t-il également des avantages du protocole git? Selon le livre de l'auteur O'Reilly, il veut dire que git est tunnelé sur ssh, alors comment fonctionne le protocole git quand le démon git ne s'exécute pas sur le serveur.
Donc, utiliser SSh: // xyz ... donne-t-il à la fois l'avantage des protocoles ssh et git?
Appréciez vos réponses à l'avance.
Jetez un coup d'œil à la deuxième partie de cette page
Le seul protocole "bête" est le protocole HTTP simple, qui ne nécessite aucun effort particulier sur le serveur. Dans les protocoles git: // et ssh: //, un processus git upload-pack (qui n'est pas un démon) est créé sur le serveur qui communique avec le client exécutant git fetch-pack. Dans ssh: // et git: //, vous obtenez une communication "intelligente".
Lorsque vous accédez à git sur ssh, il tunnelise le protocole git sur ssh, ce qui est beaucoup plus facile à configurer et plus sûr. C'est le moyen privilégié pour accéder aux référentiels distants.
C’est en fait plus "intelligent" que le protocole bare git, car il peut imposer l’authentification de l’utilisateur via des mécanismes ssh. git effectue toutes les compressions et autres sur le client, quelle que soit la couche de transport, et le décompresse sur le serveur.
Le serveur "git" ne le fait pas, tout cela se produit également avec ssh. le serveur git doit être évité si vous voulez pouvoir écrire dans le référentiel distant. si vous voulez un accès en lecture seule, les transports git ou HTTP sont "OK", mais si vous avez des développeurs qui ont besoin d'écrire dans le référentiel, vous devez simplement utiliser ssh. La configuration de tunnels pour le serveur git ne fait qu'ajouter à la complexité et à la configuration qui seront fragiles et ne vous rapporteront rien.
(Je voulais ajouter un commentaire à la réponse de @erjiang, mais je ne suis pas autorisé car je n'ai pas assez de réputation StackOverflow.)
Il semble que depuis Git 1.6.6, HTTP ne soit plus "idiot". De Blog du site Git :
À compter de la publication de la version 1.6.6 à la fin de l’année dernière (2009), cependant, Git peut maintenant utiliser le protocole HTTP à peu près aussi efficacement que le git ou versions ssh
Les différents protocoles se situant à différents niveaux (par exemple, le modèle de couche ISO 7), vous pouvez donc disposer des deux, tout comme vous pouvez être connecté par fil ou sans fil, ou par fibre.
De Wikipedia :
Pour configurer un tunnel SSH, on configure un client SSH pour qu'il transfère un port local spécifié à un port sur la machine distante. Une fois le tunnel SSH établi, l'utilisateur peut connectez-vous au port local spécifié pour accéder au service réseau. Le port local n'a pas besoin avoir le même numéro de port que le port distant.
Si vous avez besoin d'une sorte de représentation artistique ASCII:
Git Data ---> [SSH encrypts data] ----- Internet -----> [SSH decrypts data] ----> Git Data
Une recherche rapide des fichiers de pack lors d'un clone git répertorie un fichier de pack unique envoyé par le serveur au client. Le fichier de pack est répertorié sous .git/objects/pack/pack-XXXX.pack. Les fichiers à envoyer du serveur au client sont d’abord compressés. Ensuite, il y a une seule copie du contenu emballé. Cela peut être constaté lors de la comparaison des fichiers compressés à l'aide de lsof -p côté serveur et de lsof -p côté client. Dans l'exemple, des fichiers de 200 Mo sont téléchargés du serveur vers le 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.