哪个更快,SSH或GIT协议?

哪个有效? SSH://或者Git://(文件压缩)

我在Git中了解到,git协议很聪明,因为在通信的两端都有一个协议代理来压缩文件传输,从而通过有效地使用networking带宽来加快克隆速度。

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

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

从我的angular度来看,除非连接到git端口(代理端口),否则协议不起作用。 而SSH仅仅是压缩文件传输。
但是按照作者的说法,如果我们使用SSH,他说git协议是通过它隧道的。 SSH在GIT中更聪明吗?

冯C,谢谢你的回答。 “networking协议(HTTP和Git)通常是只读的”当使用–enable = receive-pack运行deamon时,可以使Git成为rw。

以下是我的担忧。 当他们说git协议是聪明的,他们的意思是当你执行git clone时,git server agent会压缩发送回客户端的数据,所以克隆应该更快。 在我的用例中,我将在香港设置git服务器,并在sanjose和其他国家使用它,所以我想因为延迟问题而在networking上高效。

所以我的问题是当我使用git克隆ssh:// user @ server / reposloc我也得到了git协议的好处。 按照Orelly作者的书,他的意思是git通过ssh传输,那么当我没有在服务器上运行git daeomon时,git协议是如何工作的。

所以使用SSh:// xyz …它是否同时提供了ssh和git协议的好处?

提前感谢您的回答。

看看这个页面的第二部分

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

2010-2014年最新情况:

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

智能http

您现在可以使用SSH或HTTPS的读/写访问您的回购。
您还可以检测您的远程服务器是否支持智能http 。
如果您必须使用代理,请添加正确的环境variables。

2015年第三季度, Yousha Aleayoub 在评论中提到:

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

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

git-http-backend是:

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


原文答案(2010年7月):

从Pro Git Book :

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

SSH也是唯一可以轻松读取和写入的基于networking的协议 。 另外两种networking协议(HTTP和Git)通常是只读的,所以即使你已经有了这些协议,你仍然需要使用SSH来完成自己的写命令。

SSH也是一个authentication的networking协议 ; 而且因为它无处不在,所以设置和使用通常很容易。

所以它并不比Git协议“更聪明”,只是Git协议未涉及的特定function的补充协议。

Git协议的缺点是缺乏身份validation。 Git协议是唯一可以访问您的项目的通常是不可取的。
一般来说,你可以将它与SSH访问配对,为less数几个有推(写)访问权限的开发人员configuration,并让其他人使用git://进行只读访问

它还需要防火墙访问端口9418,这不是企业防火墙始终允许的标准端口。 在大公司防火墙后面,这个隐蔽的端口通常被阻塞。

(这就是为什么在我的店里,我需要使用ssh + git,而不仅仅是git,即使是读访问:9418 被阻止了…)

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

这实际上比纯粹的git协议“更聪明”,因为它可以通过ssh机制强制用户身份validation。 git不pipe传输层如何都执行所有压缩和不在客户端上的操作,并在服务器上对其进行解压缩。

“混帐”服务器不这样做,所有这一切都发生在使用SSH时。 如果你想写远程仓库,应该避免使用git服务器。 如果你想只读访问git或HTTP传输是“OK”,但是如果你有开发人员需要写入存储库,你应该只使用SSH。 为git服务器设置隧道只是增加了复杂性和configuration,这将是脆弱的,并没有得到什么。

(我想给@erjiang回答添加评论,但是我没有被允许,因为我没有足够的StackOverflow声望。)

看来从Git 1.6.6开始,HTTP不再是“哑巴”了。 从Git网站的博客 :

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

维基百科 :

要build立SSH隧道,需要configurationSSH客户端将指定的本地端口转发到远程机器上的端口。 一旦build立了SSH隧道,用户就可以连接到指定的本地端口来访问networking服务。 本地端口不需要与远程端口具有相同的端口号。

如果您需要某种ASCII艺术performanceforms:

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

各种协议都在不同的层面上(例如ISO 7层模型),所以你可以同时使用这两种协议,就像你可以通过有线或无线连接,或者光纤一样。

在git克隆中快速search包文件将列出从服务器发送到客户端的单个包文件。 包文件列在.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.