दो अपलिंक लेकिन एक सुरंग: फेलओवर, संतुलन या बॉन्डिंग
फेलओवर, प्रति-फ़्लो संतुलन और एक ही फ़्लो का एकत्रीकरण तीन अलग वादे हैं। दो डिफ़ॉल्ट रूट आपको पहला देते हैं, बाकी दो नहीं।
दो इंटरनेट लाइनें VPN को अधिक उपलब्ध बना सकती हैं, और कुछ कार्यभारों के लिए उसे तेज़ भी बना सकती हैं, लेकिन कौन-सी बात होगी यह तंत्र तय करता है। दो डिफ़ॉल्ट रूट वाला राउटर बॉन्डेड नहीं है, और हज़ारों आंतरिक कनेक्शन ढोने वाली सुरंग अब भी एक बाहरी फ़्लो है। वादे का नाम पहले रखना ही किसी डिज़ाइन और किसी महँगी निराशा के बीच का अंतर है। नीचे दी गई तालिका विकल्पों को इस आधार पर अलग करती है कि हर एक को दूर के सिरे पर क्या चाहिए और लिंक जाने पर किसी स्थानांतरण का क्या होता है।
तीन वादे, और सिर्फ़ एक को साथी चाहिए
फेलओवर पसंदीदा लिंक के जाने पर भी एक मार्ग उपलब्ध रखता है। फ़्लो-हैश संतुलन स्वतंत्र फ़्लो को दोनों अपलिंक पर फैलाता है। एक-फ़्लो एकत्रीकरण एक स्थानांतरण को एक साथ दोनों लिंक इस्तेमाल करने देता है। ये अलग-अलग ज़रूरतों वाले अलग उत्पाद हैं, और सिर्फ़ आख़िरी को आपके राउटर के बाहर की किसी चीज़ के सहयोग की ज़रूरत है।
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
उस तालिका में कुछ भी दूसरी लाइन खरीदने की वजह नहीं है। वह जो करती है वह यह है कि फेलओवर डिज़ाइन को बॉन्डिंग मानकर आँका जाने से रोकती है।
राउटर को सुरंग एक ही फ़्लो जैसी क्यों दिखती है
लोड संतुलित करने वाला राउटर स्रोत और गंतव्य पतों को पोर्टों के साथ हैश करता है और फिर पूरा फ़्लो वहाँ भेजता है जहाँ हैश इशारा करता है। राउटर की नज़र में VPN सुरंग ऐसा ही एक फ़्लो है, भीतर कुछ भी चल रहा हो। आंतरिक कनेक्शन कभी हैश के फ़ैसले तक नहीं पहुँचते, क्योंकि बाहरी हेडर मार्ग तय कर चुका होता है। इसीलिए दूसरा अपलिंक बहुत से उपयोगकर्ताओं के लिए कुल क्षमता दोगुनी कर सकता है और एक उपयोगकर्ता के बड़े स्थानांतरण में कुछ नहीं बदलता।
दो अलग सुरंगें आपको दो उम्मीदवार दे सकती हैं, पर उन्हें अब भी एक सोची-समझी नीति चाहिए जो ट्रैफ़िक बाँटे और जवाब उसी मार्ग पर रखे जिसने अनुरोध ढोया था। उस कदम को छोड़ने का सामान्य नतीजा असममित राउटिंग है। कम से कम ऐसी नीति चाहिए जो फ़्लो, पसंदीदा लिंक और बैकअप लिंक का नाम ले।
ईथरनेट बॉन्डिंग असंबंधित प्रदाताओं के पार नहीं जाती, क्योंकि दूर के सिरे को एकत्रीकरण प्रोटोकॉल में हिस्सा लेना पड़ता है। सहयोगी अंतिम बिंदु के बिना दो ISP के बीच बॉन्डिंग एक शोध परियोजना है।
मल्टीपाथ TCP को दोनों सिरों पर क्या चाहिए
Linux का Multipath TCP दस्तावेज़ एक कनेक्शन से जुड़े कई उप-फ़्लो का वर्णन करता है। एक सिरे पर कर्नेल समर्थन अपने आप कुछ नहीं बदलता, क्योंकि साथी को भी वे उप-फ़्लो स्वीकार करने पड़ते हैं। दूर की ओर प्रॉक्सी दूसरी सामान्य व्यवस्था है, और वह अपनी क्षमता और उपलब्धता वाला घटक बन जाता है जिसकी योजना बनानी पड़ती है। वही तर्क WireGuard के लिए आसान जवाब को रद्द करता है, जिसका परिवहन UDP है: MPTCP TCP उप-फ़्लो बढ़ाता है और डिज़ाइन में कुछ और बिना उस सुरंग का एकत्रीकरण नहीं कर सकता।
कर्नेल सुविधा चालू है या नहीं यह उसके इर्द-गिर्द डिज़ाइन करने से पहले जाँचें, क्योंकि कई वितरण उसे बंद हालत में देते हैं। ये तीन कमांड एक मिनट में उसका जवाब देते हैं।
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showब्रोशर नहीं, कार्यभार देखकर चुनें
अगर कार्यभार बहुत से स्वतंत्र सत्र हैं, तो फ़्लो-हैश संतुलन दूर के सिरे के सहयोग के बिना क्षमता जोड़ सकता है। अगर एक बड़ा स्थानांतरण है, तो सिर्फ़ एकत्रीकरण का डिज़ाइन मदद करेगा, और उस डिज़ाइन को सहयोगी साथी चाहिए। अगर ज़रूरत यह है कि लिंक मरने पर भी काम चलता रहे, तो जवाब फेलओवर है और एक स्थानांतरण की थ्रूपुट अप्रासंगिक है।
ज़रूरत को क्रिया वाले एक वाक्य में लिखें: एक बैकअप दोगुना तेज़ पूरा होता है, या गिरा हुआ लिंक सत्र ख़त्म नहीं करता। धुँधले लक्ष्य ऐसे डिज़ाइन पैदा करते हैं जिन्हें कोई स्वीकार भी नहीं कर सकता और अस्वीकार भी नहीं। फिर तय करें कि दूर का सिरा क्या हो सकता है, क्योंकि सबसे सस्ता विकल्प अक्सर वही होता है जो वहाँ कुछ नया नहीं माँगता। वही सीमा पहली बैठक से पहले ब्रोशर के ज़्यादातर दावे हटा देती है।
ज़रूरत के दस्तावेज़ में तीनों वादों को अलग रखें। तीनों का दावा करने वाला डिज़ाइन आम तौर पर एक देता है और बाकी चुपचाप मान लेता है। अगला हिस्सा जाँचता है कि असल में कौन-सा दिया जाता है।
एक स्थानांतरण और कई जाँचें, फिर एक लिंक खींचें
एक लगातार स्थानांतरण की तुलना उसी गंतव्य पर कई समानांतर स्थानांतरणों से करें, और हर एक के लिए हानि, विलंब और प्रति-लिंक उपयोग दर्ज करें। सिर्फ़ समानांतर सत्रों में लाभ मिलने का मतलब फ़्लो वितरण है, एक-फ़्लो एकत्रीकरण नहीं। एक अपलिंक की हानि अलग से जाँचें, क्योंकि दोनों लिंक चालू रहते हुए क्षमता स्थापित सत्र के फेलओवर के बारे में कुछ नहीं कहती। हर परीक्षण से पहले और बाद में मार्ग, सॉकेट और पुनःप्रेषण काउंटर दर्ज करें।
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5जब एक ही स्थानांतरण अब भी एक अपलिंक इस्तेमाल करता है, तब डिज़ाइन ठीक वही कर रहा है जो फ़्लो हैश का मतलब है। जब समानांतर स्थानांतरण दोनों पर फैलते हैं, तब संतुलन काम करता है और एकत्रीकरण नहीं। दर्ज करें कि डिज़ाइन तीनों में से कौन-सा वादा सचमुच निभाता है, और अगली क्षमता बातचीत विक्रेता के दावे से नहीं, सबूत से शुरू होगी।