Merge branch 'zwpaper-10_git_internals_transfer_protocols'

Author: networm

book/10-git-internals/sections/transfer-protocols.asc

@@ -1,57 +1,57 @@
-=== Transfer Protocols
+=== 传输协议
 
-Git can transfer data between two repositories in two major ways: the ``dumb'' protocol and the ``smart'' protocol.
-This section will quickly cover how these two main protocols operate.
+Git 可以通过两种主要的方式在版本库之间传输数据：“哑（dumb）”协议和“智能（smart）”协议。
+本节将会带你快速浏览这两种协议的运作方式。
 
-==== The Dumb Protocol
+==== 哑协议
 
-If you're setting up a repository to be served read-only over HTTP, the dumb protocol is likely what will be used.
-This protocol is called ``dumb'' because it requires no Git-specific code on the server side during the transport process; the fetch process is a series of HTTP `GET` requests, where the client can assume the layout of the Git repository on the server.
+如果你正在架设一个基于 HTTP 协议的只读版本库，一般而言这种情况下使用的就是哑协议。
+这个协议之所以被称为“哑”协议，是因为在传输过程中，服务端不需要有针对 Git 特有的代码；抓取过程是一系列 HTTP 的 `GET` 请求，这种情况下，客户端可以推断出服务端 Git 仓库的布局。
 
 [NOTE]
 ====
-The dumb protocol is fairly rarely used these days.
-It's difficult to secure or make private, so most Git hosts (both cloud-based and on-premises) will refuse to use it.
-It's generally advised to use the smart protocol, which we describe a bit further on.
+现在已经很少使用哑协议了。
+使用哑协议的版本库很难保证安全性和私有化，所以大多数 Git 服务器宿主（包括云端和本地）都会拒绝使用它。
+一般情况下都建议使用智能协议，我们会在后面进行介绍。
 ====
 
-Let's follow the `http-fetch` process for the simplegit library:
+让我们通过 simplegit 版本库来看看 `http-fetch` 的过程：
 
 [source,console]
 ----
 $ git clone http://server/simplegit-progit.git
 ----
 
-The first thing this command does is pull down the `info/refs` file.
-This file is written by the `update-server-info` command, which is why you need to enable that as a `post-receive` hook in order for the HTTP transport to work properly:
+它做的第一件事就是拉取 `info/refs` 文件。
+这个文件是通过 `update-server-info` 命令生成的，这也解释了在使用HTTP传输时，必须把它设置为 `post-receive` 钩子的原因：
 
 [source]
 ----
 => GET info/refs
 ca82a6dff817ec66f44342007202690a93763949     refs/heads/master
 ----
 
-Now you have a list of the remote references and SHAs.
-Next, you look for what the HEAD reference is so you know what to check out when you're finished:
+现在，你得到了一个远程引用和 SHA 值的列表。
+接下来，你要确定 HEAD 引用是什么，这样你就知道在完成后应该被检出到工作目录的内容：
 
 [source]
 ----
 => GET HEAD
 ref: refs/heads/master
 ----
 
-You need to check out the `master` branch when you've completed the process.
-At this point, you're ready to start the walking process.
-Because your starting point is the `ca82a6` commit object you saw in the `info/refs` file, you start by fetching that:
+这说明在完成抓取后，你需要检出 `master` 分支。
+这时，你就可以开始感受一下这个过程了。
+因为你是从 `info/refs` 文件中所提到的 `ca82a6` 提交对象开始的，所以你的首要操作是获取它：
 
 [source]
 ----
 => GET objects/ca/82a6dff817ec66f44342007202690a93763949
 (179 bytes of binary data)
 ----
 
-You get an object back – that object is in loose format on the server, and you fetched it over a static HTTP GET request.
-You can zlib-uncompress it, strip off the header, and look at the commit content:
+你取回了一个对象——这是一个在服务端以松散格式保存的对象，是你通过使用静态 HTTP GET 请求获取的。
+你可以使用 zlib 解压缩它，去除其头部，查看提交记录的内容：
 
 [source,console]
 ----
@@ -64,104 +64,104 @@ committer Scott Chacon <[email protected]> 1240030591 -0700
 changed the version number
 ----
 
-Next, you have two more objects to retrieve – `cfda3b`, which is the tree of content that the commit we just retrieved points to; and `085bb3`, which is the parent commit:
+接下来，你还要再获取两个对象，一个是树对象 `cfda3b`，它包含有我们刚刚获取的提交对象所指向的内容，另一个是它的父提交 `085bb3`：
 
 [source]
 ----
 => GET objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 (179 bytes of data)
 ----
 
-That gives you your next commit object.
-Grab the tree object:
+这样就取得了你的下一个提交对象。
+再抓取树对象：
 
 [source]
 ----
 => GET objects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf
 (404 - Not Found)
 ----
 
-Oops – it looks like that tree object isn't in loose format on the server, so you get a 404 response back.
-There are a couple of reasons for this – the object could be in an alternate repository, or it could be in a packfile in this repository.
-Git checks for any listed alternates first:
+噢——看起来这个树对象在服务端并不以松散格式对象存在，所以你得到了一个 404 响应，代表在 HTTP 服务端没有找到该对象。
+这有好几个可能的原因——这个对象可能在替代版本库里面，或者在包文件里面。
+Git 会首先检查所有列出的替代版本库：
 
 [source]
 ----
 => GET objects/info/http-alternates
 (empty file)
 ----
 
-If this comes back with a list of alternate URLs, Git checks for loose files and packfiles there – this is a nice mechanism for projects that are forks of one another to share objects on disk.
-However, because no alternates are listed in this case, your object must be in a packfile.
-To see what packfiles are available on this server, you need to get the `objects/info/packs` file, which contains a listing of them (also generated by `update-server-info`):
+如果这返回了一个包含替代版本库 URL 的列表，那么 Git 就会去那些地址检查松散格式对象和文件——这是一种能让派生项目共享对象以节省磁盘的好方法。
+然而，在这个例子中，没有列出可用的替代版本库。所以你所需要的对象肯定在某个包文件中。
+要检查服务端有哪些可用的包文件，你需要获取 `objects/info/packs` 文件，这里面有一个包文件列表（它也是通过执行 `update-server-info` 所生成的）：
 
 [source]
 ----
 => GET objects/info/packs
 P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 ----
 
-There is only one packfile on the server, so your object is obviously in there, but you'll check the index file to make sure.
-This is also useful if you have multiple packfiles on the server, so you can see which packfile contains the object you need:
+服务端只有一个包文件，所以你要的对象显然就在里面。但是你要先检查它的索引文件以确认。
+即使服务端有多个包文件，这也是很有用的，因为这样你就可以知道你所需要的对象是在哪一个包文件里面：
 
 [source]
 ----
 => GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx
 (4k of binary data)
 ----
 
-Now that you have the packfile index, you can see if your object is in it – because the index lists the SHAs of the objects contained in the packfile and the offsets to those objects.
-Your object is there, so go ahead and get the whole packfile:
+现在你有这个包文件的索引，你可以查看你要的对象是否在里面——因为索引文件列出了这个包文件所包含的所有对象的 SHA 值，和该对象存在于包文件中的偏移量。
+你的对象就在这里，接下来就是获取整个包文件：
 
 [source]
 ----
 => GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 (13k of binary data)
 ----
 
-You have your tree object, so you continue walking your commits.
-They're all also within the packfile you just downloaded, so you don't have to do any more requests to your server.
-Git checks out a working copy of the `master` branch that was pointed to by the HEAD reference you downloaded at the beginning.
+现在你也有了你的树对象，你可以继续在提交记录上漫游。
+它们全部都在这个你刚下载的包文件里面，所以你不用继续向服务端请求更多下载了。
+Git 会将开始时下载的 HEAD 引用所指向的 `master` 分支检出到工作目录。
 
-==== The Smart Protocol
+==== 智能协议
 
-The dumb protocol is simple but a bit inefficient, and it can't handle writing of data from the client to the server.
-The smart protocol is a more common method of transferring data, but it requires a process on the remote end that is intelligent about Git – it can read local data, figure out what the client has and needs, and generate a custom packfile for it.
-There are two sets of processes for transferring data: a pair for uploading data and a pair for downloading data.
+哑协议虽然很简单但效率略低，且它不能从客户端向服务端发送数据。
+智能协议是更常用的传送数据的方法，但它需要在服务端运行一个进程，而这也是 Git 的智能之处——它可以读取本地数据，理解客户端有什么和需要什么，并为它生成合适的包文件。
+总共有两组进程用于传输数据，它们分别负责上传和下载数据。
 
-===== Uploading Data
+===== 上传数据
 
 (((git commands, send-pack)))(((git commands, receive-pack)))
-To upload data to a remote process, Git uses the `send-pack` and `receive-pack` processes.
-The `send-pack` process runs on the client and connects to a `receive-pack` process on the remote side.
+为了上传数据至远端，Git 使用 `send-pack` 和 `receive-pack` 进程。
+运行在客户端上的 `send-pack` 进程连接到远端运行的 `receive-pack` 进程。
 
 ====== SSH
 
-For example, say you run `git push origin master` in your project, and `origin` is defined as a URL that uses the SSH protocol.
-Git fires up the `send-pack` process, which initiates a connection over SSH to your server.
-It tries to run a command on the remote server via an SSH call that looks something like this:
+举例来说，在项目中使用命令 `git push origin master` 时, `origin` 是由基于 SSH 协议的 URL 所定义的。
+Git 会运行 `send-pack` 进程，它会通过 SSH 连接你的服务器。
+它会尝试通过 SSH 在服务端执行命令，就像这样：
 
 [source,console]
 ----
 $ ssh -x git@server "git-receive-pack 'simplegit-progit.git'"
 005bca82a6dff817ec66f4437202690a93763949 refs/heads/master report-status \
 	delete-refs side-band-64k quiet ofs-delta \
-	agent=git/2:2.1.1+github-607-gfba4028 delete-refs
+agent=git/2:2.1.1+github-607-gfba4028 delete-refs
 003e085bb3bcb608e1e84b2432f8ecbe6306e7e7 refs/heads/topic
 0000
 ----
 
-The `git-receive-pack` command immediately responds with one line for each reference it currently has – in this case, just the `master` branch and its SHA.
-The first line also has a list of the server's capabilities (here, `report-status`, `delete-refs`, and some others, including the client identifier).
+`git-receive-pack` 命令会立即为它所拥有的每一个引用发送一行响应——在这个例子中，就只有 `master` 分支和它的SHA值。
+第一行响应中也包含了一个服务端能力的列表（这里是 `report-status`、`delete-refs` 和一些其它的，包括客户端的识别码）。
 
-Each line starts with a 4-character hex value specifying how long the rest of the line is.
-Your first line starts with 005b, which is 91 in hex, meaning that 91 bytes remain on that line.
-The next line starts with 003e, which is 62, so you read the remaining 62 bytes.
-The next line is 0000, meaning the server is done with its references listing.
+每一行以一个四位的十六进制值开始，用于指明本行的长度。
+你看到第一行以 005b 开始，这在十六进制中表示 91，意味着第一行有 91 字节。
+下一行以 003e 起始，也就是 62，所以下面需要读取 62 字节。
+再下一行是 0000，表示服务端已完成了发送引用列表过程。
 
-Now that it knows the server's state, your `send-pack` process determines what commits it has that the server doesn't.
-For each reference that this push will update, the `send-pack` process tells the `receive-pack` process that information.
-For instance, if you're updating the `master` branch and adding an `experiment` branch, the `send-pack` response may look something like this:
+现在它知道了服务端的状态，你的 `send-pack` 进程会判断哪些提交记录是它所拥有但服务端没有的。
+`send-pack` 会告知 `receive-pack` 这次推送将会更新的各个引用。
+举个例子，如果你正在更新 `master` 分支，并且增加 `experiment` 分支，这个 `send-pack` 的响应将会是像这样：
 
 [source]
 ----
@@ -172,13 +172,13 @@ For instance, if you're updating the `master` branch and adding an `experiment`
 0000
 ----
 
-Git sends a line for each reference you're updating with the line's length, the old SHA, the new SHA, and the reference that is being updated.
-The first line also has the client's capabilities.
-The SHA-1 value of all '0's means that nothing was there before – because you're adding the experiment reference.
-If you were deleting a reference, you would see the opposite: all '0's on the right side.
+Git 会为每一个将要更新的引用发送一行数据，包括该行长度，旧 SHA 值，新 SHA 值和将要更新的引用。
+第一行也包括了客户端的能力。
+这里的全为 '0' 的 SHA-1 值表示之前没有过这个引用——因为你正要添加新的 experiment 引用。
+删除引用时，将会看到相反的情况：右边的 SHA-1 值全为 '0'。
 
-Next, the client sends a packfile of all the objects the server doesn't have yet.
-Finally, the server responds with a success (or failure) indication:
+接下来，客户端会发送一个包文件，它包含了所有服务端还没有的对象。
+最后，服务端会以成功（或失败）响应：
 
 [source]
 ----
@@ -187,8 +187,8 @@ Finally, the server responds with a success (or failure) indication:
 
 ====== HTTP(S)
 
-This process is mostly the same over HTTP, though the handshaking is a bit different.
-The connection is initiated with this request:
+HTTPS 与 HTTP 相比较，除了在“握手”过程略有不同外，其他基本相似。
+连接是从下面这个请求开始的：
 
 [source]
 ----
@@ -200,33 +200,33 @@ The connection is initiated with this request:
 0000
 ----
 
-That's the end of the first client-server exchange.
-The client then makes another request, this time a `POST`, with the data that `git-upload-pack` provides.
+这完成了客户端和服务端的第一次数据交换。
+接下来客户端发起另一个请求，这次是一个 `POST` 请求，这个请求中包含了 `git-upload-pack` 提供的数据。
 
 [source]
 ----
 => POST http://server/simplegit-progit.git/git-receive/pack
 ----
 
-The `POST` request includes the `send-pack` output and the packfile as its payload.
-The server then indicates success or failure with its HTTP response.
+这个 `POST` 请求的内容是 `send-pack` 的输出和相应的包文件。
+服务端在收到请求后相应地作出成功或失败的 HTTP 响应。
 
-===== Downloading Data
+===== 下载数据
 
 (((git commands, fetch-pack)))(((git commands, upload-pack)))
-When you download data, the `fetch-pack` and `upload-pack` processes are involved.
-The client initiates a `fetch-pack` process that connects to an `upload-pack` process on the remote side to negotiate what data will be transferred down.
+当你在下载数据时， `fetch-pack` 和 `upload-pack` 进程就起作用了。
+客户端启动 `fetch-pack` 进程，连接至远端的 `upload-pack` 进程，以协商后续传输的数据。
 
 ====== SSH
 
-If you're doing the fetch over SSH, `fetch-pack` instead runs something like this:
+如果你通过 SSH 使用抓取功能，`fetch-pack` 会像这样运行：
 
 [source,console]
 ----
 $ ssh -x git@server "git-upload-pack 'simplegit-progit.git'"
 ----
 
-After `fetch-pack` connects, `upload-pack` sends back something like this:
+在 `fetch-pack` 连接后，`upload-pack` 会返回类似下面的内容：
 
 [source]
 ----
@@ -238,12 +238,12 @@ After `fetch-pack` connects, `upload-pack` sends back something like this:
 0000
 ----
 
-This is very similar to what `receive-pack` responds with, but the capabilities are different.
-In addition, it sends back what HEAD points to (`symref=HEAD:refs/heads/master`) so the client knows what to check out if this is a clone.
+这与 `receive-pack` 的响应很相似，但是这里所包含的能力是不同的。
+而且它还包含 HEAD 引用所指向内容（`symref=HEAD:refs/heads/master`），这样如果客户端执行的是克隆，它就会知道要检出什么。
 
-At this point, the `fetch-pack` process looks at what objects it has and responds with the objects that it needs by sending ``want'' and then the SHA it wants.
-It sends all the objects it already has with ``have'' and then the SHA.
-At the end of this list, it writes ``done'' to initiate the `upload-pack` process to begin sending the packfile of the data it needs:
+这时候，`fetch-pack` 进程查看它自己所拥有的对象，并响应“want”和它需要的对象的 SHA 值。
+它还会发送“have”和所有它已拥有的对象的 SHA 值。
+在列表的最后，它还会发送“done”以通知 `upload-pack` 进程可以开始发送它所需对象的包文件：
 
 [source]
 ----
@@ -255,8 +255,8 @@ At the end of this list, it writes ``done'' to initiate the `upload-pack` proces
 
 ====== HTTP(S)
 
-The handshake for a fetch operation takes two HTTP requests.
-The first is a `GET` to the same endpoint used in the dumb protocol:
+抓取操作的握手需要两个 HTTP 请求。
+第一个是向和哑协议中相同的端点发送 `GET` 请求：
 
 [source]
 ----
@@ -270,7 +270,7 @@ The first is a `GET` to the same endpoint used in the dumb protocol:
 0000
 ----
 
-This is very similar to invoking `git-upload-pack` over an SSH connection, but the second exchange is performed as a separate request:
+这和通过 SSH 使用 `git-upload-pack` 是非常相似的，但是第二个数据交换则是一个单独的请求：
 
 [source]
 ----
@@ -280,11 +280,11 @@ This is very similar to invoking `git-upload-pack` over an SSH connection, but t
 0000
 ----
 
-Again, this is the same format as above.
-The response to this request indicates success or failure, and includes the packfile.
+这个输出格式还是和前面一样的。
+这个请求的响应包含了所需要的包文件，并指明成功或失败。
 
-==== Protocols Summary
+==== 协议总结
 
-This section contains a very basic overview of the transfer protocols.
-The protocol includes many other features, such as `multi_ack` or `side-band` capabilities, but covering them is outside the scope of this book.
-We've tried to give you a sense of the general back-and-forth between client and server; if you need more knowledge than this, you'll probably want to take a look at the Git source code.
+这一章节是传输协议的一个概貌。
+传输协议还有很多其它的特性，像是 `multi_ack` 或 `side-band`，但是这些内容已经超出了本书的范围。
+我们希望能给你展示客户端和服务端之间的基本交互过程；如果你需要更多的相关知识，你可以参阅 Git 的源代码。

status.json

@@ -105,7 +105,7 @@
       "sections/plumbing-porcelain.asc": 100,
       "sections/refs.asc": 100,
       "sections/refspec.asc": 100,
-      "sections/transfer-protocols.asc": 0
+      "sections/transfer-protocols.asc": 100
     },
     "A-git-in-other-environments": {
       "1-git-other-environments.asc": 50,