VPN കണക്ഷൻ പരിധികൾ: തത്സമയ അവസ്ഥയോ സൂക്ഷിച്ച ചരിത്രമോ
മൂന്ന് കണക്ഷൻ പരിധിക്ക് ബ്രൗസിംഗ് ചരിത്രമല്ല, സ്ലോട്ടുകളുടെ തത്സമയ അവസ്ഥ വേണം: മെക്കാനിസം എന്ത് സൂക്ഷിക്കണം, എന്ത് ഉപേക്ഷിക്കാം, ആ അവസ്ഥ പിന്നീട് എവിടേക്ക് പോകുന്നു.
മൂന്ന് ഒരേസമയ കണക്ഷനുകൾ ഒരു പ്രവേശന തീരുമാനമാണ്, അതിന് ഉത്തരം നൽകാൻ കഴിഞ്ഞ മാസം എന്ത് സംഭവിച്ചു എന്നല്ല, ഇപ്പോൾ ഏത് സ്ലോട്ടുകൾ നിറഞ്ഞിരിക്കുന്നു എന്ന് അറിയണം. സേവനത്തിന് സജീവ രേഖകളുടെ ചെറിയ പട്ടികയിൽ നിന്ന് നാലാമത്തെ സെഷൻ നിരസിക്കാം, ഒരിക്കലും ഒരു സമയരേഖ നിർമ്മിക്കാതിരിക്കാം. അത് മെക്കാനിസത്തെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്, ഓപ്പറേറ്ററെക്കുറിച്ചല്ല, സ്വകാര്യതാ നയം വായിക്കുമ്പോൾ ഈ വ്യത്യാസം പ്രധാനമാണ്. താഴെയുള്ള മാതൃക തീരുമാനത്തിന് എന്ത് വേണം, എന്ത് ഉപേക്ഷിക്കാം എന്ന് കാണിക്കുന്നു.
മെക്കാനിസം: സ്ലോട്ട് പട്ടിക, ലോഗ് അല്ല
ഏറ്റവും ലളിതമായ നടപ്പാക്കൽ ഒരു സബ്സ്ക്രിപ്ഷനെ പരമാവധി മൂന്ന് സജീവ സെഷൻ രേഖകളുമായി ബന്ധിപ്പിക്കുന്നു. അനുവദിക്കപ്പെടുന്ന ഓരോ സെഷനും ഒരു സ്ലോട്ട് എടുക്കുന്നു, സേവനം ആ സെഷൻ അവസാനിച്ചു എന്ന് തീരുമാനിക്കുമ്പോൾ സ്ലോട്ട് മോചിപ്പിക്കുന്നു. ഒരു കണക്ഷൻ മോചിപ്പിക്കുമ്പോൾ മറ്റൊരു കണക്ഷന്റെ സ്ലോട്ട് മോചിപ്പിക്കാതിരിക്കാൻ രേഖയ്ക്ക് മതിയായ പ്രത്യേകതയുള്ള ഐഡന്റിറ്റി വേണം; അതുകൊണ്ട് അക്കൗണ്ട് പേരിനേക്കാൾ സെഷൻ ഐഡന്റിഫയർ പ്രധാനമാണ്.
തിരക്കും ചരിത്രവും വ്യത്യസ്ത ഡാറ്റാ ഘടനകളാണ്. തിരക്ക് വർത്തമാനത്തെക്കുറിച്ചുള്ള അതെ-അല്ല ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, സെഷൻ അവസാനിക്കുന്ന നിമിഷത്തിൽ അത് ഉപേക്ഷിക്കാം. ചരിത്രം കൂട്ടിച്ചേർക്കാൻ മാത്രമുള്ള സംഭവപ്രവാഹമാണ്, ആരോ അത് സൂക്ഷിക്കാൻ തിരഞ്ഞെടുത്തതുകൊണ്ട് അത് നിലനിൽക്കുന്നു. ഒരു സേവനത്തിന് ഒന്ന്, രണ്ടും അല്ലെങ്കിൽ ഒന്നുമില്ലാതെയും ആകാം.
ഈ വ്യത്യാസം പുറത്തുനിന്ന് കാണാനാവില്ല. കാണാവുന്ന കണക്ഷൻ പരിധി മെമ്മറിയിലെ ചെറിയ കൗണ്ടറുമായും പങ്കിട്ട ഡാറ്റാബേസ് പട്ടികയുമായും ഡാഷ്ബോർഡുള്ള പൂർണ്ണ സംഭവ ശേഖരവുമായും പൊരുത്തപ്പെടുന്നു. പരിധിയെക്കുറിച്ച് ഒന്നും ഏതാണ് പ്രവർത്തിക്കുന്നതെന്ന് പറയുന്നില്ല.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
തത്സമയ മാതൃകയ്ക്ക് ഇപ്പോഴും ഏകോപനം എന്തിന് വേണം
നഷ്ടപ്പെട്ട കണക്ഷൻ ഉടനെ അവസാനിച്ചതായി തിരിച്ചറിയണമെന്നില്ല. ഗേറ്റ്വേ ഒരു ടൈംഔട്ട്, keepalive പരാജയം അല്ലെങ്കിൽ അക്കൗണ്ടിംഗ് നിർത്തൽ കാത്തിരിക്കുന്നു, അവയിലൊന്ന് എത്തുന്നതുവരെ സ്ലോട്ട് നിറഞ്ഞിരിക്കും. ആ കാലയളവിൽ വീണ്ടും ബന്ധിപ്പിക്കുന്ന ഉപയോക്താവിന് നാലാമത്തെ ഉപകരണവുമായി യാതൊരു ബന്ധവുമില്ലാത്ത നിരസിക്കൽ ലഭിക്കുന്നു.
വീണ്ടും ആരംഭിച്ച സെർവർ അതിന്റെ അവസ്ഥ ഒത്തുചേർക്കണം, ഒരേ അക്കൗണ്ടിന് സേവനം നൽകുന്ന നിരവധി ഗേറ്റ്വേകൾക്ക് പൊതുവായ തീരുമാനം വേണം. അല്ലാത്തപക്ഷം അക്കൗണ്ടിന് വ്യത്യസ്ത സ്ഥലങ്ങളിലേക്ക് ബന്ധിപ്പിച്ച് അതിന്റെ ക്വോട്ട കവിയാം. പങ്കിട്ടതോ വീണ്ടെടുക്കാവുന്നതോ ആയ അവസ്ഥ അത് പരിഹരിക്കുന്നു, പങ്കിട്ട അവസ്ഥ ഒരു ഡിസൈൻ ആവശ്യകതയാണ്, നിരീക്ഷണത്തിന്റെ തെളിവല്ല.
ആ ഏകോപനത്തിന്റെ ഏത് ഭാഗത്തിനും ബ്രൗസിംഗ് ചരിത്രം ആവശ്യമില്ല. പാക്കറ്റുകൾ കൈമാറുന്ന ഗേറ്റ്വേയ്ക്ക് സെഷനുകൾ എണ്ണാൻ ഒരു സെഷൻ ഏത് സൈറ്റുകൾ സന്ദർശിച്ചു എന്ന് അറിയേണ്ടതില്ല, ഈ രണ്ട് ഡാറ്റാ പ്രവാഹങ്ങളും സാധാരണയായി തികച്ചും വ്യത്യസ്ത ഘടകങ്ങളാണ് കൈകാര്യം ചെയ്യുന്നത്.
എണ്ണം മെമ്മറിയിൽ സൂക്ഷിക്കുന്നത് ബന്ധപ്പെട്ട വസ്തുതകളെ അജ്ഞാതമാക്കുന്നുമില്ല. സേവനം പ്രവർത്തിക്കുമ്പോൾ സബ്സ്ക്രിപ്ഷനുമായി ബന്ധിപ്പിച്ച രേഖ ഒരു അക്കൗണ്ടിന് സജീവ കണക്ഷനുകളുണ്ടെന്ന് വെളിപ്പെടുത്തുന്നു, ആ അവസ്ഥയിലേക്കുള്ള പ്രവേശനവും അതിന്റെ ആയുസ്സും രണ്ടും ചോദിക്കാൻ യോഗ്യമാണ്.
ആ അവസ്ഥ പിന്നീട് എവിടേക്ക് പോകുന്നു
സ്വകാര്യതാ ചോദ്യം സെർവറിന് എണ്ണാൻ കഴിയുമോ എന്നതല്ല. അവസാനിച്ച സെഷന് എന്ത് സംഭവിക്കുന്നു എന്ന് ചോദിക്കുക: രേഖ നീക്കം ചെയ്യപ്പെടുന്നുണ്ടോ, അതോ നിരീക്ഷണ പരമ്പരയിലെ ഒരു സംഭവമാകുന്നുണ്ടോ? പിന്നീട് അതേ സംഭവം ഏത് മറ്റ് ഘടകങ്ങൾ കണ്ടു എന്ന് ചോദിക്കുക, കാരണം പ്രാമാണീകരണ ലോഗുകൾ, അക്കൗണ്ടിംഗ് രേഖകൾ, ബാക്കപ്പുകൾ എന്നിവയിൽ ഓരോന്നിനും നിർവഹണ പാത ഉപേക്ഷിച്ച ഒരു പകർപ്പ് സൂക്ഷിക്കാം.
RADIUS അക്കൗണ്ടിംഗ് ഏറ്റവും വ്യക്തമായ ഉദാഹരണമാണ്. ബില്ലിംഗും സെഷൻ നിയന്ത്രണവും പിന്തുണയ്ക്കാൻ Start, Stop ജോഡി നിലനിൽക്കുന്നു, ആരെങ്കിലും അതിനെ ചരിത്രമായി ഒരിക്കലും ചോദിക്കുന്നുണ്ടോ എന്നത് കണക്കിലെടുക്കാതെ അത് കണക്ഷന്റെ രേഖ സൃഷ്ടിക്കുന്നു. അതുകൊണ്ട് അക്കൗണ്ടിംഗ് വഴി പരിധികൾ നിർവഹിക്കുന്ന സേവനം നിർമ്മാണപരമായി സ്ലോട്ട് പട്ടികയേക്കാൾ കൂടുതൽ സൂക്ഷിക്കുന്നു.
മായ്ക്കലിനും ഒരു രൂപമുണ്ട്. തത്സമയ പട്ടികയിൽ നിന്ന് നീക്കിയ രേഖ ഒരു മണിക്കൂർ മുൻപ് എടുത്ത ബാക്കപ്പിൽ നിലനിൽക്കാം, ആ ബാക്കപ്പിന്റെ സൂക്ഷിപ്പുകാലം അതിന്റേതായ ഒരു നയ പ്രസ്താവനയാണ്. പ്രാഥമിക സംഭരണി മാത്രം വായിച്ചാൽ അപൂർണ്ണമായ ഉത്തരം ലഭിക്കും.
ചോദ്യം ഫീൽഡുകളുടെ അടിസ്ഥാനത്തിൽ ചോദിക്കുക
RFC 6973-ന്റെ ഡാറ്റാ-കുറവ് മാർഗ്ഗനിർദ്ദേശം ശേഖരിക്കുകയും സൂക്ഷിക്കുകയും ചെയ്യുന്ന ഡാറ്റയെ സേവിക്കുന്ന ലക്ഷ്യവുമായി ബന്ധിപ്പിക്കുന്നു. ഇവിടെ പ്രയോഗിക്കുമ്പോൾ, ഉപയോഗപ്രദമായ ചോദ്യം ഒരേസമയ പ്രവേശന ജോലിക്ക് യഥാർത്ഥത്തിൽ ഏത് ഫീൽഡുകൾ വേണം, ആ ജോലി അവസാനിച്ചതിന് ശേഷം ഓരോന്നും സൂക്ഷിക്കുന്നതിന് ഏത് ലക്ഷ്യം ന്യായീകരണം നൽകുന്നു എന്നതാണ്.
കൃത്യമായ സേവന പ്രസ്താവന ക്വോട്ട നിർവഹിക്കാൻ ഉപയോഗിക്കുന്ന തത്സമയ കണക്ഷൻ അവസ്ഥയെ അവസാനത്തിന് ശേഷം സൂക്ഷിക്കുന്ന ഏത് രേഖകളിൽ നിന്നും വേർതിരിക്കുന്നു, വാഗ്ദാനത്തിന്റെ പരിധിയിലുള്ള മറ്റ് സിസ്റ്റങ്ങളെ പേരെടുത്ത് പറയുന്നു. മൂന്ന് കണക്ഷനുകൾ നിർവഹിക്കുന്നു എന്ന് മാത്രം പറയുന്ന വാക്യം ഒരു ശേഖരം ഉണ്ടെന്നോ ഇല്ലെന്നോ സ്ഥാപിക്കുന്നില്ല.
ജീവിതചക്രം വ്യക്തമല്ലാത്തപ്പോൾ, അത് ഒരു വിധിയല്ലാതെ ഉത്തരമില്ലാത്ത സൂക്ഷിപ്പ് ചോദ്യമായി രേഖപ്പെടുത്തുക. ഒരു പരിധിയുടെ സാന്നിധ്യം മറഞ്ഞ ചരിത്രത്തിന്റെ തെളിവല്ല, തത്സമയ അവസ്ഥയുടെ സാധ്യമായ വിശദീകരണം ദാതാവിന്റെ ഓഡിറ്റല്ല.