കിൽ സ്വിച്ച് സജീവമാകുമ്പോൾ: തുറന്ന TCP സെഷനുകൾക്ക് എന്ത് സംഭവിക്കും?

ടണൽ വീഴുന്നു, കിൽ സ്വിച്ച് സജീവമാകുന്നു, മുക്കാൽ ഭാഗം പൂർത്തിയായ ഒരു ഡൗൺലോഡ് ഒന്നുകിൽ സ്തംഭിക്കുന്നു, അല്ലെങ്കിൽ ഉടൻ പരാജയപ്പെടുന്നു. ഈ രണ്ട് ഫലങ്ങളും സംരക്ഷണത്തിന്റെ വ്യത്യസ്ത നിലകളിൽ നിന്നല്ല, നിർവഹണത്തിന്റെ വ്യത്യസ്ത തിരഞ്ഞെടുപ്പുകളിൽ നിന്നാണ് വരുന്നത്. ഉപേക്ഷിക്കപ്പെട്ട പാക്കറ്റ് കണക്ഷനെ കാത്തിരിക്കാൻ വിടുന്നു, അതേസമയം നിരസിക്കപ്പെട്ട പാക്കറ്റ് അത് അടച്ച് ആപ്ലിക്കേഷനെ അറിയിക്കുന്നു. ഏത് പെരുമാറ്റമാണ് വേണ്ടതെന്ന് തീരുമാനിക്കുന്നത് രൂപകൽപ്പനയുടെ ചോദ്യമാണ്, അത് പരിശോധിക്കുന്നത് വേറെ അഭ്യാസമാണ്.

ഉപേക്ഷിക്കൽ, നിരസിക്കൽ, റീസെറ്റ് എന്നിവ വ്യത്യസ്തമാണ്

ട്രാഫിക്ക് ഉപേക്ഷിക്കുന്ന ഫയർവാൾ നിയമം പാക്കറ്റ് എറിഞ്ഞുകളയുകയും ഒന്നും തിരികെ അയക്കാതിരിക്കുകയും ചെയ്യുന്നു, അതിനാൽ അയക്കുന്നയാൾ സ്വന്തം ടൈമറുകൾ പ്രകാരം വീണ്ടും അയച്ചുകൊണ്ടിരിക്കുന്നു. TCP റീസെറ്റോടെ നിരസിക്കുന്ന നിയമം കണക്ഷൻ ഉടൻ അടയ്ക്കുന്നു, ആപ്ലിക്കേഷന് പിശക് കാണാം. മിക്ക കിൽ സ്വിച്ചുകളും ഉപേക്ഷിക്കുന്നു, കാരണം നിരസിക്കൽ നയം വെളിപ്പെടുത്തുമായിരുന്നു, ഉപേക്ഷിക്കൽ മരിച്ച ശൃംഖലയുടെ പെരുമാറ്റത്തോട് സാമ്യമുള്ളതുമാണ്.

തടയൽ സോക്കറ്റ് അടയ്ക്കുന്നതിന് തുല്യമല്ല. ആപ്ലിക്കേഷൻ ഇപ്പോഴും സ്ഥാപിത അവസ്ഥയിൽ ഒരു ഡിസ്ക്രിപ്റ്റർ കൈവശം വയ്ക്കുന്നു, പാക്കറ്റുകൾ മാത്രമാണ് ഇല്ലാത്തത്. അതുകൊണ്ടാണ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം കണക്ഷൻ നിലവിലുണ്ടെന്ന് വാദിക്കുമ്പോൾ ഒരു പേജ് മിനിറ്റുകളോളം സ്പിന്നറിൽ ഇരിക്കാൻ കഴിയുന്നത്. ആപ്ലിക്കേഷന്റെ സന്ദേശത്തിൽ നിന്ന് ഊഹിക്കുന്നതിനുപകരം രേഖപ്പെടുത്തിയ നിർവഹണം വായിക്കുക, കാരണം രണ്ട് പെരുമാറ്റവും ശൃംഖല വീണതുപോലെ തോന്നുന്നു.

ഇടവേള നീളുമ്പോൾ ആപ്ലിക്കേഷൻ എന്ത് ചെയ്യുന്നു

TCP വർദ്ധിക്കുന്ന കാലതാമസങ്ങളോടെ വീണ്ടും അയക്കുന്നു, Linux ന്റെ സ്വതേയുള്ള പുനഃശ്രമ ബജറ്റ് സെക്കൻഡുകളിലല്ല, ഏകദേശം പതിനഞ്ച് മിനിറ്റിൽ തീരുന്നു. അതുവരെ സോക്കറ്റ് ഉപയോഗപ്രദമായി തുറന്നിട്ടില്ല, അടഞ്ഞിട്ടുമില്ല. സ്വന്തം കീപ്പലൈവ് അല്ലെങ്കിൽ അഭ്യർത്ഥനാ സമയപരിധിയുള്ള ആപ്ലിക്കേഷനുകൾ പലപ്പോഴും നേരത്തെ വിട്ടുകൊടുക്കുന്നു, അതുകൊണ്ടാണ് ഒരേ യന്ത്രത്തിലെ രണ്ട് പ്രോഗ്രാമുകൾ ഒരു തടസ്സത്തിനിടയിൽ വ്യത്യസ്തമായി പെരുമാറുന്നത്.

ടണൽ മടങ്ങുമ്പോൾ പ്രാദേശിക സോക്കറ്റ് മാറിയിട്ടില്ല, പക്ഷേ പാത മാറിയേക്കാം. പുതിയ പൊതു ഉറവിട വിലാസം സെർവറിൽ വേറെ നാലിനം സൃഷ്ടിക്കുന്നു, അതിനാൽ അപ്പുറത്തെ സ്റ്റേറ്റ്ഫുൾ ഫയർവാൾ ഇനി സെഷനുമായി പൊരുത്തപ്പെടുന്നില്ല. ക്ലയന്റ് ഒരിക്കലും പിശക് കണ്ടിട്ടില്ലെങ്കിലും കണക്ഷൻ മരിച്ചു.

വീണ്ടെടുക്കൽ ആവശ്യമാണോ എന്ന് തീരുമാനിക്കുക

രണ്ട് കരാറുകളിൽ നിന്ന് തിരഞ്ഞെടുക്കുക. ഒന്നുകിൽ സെഷൻ ഒരു ചെറിയ ഇടവേളയെ അതിജീവിക്കണം, അതിന് സ്ഥിരമായ വിലാസനിർണ്ണയവും അവസ്ഥ നിലനിർത്തുന്ന സെർവറും വേണം, അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ വ്യക്തമായി വീണ്ടും കണക്ട് ചെയ്യണം, അതിന് ആവർത്തിക്കാൻ സുരക്ഷിതമായ പുനഃശ്രമ യുക്തി വേണം. ഇവയ്ക്കിടയിലുള്ളത് ഏറ്റവും മോശം ഫലം നൽകുന്നു: സെർവർ ഇതിനകം രേഖപ്പെടുത്തിയത് വീണ്ടും അയക്കുന്ന ക്ലയന്റ്, അല്ലെങ്കിൽ ആർക്കും കാണാൻ കഴിയാത്ത സെഷന് വിജയം റിപ്പോർട്ട് ചെയ്യുന്ന ക്ലയന്റ്.

സ്ഥിരമായ വിലാസനിർണ്ണയം ആളുകൾ മറക്കുന്ന ഭാഗമാണ്, കാരണം വേറെ പൊതു വിലാസത്തിൽ എത്തുന്ന വീണ്ടും-കണക്ഷൻ ക്ലയന്റിന്റെ സോക്കറ്റ് ആരോഗ്യകരമായി തോന്നിയാലും സെർവർ വശത്തെ അവസ്ഥ അസാധുവാക്കുന്നു. രണ്ട് കരാറുകളിൽ ഏതാണ് ഓരോ ആപ്ലിക്കേഷനും ബാധകമെന്ന് എഴുതിവയ്ക്കുക, കാരണം അവയെല്ലാം ഒത്തുപോകുന്നത് അപൂർവമാണ്.

തടയലും വീണ്ടെടുക്കലും വെവ്വേറെ പരിശോധിക്കുക

ചോർച്ച സംരക്ഷണവും സെഷൻ അതിജീവനവും രണ്ട് സ്വഭാവങ്ങളായി കാണുക, കാരണം ഒന്ന് കടക്കുന്നത് മറ്റൊന്നിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. അതിജീവിച്ച സെഷൻ നേരിട്ടുള്ള ട്രാഫിക് തടഞ്ഞു എന്നതിന്റെ തെളിവല്ല, മരിച്ച സെഷൻ എല്ലാ നേരിട്ടുള്ള പാതയും തടഞ്ഞു എന്നതിന്റെ തെളിവുമല്ല.

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'

വീണ്ടെടുക്കൽ നിരീക്ഷിക്കുമ്പോൾ ഹാനികരമല്ലാത്ത ഒരു പരിശോധനാ പ്രവർത്തനം ഉപയോഗിക്കുക, അങ്ങനെ ഇരട്ട സമർപ്പണം സംഭവമായി മാറരുത്. നിങ്ങൾ യഥാർത്ഥത്തിൽ കണ്ട പരാജയ രീതി രേഖപ്പെടുത്തുക: ആപ്ലിക്കേഷൻ എന്ത് കാണിച്ചു, സോക്കറ്റ് അതിജീവിച്ചോ, അത് സ്വയം എപ്പോൾ വീണ്ടെടുത്തു.

പ്രതീക്ഷിക്കുന്ന പെരുമാറ്റം നിർവഹണ നിയമത്തിന് അടുത്ത് എഴുതി തീയതി ചേർക്കുക. ആ നിയമം മാറ്റുന്ന അടുത്ത വ്യക്തി വിന്യാസം ഏത് കരാറാണ് വാഗ്ദാനം ചെയ്തതെന്ന് അറിയണം.