Which is faster, ssh or git protocol?

Question

Which is effecient? SSH:// or Git:// (File compression)

I understand in Git , git protocol is smart because there is a protocol agent on both end of commumnication to compress the file transfer resulting in faster clone by effeciently using the network bandwidth.

From an O'Reilly book I found the following statements.

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*

I'm not sure if the author means what he says. He talks of git protocol getting tunneled over SSH.

From my perspective, unless you connect to the git port (agent port), the protocol is not in effect. And SSH is mere uncompressed file transfer.
But as per the author, if we use SSH he says the git protocol is tunneled over it. So is SSH smarter in GIT?

Von C, Thanks for your answer. "Network protocols (HTTP and Git) are generally read-only" Git can be made rw when you run the deamon with --enable=receive-pack.

Following are my concerns. When they say git protocol is smart, they mean when you execute git clone , git server agent compresses the data that is sent back to the client , so the clone should be faster. Im my usecase i will be setting the git server in hongkong and using it on sanjose and other countries as well , So i want to be efficient over network due to latency concerns.

So my question is when i use git clone ssh://user@server/reposloc do i get the benefits of git protocol also . As per Orelly author book he means git is tunneled over ssh, then how does git protocol work when i dont have git daeomon running on the server.

So using SSh://xyz... does it give both the benefit of ssh and git protocols ?

appreciate your answers in advance.

Answer 1

From Wikipedia:

To set up an SSH tunnel, one configures an SSH client to forward a specified local port to a port on the remote machine. Once the SSH tunnel has been established, the user can connect to the specified local port to access the network service. The local port need not have the same port number as the remote port.

If you need some kind of ASCII art representation:

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

Answer 2

When you access git over ssh it just tunnels the git protocol over ssh, way easier to set up and way more secure, this the preferred way to access remote repositories.

This is actually "smarter" than the bare git protocol, because it can enforce user authentication via ssh mechanisms. git does all the compressing and what not on the client regardless of the transport layer, and it decompresses it on the server.

The "git" server doesn't do this, all this happens when using ssh as well. the git server should be avoided if you want to be able to write to the remote repository. if you want read only access git or HTTP transports are "OK", but if you have developers that need to write to the respository you should just use ssh. Setting up tunnels for the git server is just adding to complexity and configuration that will be brittle and gain you nothing.

Answer 3

From the Pro Git Book:

Probably the most common transport protocol for Git is SSH.
This is because SSH access to servers is already set up in most places — and if it isn’t, it’s easy to do.

SSH is also the only network-based protocol that you can easily read from and write to. The other two network protocols (HTTP and Git) are generally read-only, so even if you have them available for the unwashed masses, you still need SSH for your own write commands.

SSH is also an authenticated network protocol; and because it’s ubiquitous, it’s generally easy to set up and use.

So it is not "smarter" than Git protocol, just a complementary protocol for certain features not addressed by the Git protocol.

The downside of the Git protocol is the lack of authentication. It’s generally undesirable for the Git protocol to be the only access to your project.
Generally, you’ll pair it with SSH access for the few developers who have push (write) access and have everyone else use git:// for read-only access

It also requires firewall access to port 9418, which isn’t a standard port that corporate firewalls always allow. Behind big corporate firewalls, this obscure port is commonly blocked.

(that is why in my shop, I need to use ssh+git and not just git, even for read access: 9418 is blocked...)

Answer 4

don't post follow up questions as answers, edit the original question

Answer 5

Take a look at the second part of this page: http://book.git-scm.com/7_transfer_protocols.html

The only "dumb" protocol is straight HTTP, which requires no special effort on the server. In both the git:// and ssh:// protocols, a git upload-pack process (which is not a daemon) is forked on the server that communicates with the client who's running git fetch-pack. In both ssh:// and git://, you get "smart" communication.