कौन सा तेज़, एसएसएच या गिट प्रोटोकॉल है?

कौन सा प्रभावशाली है? एसएसएच: // या गिट: // (फ़ाइल संपीड़न)कौन सा तेज़, एसएसएच या गिट प्रोटोकॉल है?

मैं गिट में समझता हूं, गिट प्रोटोकॉल स्मार्ट है क्योंकि फाइल ट्रांसफर को संपीड़ित करने के लिए कमांड के दोनों छोर पर प्रोटोकॉल एजेंट होता है जिसके परिणामस्वरूप तेजी से क्लोन होता है नेटवर्क बैंडविड्थ।

ओ'रेली पुस्तक से मुझे निम्नलिखित बयान मिले।

For secure, authenticated connections, the Git native 
protocol can be tunneled over an SSH connection using 
the following URL templates: 

ssh: ///[[email protected]]example.com[:port]/path/to/repo.git 
ssh: //[[email protected]]example.com/path/to/repo.git 
ssh: //[[email protected]]example.com/~user2/path/to/repo.git 
ssh: //[[email protected]]example.com/~/path/to/repo.git*

मुझे यकीन नहीं है कि लेखक का अर्थ है कि वह क्या कहता है। वह एसएसएच पर सुरंग हो रही गिट प्रोटोकॉल की बात करता है।

मेरे परिप्रेक्ष्य से, जब तक कि आप गिट पोर्ट (एजेंट पोर्ट) से कनेक्ट न हों, प्रोटोकॉल प्रभावी नहीं है। और एसएसएच केवल असम्पीडित फ़ाइल स्थानांतरण है।
लेकिन लेखक के अनुसार, यदि हम एसएसएच का उपयोग करते हैं तो उनका कहना है कि गिट प्रोटोकॉल इसके ऊपर सुरंग है। तो जीआईटी में एसएसएच स्मार्ट है?

वॉन सी, आपके उत्तर के लिए धन्यवाद। "नेटवर्क प्रोटोकॉल (HTTP और गिट) आम तौर पर केवल पढ़ने के लिए होते हैं" जब आप डीमॉन को --enable = get-pack के साथ चलाते हैं तो गिट बनाया जा सकता है।

मेरी चिंताएं निम्नलिखित हैं। जब वे कहते हैं कि गिट प्रोटोकॉल स्मार्ट है, तो उनका मतलब है कि जब आप गिट क्लोन निष्पादित करते हैं, तो गिट सर्वर एजेंट क्लाइंट को वापस भेजे गए डेटा को संपीड़ित करता है, इसलिए क्लोन तेज़ी से होना चाहिए। मैं अपना उपयोगकेस मैं हांगकांग में गिट सर्वर स्थापित कर रहा हूं और इसे संजोज और अन्य देशों पर भी इस्तेमाल कर रहा हूं, इसलिए मैं विलंबता चिंताओं के कारण नेटवर्क पर कुशल होना चाहता हूं।

तो मेरा सवाल यह है कि जब मैं गिट क्लोन ssh: // user @ server/reposloc का उपयोग करता हूं तो मुझे गिट प्रोटोकॉल का लाभ भी मिलता है। ओरेली लेखक पुस्तक के अनुसार उनका मतलब है कि गिट एसएसएच पर सुरंग है, फिर गिट प्रोटोकॉल कैसे काम करता है जब मेरे पास सर्वर पर गिट डाइओमोन नहीं चल रहा है।

तो एसएसएच का उपयोग करके: // xyz ... क्या यह एसएसएच और गिट प्रोटोकॉल दोनों का लाभ देता है?

अग्रिम में आपके उत्तरों की सराहना करते हैं।

स्रोत

2010-07-14 vengateswaran c

"तो SSH का उपयोग कर: // xyz ... यह दोनों ssh और Git प्रोटोकॉल का लाभ देता है" हां –

मुझे अभी भी प्रश्न का उत्तर नहीं दिखाई दे रहा है। मेरे पास खींचने के लिए कई गीगाबाइट हैं और एसएसएच या https का उपयोग कर सकते हैं, जिसमें कम से कम समय लगेगा? –

पर एक नजर डालें this page

केवल "गूंगा" प्रोटोकॉल के दूसरे भाग सीधे HTTP, जो सर्वर पर कोई विशेष प्रयास की आवश्यकता है। दोनों गिट में: // और ssh: // प्रोटोकॉल, git upload-pack प्रक्रिया (जो एक डिमन नहीं है) सर्वर पर फोर्क किया गया है जो git fetch-pack चला रहे क्लाइंट के साथ संचार करता है। दोनों ssh: // और git: // में, आपको "स्मार्ट" संचार मिलता है।

स्रोत

2010-07-14 20:20:31 erjiang

हाय माज़िन ... धन्यवाद। यह मेरी चिंताओं का जवाब देता है। आपके योगदान के लिए धन्यवाद। –

गिट: // में एन्क्रिप्शन या प्रमाणीकरण ओवरहेड नहीं है जो ssh: // उपकरण है। git: // ssh: // के समान तेज़ डेटा-स्थानांतरण तंत्र का उपयोग करता है लेकिन कम गहन सर्वर-साइड है। – aus

साफ। मैं एसएसएच के साथ रहूंगा क्योंकि यह सुरक्षा के साथ दिमाग में बनाया गया है। –

Wikipedia से:

एक SSH सुरंग की स्थापना करने के लिए, एक एक SSH ग्राहक कॉन्फ़िगर दूरस्थ मशीन पर एक बंदरगाह करने के लिए एक निर्दिष्ट स्थानीय बंदरगाह अग्रेषित करने के लिए। एक बार एसएसएच सुरंग स्थापित हो जाने के बाद, उपयोगकर्ता नेटवर्क सेवा तक पहुंचने के लिए निर्दिष्ट स्थानीय पोर्ट से कनेक्ट कर सकता है। स्थानीय बंदरगाह की आवश्यकता नहीं है रिमोट पोर्ट के समान पोर्ट नंबर है।

आप ASCII आर्ट प्रतिनिधित्व के कुछ प्रकार की जरूरत है:

Git Data ---> [SSH encrypts data] ----- Internet -----> [SSH decrypts data] ----> Git Data

स्रोत

2010-07-14 17:33:26

इस उत्तर के लिए धन्यवाद, यह मेरी चिंता का समाधान करता है, लेकिन क्या आप मुझे बता सकते हैं कि यह सुनिश्चित करने के लिए यूआरएल क्या है कि अनुरोध वास्तव में गिट प्रोटोकॉल सर्वर के लिए सुरंग किया गया है। क्या यह कुछ चीज है ssh: // user @ host: [git port]/repository location ??? कृपया पक्का करेें। –

किसी भी प्रोटोकॉल सर्वर के लिए सुरंग नहीं है। आप __don't__ नंगे गिट प्रोटोकॉल का उपयोग करना चाहते हैं, यह __not__ एक इष्टतम समाधान है। –

आप SSH पर पहुँच प्राप्त करते हैं Git यह सिर्फ SSH पर Git प्रोटोकॉल सुरंगों, रास्ता आसान की स्थापना की और जिस तरह से और अधिक सुरक्षित करने के लिए, इस रिमोट रिपॉजिटरीज तक पहुंचने का पसंदीदा तरीका।

यह वास्तव में नंगे गिट प्रोटोकॉल की तुलना में "स्मार्ट" है, क्योंकि यह एसएसएच तंत्र के माध्यम से उपयोगकर्ता प्रमाणीकरण को लागू कर सकता है। गिट परिवहन प्रक्रिया के बावजूद सभी संपीड़न और क्लाइंट पर नहीं है, और यह सर्वर पर इसे डिकंप्रेस करता है।

"गिट" सर्वर ऐसा नहीं करता है, यह सब एसएसएच का उपयोग करते समय भी होता है।यदि आप रिमोट रिपोजिटरी को लिखने में सक्षम होना चाहते हैं तो गिट सर्वर से बचा जाना चाहिए। यदि आप केवल पढ़ने के लिए गिट या HTTP ट्रांसपोर्ट पढ़ना चाहते हैं तो "ठीक है", लेकिन यदि आपके पास ऐसे डेवलपर्स हैं जिन्हें रेस्पॉजिटरी को लिखने की आवश्यकता है तो आपको केवल एसएसएच का उपयोग करना चाहिए। गिट सर्वर के लिए सुरंगों की स्थापना करना जटिलता और कॉन्फ़िगरेशन में जोड़ रहा है जो भंगुर होगा और आपको कुछ भी हासिल नहीं करेगा।

स्रोत

2010-07-14 17:34:12

धन्यवाद। मैं इस जवाब से पूरी तरह सहमत नहीं हूं। क्योंकि जब आप गिट पुश ssh: // user @ server/location का उपयोग करते हैं तो आपको GIT डिमन चलाना नहीं पड़ता है। जब गिट डिमन नहीं चल रहा है तो आप कैसे कहते हैं कि एसएसएच पर गिट सुरंग है?गिट प्रोटोकॉल सर्वर नहीं चल रहा है, तो गिट प्रोटोकॉल को कौन संभालता है? –

एसएसएच सिर्फ परिवहन है, यह अभी भी एसएसएच पर "गिट प्रोटोकॉल" की बात करता है। यही वह है जो एसएसएच पर काम करता है, एसएसएच पर गिट रिमोट रिपोजिटरीज के साथ काम करने का सबसे प्रभावी तरीका है। आपको अभी भी रिमोट मशीन पर गिट की आवश्यकता है, लेकिन यह एक डेमॉन का उपयोग नहीं करता है, यह जटिल नहीं है। –

मुझे यकीन है कि ssh: // और git + ssh: // के बीच एक अंतर है। – erjiang

अद्यतन 2010-2014:

दोनों ssh और https, बराबर हैं Git के बाद से 1.6.6+ (2010) और smart http protocol के कार्यान्वयन:

smart http

अब आप उपयोग कर सकते हैं एसएसएच या https अपने repos को पढ़ने/लिखने के लिए उपयोग के लिए।
आप detect if your remote server supports smart http भी कर सकते हैं।
यदि आपको प्रॉक्सी का उपयोग करना है तो सही वातावरण चर जोड़ें।

Q3 2015, Yousha Aleayoub रूप in the comments का उल्लेख है:

GitHub "Which remote URL should I use?"

https:// क्लोन यूआरएल, सभी खजाने पर उपलब्ध सार्वजनिक और निजी हैं।
वे स्मार्ट हैं, इसलिए वे आपको भंडार में आपकी अनुमतियों के आधार पर या तो केवल पढ़ने-पढ़ने या पढ़ने/लिखने के लिए उपलब्ध कराएंगे। http:// और https:// प्रोटोकॉल पर भंडार तक पहुँचने Git ग्राहकों को एक Git भंडार की सामग्री को सेवा करने के लिए

सरल CGI कार्यक्रम:

git-http-backend है।
कार्यक्रम स्मार्ट HTTP प्रोटोकॉल और पीछे की तरफ संगत गूंगा HTTP प्रोटोकॉल, साथ ही स्मार्ट HTTP प्रोटोकॉल का उपयोग कर धक्का देने वाले क्लाइंट दोनों का उपयोग करके ग्राहकों को लाता है।

मूल जवाब (जुलाई 2010):

Pro Git Book से:

शायद Git के लिए सबसे आम परिवहन प्रोटोकॉल SSH है।
ऐसा इसलिए है क्योंकि अधिकांश स्थानों पर सर्वरों के लिए एसएसएच एक्सेस पहले से स्थापित है - और यदि ऐसा नहीं है, तो करना आसान है।

एसएसएच भी एकमात्र नेटवर्क-आधारित प्रोटोकॉल है जिसे आप आसानी से पढ़ सकते हैं और पर लिख सकते हैं। अन्य दो नेटवर्क प्रोटोकॉल (HTTP और गिट) आमतौर पर केवल पढ़ने के लिए होते हैं, इसलिए यदि आप उन्हें अवांछित लोगों के लिए उपलब्ध कराते हैं, तो भी आपको अपने स्वयं के लेखन आदेशों के लिए एसएसएच की आवश्यकता है।

एसएसएच भी एक प्रमाणीकृत नेटवर्क प्रोटोकॉल है; और क्योंकि यह सर्वव्यापी है, यह आमतौर पर सेट अप और उपयोग करना आसान है।

तो यह गिट प्रोटोकॉल से "स्मार्ट" नहीं है, केवल कुछ विशेषताओं के लिए एक पूरक प्रोटोकॉल है जो गिट प्रोटोकॉल द्वारा संबोधित नहीं है।

गिट प्रोटोकॉल का नकारात्मकता प्रमाणीकरण की कमी है। यह आमतौर पर गिट प्रोटोकॉल के लिए आपकी परियोजना के लिए एकमात्र पहुंच होने के लिए अवांछनीय है।
आम तौर पर, आप इसे कुछ डेवलपर्स जो धक्का (लिख) उपयोग किया है और रीड-ओनली पहुंच

के लिए हर किसी उपयोग git:// है के लिए SSH का उपयोग के साथ जोड़ी जाएगा यह भी पोर्ट 9418 के लिए फ़ायरवॉल का उपयोग की आवश्यकता है, जो isn ' एक मानक बंदरगाह है कि कॉर्पोरेट फ़ायरवॉल हमेशा अनुमति देते हैं। बड़े कॉर्पोरेट फ़ायरवॉल के पीछे, यह अस्पष्ट बंदरगाह आम तौर पर अवरुद्ध है।

(यही कारण है कि मेरी दुकान में, मैं जरूरत ssh + Git और न सिर्फ Git उपयोग करने के लिए, यहां तक कि पढ़ने के लिए पहुंच के लिए है: 9418 अवरुद्ध है ...)

स्रोत

2010-07-14 17:35:33 VonC

+1 आश्वस्त, मैं recon recon सही जवाब होना चाहिए क्योंकि यह नोब के लिए भी बेहतर बताता है। – Val

@ वैल धन्यवाद। एसएसएच का उपयोग करने से उपयोगकर्ता पहुंच प्रबंधन के बारे में अपनी बहस होती है: http://stackoverflow.com/a/16184533/6309 – VonC

की टिप्पणियां देखें स्वयं को ध्यान दें: 25 वें अपवॉट के साथ, इस जवाब के लिए "अच्छा उत्तर" चांदी का बैज मेरा है 1000 वां (यह मुझे लगभग 6 साल भी ले गया)। – VonC

विभिन्न प्रोटोकॉल, विभिन्न स्तरों (जैसे आईएसओ 7 परत मॉडल) पर हैं तो आप दोनों हो सकते हैं, तो आप तारों या किसी तार, या फाइबर से जुड़ा जा सकता है बस के रूप में।

स्रोत

2011-07-17 18:08:44

(मैं इस सवाल का जवाब @erjiang के लिए एक टिप्पणी जोड़ना चाहते थे, लेकिन क्योंकि मैं काफी StackOverflow प्रतिष्ठा की जरूरत नहीं है मैं अनुमति नहीं कर रहा हूँ।)

ऐसा लगता है कि Git 1.6.6 के बाद से, HTTP नहीं है " गूंगा "अब और। Git website's blog से:

पिछले साल (2009) के अंत में संस्करण 1.6.6 के रिलीज के रूप में, हालांकि, Git अब HTTP प्रोटोकॉल बस के बारे में के रूप में कुशलता से Git या ssh संस्करणों
के रूप में उपयोग कर सकते हैं

स्रोत

2014-01-13 11:42:00 Xavi

एक Git क्लोन दौरान पैक फ़ाइलों की एक त्वरित खोज ग्राहक के लिए सर्वर से भेजा जाता है कि एक ही पैक फ़ाइल सूची जाएगा। पैक फ़ाइल .git/ऑब्जेक्ट्स/पैक/पैक-XXXX.pack के अंतर्गत सूचीबद्ध है। सर्वर से क्लाइंट को भेजे जाने वाली फ़ाइलों को पहले पैक किया जाता है, संपीड़ित किया जाता है। फिर पैक की गई सामग्रियों की एक प्रति है। सर्वर पक्ष पर lsof -p का उपयोग करके पैक की गई फ़ाइलों की तुलना करते समय और क्लाइंट पक्ष पर lsof -p की तुलना में यह देखा जा सकता है। नमूना मामले में एक 200MB फ़ाइलों ग्राहक के लिए सर्वर से अपलोड की गई है ....

1) Server side 
    lsof -p 8079 | grep pack 
    git-uploa 8079 REG 253,2 277896169 5140075 /home/server/work/work0617/.git/objects/pack/pack-492945ae602a975d46df133f6ded9642146fb6a7.pack 
    git-uploa 8079 REG 253,2 1703472 5140076 /home/server/work/work0617/.git/objects/pack/pack-492945ae602a975d46df133f6ded9642146fb6a7.idx 
    git-uploa 8079 REG 253,2 277896169 5140075 /home/server/work/work0617/.git/objects/pack/pack-492945ae602a975d46df133f6ded9642146fb6a7.pack 

2) Client side 
    lsof -p 3140 | grep pack 
    git  3140 3u REG 8,1 101031935 3681610 /home/client/work/work0617/work0617/.git/objects/pack/tmp_pack_pRfYPa 

3) The server side pack file 277MB. The file on the client side is 101MB and growing. So a single compressed file is copied over.

स्रोत

2014-06-17 17:04:11

कौन सा तेज़, एसएसएच या गिट प्रोटोकॉल है?

उत्तर

संबंधित मुद्दे