OpenVPN TCP मा: rto_min ले लाइनको टाउकोको अवरोध हटाउँदैन

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

लक्षण ध्यान दिएर पढ्न लायक छ किनकि यसले सेटिङ नभई कार्यविधि देखाउँछ: रोकावट साझा छ, त्यसैले कारण पनि साझा छ, र साझा वस्तु बाहिरी जडान हो। यो हुँदा लगमा बाँकी सबै सामान्य देखिन्छ।

लक्षण: सबै एकैचोटि रोकिन्छन्

दुई भित्री जडान एकैसाथ अल्झिनु नै सुराक हो। ढिलो डाउनलोड र ढिलो शेल छुट्टाछुट्टै क्रम-संख्या र छुट्टै भीड अवस्था भएका छुट्टाछुट्टै TCP कुराकानी हुन्, त्यसैले एउटामा भएको खराबीले अर्कोलाई छुनु हुँदैन। तिनीहरू एउटै लयमा रोकिँदा तिनका माथि केही तिनका बाइट मिलाइरहेको हुन्छ।

त्यो केही टनेलको यातायात तह हो। TCP मोडमा OpenVPN ले इन्क्याप्सुलेटेड प्याकेट साथीतर्फको एउटै TCP जडानमा लेख्छ, र TCP को सम्झौता एउटै बाइट प्रवाहको क्रमिक डेलिभरी हो। पछिका बाइट हराएका भन्दा अघि अनुप्रयोगलाई दिइँदैन, ती कुन भित्री कुराकानीका भए पनि।

लक्षणले के भन्दैन भन्नेमा ध्यान दिनुहोस्। यसले बाटो बिग्रिएको, सर्भर अधिभारित भएको वा इन्क्रिप्शन ढिलो भएको भन्दैन। तीले अरू आकार दिन्छन्: समान रूपमा कम थ्रुपुट, समय सकिने, वा एउटै दिशालाई असर गर्ने खराबी। हराएको खण्ड पुनः पठाउँदा अन्त्य हुने साझा रोकावट ठ्याक्कै क्रमको प्रभाव हो।

एउटा बाहिरी बाइट प्रवाह, धेरै भित्री कुराकानी

टनेलले एकैसाथ डाउनलोड र शेल बोकेको कल्पना गर्नुहोस्। बाहिरी जडानको एउटा खण्ड हराउँछ। अर्का खण्डहरू प्राप्त गर्ने होस्टसम्म पुग्न सक्छन्, र प्राप्त गर्ने TCP स्ट्याकले तिनलाई स्वीकार गर्छ, तर खाली ठाउँ नभरिएसम्म तिनलाई माथि दिन सक्दैन। त्यसैले OpenVPN सँग शेलका लागि पढ्न केही छैन, शेलका आफ्नै बाइट धेरै अघि आइपुगे पनि।

यो एउटै जडानभित्रको कतारको सुरुवातको अवरोध हो, र यसले दुई अनुप्रयोगले भित्री जडान साझा गर्नुपर्ने माग गर्दैन। तिनले बाहिरी जडान साझा गर्छन्, र त्यो पर्याप्त छ।

दोस्रो क्रमको प्रभावले यसलाई अझ बिगार्छ। स्वीकृति नदेख्ने भित्री पठाउनेले बाहिरी तहले पठाउन खोजिरहेको डेटा फेरि पठाउन सक्छ। त्यो पुनःपठन बाटोमा थप टनेल ट्राफिक बन्छ जसले भर्खरै खण्ड गुमाउन सक्ने प्रमाण दिएको छ, त्यसैले रिकभरीको काम महत्त्वपूर्ण रिकभरीसँग प्रतिस्पर्धा गर्छ।

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

लामो भित्री टाइमरले किन मद्दत गर्न सक्दैन

बाटोमा rto_min ले न्यूनतम पुनःपठन समयसीमा बढाउँदा त्यो बाटो प्रयोग गर्ने स्थानीय रूपमा उत्पन्न TCP ट्राफिकका लागि टाइमरमा आधारित पुनःपठन ढिलो हुन्छ। यो वास्तविक प्रभाव भएको वास्तविक नब हो, र यसले पहिलो नभई दोस्रो क्रमको समस्या सम्हाल्छ।

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

यसले गर्न नसक्ने भनेको बाहिरी बाइट क्रमबाहिर छोड्नु, हराएको खण्ड छिटो रिकभर गर्नु, वा टाढाको अनुप्रयोग सर्भरलाई त्यही टाइमर अपनाउन बाध्य पार्नु हो। प्राप्त गर्ने स्ट्याक अझै क्रममा डेलिभरी गर्छ, र टाढाको छेउको पठाउनेले अझै आफ्नै गोल-फेर मापन प्रयोग गर्छ।

यसले अरू सबै नोक्सान-रिकभरी विधि पनि बन्द गर्दैन। जहाँ साँचो नोक्सानलाई टाइमरमा आधारित रिकभरी चाहिन्छ, त्यहाँ ठूलो न्यूनतमले अनुप्रयोगलाई काम गर्नुअघि बढी पर्खाउँछ, जो ढिलाइप्रति संवेदनशील सत्रलाई चाहिनेको ठीक उल्टो हो।

बाह्र सेकेन्डको स्थिर भुइँ यो विषयको सल्लाहमा यसरी देखिन्छ जनि TCP टनेलको अस्तित्वले यसलाई अनिवार्य गर्छ। RFC 6298 मा वर्णन गरिएको पुनःपठन टाइमर मापिएको गोल-फेर समयबाट घातांकी पछाडि हट्नेसहित निकालिन्छ, त्यसैले स्थिर भुइँ कुनै खास बाटोका लागि नीतिको छनोट हो, प्रोटोकलको आवश्यकता होइन। व्यापक रूपमा लागू गर्दा यसले लक्षण लुकाउँछ र सँगै त्यो बाटोले समेट्ने हरेक प्रवाहको रिकभरी बदल्छ।

tcp-nodelay ले के गर्छ र के गर्दैन

यातायात सकेटमा Nagle शैलीको बफरिङ बन्द गर्ने टनेल विकल्पको उद्देश्य साँघुरो छ: साना लेखनलाई पठाउनुअघि थप डेटा पर्खनबाट रोक्छ। यसले अन्तरक्रियात्मक ट्राफिकलाई अन्यथा स्वस्थ बाटोमा थप ढिलाइबाट बच्न मद्दत गर्छ।

यसले यातायातलाई अक्रमिक बनाउँदैन, र हराएको खण्डपछिको रिकभरी छोटो पार्दैन। पुनःपठन समयसीमाका लागि रोकिने शेल त्यो विकल्प खुला हुँदा पनि रोकिन्छ, किनकि विकल्पले क्रमको नियम कहिल्यै छोएन।

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

यातायातको निष्पक्ष तुलना कसरी गर्ने

यदि सञ्चालकले अनुमति दिन्छ र दुवै सेवा छन् भने, उही सर्भरतर्फको उही पहुँच बाटोमा एउटै कार्यभार बोक्ने UDP सेवा र TCP सेवाको तुलना गर्नुहोस्। दुई परीक्षणबीच देश, प्रदायक वा सर्भर पुस्ता बदल्दा नतिजामा हाबी हुने चर भित्रिन्छ।

थ्रुपुटको अङ्क नभई साझा रोकावट हेर्नुहोस्। बाहिरी नोक्सानका बेला धेरै भित्री अनुप्रयोग एकैसाथ अल्झिनु नै कतारको सुरुवातको अवरोध पहिचान गर्ने अवलोकन हो; स्पिड टेस्टको एउटा कम अङ्कले त्यो गर्दैन।

टनेल इन्टरफेस र भौतिक इन्टरफेसमा गरिएको अनुमतिप्राप्त क्याप्चरले दुई तह छुट्ट्याउँछ, किनकि भित्री र बाहिरी पुनःपठन फरक क्रम-क्षेत्र भएका फरक जडानका हुन्। बाहिरी प्रवाहले खाली ठाउँ देखाउँदा भित्री पुनःपठन देख्नु प्रत्यक्ष प्रमाण हो।

UDP मा जाँदा थप भरपर्दो प्रवाह हट्छ र भित्री TCP ले आफ्नै रिकभरी गर्छ। यसले शून्य नोक्सान वा कम ढिलाइको वाचा गर्दैन, र भरिएको अपलिंक, अत्यधिक कतार वा MTU समस्या अझै सुधार्नुपर्नेछ। टनेलबाहिरको ट्राफिक कहिल्यै टनेलको क्रम-खाली ठाउँपछाडि रोकिँदैन, तर दुवै बाटोले एउटै भीड भएको लिंक साझा गर्दा यो अझै पीडित हुन सक्छ, र त्यो साझा अवरोध यसमा नथुपारी आफ्नै छानबिनको योग्य छ।