Git内部原理之深入解析传输协议
生活随笔
收集整理的這篇文章主要介紹了
Git内部原理之深入解析传输协议
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
一、啞協議
- 如果正在架設一個基于 HTTP 協議的只讀版本庫，一般而言這種情況下在版本庫之間傳輸數據使用的就是啞協議，這個協議之所以被稱為“啞”協議，是因為在傳輸過程中，服務端不需要有針對 Git 特有的代碼；抓取過程是一系列 HTTP 的 GET 請求，這種情況下，客戶端可以推斷出服務端 Git 倉庫的布局。
- 現在已經很少使用啞協議了，使用啞協議的版本庫很難保證安全性和私有化，所以大多數 Git 服務器宿主（包括云端和本地）都會拒絕使用它，一般情況下都建議使用智能協議。
- 通過 simplegit 版本庫來看看 http-fetch 的過程：
- 它做的第一件事就是拉取 info/refs 文件，這個文件是通過 update-server-info 命令生成的，這也解釋了在使用 HTTP 傳輸時，必須把它設置為 post-receive 鉤子的原因：
- 現在得到了一個遠程引用和 SHA-1 值的列表。接下來，要確定 HEAD 引用是什么，這樣就知道在完成后應該被檢出到工作目錄的內容：
- 這說明在完成抓取后，需要檢出 master 分支。這時，就可以開始遍歷處理了，因為是從 info/refs 文件中所提到的 ca82a6 提交對象開始的，所以首要操作是獲取它：
- 取回了一個對象，這是一個在服務端以松散格式保存的對象，是通過使用靜態 HTTP GET 請求獲取的。可以使用 zlib 解壓縮它，去除其頭部，查看提交記錄的內容：
- 接下來，還要再獲取兩個對象，一個是樹對象 cfda3b，它包含有我們剛剛獲取的提交對象所指向的內容，另一個是它的父提交 085bb3：
- 這樣就取得了下一個提交對象，再抓取樹對象：
- 看起來這個樹對象在服務端并不以松散格式對象存在，所以得到了一個 404 響應，代表在 HTTP 服務端沒有找到該對象。這有好幾個可能的原因，這個對象可能在替代版本庫里面，或者在包文件里面。Git 會首先檢查所有列出的替代版本庫：
- 如果這返回了一個包含替代版本庫 URL 的列表，那么 Git 就會去那些地址檢查松散格式對象和文件，這是一種能讓派生項目共享對象以節省磁盤的好方法。然而，在這個例子中，沒有列出可用的替代版本庫，所以所需要的對象肯定在某個包文件中。要檢查服務端有哪些可用的包文件，需要獲取 objects/info/packs 文件，這里面有一個包文件列表（它也是通過執行 update-server-info 所生成的）：
- 服務端只有一個包文件，所以需要的對象顯然就在里面。但是要先檢查它的索引文件以確認，即使服務端有多個包文件，這也是很有用的，因為這樣就可以知道你所需要的對象是在哪一個包文件里面：
- 現在有這個包文件的索引，可以查看需要的對象是否在里面，因為索引文件列出了這個包文件所包含的所有對象的 SHA-1 值，和該對象存在于包文件中的偏移量，需要的對象就在這里，接下來就是獲取整個包文件：
- 現在也有了樹對象，可以繼續在提交記錄上漫游，它們全部都在這個剛下載的包文件里面，所以不用繼續向服務端請求更多下載了。Git 會將開始時下載的 HEAD 引用所指向的 master 分支檢出到工作目錄。
二、智能協議
- 啞協議雖然很簡單但效率略低，且它不能從客戶端向服務端發送數據。智能協議是更常用的傳送數據的方法，但它需要在服務端運行一個進程，而這也是 Git 的智能之處，它可以讀取本地數據，理解客戶端有什么和需要什么，并為它生成合適的包文件，總共有兩組進程用于傳輸數據，它們分別負責上傳和下載數據。
① 上傳數據
- 為了上傳數據至遠端，Git 使用 send-pack 和 receive-pack 進程，運行在客戶端上的 send-pack 進程連接到遠端運行的 receive-pack 進程。
- SSH：
-
- 舉例來說，在項目中使用命令 git push origin master 時，origin 是由基于 SSH 協議的 URL 所定義的。Git 會運行 send-pack 進程，它會通過 SSH 連接服務器，嘗試通過 SSH 在服務端執行命令，就像這樣：
-
- git-receive-pack 命令會立即為它所擁有的每一個引用發送一行響應，例子中就只有 master 分支和它的 SHA-1 值，第一行響應中也包含了一個服務端能力的列表（這里是 report-status、delete-refs 和一些其它的，包括客戶端的識別碼）。
-
- 每一行以一個四位的十六進制值開始，用于指明本行的長度，可以看到第一行以 00a5 開始，這在十六進制中表示 165，意味著第一行有 165 字節；下一行是 0000，表示服務端已完成了發送引用列表過程。
-
- 現在它知道了服務端的狀態，send-pack 進程會判斷哪些提交記錄是它所擁有但服務端沒有的。send-pack 會告知 receive-pack 這次推送將會更新的各個引用。舉個例子，如果正在更新 master 分支，并且增加 experiment 分支，這個 send-pack 的響應將會是像這樣：
-
- 第一行也包括了客戶端的能力，這里的全為 0 的 SHA-1 值表示之前沒有過這個引用，因為正要添加新的 experiment 引用；刪除引用時，將會看到相反的情況：右邊的 SHA-1 值全為 0。
-
- 然后，客戶端會發送一個包含了所有服務端上所沒有的對象的包文件，最終，服務端會響應一個成功（或失敗）的標識：
- HTTP(S)：
-
- 上傳過程在 HTTP 上幾乎是相同的，除了握手階段有一點小區別，連接是從下面這個請求開始的：
- 這完成了客戶端和服務端的第一次數據交換。接下來客戶端發起另一個請求，這次是一個 POST 請求，這個請求中包含了 send-pack 提供的數據：
- 這個 POST 請求的內容是 send-pack 的輸出和相應的包文件，服務端在收到請求后相應地作出成功或失敗的 HTTP 響應。請牢記，HTTP 協議有可能會進一步用分塊傳輸編碼將數據包裹起來。
② 下載數據
- 當下載數據時， fetch-pack 和 upload-pack 進程就起作用了，客戶端啟動 fetch-pack 進程，連接至遠端的 upload-pack 進程，以協商后續傳輸的數據。
- SSH：
- 如果通過 SSH 使用抓取功能，fetch-pack 會像這樣運行：
-
- 在 fetch-pack 連接后，upload-pack 會返回類似下面的內容：
-
- 這與 receive-pack 的響應很相似，但是這里所包含的能力是不同的，而且它還包含 HEAD 引用所指向內容（symref=HEAD:refs/heads/master），這樣如果客戶端執行的是克隆，它就會知道要檢出什么。
- 這時候，fetch-pack 進程查看它自己所擁有的對象，并響應 “want” 和它需要的對象的 SHA-1 值，它還會發送“have”和所有它已擁有的對象的 SHA-1 值。在列表的最后，它還會發送“done”以通知 upload-pack 進程可以開始發送它所需對象的包文件：
- HTTP(S)：
-
- 抓取操作的握手需要兩個 HTTP 請求，第一個是向和啞協議中相同的端點發送 GET 請求：
- 這和通過 SSH 使用 git-upload-pack 是非常相似的，但是第二個數據交換則是一個單獨的請求：
- 這個輸出格式還是和前面一樣的，這個請求的響應包含了所需要的包文件，并指明成功或失敗。
總結
以上是生活随笔為你收集整理的Git内部原理之深入解析传输协议的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Git内部原理之深入解析Git的引用和包
- 下一篇： Git内部原理之深入解析维护与数据恢复