59

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

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

从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*

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

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

冯 C，谢谢你的回答。“网络协议（HTTP 和 Git）通常是只读的”rw当您使用--enable=receive-pack.

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

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

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

提前感谢您的回答。

4

7 回答 7

55

2010-2014 年更新：

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

智能http

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

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

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

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

是git-http-backend：

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

原始答案（2010 年 7 月）：

来自Pro Git 书：

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

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

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

所以它并不比 Git 协议“更聪明”，只是对 Git 协议未解决的某些功能的补充协议。

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

它还需要防火墙访问端口 9418，这不是公司防火墙始终允许的标准端口。在大公司的防火墙后面，这个不起眼的端口通常被封锁。

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

于 2010-07-14T17:35:33.273 回答
41

看看这个页面的第二部分

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

于 2010-07-14T20:20:31.787 回答
6

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

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

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

于 2014-01-13T11:42:00.930 回答
4

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

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

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

于 2010-07-14T17:34:12.840 回答
1

来自维基百科：

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

如果您需要某种 ASCII 艺术表示：

Git Data ---> [SSH encrypts data] ----- Internet -----> [SSH decrypts data] ----> Git Data
于 2010-07-14T17:33:26.133 回答
1

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

于 2011-07-17T18:08:44.237 回答
0

在 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.
于 2014-06-17T17:04:11.307 回答