ठूला डाउनलोड र 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

लक्षणलाई यसरी सम्बोधन गर्दा निकास-निर्णय सुरक्षा नीतिले राखेको ठाउँमै रहन्छ, र एक आदेशले उल्टाउन सकिन्छ। पूरै ट्राफिक-वर्गका लागि निकास बदल्नु प्रमाणीकरण, लगिङ र पहुँच-नियमका परिणामसहितको नीति परिवर्तन हो, त्यसैले ढिलाइको गुनासोमा त्यो पहिलो साधन हुनुहुँदैन।

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

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