मुझे दो मेजबानों के बीच कई द्वैध चैनल चाहिए। केवल एक टीसीपी कनेक्शन स्थापित करने के लिए कई फायदे हैं। लेकिन मुझे संदेह है कि मल्टीप्लेक्सिंग कुछ अपरिहार्य समस्याओं का कारण होगी। क्या यह प्रदर्शन को नुकसान पहुंचाएगा या विलंबता में काफी वृद्धि करेगा? और मेमोरी उपयोग और सीपीयू उपयोग के बारे में क्या? क्या कोई सुझाव या चेतावनी है जिसे आप देना चाहेंगे?
जवाबों:
TLDR: टीसीपी के शीर्ष पर कई चैनलों को मल्टीप्लेक्स करते समय (अगर आप इसे सही करते हैं) तो बड़ी खामी आपको चैनलों के बीच हेड-ऑफ-लाइन ब्लॉक होने के कारण बढ़ी हुई विलंबता है।
कोरोलरी: यदि आप विलंबता के बारे में परवाह नहीं करते हैं तो आपको ठीक होना चाहिए।
दूसरी ओर एकल टीसीपी कनेक्शन का उपयोग करने का अर्थ है "अन्य प्रवाह और लंबे समय तक रहने वाले कनेक्शन के साथ कम प्रतिस्पर्धा, जिसके कारण उपलब्ध नेटवर्क क्षमता का बेहतर उपयोग होता है" ।
यदि आप एक ही टीसीपी स्ट्रीम के कई चैनलों को मल्टीप्लेक्स करते हैं, तो चैनल हेड-ऑफ-लाइन ब्लॉकिंग का शिकार हो सकते हैं :
हेड-ऑफ-लाइन ब्लॉकिंग (HOL) तब हो सकती है जब ट्रांसपोर्ट प्रोटोकॉल ऑर्डर या आंशिक-ऑर्डर की गई सेवा प्रदान करते हैं: यदि सेगमेंट खो जाते हैं, तो बाद के संदेशों को रिसीवर कतार में सफल रिट्रांसमिशन के लिए इंतजार करना पड़ता है और इस प्रकार देरी हो जाती है।
जब आप टीसीपी के ऊपर कई धाराओं को मल्टीप्लेक्स करते हैं तो आपको चैनलों के बीच एचओएल मिलता है ।
यदि चैनल ए ने टीसीपी भेजें बफर को भर दिया है, तो आपको इस डेटा के सभी प्राप्त होने से पहले इंतजार करना होगा क्योंकि चैनल बी के किसी भी नए डेटा को प्रभावी रूप से दूरस्थ एप्लिकेशन परत पर प्रेषित किया जा सकता है।
टीसीपी के शीर्ष पर मल्टीप्लेक्सिंग चैनलों और हैकर्न्यूज पर चर्चा के बारे में अधिक जानकारी के लिए "टीसीपी के शीर्ष पर मल्टीप्लेक्सिंग" देखें ।
इसका एक विशिष्ट उदाहरण SSH है। SSH कई चैनलों को मल्टीप्लेक्स कर सकता है (देखें ControlMaster, ControlPathऔर ControlPersistOpenSSH में)। इसका उपयोग करने से एक नए SSH सत्र (प्रारंभिक विलंबता) को शुरू करने की लागत कम हो जाती है, लेकिन एक चैनल पर भारी स्थानांतरण आमतौर पर अन्य लोगों की विलंबता / अन्तरक्रियाशीलता को बढ़ाता है (जो कि अगर आप कई टीसीपी स्ट्रीम का उपयोग नहीं करते हैं): यदि आप एक इंटरैक्टिव का उपयोग कर रहे हैं सत्र और उसी चैनल पर एक भारी फ़ाइल स्थानांतरण को ट्रिगर करना शुरू करते हैं, आपका सत्र बहुत कम इंटरएक्टिव होने लगेगा।
HTTP / 2 HOL अवरोध को ठीक करने के लिए TCP पर अनुरोधों / प्रतिक्रियाओं के बहुसंकेतन का उपयोग करता है। यह सुविधा HTTP / 2 के बारे में कई लेखों और पत्रों में विज्ञापित है। HTTP / 2 आरएफसी का दावा है:
HTTP / 1.1 ने अनुरोध जोड़ा पाइपलाइनिंग, लेकिन यह केवल आंशिक रूप से संबोधित अनुरोध संगामिति है और अभी भी हेड-ऑफ-लाइन ब्लॉकिंग से ग्रस्त है।
[...]
परिणामी प्रोटोकॉल नेटवर्क के लिए अधिक अनुकूल है क्योंकि HTTP / 1.x की तुलना में कम टीसीपी कनेक्शन का उपयोग किया जा सकता है। इसका मतलब अन्य प्रवाह और लंबे समय तक जीवित कनेक्शन के साथ कम प्रतिस्पर्धा है, जो बदले में उपलब्ध नेटवर्क क्षमता का बेहतर उपयोग करता है।
हालाँकि जो चर्चा नहीं की गई है वह यह है कि एचओएल ब्लॉकिंग पूरी तरह से हल नहीं हुई है। HTTP / 2 ओवरसीपी अभी भी ग्रस्त है ) टीसीपी-स्तरीय एचओएल ब्लॉकिंग से ।
इस LWN लेख में QUIC के बारे में चर्चा की गई है :
HTTP / 2 को एक ही कनेक्शन में निर्मित कई "स्ट्रीम" का उपयोग करके इस समस्या को हल करने के लिए डिज़ाइन किया गया था । [...] यह एक नई समस्या पैदा करता है: एक एकल पैकेट का नुकसान एक ही बार में सभी धाराओं के प्रसारण को रोक देगा, जिससे नई विलंबता मुद्दे बनेंगे। हेड-ऑफ-द-लाइन-ब्लॉकिंग समस्या पर यह वेरिएंट टीसीपी में ही बनाया गया है और HTTP स्तर पर अधिक ट्विक्स के साथ तय नहीं किया जा सकता है।
यह SCTP (मल्टीस्ट्रीमिंग) की विशिष्ट विशेषताओं में से एक है, आप एक ही SCTP एसोसिएशन में कई स्वतंत्र स्ट्रीम कर सकते हैं और प्रत्येक स्ट्रीम अन्य को ब्लॉक नहीं करता है।
एससीटीपी पर एसएसएच देखें - एसएसएच में क्रॉस-चैनल एचओएल ब्लॉकिंग से बचने के लिए एससीटीपी का उपयोग करने के प्रभाव के लिए एससीटीपी के लिए एक मल्टी-चैनल प्रोटोकॉल का अनुकूलन।
SCTP केवल हेड-ऑफ-लाइन ब्लॉकिंग के रूप में जाने वाले प्रभाव को कम करने के लिए एक ही स्ट्रीम के भीतर संदेशों के क्रम को संरक्षित करता है। यदि कोई संदेश खो जाता है, तो बाद के संदेशों को तब तक विलंबित करना पड़ता है जब तक कि खोए हुए को ऑर्डर को संरक्षित करने के लिए वापस नहीं ले लिया जाता है। चूंकि केवल एक ही स्ट्रीम के संदेशों में देरी होती है, इसलिए नुकसान के बाद प्रभावित संदेशों की संख्या कम हो जाती है।
[...]
एससीटीपी की धाराओं पर एसएसएच के चैनलों की मैपिंग करके, मल्टी-स्ट्रीमिंग का लाभ एसएसएच को उपलब्ध कराया जाता है, जो हेड-ऑफ-लाइन ब्लॉकिंग का शमन है ।
SCTP को तैनात करना आसान नहीं है (क्योंकि OS की उपलब्धता, मिडबॉक्स इंटरेक्शन आदि)। एक संभावना यह है कि इसे यूडीपी पर यूजर्सस्पेस में लागू किया जाएगा ।
एक अन्य उदाहरण, UDP पर HTTP को बहुसंकेतन के लिए प्रयोग किया जाने वाला प्रयोगात्मक QUIC प्रोटोकॉल है (क्योंकि TCP के शीर्ष पर कई धाराएँ HTTP / 2 के रूप में HTTP HOL अवरुद्ध होने से ग्रस्त हैं ):
QUIC एक नया परिवहन है जो टीसीपी की तुलना में विलंबता को कम करता है । सतह पर, QUIC टीसीपी + टीएलएस + एचटीटीपी / 2 यूडीपी पर लागू होने के समान है।
[...]
लाइन ब्लॉकिंग के बिना मल्टीप्लेक्सिंग
Google का QUIC प्रोटोकॉल: TCP से UDP पर मल्टीप्लेक्सिंग चैनलों के लिए टीसीपी से यूडीपी में वेब को स्थानांतरित करना QUIC और HOL ब्लॉकिंग का एक अच्छा अवलोकन प्रस्तुत करता है।
एक हालिया प्रस्तुति का दावा है कि HTTP से अधिक QUIC विलंबता में सुधार करता है, लेकिन HOL- अवरुद्ध सुधार एक "छोटा लाभ" है:
0-RTT, विलंबता सुधार का 50% से अधिक
[...]
कम समय आधारित रिट्रांसमिशन टेल लेटेंसी में सुधार करते हैं […]
अन्य, छोटे लाभ, उदाहरण के लिए ब्लॉक अवरुद्ध का सिर
ध्यान दें कि जबकि QUIC को "बहुत ही टीसीपी + टीएलएस + एचटीटीपी / यूडीपी पर लागू" के रूप में वर्णित किया गया है, यह वास्तव में एक सामान्य-प्रयोजन परिवहन है जो कि स्वतंत्र रूप से एचटीटीपी / 2 का उपयोग किया जा सकता है और आपकी आवश्यकताओं के अनुरूप हो सकता है।
नोट: HTTP / QUIC si को HTTP / 3 के रूप में मानकीकृत किया जाएगा ।
मैं कहूंगा कि आपको ZeroMQ गाइड को पढ़ने की जरूरत है , इसके कारण और नुकसान के साथ यह पैटर्न आवश्यक रीडिंग है।
लेकिन अन्यथा, आपके एप्लिकेशन डेटा वितरण से नेटवर्क चैनल को डिस्कनेक्ट करने में कोई समस्या नहीं है। आपको भेजे गए डेटा पैकेटों के muxing और demuxing पर ले जाना होगा (और मैं यहां एक पैकेट-आधारित आर्किटेक्चर की सिफारिश करूंगा, निरंतर प्रवाह में डेटा स्ट्रीमिंग नहीं) और प्रत्येक छोर पर बफरिंग।
थोड़ा प्रभाव होना चाहिए अन्यथा, आपको अधिक मेमोरी की आवश्यकता हो सकती है - लेकिन केवल थोड़ा - बफर डेटा के लिए, और थोड़ा अधिक सीपीयू जैसा कि आप लॉक और पार्स पैकेट के लिए अधिक कोड संभाल रहे हैं, लेकिन कुछ भी महत्वपूर्ण नहीं है। (जब तक कि आप कुछ विशेषज्ञ नहीं लिख रहे हैं, जिसके लिए बड़े थ्रूपुट की आवश्यकता होती है और प्रदर्शन महत्वपूर्ण है)।
हां, मैंने इस सिद्धांत का उपयोग करके क्लाइंट-सर्वर डेटाबेस सिस्टम बनाया है।
चैनल एक टीसीपी कनेक्शन पर मल्टीप्लेक्स किए गए हैं, जो प्रत्येक डेटा के पैकेट भेजते हैं, जो फिर दूसरे छोर पर संबंधित प्राप्तकर्ताओं से अलग हो जाते हैं।
एक गार्बल चैनल द्वारा कनेक्शन का हॉगिंग टीसीपी कनेक्शन प्रेषक द्वारा राउंड-रॉबिन का चयन करके किया जाता है, जिसमें से पैकेट उन चैनलों के बीच से संचारित होता है जिनके पास भेजने के लिए डेटा तैयार है।
एक चैनल के मामले को संभालने के लिए 1 जीबी पैकेट भेजने का फैसला करने और बाकी सभी को लॉक करने के लिए, प्रेषक किसी पैकेट को चंक्स में विभाजित करने का विकल्प चुन सकता है और केवल एक चैंक भेजने से पहले ही दूसरे चैनल को चालू कर देता है। प्राप्तकर्ता के पैकेट को प्राप्त करने से पहले एक पैकेट में चूजों के पुनर्मूल्यांकन के अंत में किया जाता है।