मोठे डाउनलोड विरुद्ध 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

लक्षणाला अशा प्रकारे हाताळल्यास निर्गमनाचा निर्णय सुरक्षा धोरणाने ठेवलेल्या जागीच राहतो, आणि तो एका आदेशाने उलटता येतो. संपूर्ण रहदारी-वर्गासाठी निर्गमन बदलणे हे प्रमाणीकरण, नोंदणी आणि प्रवेश-नियमांच्या परिणामांसह धोरण बदल आहे, म्हणून विलंबाच्या तक्रारीवर ते पहिले साधन नसावे.

गरज खरोखर वेगळे इंटरनेट निर्गमन असेल, तर ते त्या शब्दांत सांगा आणि समर्थित सीमेवर लागू करा: मंजूर कार्यप्रवाहातून नवीन कनेक्शन, किंवा निवडलेल्या निर्गमनातून स्वतःची विनंती उघडणारे अ‍ॅप्लिकेशन. नंतर कोणती कार्ये कोणते निर्गमन वापरतात ते नोंदवा, जेणेकरून पुढच्या व्यक्तीला ते राउटिंग तक्त्यातून ओळखावे लागणार नाही.

बदल-नोंदीत तपासणी यादी ठेवा: निर्णय-बिंदू, तो चालवणारे फील्ड किंवा कार्य, प्रवाह आधीच आहे का, आणि मोजलेले लक्षण विलंब होता की निर्गमन. चार प्रश्न, आणि चारही उत्तर देणारे धोरण हे संरक्षित नव्हे तर चालवता येणारे धोरण आहे.