哪个是更智能的 git 协议，ssh 或 git（通过 ssh）或 https 协议？

Which is the smarter git protocol, ssh or git(over ssh) or https protocol?

提问by vengateswaran c

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

哪个有效？SSH:// 或 Git://（文件压缩）

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

我在 Git 中理解，git 协议是智能的，因为在通信的两端都有一个协议代理来压缩文件传输，从而通过有效地使用网络带宽来加快克隆速度。

From an O'Reilly bookI found the following statements.

从O'Reilly 的一本书中，我发现了以下陈述。

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.

我不确定作者是否是他所说的意思。他谈到了通过 SSH 建立隧道的 git 协议。

From my perspective, unless you connect to the git port (agent port), the protocol is not in effect. And SSH is merely an 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?

在我看来，除非你连接到 git 端口（代理端口），否则协议是无效的。SSH 只是一种未压缩的文件传输。但是按照作者的说法，如果我们使用 SSH，他说 git 协议是通过它隧道传输的。那么 SSH 在 GIT 中更智能吗？

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

Von C，谢谢你的回答。“网络协议（HTTP 和 Git）通常是只读的”rw当您使用--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. In my use case I'll be setting the Git server in Hongkong and using it on San Jose and other countries as well, So I want to be efficient over network due to latency concerns.

以下是我的担忧。
当他们说 git protocol is smart 时，他们的意思是当您执行 时git clone，Git 服务器代理会压缩发送回客户端的数据，因此克隆应该更快。在我的用例中，我将在香港设置 Git 服务器并在圣何塞和其他国家/地区使用它，因此由于延迟问题，我希望通过网络提高效率。

So my question is when I use git clone ssh://user@server/reposlocdo I get the benefits of git protocol also? As per O'Reilly author book he means git is tunneled over ssh, then how does git protocol work when I don't have git daemon running on the server.

所以我的问题是，当我使用时，我git clone ssh://user@server/reposloc还能获得 git 协议的好处吗？根据 O'Reilly 作者的书，他的意思是 git 通过 ssh 建立隧道，然后当我没有在服务器上运行 git 守护程序时，git 协议如何工作。

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

那么使用 SSh://xyz ... 它是否同时提供了 ssh 和 git 协议的好处？

Appreciate your answers in advance.

提前感谢您的回答。

采纳答案by erjiang

Take a look at the second part of this page

看看这个页面的第二部分

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-packprocess (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.

唯一的“哑巴”协议是直接的 HTTP，它不需要在服务器上做特别的努力。在 git:// 和 ssh:// 协议中，一个git upload-pack进程（不是守护进程）在与运行git fetch-pack. 在 ssh:// 和 git:// 中，您都可以获得“智能”通信。

回答by VonC

Update 2010-2014:

2010-2014 年更新：

Both ssh and https are equivalent, since Git 1.6.6+ (2010) and the implementation of smart http protocol:

ssh 和 https 是等效的，因为 Git 1.6.6+ (2010) 和智能 http 协议的实现：

You now can use ssh or https for read/write access to your repos.
You can also detect if your remote server supports smart http.
Add the right environment variable if you have to use a proxy.

您现在可以使用 ssh 或 https 对您的存储库进行读/写访问。
您还可以检测您的远程服务器是否支持智能 http。
如果必须使用代理，请添加正确的环境变量。

Q3 2015, as Yousha Aleayoubmentions in the comments:

2015 年第三季度，正如Yousha Aleayoub在评论中提到的：

GitHub "Which remote URL should I use?"

GitHub“我应该使用哪个远程 URL？”

The https://clone URLs are available on all repositories, public and private.
They are smart, so they will provide you with either read-only or read/write access, depending on your permissions to the repository.

该https://克隆网址，可在所有存储库，公共和私人。
它们很聪明，因此它们将为您提供只读或读/写访问权限，具体取决于您对存储库的权限。

The git-http-backendis the:

这git-http-backend是：

simple CGI program to serve the contents of a Git repository to Git clients accessing the repository over http://and https://protocols.
The program supports clients fetching using both the smart HTTP protocol and the backwards-compatible dumb HTTP protocol, as well as clients pushing using the smart HTTP protocol.

简单的 CGI 程序，用于将 Git 存储库的内容提供给通过http://和https://协议访问存储库的 Git 客户端。
该程序支持使用智能HTTP协议和向后兼容的哑HTTP协议的客户端获取，以及使用智能HTTP协议的客户端推送。

---

---

Original answer (July 2010):

原始答案（2010 年 7 月）：

From the Pro Git Book:

来自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.

Git 最常见的传输协议可能是 SSH。
这是因为在大多数地方已经设置了对服务器的 SSH 访问——如果没有，这很容易做到。

SSH 也是唯一可以轻松读取和写入的基于网络的协议。其他两个网络协议（HTTP 和 Git）通常是只读的，因此即使您将它们用于未清洗的大众，您仍然需要 SSH 来执行您自己的写入命令。

SSH 也是一种经过身份验证的网络协议；并且因为它无处不在，所以通常很容易设置和使用。

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

因此，它并不比 Git 协议“更智能”，只是针对 Git 协议未解决的某些功能的补充协议。

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.

Git 协议的缺点是缺乏身份验证。Git 协议作为对项目的唯一访问通常是不可取的。
通常，您会将其与 SSH 访问配对，以供少数拥有推送（写入）访问权限且其他所有人都使用git://只读访问权限的开发人员使用

它还需要防火墙访问端口 9418，这不是企业防火墙始终允许的标准端口。在大型企业防火墙后面，这个不起眼的端口通常被阻止。

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

（这就是为什么在我的商店中，我需要使用 ssh+git 而不仅仅是 git，即使是读取访问：9418被阻止...）

回答by Xavi

(I wanted to add a comment to @erjiang answer, but I'm not allowed because I don't have enough StackOverflow reputation.)

（我想在@erjiang 的答案中添加评论，但我不被允许，因为我没有足够的 StackOverflow 声誉。）

It seems that since Git 1.6.6, HTTP is not "dumb" anymore. From Git website's blog:

似乎从 Git 1.6.6 开始，HTTP 不再是“哑巴”了。来自Git 网站的博客：

As of the release of version 1.6.6 at the end of last year (2009), however, Git can now use the HTTP protocol just about as efficiently as the git or ssh versions

然而，截至去年年底（2009 年）发布 1.6.6 版本，Git 现在可以像 git 或 ssh 版本一样有效地使用 HTTP 协议

回答by Xavi

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.

当您通过 ssh 访问 git 时，它只是通过 ssh 隧道传输 git 协议，这样更容易设置且更安全，这是访问远程存储库的首选方式。

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.

这实际上比裸 git 协议“更智能”，因为它可以通过 ssh 机制强制执行用户身份验证。无论传输层如何，git 都会在客户端执行所有压缩以及不在客户端上的操作，并在服务器上对其进行解压缩。

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.

“git”服务器不会这样做，所有这些在使用 ssh 时也会发生。如果您希望能够写入远程存储库，则应避免使用 git 服务器。如果您想要只读访问 git 或 HTTP 传输是“OK”，但如果您的开发人员需要写入存储库，您应该只使用 ssh。为 git 服务器设置隧道只会增加复杂性和配置，这将是脆弱的，并且一无所获。

回答by Sachin Naik

A quick search of the pack files during a git clone will list a single pack file that is sent from the server to the client. The pack file is listed under .git/objects/pack/pack-XXXX.pack. The files to be sent from the server to the client are first packed, compressed. Then there is a single copy of the packed contents. This can be seen when comparing the packed files using lsof -p on the server side and lsof -p on the client side. In the sample case a 200MB files is uploaded from the server to the client....

在 git clone 期间快速搜索包文件将列出从服务器发送到客户端的单个包文件。包文件列在 .git/objects/pack/pack-XXXX.pack 下。要从服务器发送到客户端的文件首先被打包、压缩。然后是打包内容的单个副本。这可以在服务器端使用 lsof -p 和客户端使用 lsof -p 比较打包文件时看到。在示例案例中，一个 200MB 的文件从服务器上传到客户端......

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.

回答by Philip Oakley

The various protocols are at different levels (e.g. the ISO 7 layer model), so you can have both, just as you could be connected by Wires or Wirelessly, or fibre.

各种协议处于不同级别（例如 ISO 7 层模型），因此您可以同时拥有两者，就像您可以通过有线或无线或光纤连接一样。

回答by David Pratte

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.

要设置 SSH 隧道，需要配置 SSH 客户端以将指定的本地端口转发到远程计算机上的端口。一旦建立了 SSH 隧道，用户就可以连接到指定的本地端口来访问网络服务。本地端口不需要与远程端口具有相同的端口号。

If you need some kind of ASCII art representation:

如果您需要某种 ASCII 艺术表现形式：

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