wake-up-neo.com

Welches ist das intelligentere Git-Protokoll, SSH oder Git (über SSH) oder https-Protokoll?

Welches ist effizient? SSH: // oder Git: // (Dateikomprimierung)

Ich verstehe in Git, dass Git-Protokoll intelligent ist, da es an beiden Enden der Kommunikation einen Protokollagenten gibt, um die Dateiübertragung zu komprimieren, was zu einem schnelleren Klonen führt, indem die Netzwerkbandbreite effizient genutzt wird.

Aus einem O'Reilly-Buch habe ich die folgenden Aussagen gefunden.

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*

Ich bin nicht sicher, ob der Autor meint, was er sagt. Er spricht davon, dass Git-Protokoll über SSH getunnelt wird. 

Aus meiner Sicht ist das Protokoll nicht wirksam, es sei denn, Sie stellen eine Verbindung zum Git-Port (Agent-Port) her. Und SSH ist nur eine unkomprimierte Dateiübertragung.
Wenn wir SSH verwenden, sagt er, dass das git-Protokoll darüber getunnelt wird. Ist SSH also intelligenter in der GIT?

Von C. Danke für Ihre Antwort. "Netzwerkprotokolle (HTTP und Git) sind im Allgemeinen schreibgeschützt" Git kann rw erstellt werden, wenn Sie den Deamon mit --enable=receive-pack ausführen. 

Folgendes sind meine Bedenken.
Wenn sie sagen, dass das git-Protokoll intelligent ist, bedeutet dies, dass der git Server-Agent beim Ausführen von git clone die an den Client zurückgesendeten Daten komprimiert, sodass der Klon schneller sein sollte. In meinem Anwendungsfall werde ich den Git-Server in Hongkong einrichten und auch in San Jose und anderen Ländern verwenden. Daher möchte ich aufgrund von Latenzproblemen über das Netzwerk effizient sein.

Meine Frage ist also, wenn ich git clone ssh://[email protected]/reposloc benutze, bekomme ich auch die Vorteile des git-Protokolls? Laut O'Reillys Autorenbuch bedeutet er, dass git über ssh getunnelt wird. Wie funktioniert das git-Protokoll, wenn auf dem Server kein git-Daemon läuft?.

Also mit SSh: // xyz ... hat es den Vorteil der Protokolle ssh und git?

Schätzen Sie Ihre Antworten im Voraus.

44
vengateswaran c

Werfen Sie einen Blick auf den zweiten Teil von diese Seite

Das einzige "dumme" Protokoll ist reines HTTP, das keinen besonderen Aufwand auf dem Server erfordert. In den beiden Protokollen git: // und ssh: // wird ein git upload-pack-Prozess (der kein Dämon ist) auf dem Server verzweigt, der mit dem Client kommuniziert, der git fetch-pack ausführt. In beiden ssh: // und git: // erhalten Sie eine "intelligente" Kommunikation.

38
erjiang

Update 2010-2014:

Sowohl ssh als auch https sind gleichwertig, seit Git 1.6.6+ (2010) und der Implementierung von smart http protocol:

smart http

Sie können jetzt ssh oder https für den Lese-/Schreibzugriff auf Ihre Repos verwenden.
Sie können auch erkennen, ob Ihr Remote-Server Smart http unterstützt.
Fügen Sie die richtige Umgebungsvariable hinzu, wenn Sie einen Proxy verwenden müssen.

Q3 2015, als Yousha Aleayoub Erwähnungen in den Kommentaren :

GitHub "Welche Remote-URL sollte ich verwenden?"

Die https://-Klon-URLs sind für alle öffentlichen und privaten Repositorys verfügbar.
Sie sind intelligent, sodass Sie je nach Ihren Berechtigungen für das Repository entweder Schreib- oder Lese-/Schreibzugriff erhalten.

Der git-http-backend ist der:

einfaches CGI-Programm, um den Inhalt eines Git-Repositorys für Git-Clients bereitzustellen, die über http://- und https://-Protokolle auf das Repository zugreifen.
Das Programm unterstützt das Abrufen von Clients sowohl mit dem intelligenten HTTP-Protokoll als auch mit dem rückwärtskompatiblen dummen HTTP-Protokoll sowie mit Push-Clients, die das intelligente HTTP-Protokoll verwenden.


Ursprüngliche Antwort (Juli 2010):

Aus dem Pro Git Book :

Wahrscheinlich das häufigste Transportprotokoll für Git ist SSH.
Dies ist darauf zurückzuführen, dass der SSH-Zugriff auf Server an den meisten Orten bereits eingerichtet ist. Wenn dies nicht der Fall ist, ist das ganz einfach. 

SSH ist auch das einzige netzwerkbasierte Protokoll, aus dem Sie problemlos lesen und schreiben können. Die anderen beiden Netzwerkprotokolle (HTTP und Git) sind im Allgemeinen schreibgeschützt. Selbst wenn Sie sie für die ungewaschenen Massen zur Verfügung haben, benötigen Sie dennoch SSH für Ihre eigenen Schreibbefehle. 

SSH ist auch ein authentifiziertes Netzwerkprotokoll; und weil es allgegenwärtig ist, ist es im Allgemeinen einfach einzurichten und zu verwenden.

Es ist also nicht "intelligenter" als das Git-Protokoll, nur ein komplementäres Protokoll für bestimmte Funktionen, die nicht vom Git-Protokoll angesprochen werden.

Der Nachteil des Git-Protokolls ist die fehlende Authentifizierung. Im Allgemeinen ist es nicht wünschenswert, dass das Git-Protokoll der einzige Zugriff auf Ihr Projekt ist.
Im Allgemeinen werden Sie es mit dem SSH-Zugriff für die wenigen Entwickler koppeln, die über Push-Zugriff (Schreibzugriff) verfügen und alle anderen Benutzer git:// für den schreibgeschützten Zugriff verwenden

Außerdem ist ein Firewall-Zugriff auf Port 9418 erforderlich. Dies ist kein Standardport, den Unternehmensfirewalls immer zulassen. Hinter großen Firewalls ist dieser obskure Hafen normalerweise blockiert.

(das ist der Grund, warum ich in meinem Shop brauche, um ssh + git zu verwenden und nicht nur git, selbst für Lesezugriff: 9418 ist gesperrt ...)

48
VonC

Wenn Sie auf git über ssh zugreifen, wird das git-Protokoll einfach über ssh getunnelt. Dies ist viel einfacher einzurichten und sicherer. Dies ist der bevorzugte Weg, um auf entfernte Repositorys zuzugreifen. 

Dies ist tatsächlich "intelligenter" als das Bare-Git-Protokoll, da es die Benutzerauthentifizierung über SSH-Mechanismen erzwingen kann. git führt die gesamte Komprimierung aus und was nicht auf dem Client, unabhängig von der Transportschicht, und dekomprimiert sie auf dem Server. 

Der "git" -Server tut dies nicht, all dies geschieht auch bei Verwendung von ssh. Der Git-Server sollte vermieden werden, wenn Sie in das Remote-Repository schreiben möchten. Wenn Sie nur Lesezugriff haben möchten oder HTTP-Transporte "OK" sind, aber wenn Sie Entwickler haben, die in das Respository schreiben müssen, sollten Sie ssh verwenden. Das Einrichten von Tunneln für den Git-Server erhöht lediglich die Komplexität und Konfiguration, die spröde wird und Ihnen nichts bringt.

3
user177800

(Ich wollte @erjiang answer einen Kommentar hinzufügen, aber ich darf nicht, da ich nicht genügend StackOverflow-Reputation habe.)

Es scheint, dass HTTP seit Git 1.6.6 nicht mehr "dumm" ist. Aus dem Blog der Git-Website :

Ab dem Release der Version 1.6.6 Ende letzten Jahres (2009) jedoch Git kann das HTTP-Protokoll jetzt genauso effizient wie das Git .__ verwenden. oder ssh-Versionen 

2
Xavi

Die verschiedenen Protokolle befinden sich auf verschiedenen Ebenen (z. B. das ISO 7-Schichtenmodell). Sie können also beides haben, genauso wie Sie über Kabel oder drahtlos oder über Glasfaser verbunden sein könnten. 

1
Philip Oakley

Aus Wikipedia :

Um einen SSH-Tunnel einzurichten, wird ein SSH-Client so konfiguriert, dass er einen angegebenen lokalen Port an .__ weiterleitet. einen Port auf der Remote-Maschine. Nachdem der SSH-Tunnel eingerichtet wurde, kann der Benutzer Stellen Sie eine Verbindung zum angegebenen lokalen Port her, um auf den Netzwerkdienst zuzugreifen. Der lokale Port muss nicht haben die gleiche Portnummer wie der Remote-Port.

Wenn Sie eine Art ASCII Grafikdarstellung benötigen:

Git Data ---> [SSH encrypts data] ----- Internet -----> [SSH decrypts data] ----> Git Data
1
David Pratte

Eine schnelle Suche der Pack-Dateien während eines Git-Klons listet eine einzelne Pack-Datei auf, die vom Server an den Client gesendet wird. Die Packdatei ist unter .git/objects/pack/pack-XXXX.pack aufgeführt. Die vom Server an den Client zu sendenden Dateien werden zunächst gepackt und komprimiert. Dann gibt es eine einzige Kopie des gepackten Inhalts. Dies ist beim Vergleich der gepackten Dateien mit lsof -p auf der Serverseite und lsof -p auf der Clientseite ersichtlich. Im Beispielfall werden 200MB-Dateien vom Server zum Client hochgeladen.

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.
0
Sachin Naik