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 समस्या अजूनही सुधारावी लागेल। बोगद्याबाहेरील रहदारी कधीही बोगद्याच्या क्रम-रिकाम्या जागेमागे अडवली जात नाही, तरीही दोन्ही मार्ग एकच गर्दीची लिंक सामायिक करतात तेव्हा ती अजूनही त्रास सहन करू शकते, आणि तो सामायिक अडथळा यात दुमडण्याऐवजी स्वतःच्या चौकशीला पात्र आहे।