ട്രാഫിക് ക്വോട്ട ഏത് Squid ബൈറ്റ് കൗണ്ടർ ഉപയോഗിക്കണം?
Squid ലോഗ് ഫീൽഡുകൾ കൂട്ടിച്ചേർക്കുന്നതിന് മുമ്പ് പ്രോക്സി ക്വോട്ട ഉത്തരങ്ങളോ അഭ്യർത്ഥനകളോ അപ്സ്ട്രീം ബോഡികളോ ആക്സസ് ലിങ്ക് ട്രാഫിക്കോ അളക്കുന്നുവെന്ന് തീരുമാനിക്കുക.
“ഓരോ ഉപയോക്താവിനും പത്ത് ജിഗാബൈറ്റ് നൽകുക” എന്നത് രണ്ട് റിപ്പോർട്ടുകൾ വിയോജിക്കുന്നതുവരെ കൃത്യമായി തോന്നും. ഒന്ന് ക്ലയന്റുകൾക്ക് അയച്ച ഉത്തരങ്ങൾ കൂട്ടി; മറ്റൊന്ന് അപ്സ്ട്രീമിൽ നിന്ന് എടുത്ത ബൈറ്റുകൾ എണ്ണി. രണ്ടും തങ്ങൾ തിരഞ്ഞെടുത്ത ഫീൽഡ് ശരിയായി റിപ്പോർട്ട് ചെയ്യുന്നുണ്ടാകാം.
Squid ലോഗ് ഫോർമാറ്റിൽ വ്യത്യസ്ത കൗണ്ടറുകൾ ഉണ്ട്:
| ഫീൽഡ് | രേഖപ്പെടുത്തിയ അളവ് |
|---|---|
%<st | അനുകൂലനത്തിന് ശേഷം ക്ലയന്റിലേക്ക് അയച്ച മൊത്തം ഉത്തര ട്രാഫിക് |
%>st | ക്ലയന്റിൽ നിന്ന് സ്വീകരിച്ച മൊത്തം അഭ്യർത്ഥന വലുപ്പം, chunked എൻകോഡിംഗ് ബൈറ്റുകൾ ഒഴികെ |
%<bs | അടുത്ത ഹോപ്പിൽ നിന്ന് സ്വീകരിച്ച HTTP-തുല്യ സന്ദേശ ബോഡി ബൈറ്റുകൾ, രേഖപ്പെടുത്തിയ ഒഴിവാക്കലുകൾക്കൊപ്പം |
Squid-ന്റെ സ്വാഭാവിക ലോഗിലെ bytes നിര ക്ലയന്റ് ഉത്തര കൗണ്ടർ ഉപയോഗിക്കുന്നു. സംരക്ഷിച്ച ഫയലിന്റെ നീളത്തിന് തുല്യമാണെന്ന വാഗ്ദാനമല്ല അത്, ISP ഈടാക്കുന്ന ഓരോ Ethernet അല്ലെങ്കിൽ IP ബൈറ്റിന്റെയും അളവുമല്ല.
കാഷെ ഹിറ്റുകൾ വ്യത്യാസം വിശദീകരിക്കുന്നു: Squid-ന് അപ്സ്ട്രീമിൽ നിന്ന് പുതിയത് എടുക്കാതെ തന്നെ ഉത്തരം അയക്കാം. അപ്ലോഡ് കൂടിയ ജോലി മറ്റൊന്ന് കാണിക്കുന്നു: ഉത്തരങ്ങൾ മാത്രം എണ്ണിയാൽ അഭ്യർത്ഥന ദിശ ബജറ്റിന് പുറത്താകും.
CONNECT-ന്, ടണലിനുള്ളിലെ ഓരോ എൻക്രിപ്റ്റ് ചെയ്ത ഫയലോ പേജോ മനസ്സിലാക്കാതെ തന്നെ പ്രോക്സിക്ക് കൈമാറ്റം ചെയ്ത ട്രാഫിക് കണക്കാക്കാം. എന്നാൽ ടണലിന്റെ ബൈറ്റ് ആകെത്തുകയെ ഡൗൺലോഡ് ചെയ്ത ആപ്ലിക്കേഷൻ ഒബ്ജക്റ്റുകളുടെ കൃത്യമായ പട്ടികയാക്കി മാറ്റാനാവില്ല.
കൗണ്ടറിന് അടുത്ത് ക്വോട്ടാ കരാർ എഴുതുക: ദിശ, നിരീക്ഷണ പോയിന്റ്, അക്കൗണ്ടിംഗ് കാലയളവ്, ഐഡന്റിറ്റി. ശേഷം ലോഗ് ഫോർമാറ്റിന്റെ പതിപ്പ് റിപ്പോർട്ടുകൾക്കൊപ്പം സൂക്ഷിക്കുക. ഒരു ബൈറ്റിന്റെ അർത്ഥത്തെക്കുറിച്ചുള്ള അഭിപ്രായവ്യത്യാസം ഓരോ മൂല്യവും ഊഹിച്ച തിരുത്തൽ ഘടകം കൊണ്ട് ഗുണിച്ച് “പരിഹരിക്കരുത്”. പ്രാബല്യത്തിനായി പൂർത്തിയായ ഇടപാടുകളുടെ ആകെത്തുക തത്സമയ ഉപയോഗത്തിൽ നിന്ന് പിന്നിലാകാം.