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 की समस्या फिर भी ठीक करनी पड़ेगी। सुरंग के बाहर का यातायात कभी सुरंग की क्रम-खाली जगह के पीछे नहीं रुकता, हालाँकि जब दोनों रास्ते एक ही भरी हुई लिंक साझा करें तो वह फिर भी प्रभावित हो सकता है, और वह साझा अवरोध इसमें जोड़ने के बजाय अपनी अलग जाँच का हक़दार है।