用 strace 命令浅析 git push 通过 SSH 工作的原理

昨天，突如其来的好奇充斥着我的脑袋：究竟 git push 如何通过 SSH 工作呢？由于我越来越习惯使用 strace 来折腾这类问题，所以我又尝试用它来练练手。如果我利用 strace（跟踪）git push 命令到这个网站的（资料）库，会得到如下显示：

1	[pid 15943] execve( "/usr/bin/ssh" , [ "ssh" , "git@github.com" , "git-receive-pack 'kamalmarhubi/w" ...], [/* 51 vars */]) = 0

所以 git push 最终会调用 ssh git@github.com git-receive-pack <repo-path>。然后在我的终端（terminal）尝试输入以下命令，得到了以下线索：

1 2 3 4 5 6 7

$ ssh git@github.com git-receive-pack kamalmarhubi /website   00bb2979fec627d60938c4ed2086cc60bb1 refs /heads/gh-pagesreport-status delete-refs side-band-64k quiet atomic ofs-delta agent=git /2 :2.4.8~upload-pack-wrapper-script-1211-gc27b061   003f04bfcb3e238e5660ae9e71a6ce99f472211fe85f refs /heads/master   0000

终端依然在等待我的输入。SSH 用来解决身份验证和远程控制的问题，验证成功后，SSH 的另一端会运行一段命令来进行数据交换。而上面这几行就是数据交换的开始。

在网上稍微搜索了一下，我知道了这个协议是由行组成的，而每一行的 4 位前置码正是行长度的十六进制表示。后面跟着提交的 SHA-1 和 ref ，发送端以一行 “0000” 作为结束标识符。

上面的每一行对应（资料）库里的每一个分支：第一行自带了一条长长的小尾巴，好像是发送程序的自我介绍和支持的相关功能。

我在研究这些代码的时候，使用 xsel 命令把输出结果复制到编辑器上面，不过令人困惑的是，我粘贴得到的竟然只有第一行而不是所有元数据。

1	00bb29793c39c8e4bfec627d60938c4ed2086cc60bb1 refs /heads/gh-pages

通过 hexdump –C 查看完整的输出后发现，原来在 refs/heads/gh-pages 后面有一个空字节，而且在末尾处还换行了（用星号 * 标记处）：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

00000000  30 30 62 62 32 39 37 39  33 63 33 39 63 38 65 34  |00bb29793c39c8e4|   00000010  62 66 65 63 36 32 37 64  36 30 39 33 38 63 34 65  |bfec627d60938c4e|   00000020  64 32 30 38 36 63 63 36  30 62 62 31 20 72 65 66  |d2086cc60bb1 ref|   00000030  73 2f 68 65 61 64 73 2f  67 68 2d 70 61 67 65 73  |s /heads/gh-pages |   00000040 *00*72 65 70 6f 72 74 2d  73 74 61 74 75 73 20 64  |.report-status d|   00000050  65 6c 65 74 65 2d 72 65  66 73 20 73 69 64 65 2d  |elete-refs side-|   00000060  62 61 6e 64 2d 36 34 6b  20 71 75 69 65 74 20 61  |band-64k quiet a|   00000070  74 6f 6d 69 63 20 6f 66  73 2d 64 65 6c 74 61 20  |tomic ofs-delta |   00000080  61 67 65 6e 74 3d 67 69  74 2f 32 3a 32 2e 34 2e  |agent=git /2 :2.4.|   00000090  38 7e 75 70 6c 6f 61 64  2d 70 61 63 6b 2d 77 72  |8~upload-pack-wr|   000000a0  61 70 70 65 72 2d 73 63  72 69 70 74 2d 31 32 31  |apper-script-121|   000000b0  31 2d 67 63 32 37 62 30  36 31*0a*30 30 33 66 37  |1-gc27b061.003f7|   000000c0  39 32 66 34 39 36 65 37  35 33 64 62 39 33 33 30  |92f496e753db9330|   000000d0  66 30 61 34 65 38 32 39  30 62 38 61 36 63 62 61  |f0a4e8290b8a6cba|   000000e0  38 61 62 36 64 61 62 20  72 65 66 73 2f 68 65 61  |8ab6dab refs /hea |   000000f0  64 73 2f 6d 61 73 74 65  72 0a 30 30 30 30        |ds /master .0000|   000000fe

我在没有仔细研究的情况下，大胆地做了一个猜想：那些在 github 上做开发的家伙们，定义了一个相当简单的长度前缀+换行分隔协议（length-prefixed, newline-separated protocol），当他们有需要向协议里面加入一些元数据的时候，可以保持和老版本 git 的兼容性。这个解决方案巧妙地利用了 C 语言的 0 结尾字符串：把元数据放在空字节和新行之间。用这种方式读取数据（读取到新行之前位置）可以得到所有的元数据。元数据处理代码在执行时会跳过空字节，但是现有的协议代码却只能看到到空字节之前的数据，它们对这种改动完全无感!

所以我之前用 xsel 命令复制数据时，那些空字节后面的东东被完美地忽略了。

真相就只有一个，谜底就这样被解开了！（其实wo真不是柯南哦）

问啊-一键呼叫程序员答题神器，牛人一对一服务，开发者编程必备官方网站：www.wenaaa.com


QQ群290551701 聚集很多互联网精英，技术总监，架构师，项目经理！开源技术研究，欢迎业内人士，大牛及新手有志于从事IT行业人员进入！