哪个更聪明的git协议，ssh或git（通过ssh）或https协议？

Question

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

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

从an O'Reilly book我发现了以下陈述。

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*

我不确定作者是否意味着他所说的。他谈到git协议通过SSH进行隧道传输。

从我的角度来看，除非你连接到git端口（代理端口），否则协议不起作用。 SSH仅仅是未压缩的文件传输 但是根据作者的说法，如果我们使用SSH，他说git协议是通过它进行隧道传输的。那么在GIT中更聪明的是SSH吗？

Von C， 感谢您的回答。 “网络协议（HTTP和Git）通常是只读的”当您使用rw运行守护程序时，可以使用--enable=receive-pack Git。

以下是我的担忧 当他们说git协议是智能的时，他们就意味着当你执行git clone时，git服务器代理会压缩发送回客户端的数据，因此克隆应该更快。在我的用例中，我将在香港设置git服务器，并在圣何塞和其他国家使用它，所以我希望由于延迟问题而在网络上保持高效。

所以我的问题是当我使用git clone ssh://user@server/reposloc时，我是否也获得了git协议的好处？根据O'Reilly作者的书，他的意思是git通过ssh进行隧道传输，那么当我没有在服务器上运行git守护进程时，git协议如何工作。

所以使用SSh：// xyz ...它是否同时提供了ssh和git协议的好处？

提前感谢您的答案。

Answer 1

2010-2014更新：

自Git 1.6.6 +（2010）以及 smart http protocol 的实施以来，ssh和https都是等效的：

您现在可以使用ssh或https对您的回购进行读/写访问 您还可以detect if your remote server supports smart http 如果必须使用代理，请添加正确的环境变量。

2015年第3季度，Yousha Aleayoub提及in the comments：

GitHub "Which remote URL should I use?"

  

所有存储库（公共和私有）都可以使用https://克隆URL   它们很聪明，因此它们将为您提供只读或读/写访问权限，具体取决于您对存储库的权限。

git-http-backend是：

  

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

---

原始答案（2010年7月）：

来自Pro Git Book：

  

Git最常见的传输协议可能是SSH   这是因为在大多数地方已经建立了对服务器的SSH访问 - 如果不是这样，那么很容易做到。

     

SSH也是唯一可以轻松读取和写入的基于网络的协议。另外两个网络协议（HTTP和Git）通常是只读的，所以即使你有可用于未洗涤的群体，你仍然需要SSH来处理你自己的写命令。

     

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

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

  

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

     

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

（这就是为什么在我的商店，我需要使用ssh + git而不仅仅是git，即使是读取权限：9418 被阻止...）< / p>

Answer 2

看看this page

的第二部分

唯一的“哑”协议是直接HTTP，在服务器上不需要特别的努力。在git：//和ssh：//协议中，git upload-pack进程（不是守护进程）在服务器上分叉，该服务器与正在运行git fetch-pack的客户端通信。在ssh：//和git：//中，您都可以进行“智能”通信。

Answer 3

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

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

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

Answer 4

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

似乎自Git 1.6.6以来，HTTP不再“愚蠢”了。来自Git website's blog：

  

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

Answer 5

来自Wikipedia：

  

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

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

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

Answer 6

各种协议处于不同的级别（例如ISO 7层模型），因此您可以同时使用Wires或Wirelessly或光纤连接两者。

Answer 7

在git clone期间快速搜索pack文件将列出从服务器发送到客户端的单个pack文件。包文件列在.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.