கில் சுவிட்ச் செயல்படும்போது: திறந்த TCP அமர்வுகளுக்கு என்ன நடக்கும்?

சுரங்கப்பாதை விழுகிறது, கில் சுவிட்ச் செயல்படுகிறது, மேலும் முக்கால் பங்கு முடிந்திருந்த பதிவிறக்கம் ஒன்று உறைகிறது அல்லது உடனடியாகத் தோல்வியடைகிறது. இந்த இரண்டு விளைவுகளும் பாதுகாப்பின் வெவ்வேறு நிலைகளிலிருந்து அல்ல, அமலாக்கத்தின் வெவ்வேறு தேர்வுகளிலிருந்து வருகின்றன. நிராகரிக்கப்பட்ட பாக்கெட் இணைப்பைக் காத்திருக்க வைக்கிறது, ஆனால் மறுக்கப்பட்ட பாக்கெட் அதை மூடி பயன்பாட்டுக்குத் தெரிவிக்கிறது. எந்த நடத்தை வேண்டும் என்பது வடிவமைப்புக் கேள்வி, அதைச் சோதிப்பது தனி பயிற்சி.

நிராகரித்தல், மறுத்தல் மற்றும் மீட்டமைத்தல் வேறுபடுகின்றன

போக்குவரத்தை நிராகரிக்கும் ஃபயர்வால் விதி பாக்கெட்டைத் தூக்கி எறிந்து எதையும் திருப்பி அனுப்பாது, எனவே அனுப்புநர் தனது சொந்த நேரங்களின்படி மீண்டும் அனுப்பிக்கொண்டே இருப்பார். TCP reset மூலம் மறுக்கும் விதி இணைப்பை உடனே மூடுகிறது, பயன்பாட்டுக்குப் பிழை தெரிகிறது. பெரும்பாலான கில் சுவிட்சுகள் நிராகரிக்கின்றன, ஏனெனில் மறுத்தல் கொள்கையை வெளிப்படுத்தும், மேலும் நிராகரித்தல் இறந்த வலையமைப்பின் நடத்தையைப் போலத் தெரிகிறது.

தடுப்பது சாக்கெட்டை மூடுவதற்குச் சமமானது அல்ல. பயன்பாடு இன்னும் நிறுவப்பட்ட நிலையில் விவரிப்பான் வைத்திருக்கிறது, பாக்கெட்டுகள் மட்டுமே இல்லை. அதனால்தான் இயக்க முறைமை இணைப்பு உள்ளது என்று வாதிடும்போது பக்கமானது நிமிடங்கள் சுழலியில் இருக்க முடியும். பயன்பாட்டின் செய்தியிலிருந்து ஊகிப்பதற்குப் பதிலாக ஆவணப்படுத்தப்பட்ட அமலாக்கத்தைப் படிக்கவும், ஏனெனில் இரண்டு நடத்தைகளும் வலையமைப்பு விழுந்ததைப் போலவே தெரிகின்றன.

இடைவெளி நீடிக்கும்போது பயன்பாடு என்ன செய்கிறது

TCP அதிகரிக்கும் தாமதங்களுடன் மீண்டும் அனுப்புகிறது, Linux இன் இயல்புநிலை மறுமுயற்சி நிதி நொடிகளில் அல்ல, சுமார் காலாண்டு மணி நேரத்தில் தீர்ந்துவிடும். அதுவரை சாக்கெட் பயனுள்ள வகையில் திறந்தும் இல்லை, மூடியும் இல்லை. தங்கள் சொந்த keepalive அல்லது கோரிக்கை நேர வரம்புகளைக் கொண்ட பயன்பாடுகள் பெரும்பாலும் முன்பே விட்டுவிடும், அதனால்தான் ஒரே இயந்திரத்தில் இரண்டு நிரல்கள் ஒரு குறுக்கீட்டின் போது வேறுபடுகின்றன.

சுரங்கப்பாதை திரும்பியதும் உள்ளூர் சாக்கெட் மாறவில்லை, ஆனால் பாதை மாறியிருக்கலாம். புதிய பொது மூல முகவரி சேவையகத்தில் வேறு நான்கு-கூறை உருவாக்குகிறது, எனவே எதிர்ப்பக்கத்து நிலை ஃபயர்வால் இனி அமர்வுடன் பொருந்தாது. வாடிக்கையாளர் ஒருபோதும் பிழையைக் காணாவிட்டாலும் இணைப்பு இறந்துவிட்டது.

மீட்பு தேவையா என்று தீர்மானிக்கவும்

இரண்டு ஒப்பந்தங்களில் ஒன்றைத் தேர்ந்தெடுக்கவும். ஒன்று, அமர்வு குறுகிய இடைவெளியைத் தாண்ட வேண்டும், அதற்கு நிலையான முகவரியிடல் மற்றும் தனது நிலையைத் தக்கவைக்கும் சேவையகம் தேவை; அல்லது பயன்பாடு தூய்மையாக மீண்டும் இணைய வேண்டும், அதற்கு மீண்டும் செய்யப் பாதுகாப்பான மறுமுயற்சி தர்க்கம் தேவை. இவற்றுக்கு இடையில் எதுவும் மோசமான முடிவைத் தரும்: சேவையகம் ஏற்கனவே பதிவு செய்ததை மீண்டும் அனுப்பும் வாடிக்கையாளர், அல்லது யாரும் பார்க்க முடியாத அமர்வுக்கு வெற்றியைப் புகாரளிக்கும் வாடிக்கையாளர்.

நிலையான முகவரியிடல் என்பது மக்கள் மறக்கும் பகுதி, ஏனெனில் வேறு பொது முகவரியில் இறங்கும் மறுஇணைப்பு வாடிக்கையாளரின் சாக்கெட் ஆரோக்கியமாகத் தெரிந்தாலும் சேவையகப் பக்க நிலையைச் செல்லாததாக்குகிறது. இரண்டு ஒப்பந்தங்களில் எது எந்தப் பயன்பாட்டுக்குப் பொருந்துகிறது என்பதை எழுதுங்கள், ஏனெனில் அவை அனைத்தும் பொருந்துவது அரிது.

தடுப்பையும் மீட்பையும் தனித்தனியாகச் சரிபார்க்கவும்

கசிவுப் பாதுகாப்பையும் அமர்வு தப்பிப்பிழைப்பையும் இரண்டு பண்புகளாகக் கருதுங்கள், ஏனெனில் ஒன்றைத் தாண்டுவது மற்றொன்றைப் பற்றி எதுவும் கூறாது. தப்பிப்பிழைத்த அமர்வு நேரடிப் போக்குவரத்து தடுக்கப்பட்டதற்கான சான்று அல்ல, இறந்த அமர்வு ஒவ்வொரு நேரடிப் பாதையும் தடுக்கப்பட்டதற்கான சான்று அல்ல.

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

மீட்பைக் கவனிக்கும்போது பாதிப்பில்லாத சோதனைச் செயல்பாட்டைப் பயன்படுத்துங்கள், இதனால் இரட்டைச் சமர்ப்பிப்பு சம்பவமாகாது. நீங்கள் உண்மையில் கண்ட தோல்வி முறையைப் பதிவு செய்யுங்கள்: பயன்பாடு என்ன காட்டியது, சாக்கெட் தப்பிப்பிழைத்ததா, அது தானாக எப்போது மீண்டது.

எதிர்பார்க்கப்படும் நடத்தையை அமலாக்க விதிக்கு அடுத்து எழுதி தேதியிடுங்கள். அந்த விதியை அடுத்து மாற்றும் நபர் வரிசைப்படுத்தல் எந்த ஒப்பந்தத்தை உறுதியளித்தது என்பதை அறிய வேண்டும்.