文档章节

Google 的 Git v2 带来颠覆性性能提升?恐怕未必

小念仔
 小念仔
发布于 2018/05/27 11:23
字数 1211
阅读 8
收藏 0

作者简介

王振威,CODING 创始团队成员之一,多年系统软件开发经验,擅长 Linux,Golang,Java,Ruby,Docker 等技术领域,近两年来一直在 CODING 从事系统架构和运维工作

前言

最近 Google 发布了一篇文章,描述了对 Git 的一个传输协议的更新,引起了国内技术圈的不小规模的轰动(相关文章请自行百度“Git v2 性能提升”)。 很多技术圈的朋友也在转载这个新闻,那至于性能改进有多大,里面的细节是什么呢?事实上这次改动只在极端情况下有性能提升,绝大多数情况下,用户感受不到性能的提升。很多不明所以的转发大概是因为 Google 的品牌效应吧 :)

Git 是什么?

为了讲清楚 why,我们先来简单介绍一下 Git 相关的协议。如果你还不了解 Git,想了解更多内容,可参考其官方网站:http://git-scm.com/ . 也可来 https://coding.net/help/doc/git 这里了解如何在国内使用优质快速的 Git 托管服务。

Git 传输协议

Git 常见的有三种协议,SSH,HTTP(S),Git,使用最广泛的是前两种。

让我们来看一下, HTTP(S) 和 SSH 协议的使用示例

git clone https://git.coding.net/wzw/coding-demo.git

Cloning into 'coding-demo'...

remote: Counting objects: 3, done.

remote: Total 3 (delta 0), reused 0 (delta 0)

Unpacking objects: 100% (3/3), done.

git clone git@git.coding.net:wzw/coding-demo.git

Cloning into 'coding-demo'...

remote: Counting objects: 3, done.

remote: Total 3 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (3/3), done.

可以看到,对于全新 clone 来讲两者基本上的过程是一模一样的。

事实上, Git 底层对于各种应用层协议的底层处理是一致的,不管是 HTTP(S) 还是 SSH 还是 Git 协议。

让我们来进一步看一下, Git 在传输过程中都做了什么。

GIT_TRACE=1 GIT_TRACE_PACKET=1 git clone https://git.coding.net/wzw/coding-demo.git

17:48:21.767799 git.c:344               trace: built-in: git 'clone' 'https://git.coding.net/wzw/coding-demo.git'

Cloning into 'coding-demo'...

17:48:21.797959 run-command.c:626       trace: run_command: 'git-remote-https' 'origin' 'https://git.coding.net/wzw/coding-demo.git'

17:48:22.278880 pkt-line.c:80           packet:          git< # service=git-upload-pack

17:48:22.279390 pkt-line.c:80           packet:          git< 0000

17:48:22.279405 pkt-line.c:80           packet:          git< fdacba1d541c75bd48f2cd742ee18f77ea3517a1 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed no-done symref=HEAD:refs/heads/master agent=git/2.15.0

17:48:22.279419 pkt-line.c:80           packet:          git< fdacba1d541c75bd48f2cd742ee18f77ea3517a1 refs/heads/master

17:48:22.279431 pkt-line.c:80           packet:  

好,基础知识补充完毕,有没有发现火爆的区块链在技术层面上跟 Git 的存储是有相似之处的 :)

在 Clone 过程中,服务器端首先会推荐给客户端一些 ref 列表,这也是 Git v2 协议号称的性能改进的地方,后文有解释。

像这样:

17:49:19.772436 pkt-line.c:80           packet:        clone< fdacba1d541c75bd48f2cd742ee18f77ea3517a1 refs/heads/master

17:49:19.772527 pkt-line.c:80           packet:        clone< 1536ad10fc0a188c50680932ca191c8da46938c4 refs/heads/test-abc

17:49:19.772549 pkt-line.c:80           packet:        clone< 1536ad10fc0a188c50680932ca191c8da46938c4 refs/heads/test-bcd

17:49:19.772566 pkt-line.c:80           packet:        clone< 30eb4b0d813c662c4d7e87c4d3b4cf561e544f8e refs/tags/v1.0

17:49:19.772863 pkt-line.c:80           packet:        clone< 1536ad10fc0a188c50680932ca191c8da46938c4 refs/tags/v1.0^{}

很显然,上文中的 40 位16进制数字就是对应后面的 ref 指向的对象 ID。

而客户端,只需要依据自己感兴趣的 ref 和自己本地已经存在的对象库(对于 pull 和 fetch 来讲,本地有对象库,对于 clone 来讲本地还没有对象库,那么他就是需要所有的感兴趣的对象)。

在客户端计算完毕自己感兴趣的对象列表后,会用 want 指令告诉远端服务器。

17:49:19.776185 pkt-line.c:80           packet:        clone> want fdacba1d541c75bd48f2cd742ee18f77ea3517a1 multi_ack_detailed side-band-64k thin-pack ofs-delta deepen-since deepen-not agent=git/2.15.1.(Apple.Git-101)

17:49:19.776215 pkt-line.c:80           packet:        clone> want fdacba1d541c75bd48f2cd742ee18f77ea3517a1

17:49:19.776224 pkt-line.c:80           packet:        clone> want 1536ad10fc0a188c50680932ca191c8da46938c4

17:49:19.776232 pkt-line.c:80           packet:        clone> want 1536ad10fc0a188c50680932ca191c8da46938c4

17:49:19.776239 pkt-line.c:80           packet:        clone> want 30eb4b0d813c662c4d7e87c4d3b4cf561e544f8e

如果客户端执行的是 pull 或者 fetch ,他还会告诉远端自己已经有了什么对象(在文章的后面,我们会补充一段专门说明此点)。

远端服务器会根据客户端想要的对象以及客户端已经有的对象并对比自身的对象库和对象依赖关系,将客户端必须的对象整理起来并打包压缩传给客户端。

客户端收到对象包后,解包并校验对象,并更新引用的对应指向。

Google 在 Protocol version 2 做了什么

完整的 version 2 的协议说明在这里: https://www.kernel.org/pub/software/scm/git/docs/technical/protocol-v2.html

这里我们对其做的主要改动做些说明,主要有三点:

服务端引用过滤

新特性的易扩展性升级(例如可声明想要什么 ref)

简化的客户端 HTTP 协议处理

被很多标题党夸大其词的主要是其第一点:服务端引用过滤。

Google 官方的博客中对此段的描述是这样的:

The main motivation for the new protocol was to enable server sid

© 著作权归作者所有

小念仔
粉丝 0
博文 10
码字总数 10688
作品 0
洛阳
私信 提问
Git 协议 v2 正式推出,带来显著的性能提升

分布式版本控制系统 Git 将迎来巨大的性能提升 —— Git 协议 v2 已正式推出。 来自 Git 团队的 Brandon Williams 今天在博客上宣布推出了 Git 协议的 v2 版本(Git protocol version 2),v2 ...

局长
2018/05/19
9.6K
41
Git 2.18版本发布:支持Git协议v2,提升性能

在最新的官方 Git 客户端正式版2.18中添加了对 Git wire 协议 v2 的支持,并引入了一些性能与 UI 改进的新特性。在 Git 的核心团队成员 Brandon Williams 公开宣布这一消息前几周,Git 协议 ...

六库科技
2018/07/22
6
0
码云已经支持 Git Wire Protocol

前言 两个半月前,Google 开发者宣布了 Git Wire Protocol,即 Git v2 协议,Git Wire Protocol 协议改进了 Git 的传输过程,增加了可扩展性。关于协议的背景和细节介绍,大家可以去 《码云即...

Force武装卫队
2018/09/05
1K
9
Linux Kernel 开发报告 25 周年版

Linux 基金会发布 2016 年度 Linux 内核开发报告,这次恰逢 Linux 内核 25 周年,所以相比往年又更多的回顾性内容,值得一读。 Linux 内核开发报告 2016 版 一些有趣的信息: 自 3.18 内核以...

局长
2016/09/08
1K
7
经典分类CNN模型系列其六:Inception v4与Inception-Resnet v1/v2

介绍 Inception系列模型设计的核心思想讲至Inception v3基本已经尽了。但2015年Resnet的提出及其在ILSVRC 2015的成功使得Google team开始重新评估CNN深度模型的设计。他们自然不肯屈服于Res...

manofmountain
2018/08/19
0
0

没有更多内容

加载失败,请刷新页面

加载更多

读书笔记:深入理解ES6 (五)

第五章 解构:使数据访问更便捷 第1节 为什么使用解构功能?   在ES5中,开发者们从对象、数组中获取特定数据并赋值给变量,编写了很多看起来同质化的代码。例如: 1 let options = {2 ...

张森ZS
5分钟前
1
0
CentOS7 yum方式安装MySQL5.7

在CentOS中默认安装有MariaDB,这个是MySQL的分支,但为了需要,还是要在系统中安装MySQL,而且安装完成之后可以直接覆盖掉MariaDB。 1 下载并安装MySQL官方的 Yum Repository [root@localho...

roockee
13分钟前
3
0
Allegro三种自定义设置快捷键的方法

Allegro自定义设置快捷键的三种方法: 1、在Allegro PCB editor 命令窗口直接定义 2、通过修改用户变量env文件来设置快捷键 3、定义笔画为快捷键 1、在Allegro PCB editor 命令窗口直接定义 ...

demyar
18分钟前
2
0
如何做一张能让人眼前一亮的大屏?

作为在职场驰骋的社会人,提到数据可视化大家应该都不陌生了。数据可视化的作用也不用我多说,主要是利用图形化手段,更清晰直观地将数据展示。多层次、交互式的可视化分析能够方便决策者理解...

朕想上头条
18分钟前
2
0
TL138/1808/6748-EthEVM开发板硬件CPU、FLASH、RAM

TL138/1808/6748-EthEVM是广州创龙基于SOM-TL138/1808/6748核心板开发的一款开发板,具有三个网络接口。由于SOM-TL138/1808/6748核心板管脚兼容,所以此三个核心板共用同一个底板。开发板采用...

Tronlong创龙
23分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部