Chapters ▾ 2nd Edition

10.6 Git Internals - Oordragprotokolle (Transfer Protocols)

Oordragprotokolle (Transfer Protocols)

Git kan data tussen twee bewaarplekke op twee hoofmaniere oordra: die “dom” (dumb) protokol en die “slim” (smart) protokol. Hierdie afdeling sal vinnig dek hoe hierdie twee hoofprotokolle werk.

Die Dom Protokol (The Dumb Protocol)

As jy 'n bewaarplek opstel om leesalleen (read-only) oor HTTP bedien te word, is die dom protokol waarskynlik wat gebruik sal word. Hierdie protokol word “dom” genoem omdat dit geen Git-spesifieke kode aan die bedienerkant tydens die vervoerproses vereis nie; die aftrekproses (fetch process) is 'n reeks HTTP GET-versoeke, waar die kliënt die uitleg van die Git-bewaarplek op die bediener kan aanneem.

Note

Die dom protokol word deesdae redelik selde gebruik. Dit is moeilik om te beveilig of privaat te maak, so die meeste Git-gashere (beide wolk-gebaseerde en op-perseel) sal weier om dit te gebruik. Dit word oor die algemeen aangeraai om die slim protokol te gebruik, wat ons 'n entjie verder bespreek.

Kom ons volg die http-fetch-proses vir die simplegit-biblioteek:

$ git clone http://server/simplegit-progit.git

Die eerste ding wat hierdie opdrag doen, is om die info/refs-lêer af te trek. Hierdie lêer word deur die update-server-info-opdrag geskryf, wat is hoekom jy dit as 'n post-receive-haak moet aktiveer sodat die HTTP-vervoer behoorlik kan werk:

=> GET info/refs
ca82a6dff817ec66f44342007202690a93763949     refs/heads/master

Nou het jy 'n lys van die afgeleë verwysings (remote references) en SHA-1’s. Vervolgens soek jy wat die HEAD-verwysing is sodat jy weet wat om uit te trek (check out) wanneer jy klaar is:

=> GET HEAD
ref: refs/heads/master

Jy moet die master-tak uittrek wanneer jy die proses voltooi het. Op hierdie punt is jy gereed om die stap-proses (walking process) te begin. Omdat jou beginpunt die ca82a6 vasleggingsobjek is wat jy in die info/refs-lêer gesien het, begin jy deur dit af te haal (fetch):

=> GET objects/ca/82a6dff817ec66f44342007202690a93763949
(179 bytes of binary data)

Jy kry 'n objek terug – daardie objek is in los formaat op die bediener, en jy het dit oor 'n statiese HTTP GET-versoek afgehaal. Jy kan dit met zlib ontsaampers (uncompress), die kopstuk afstroop en na die vasleggingsinhoud kyk:

$ git cat-file -p ca82a6dff817ec66f44342007202690a93763949
tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
author Scott Chacon <schacon@gmail.com> 1205815931 -0700
committer Scott Chacon <schacon@gmail.com> 1240030591 -0700

Change version number

Vervolgens het jy nog twee objekte om te herwin – cfda3b, wat die boom van inhoud is waarna die vaslegging wat ons pas herwin het wys; en 085bb3, wat die ouer-vaslegging is:

=> GET objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
(179 bytes of data)

Dit gee jou jou volgende vasleggingsobjek. Gryp die boom-objek:

=> GET objects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf
(404 - Not Found)

Oeps – dit lyk of daardie boom-objek nie in los formaat op die bediener is nie, so jy kry 'n 404-reaksie terug. Daar is 'n paar redes hiervoor – die objek kan in 'n alternatiewe bewaarplek wees, of dit kan in 'n paklêer (packfile) in hierdie bewaarplek wees. Git kyk eers vir enige gelyste alternatiewe:

=> GET objects/info/http-alternates
(empty file)

As dit terugkom met 'n lys van alternatiewe URL’e, kyk Git vir los lêers en paklêers daar – dit is 'n oulike meganisme vir projekte wat vurke (forks) van mekaar is om objekte op die skyf te deel. Aangesien geen alternatiewe in hierdie geval gelys is nie, moet jou objek egter in 'n paklêer wees. Om te sien watter paklêers op hierdie bediener beskikbaar is, moet jy die objects/info/packs-lêer kry, wat 'n lys daarvan bevat (ook gegenereer deur update-server-info):

=> GET objects/info/packs
P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack

Daar is net een paklêer op die bediener, so jou objek is natuurlik daarin, maar jy sal die indekslêer nagaan om seker te maak. Dit is ook nuttig as jy veelvuldige paklêers op die bediener het, sodat jy kan sien watter paklêer die objek bevat wat jy benodig:

=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx
(4k of binary data)

Noudat jy die paklêer-indeks het, kan jy sien of jou objek daarin is – want die indeks lys die SHA-1’s van die objekte wat in die paklêer vervat is asook die beginpunte (offsets) na daardie objekte. Jou objek is daar, so gaan voort en kry die hele paklêer:

=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
(13k of binary data)

Jy het jou boom-objek, so jy gaan voort om deur jou vasleggings te stap. Hulle is almal ook binne die paklêer wat jy pas afgelaai het, so jy hoef nie nog versoeke na jou bediener te rig nie. Git trek 'n werkkopie uit van die master-tak waarna gewys is deur die HEAD-verwysing wat jy aan die begin afgelaai het.

Die Slim Protokol (The Smart Protocol)

Die dom protokol is eenvoudig maar 'n bietjie ondoeltreffend, en dit kan nie die skryf van data van die kliënt na die bediener hanteer nie. Die slim protokol is 'n meer algemene metode om data oor te dra, maar dit vereis 'n proses aan die afgeleë kant wat intelligent is oor Git – dit kan plaaslike data lees, uitvind wat die kliënt het en benodig, en 'n pasgemaakte paklêer daarvoor genereer. Daar is twee stelle prosesse om data oor te dra: 'n paar vir die oplaai van data en 'n paar vir die aflaai van data.

Oplaai van Data (Uploading Data)

Om data na 'n afgeleë proses op te laai, gebruik Git die send-pack en receive-pack prosesse. Die send-pack proses loop op die kliënt en koppel aan 'n receive-pack proses aan die afgeleë kant.

SSH

Sê byvoorbeeld jy voer git push origin master in jou projek uit, en origin word gedefinieer as 'n URL wat die SSH-protokol gebruik. Git skakel die send-pack proses aan, wat 'n verbinding oor SSH na jou bediener inisieer. Dit probeer 'n opdrag op die afgeleë bediener uitvoer via 'n SSH-roep wat min of meer so lyk:

$ ssh -x git@server "git-receive-pack 'simplegit-progit.git'"
00a5ca82a6dff817ec66f4437202690a93763949 refs/heads/master□report-status \
	delete-refs side-band-64k quiet ofs-delta \
	agent=git/2:2.1.1+github-607-gfba4028 delete-refs
0000

Die git-receive-pack-opdrag reageer onmiddellik met een reël vir elke verwysing wat dit tans het – in hierdie geval, net die master-tak en sy SHA-1. Die eerste reël bevat ook 'n lys van die bediener se vermoëns (hier, report-status, delete-refs, en 'n paar ander, insluitend die kliënt-identifiseerder).

Die data word in stukke (chunks) oorgedra. Elke stuk begin met 'n 4-karakter heksadesimale waarde wat spesifiseer hoe lank die stuk is (insluitend die 4 grepe van die lengte self). Stukke bevat gewoonlik 'n enkele reël data en 'n agtereenvolgende reëltoevoer (linefeed). Jou eerste stuk begin met 00a5, wat heksadesimaal vir 165 is, wat beteken dat die stuk 165 grepe lank is. Die volgende stuk is 0000, wat beteken die bediener is klaar met sy verwysingslys.

Noudat dit die bediener se toestand ken, bepaal jou send-pack-proses watter vasleggings dit het wat die bediener nie het nie. Vir elke verwysing wat hierdie push sal opdateer, vertel die send-pack-proses die receive-pack-proses daardie inligting. As jy byvoorbeeld die master-tak opdateer en 'n experiment-tak byvoeg, kan die send-pack-reaksie min of meer so lyk:

0076ca82a6dff817ec66f44342007202690a93763949 15027957951b64cf874c3557a0f3547bd83b3ff6 \
	refs/heads/master report-status
006c0000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d \
	refs/heads/experiment
0000

Git stuur 'n reël vir elke verwysing wat jy opdateer met die reël se lengte, die ou SHA-1, die nuwe SHA-1, en die verwysing wat opgedateer word. Die eerste reël het ook die kliënt se vermoëns. Die SHA-1 waarde van slegs '0’e beteken dat niks voorheen daar was nie – omdat jy die experiment-verwysing byvoeg. As jy 'n verwysing sou uitvee, sou jy die teenoorgestelde sien: slegs '0’e aan die regterkant.

Vervolgens stuur die kliënt 'n paklêer van al die objekte wat die bediener nog nie het nie. Laastens reageer die bediener met 'n aanduiding van sukses (of mislukking):

000eunpack ok
HTTP(S)

Hierdie proses is grootliks dieselfde oor HTTP, alhoewel die handdruk (handshaking) 'n bietjie anders is. Die verbinding word met hierdie versoek begin:

=> GET http://server/simplegit-progit.git/info/refs?service=git-receive-pack
001f# service=git-receive-pack
00ab6c5f0e45abd7832bf23074a333f739977c9e8188 refs/heads/master□report-status \
	delete-refs side-band-64k quiet ofs-delta \
	agent=git/2:2.1.1~vmg-bitmaps-bugaloo-608-g116744e
0000

Dit is die einde van die eerste kliënt-bediener-uitruiling. Die kliënt rig dan nog 'n versoek, hierdie keer 'n POST, met die data wat send-pack verskaf.

=> POST http://server/simplegit-progit.git/git-receive-pack

Die POST-versoek sluit die send-pack-afvoer en die paklêer as sy vrag (payload) in. Die bediener dui dan sukses of mislukking met sy HTTP-reaksie aan.

Hou in gedagte die HTTP-protokol kan hierdie data verder toedraai binne 'n gefragmenteerde oordragkodering (chunked transfer encoding).

Aflaai van Data (Downloading Data)

Wanneer jy data aflaai, is die fetch-pack en upload-pack prosesse betrokke. Die kliënt inisieer 'n fetch-pack proses wat aan 'n upload-pack proses aan die afgeleë kant koppel om te onderhandel watter data oorgedra sal word.

SSH

As jy die fetch oor SSH doen, loop fetch-pack min of meer soos volg:

$ ssh -x git@server "git-upload-pack 'simplegit-progit.git'"

Nadat fetch-pack gekoppel het, stuur upload-pack iets soos dit terug:

00dfca82a6dff817ec66f44342007202690a93763949 HEAD□multi_ack thin-pack \
	side-band side-band-64k ofs-delta shallow no-progress include-tag \
	multi_ack_detailed symref=HEAD:refs/heads/master \
	agent=git/2:2.1.1+github-607-gfba4028
003fe2409a098dc3e53539a9028a94b6224db9d6a6b6 refs/heads/master
0000

Dit is baie soortgelyk aan waarmee receive-pack reageer, maar die vermoëns verskil. Daarbenewens stuur dit terug waarna HEAD wys (symref=HEAD:refs/heads/master) sodat die kliënt weet wat om uit te trek as dit 'n kloon is.

Op hierdie stadium kyk die fetch-pack-proses na watter objekte dit het en reageer met die objekte wat dit benodig deur “want” te stuur en dan die SHA-1 wat dit wil hê. Dit stuur al die objekte wat dit reeds het met “have” en dan die SHA-1. Aan die einde van hierdie lys, skryf dit “done” om die upload-pack-proses te inisieer om die paklêer te begin stuur van die data wat dit benodig:

003cwant ca82a6dff817ec66f44342007202690a93763949 ofs-delta
0032have 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
0009done
0000
HTTP(S)

Die handdruk vir 'n fetch-operasie neem twee HTTP-versoeke. Die eerste is 'n GET na dieselfde eindpunt wat in die dom protokol gebruik word:

=> GET $GIT_URL/info/refs?service=git-upload-pack
001e# service=git-upload-pack
00e7ca82a6dff817ec66f44342007202690a93763949 HEAD□multi_ack thin-pack \
	side-band side-band-64k ofs-delta shallow no-progress include-tag \
	multi_ack_detailed no-done symref=HEAD:refs/heads/master \
	agent=git/2:2.1.1+github-607-gfba4028
003fca82a6dff817ec66f44342007202690a93763949 refs/heads/master
0000

Dit is baie soortgelyk aan die oproep van git-upload-pack oor 'n SSH-verbinding, maar die tweede uitruiling word as 'n aparte versoek uitgevoer:

=> POST $GIT_URL/git-upload-pack HTTP/1.0
0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7
0032have 441b40d833fdfa93eb2908e52742248faf0ee993
0000

Weereens, dit is dieselfde formaat as hierbo. Die antwoord op hierdie versoek dui op sukses of mislukking, en sluit die paklêer in.

Protokolle Opsomming (Protocols Summary)

Hierdie afdeling bevat 'n baie basiese oorsig van die oordragprotokolle. Die protokol sluit baie ander kenmerke in, soos multi_ack of side-band vermoëns, maar die dekking daarvan val buite die bestek van hierdie boek. Ons het probeer om vir jou 'n idee te gee van die algemene heen-en-weer tussen kliënt en bediener; as jy meer kennis as dit nodig het, sal jy waarskynlik na die Git-bronkode wil kyk.