VPN ഡൗൺലോഡ് നിങ്ങളുടെ നേരിട്ടുള്ള കണക്ഷനെ മറികടക്കാൻ കഴിയുന്നത് എന്തുകൊണ്ട്

ടണൽ ബന്ധിപ്പിച്ച് വലിയ ഡൗൺലോഡ് തുടങ്ങുക, അതേ ഫയൽ ടണൽ ഇല്ലാതെ ലഭിച്ച വേഗതയുടെ ഏകദേശം ഇരട്ടി വേഗതയിൽ അത് മുന്നോട്ട് പോകുന്നത് കാണാം. ഇത് പരസ്യം പോലെ തോന്നാം, പക്ഷേ വീട്ടിലെ ലൈനിൽ ഇത് യഥാർത്ഥ അളവെടുപ്പാകാം. സാധാരണ കാരണം ഒരു പോർട്ടിലേക്ക് ബന്ധിച്ച ഒരു വേഗപരിധിയാണ്: ടണൽ നിങ്ങളുടെ കൈമാറ്റത്തെ രൂപീകരണി നോക്കാത്ത ഇടത്തേക്ക് കൊണ്ടുപോകുന്നു, ലൈനിന്റെ യഥാർത്ഥ ശേഷി ആദ്യമായി പ്രത്യക്ഷപ്പെടുന്നു.

അതായത് പ്രസക്തമായ സംഖ്യ VPN എത്ര വേഗത്തിലായിരുന്നു എന്നതല്ല. നിങ്ങളുടെ ലൈനിൽ നിന്ന് എത്ര ഭാഗം നിങ്ങൾക്ക് ഒരിക്കലും ലഭിച്ചില്ല, എന്തുകൊണ്ട് എന്നതാണ്.

പാതയെയല്ല, പോർട്ടിനെ പിന്തുടരുന്ന പരിധി

ആക്സസ് ദാതാവിന് വരിക്കാരന് പ്രോട്ടോക്കോൾ അല്ലെങ്കിൽ ലക്ഷ്യ പോർട്ട് അനുസരിച്ച് ത്രൂപുട്ട് പരിമിതപ്പെടുത്താം, പോർട്ട് 80 പ്രിയപ്പെട്ട ലക്ഷ്യമാണ് കാരണം സാധാരണ ബ്രൗസിംഗിന്റെ വലിയൊരു ഭാഗം അത് ഉപയോഗിക്കുന്നു. പരിധി പലപ്പോഴും ആദ്യ പാക്കറ്റിൽ നിന്ന് പ്രയോഗിക്കുന്നില്ല: കൈമാറ്റം ലൈൻ വേഗതയോട് അടുത്ത് ആരംഭിക്കുന്നു, ബേൺ അലവൻസ് കത്തിക്കുന്നു, പിന്നീട് പരിമിതമായ സംഖ്യയിൽ എത്തി നിൽക്കുന്നു. ആദ്യ സെക്കൻഡുകൾ ആരോഗ്യകരമായി തോന്നുന്നു, ബാക്കി കൈമാറ്റം അല്ല.

അതേ ബൈറ്റുകൾ മറ്റൊരു പോർട്ടിലൂടെ അയയ്ക്കുക, 80-ലെ രൂപീകരണി അവ ഒരിക്കലും കാണില്ല. ടണൽ ഒരു ഹോപ്പ്, എൻക്രിപ്ഷൻ, സ്വന്തം ഓവർഹെഡ് ചേർത്തിട്ടും നേരിട്ടുള്ള ബന്ധത്തെ തോൽപ്പിക്കുന്നതായി തോന്നുന്നു. മെച്ചപ്പെട്ടത് പാതയല്ല, ഒരു നിയമത്തിന്റെ അഭാവമാണ്.

അതുകൊണ്ടാണ് ഫയലുകളിലും ലക്ഷ്യസ്ഥാനങ്ങളിലും ഈ ഫലം ഇത്ര സ്ഥിരതയുള്ളത്. പരിധി പോർട്ടിലാണെങ്കിൽ, ആ പോർട്ടിലൂടെ കടത്തുന്ന എല്ലാം ഒരേ രീതിയിൽ പെരുമാറുന്നു, ഫയലിന്റെ വലിപ്പം എന്തായാലും അതിഥി ആരായാലും. വേറെ നിയമത്തെ ആകർഷിക്കുന്ന ലക്ഷ്യം വേറെ വക്രം കാണിക്കുന്നു, ആ വ്യത്യാസം തന്നെ രോഗനിർണ്ണയമാണ്.

കൊടുമുടിയല്ല, സമതലം അളക്കുക

കൈമാറ്റത്തിന്റെ ഏറ്റവും കുറവ് വിവരമുള്ള ഭാഗമാണ് കൊടുമുടി, കാരണം ബഫർ നിറയുമ്പോൾ എല്ലാ ബന്ധവും നന്നായി തോന്നുന്നു. വേഗത എവിടെ സ്ഥിരപ്പെടുന്നു, എത്ര കാലം അവിടെ നിൽക്കുന്നു എന്ന് കുറിക്കുക.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

ഒരേ യന്ത്രത്തിൽ, ഒരേ മണിക്കൂറിൽ, താരതമ്യപ്പെടുത്താവുന്ന ശൃംഖലകളിലെ അതിഥികൾക്കെതിരെ ജോടി തുടർച്ചയായി പ്രവർത്തിപ്പിക്കുക. ഒരു സാമ്പിൾ ഒന്നും തെളിയിക്കുന്നില്ല; ഓരോന്നിന്റെയും രണ്ട് പ്രവർത്തനങ്ങളിലെ വക്രത്തിന്റെ രൂപമാണ് ബേൺ അലവൻസിനെ സ്ഥിരമായ പരിധിയിൽ നിന്ന് വേർതിരിക്കുന്നത്. വേഗത എവിടെ പരന്നു നിൽക്കുന്നു എന്ന് എഴുതുക, ആദ്യ സെക്കൻഡ് എന്ത് കാണിച്ചു എന്നല്ല, കാരണം ബേൺ എന്നത് രൂപീകരണി പരിമിതപ്പെടുത്താൻ തുടങ്ങുന്നതിന് മുമ്പ് തരുന്നത് തന്നെയാണ്. കൈമാറ്റത്തിന്റെ അവസാനം വരെ നിലനിൽക്കുന്ന ശാന്തമായ സമതലമാണ് താരതമ്യപ്പെടുത്തേണ്ട സംഖ്യ.

ഫയൽ ഇതിനകം കംപ്രസ് ചെയ്ത് സൂക്ഷിക്കുക, ഗതാഗത കംപ്രഷൻ വിശദീകരണമായി നൽകാൻ കഴിയാതിരിക്കാൻ. PDF അല്ലെങ്കിൽ ആർക്കൈവ് ആ ചരം ഒഴിവാക്കുന്നു, ടണൽ പേലോഡ് ഞെരുക്കി എന്ന് ആരും വാദിക്കാനും വയ്യ. രണ്ട് കൈമാറ്റങ്ങളും ഒരേ ഫയൽ ഉപയോഗിക്കുന്നുവെങ്കിൽ ബാക്കിയുള്ള ഒരേയൊരു വ്യത്യാസം പാതയും പോർട്ടും ആണ്. ഓരോ സംഖ്യയുടെയും അടുത്ത് ഉപകരണവും പോർട്ടും എഴുതുക, അല്ലെങ്കിൽ രണ്ടാം പ്രവർത്തനം ആദ്യത്തേതുമായി താരതമ്യപ്പെടുത്താനാവില്ല.

കാരണം വേർതിരിക്കുന്ന മൂന്ന് താരതമ്യങ്ങൾ

അവ ക്രമത്തിൽ ചെയ്ത് മാതൃക വ്യക്തമാകുമ്പോൾ നിർത്തുക, കാരണം ഓരോന്നും വ്യത്യസ്ത കഥ ഒഴിവാക്കുന്നു.

1. അതേ ഡൗൺലോഡ് സാധാരണ വെബ് പാതയിലൂടെയും മറ്റൊരു പോർട്ടിലെ കൈമാറ്റ ഉപകരണത്തിലൂടെയും, താരതമ്യപ്പെടുത്താവുന്ന ശേഷിയുള്ള അതിഥിയിൽ നിന്ന് ആവർത്തിക്കുക.
2. രണ്ടും കംപ്രസ് ചെയ്യാനാവാത്ത ഫയൽ കൊണ്ട് ആവർത്തിക്കുക, കംപ്രഷൻ സ്ഥാനാർത്ഥിയല്ലാതാകാൻ.
3. ടണൽ സെർവർ നിങ്ങൾ തന്നെ നടത്തുന്നുവെങ്കിൽ അത് വീണ്ടും പോർട്ട് 80-ലേക്ക് ബന്ധിക്കുക, ഇരു അറ്റങ്ങളും യോജിക്കാൻ ക്ലയന്റ് പ്രൊഫൈൽ ക്രമീകരിക്കുക, വീണ്ടും കൈമാറുക. ടണൽ ഇപ്പോൾ പരിമിതമായ വെബ് വേഗതയിൽ ഇരിക്കുന്നുവെങ്കിൽ, നിയന്ത്രണം പോർട്ടിനെ പിന്തുടരുന്നു, VPN-നെയല്ല.

മൂന്നാം ഘട്ടമാണ് നിർണ്ണായകം, കോൺഫിഗറേഷൻ മാറ്റം ആവശ്യമുള്ളതിനാൽ ആളുകൾ ഒഴിവാക്കുന്നതും അതു തന്നെ. അതില്ലാതെ നിങ്ങൾ കാണിച്ചത് രണ്ട് കാര്യങ്ങൾ വ്യത്യസ്തമാണ് എന്നാണ്, പോർട്ടാണ് കാരണം എന്നല്ല.

ഈ അളവെടുപ്പിന് പിന്തുണയ്ക്കാനാവാത്തത്

ടണൽ പൊതുവെ വേഗത്തിലാണ്, അത് എന്തെങ്കിലും കംപ്രസ് ചെയ്യുന്നു, അല്ലെങ്കിൽ ലൈനിലെ മറ്റ് പോർട്ടുകൾ നിയന്ത്രണമില്ലാത്തതാണ് എന്ന് ഇത് കാണിക്കുന്നില്ല. ഈ കൈമാറ്റത്തെ, ഈ ലൈനിൽ, ഈ മണിക്കൂറിൽ വിവരിക്കുന്നു. പരിധികൾ സെഷനനുസരിച്ച്, വരിക്കാരനനുസരിച്ച് അല്ലെങ്കിൽ ദിവസത്തിലെ സമയമനുസരിച്ച് ബാധകമാകാം, അറിയിപ്പില്ലാതെ മാറാം.

നേരിട്ടുള്ള പാത തകർന്നു എന്നും ഇത് തെളിയിക്കുന്നില്ല. പരിമിതമായ പാതയും പ്രവർത്തിക്കുന്നു; അത് മനഃപൂർവം പരിമിതപ്പെടുത്തിയതാണ്, മനഃപൂർവമായ നയം നന്നാക്കലിനായി കാത്തിരിക്കുന്ന തകരാറല്ല.

എല്ലാം ടണലിലൂടെ കടത്തുന്നതിന് ഇത് ഒരിക്കലും ന്യായം പറയുന്നില്ല. പോർട്ട് 80-ലെ ഓരോ അപ്ലിക്കേഷനും പരിമിതമായി തുടരുന്നു, നിങ്ങൾ വഴിതിരിച്ചുവിടുന്ന എല്ലാം ഇപ്പോൾ ഒരു അധിക ഹോപ്പിനെയും അധിക പരാജയരീതിയെയും ആശ്രയിക്കുന്നു.

കണ്ടെത്തലിനെ പ്രവർത്തനക്ഷമമായ ഒന്നാക്കുക

നിരീക്ഷണം വിധിയല്ല, അളവെടുപ്പായി എഴുതുക: പോർട്ട് 80-ലെ വലിയ കൈമാറ്റങ്ങൾ അതേ ഫയൽ മറ്റൊരു പോർട്ടിൽ എത്തുന്ന വേഗതയുടെ ഏകദേശം പകുതിയിൽ എത്തി നിൽക്കുന്നു, ഈ മണിക്കൂറുകളിൽ, ഈ ലൈനിൽ, ഈ സാമ്പിളുകൾ അറ്റാച്ച് ചെയ്ത്. ആരെങ്കിലും അന്വേഷിക്കാവുന്ന ഒരു പിന്തുണ അഭ്യർത്ഥനയാണിത്.

«VPN വേഗത്തിലാണ്» എന്നല്ല അത്. എൻക്രിപ്ഷന്റെ അധിക ഭാരത്തെക്കുറിച്ചുള്ള മറുപടി ക്ഷണിക്കുന്നു, ആ മറുപടി സാങ്കേതികമായി ശരിയാണെങ്കിലും ആർക്കും ഉപകാരപ്രദമായ ഒന്നും പറയുന്നില്ല. സാമ്പിളുകളുടെ എണ്ണം, മണിക്കൂർ, പോർട്ട് എന്നിവ അറ്റാച്ച് ചെയ്യുക, വായനക്കാരന് മാതൃക പുനരുൽപ്പാദിപ്പിക്കാനാകാൻ.

വലിയ തോതിലുള്ള കൈമാറ്റങ്ങൾക്ക് മറ്റൊരു പോർട്ട് തുടർന്നും ഉപയോഗിക്കാൻ തീരുമാനിക്കുന്നുവെങ്കിൽ, നിങ്ങളുടെ രേഖകളിൽ മുന്നറിയിപ്പ് എഴുതുക: ഒരു ശ്രോതാവിനെ പോർട്ട് 80-ലേക്ക് മാറ്റുന്നത് അവിടെ ഇതിനകം ബന്ധിച്ചിട്ടുള്ള ഏതെങ്കിലും വെബ് സെർവറുമായി കൂട്ടിയിടിക്കുന്നു, ഫലമായുണ്ടാകുന്ന തകരാർ പോർട്ട് സംഘർഷമല്ല, തകർന്ന ടണൽ പോലെയാണ് കാണപ്പെടുന്നത്.