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 பிரச்சினை இன்னும் சரிசெய்யப்பட வேண்டும். சுரங்கப்பாதைக்கு வெளியேயான போக்குவரத்து சுரங்கப்பாதையின் வரிசை இடைவெளிக்குப் பின்னால் ஒருபோதும் தடுத்து வைக்கப்படுவதில்லை, இரு பாதைகளும் ஒரே நெரிசலான இணைப்பைப் பகிரும்போது அது இன்னும் பாதிக்கப்படலாம், அந்தப் பகிரப்பட்ட இடையூறு இதில் மடிக்கப்படாமல் தனி விசாரணைக்கு உரியது.