दोन अपलिंक पण एकच बोगदा: फेलओव्हर, संतुलन की बाँडिंग
फेलओव्हर, प्रति-प्रवाह संतुलन आणि एकाच प्रवाहाचे एकत्रीकरण ही तीन वेगळी वचने आहेत। दोन डीफॉल्ट मार्ग तुम्हाला पहिले देतात, बाकीचे दोन नाहीत।
दोन इंटरनेट लायनी 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जेव्हा एकच हस्तांतरण अजूनही एक अपलिंक वापरते, तेव्हा रचना प्रवाह हॅश सुचवतो तेच करत असते। जेव्हा समांतर हस्तांतरणे दोन्हींवर पसरतात, तेव्हा संतुलन चालते आणि एकत्रीकरण चालत नाही। रचना तीनपैकी कोणते वचन खरेच पाळते ते नोंदवा, आणि पुढील क्षमतेची चर्चा विक्रेत्याच्या दाव्यापासून नाही, पुराव्यापासून सुरू होईल।