बड़े डाउनलोड बनाम VPN: रास्ता अनुरोध पर ही चुनें

“बड़े डाउनलोड VPN के बगल से भेजो और छोटी प्रतिक्रियाएँ उसी पर रखो” राउटिंग नीति जैसा लगता है, पर है नहीं। राउटर उसी क्षण उपलब्ध जानकारी से निर्णय लेता है: पते, पोर्ट, प्रोटोकॉल, firewall चिह्न, पहचाना गया प्रवाह। प्रतिक्रिया का अंतिम आकार उस समुच्चय में नहीं है, क्योंकि वह अभी आया नहीं है, और जब राउटर बाइट नाप सकेगा तब वह उन्हें पहले ही ले जा रहा होगा। यदि आप कार्य के अनुसार मार्गदर्शन चाहते हैं, तो निर्णय ऐसे बिंदु पर जाना चाहिए जो कार्य को जानता है, और नीचे दी गई जाँच-सूची बताती है कि आपके डिज़ाइन में ऐसा बिंदु है या नहीं।

राउटर किसी प्रतिक्रिया को क्यों नहीं नाप सकता

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

स्वयं प्रोटोकॉल का मेटाडेटा भी दिखने से कमज़ोर है। HTTP ऐसी प्रतिक्रियाएँ अनुमत करता है जिनकी लंबाई शरीर से पहले घोषित नहीं होती, और एक उपयोगकर्ता-क्रिया ऐसे कई अनुरोध पैदा कर सकती है जिनकी संयुक्त लागत किसी एक हेडर मान जैसी नहीं होती। हेडर को कार्य का आकार मानना राउटिंग त्रुटि से पहले मॉडलिंग त्रुटि है।

जाँच 1: क्या ऐसा निर्णय-बिंदु है जो रास्ता चुन सके?

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

यदि उत्तर “गेटवे” है, तो जाँच-सूची पहले ही विफल हो चुकी है। गेटवे ज्ञात प्रवाहों को गंतव्य, चिह्न या क्लाइंट खंड के अनुसार वर्गीकृत करके पहले पैकेट से निर्धारित मार्ग पर भेज सकता है, जो स्वीकृत अपडेटर के लिए अक्सर पर्याप्त होता है और अज्ञात प्रतिक्रिया-आकार के लिए कभी पर्याप्त नहीं।

जाँच 2: मेटाडेटा वास्तव में आपको क्या बताता है?

एप्लिकेशन-जागरूक मार्गदर्शन उतना ही अच्छा है जितने अच्छे वे फ़ील्ड हैं जिन्हें वह पढ़ता है। HTTP का अर्थ-विज्ञान में प्रतिक्रिया-लंबाई के नियम ऐसे मामले अनुमत करते हैं जहाँ लंबाई शुरुआत में उपलब्ध नहीं होती, और सामग्री-एन्कोडिंग स्थानांतरित बाइट-गणना को प्रस्तुति के आकार से भिन्न बना देती है। इसलिए हेडर के सीमा पार करने पर रास्ता बदलने वाली नीति असंगत व्यवहार करेगी, और अधिकतर ठीक उन बड़े स्थानांतरणों पर जिन्हें पकड़ने के लिए वह बनी थी।

एप्लिकेशन मेटाडेटा जिसका समर्थन कर सकता है वह कार्य के बारे में निर्णय है: यह वर्कफ़्लो थोक सिंक है, यह इंटरैक्टिव है, यह ज्ञात स्रोत से सॉफ़्टवेयर अपडेट है। वह मंशा की भाषा में लिखी नीति है, और परखने के लिए पर्याप्त स्थिर है। “यह प्रतिक्रिया चालीस मेगाबाइट से बड़ी होगी” ऐसी नीति नहीं है।

जाँच 3: क्या प्रवाह पहले से मौजूद है?

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

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

इसलिए व्यावहारिक नियम यह है कि कनेक्शन के बीच में एक निर्गम से दूसरे पर जाना नया संबंध है, स्थानांतरण नहीं। यदि डिज़ाइन चाहता है कि वही कनेक्शन चले, तो निर्णय पहले SYN से पहले लेना था, और बाद में जोड़ा गया कोई पैकेट-नियम उसे साफ़ तौर पर फिर नहीं बना सकता।

जाँच 4: क्या असली आवश्यकता विलंब है, निर्गम नहीं?

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

tc qdisc replace dev eth0 root cake bandwidth 100mbit

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

यदि आवश्यकता वास्तव में अलग इंटरनेट निर्गम है, तो उन्हीं शब्दों में कहिए और समर्थित सीमा पर लागू कीजिए: स्वीकृत वर्कफ़्लो से नया कनेक्शन, या ऐसा एप्लिकेशन जो चुने गए निर्गम से अपना अनुरोध खोले। फिर दर्ज कीजिए कि कौन-से कार्य कौन-सा निर्गम उपयोग करते हैं, ताकि अगले व्यक्ति को उसे राउटिंग तालिका से अनुमान लगाना न पड़े।

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