VPN അപ്‌ലോഡ് ഡൗൺലോഡിനേക്കാൾ മന്ദഗതിയാണോ? ഏത് പരിധിയിലാണ് നിങ്ങൾ എത്തുന്നതെന്ന് തീരുമാനിക്കുക
അസമമായ ലൈൻ, തിരക്കേറിയ അപ്‌ലിങ്ക്, കുടുങ്ങുന്ന പ്രവാഹം എന്നിവ മൂന്ന് വ്യത്യസ്ത പരിധികളാണ്. ഒരു സമയത്ത് ഒരു ദിശ പരിശോധിക്കുക, തുടർന്ന് നിങ്ങളുടെ അപ്‌ലോഡ് ഏത് പരിധിയിലാണ് എത്തുന്നതെന്ന് തീരുമാനിക്കുക.
മിക്ക ആക്സസ് ലൈനുകളും അസമമാണ്, അതിനാൽ ഒരു ടണൽ സാധാരണയായി ഡൗൺലോഡിനേക്കാൾ മന്ദഗതിയിൽ അപ്‌ലോഡ് ചെയ്യും, അത് തകരാറല്ല, പ്രതീക്ഷിത ഉത്തരമാണ്. രസകരമായ ചോദ്യം, നിങ്ങളുടെ അപ്‌ലോഡ് ലൈൻ കൊണ്ടാണോ, ഇതിനകം അത് ഉപയോഗിക്കുന്ന മറ്റെന്തെങ്കിലും കൊണ്ടാണോ, അല്ലെങ്കിൽ സ്ഥിരമായി ഒഴുകുന്നതിനുപകരം നിൽക്കുന്ന ഒരു പ്രവാഹം കൊണ്ടാണോ പരിമിതപ്പെടുന്നത് എന്നതാണ്. ഈ മൂന്നും ഒരേ പരാതി സൃഷ്ടിക്കുകയും വ്യത്യസ്ത ജോലി ആവശ്യപ്പെടുകയും ചെയ്യുന്നു.
പ്രോഗ്രസ് ബാറിൽ നിന്ന് ഒരേപോലെ തോന്നുന്ന മൂന്ന് പരിധികൾ
ശേഷി ആദ്യത്തേതാണ്, അത് ടണലിന്റേതല്ല, ആക്സസ് ഉൽപ്പന്നത്തിന്റെ സ്വഭാവമാണ്. കുറച്ച് മെഗാബിറ്റിന്റെ അപ്‌ലിങ്ക് ഉപഭോക്തൃ ഫൈബറിലും പല മൊബൈൽ പ്ലാനുകളിലും സാധാരണമാണ്, കൂടാതെ എൻക്രിപ്ഷൻ ചെലവ് ആ വിടവിന് മുന്നിൽ ചെറുതാണ്. എൻകാപ്സുലേഷൻ ഓരോ പാക്കറ്റിലും ബൈറ്റുകൾ ചേർക്കുന്നു, അത് ഉപയോഗപ്രദമായ ത്രൂപുട്ട് രണ്ട് ദിശകളിലും കുറയ്ക്കുന്നു, ഒന്നിൽ മാത്രമല്ല, അതിനാൽ അതിന് ഒറ്റയ്ക്ക് വലിയ അസമത്വം വിശദീകരിക്കാനാവില്ല.
മത്സരം രണ്ടാമത്തേതാണ്. ക്ലൗഡ് സമന്വയം, ഫോട്ടോ ലൈബ്രറികൾ, അപ്‌ഡേറ്റ് ഏജന്റുകൾ എന്നിവ യന്ത്രം നിഷ്ക്രിയമായി തോന്നുമ്പോൾ അപ്‌ലോഡ് ചെയ്യുന്നു, അതേ ലൈനിലെ രണ്ടാമത്തെ ഉപകരണവും അതുതന്നെ ചെയ്യുന്നു. ക്യൂ മൂന്നാമത്തേതാണ്: പൂരിതമായ അപ്‌ലിങ്ക് ഇന്ററാക്ടീവ് ട്രാഫിക്കിനെ ബൾക്ക് ഡാറ്റയുടെ പിന്നിലേക്ക് തള്ളുന്നു, അതിനാൽ കൈമാറ്റം തന്നെ ആരോഗ്യകരമായ പുരോഗതി റിപ്പോർട്ട് ചെയ്യുമ്പോൾ കോളുകൾ വിച്ഛേദിക്കപ്പെടുന്നു.
ഒരു സമയത്ത് ഒരു ദിശ അളക്കുക
ഒരേ ഉപകരണം, ഒരേ പ്രൊഫൈൽ, ഒരേ ലക്ഷ്യസ്ഥാനം എന്നിവ ഉപയോഗിക്കുക, മത്സരം നിരീക്ഷിക്കാൻ ഉദ്ദേശിക്കുന്നില്ലെങ്കിൽ രണ്ട് ദിശകളും ഒരുമിച്ച് ഒരിക്കലും പ്രവർത്തിപ്പിക്കരുത്. ആദ്യ ഓട്ടത്തിന് മുമ്പ് നിങ്ങളുടെ സ്വന്തം ഓപ്ഷണൽ കൈമാറ്റങ്ങൾ താൽക്കാലികമായി നിർത്തുക. ഇടയിൽ ഒരു ഫ്ലാഗുള്ള രണ്ട് ഓട്ടങ്ങൾ അതിൽ ഭൂരിഭാഗവും തീർക്കുന്നു.
iperf3 സ്ഥിരമായി ക്ലയന്റിൽ നിന്ന് അയയ്ക്കുന്നു, അതിനാൽ സാധാരണ ഓട്ടം നിങ്ങളുടെ അപ്‌ലോഡ് പാത അളക്കുന്നു; -R ദിശ തിരിച്ച് ഡൗൺലോഡ് അളക്കുന്നു. അവ കുറച്ച് മിനിറ്റ് ഇടവേളയിൽ പ്രവർത്തിപ്പിച്ച് ശരാശരി എടുക്കുന്നതിനുപകരം രണ്ട് സംഖ്യകളും രേഖപ്പെടുത്തുക:
iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -Rഅപ്‌ലോഡ് സംഖ്യ ഡൗൺലോഡ് സംഖ്യയുടെ ചെറിയ ഭാഗമാണെങ്കിൽ, ഓട്ടങ്ങൾക്കിടയിൽ സ്ഥിരമായി നിലനിൽക്കുകയാണെങ്കിൽ, ആകൃതി അസമമായ ആക്സസ് ലൈനുമായി യോജിക്കുന്നു, ടണൽ ഇവിടെ കഥയല്ല. അപ്‌ലോഡ് ഓട്ടങ്ങൾക്കിടയിൽ ആടിയാടി നടന്നാലോ പത്ത് സെക്കൻഡിന് ശേഷം തകർന്നാലോ, വായന തുടരുക.
അപ്‌ലോഡ് എവിടെ മാറുന്നു എന്നതിൽ നിന്ന് തീരുമാനിക്കുക
ഒരു സമയത്ത് ഒരു വേരിയബിൾ മാറ്റി ഏത് ദിശ ചലിക്കുന്നു എന്ന് നോക്കുക. മികച്ച രീതിയിൽ അപ്‌ലോഡ് ചെയ്യുന്ന രണ്ടാമത്തെ VPN എൻഡ്‌പോയിന്റ് ആ പോയിന്റിലേക്കോ അതിലേക്കുള്ള റൂട്ടിലേക്കോ വിരൽ ചൂണ്ടുന്നു. ഒരേ ലൈനിലെ രണ്ടാമത്തെ ഉപകരണത്തിൽ നിന്നുള്ള അതേ മന്ദഗതിയിലുള്ള അപ്‌ലോഡ് ലൈനിലേക്ക് വിരൽ ചൂണ്ടുന്നു. മറ്റൊരു ലൈനിലെ മറ്റൊരു ഉപകരണവും മന്ദഗതിയിലാണെങ്കിൽ അത് ലക്ഷ്യസ്ഥാനത്തിന്റെ ഇൻഗ്രെസ് നയത്തിലേക്ക് വിരൽ ചൂണ്ടുന്നു, അത് നിങ്ങൾക്ക് പ്രാദേശികമായി പരിഹരിക്കാനാവില്ല.
ഒരേ ജോലിഭാരത്തിന് സെക്കൻഡിൽ ബൈറ്റുകളും കഴിഞ്ഞ സമയവും രേഖപ്പെടുത്തുക, ഒരൊറ്റ വേഗത സ്കോറല്ല. ബാക്കപ്പ് ക്ലയന്റും സ്പീഡ് ടെസ്റ്റും വ്യത്യസ്ത ലക്ഷ്യസ്ഥാനങ്ങളും വ്യത്യസ്ത സമവർത്തിതയും ഉപയോഗിക്കുന്നു, അതിനാൽ അവയുടെ സംഖ്യകൾ താരതമ്യം ചെയ്യുന്നത് ഒന്നിനും ഉത്തരം നൽകുന്നില്ല. ചെറിയ അഭ്യർത്ഥനകൾ കുഴപ്പമില്ലെങ്കിൽ, വലിയ കൈമാറ്റങ്ങൾ മാത്രം ഇഴയുകയാണെങ്കിൽ, പരിധി ഒരുപക്ഷേ ബാൻഡ്‌വിഡ്ത്ത് അല്ല.
ദൈനംദിന ഉപയോഗത്തിന്, പശ്ചാത്തല അപ്‌ലോഡ് പരിമിതപ്പെടുത്തുകയോ മീറ്റിംഗ് സമയത്തിന് പുറത്ത് ഷെഡ്യൂൾ ചെയ്യുകയോ ചെയ്യുന്നത് ഏതെങ്കിലും ടണൽ ക്രമീകരണത്തേക്കാൾ കൂടുതൽ സഹായിക്കുന്നു. ആ മാറ്റം സംയോജിത ജോലിഭാരത്തിൽ വിലയിരുത്തുക: വൈകി പൂർത്തിയാകുന്നെങ്കിലും കോളുകൾ നശിപ്പിക്കാത്ത ബാക്കപ്പ് സാധാരണയായി മികച്ച കരാർ.
കുടുങ്ങൽ മന്ദതയെ തോൽപ്പിക്കുമ്പോൾ
ആവർത്തിക്കാവുന്ന ഒരു ബിന്ദുവിൽ മരവിച്ച് പിന്നീട് തുടരുന്ന കൈമാറ്റം വേഗത പരിധിയല്ല, പാതയുടെ MTU പ്രശ്നം പോലെ പ്രവർത്തിക്കുന്നു. ടണൽ പാക്കറ്റിന് ഉപയോഗപ്രദമായ പേലോഡ് കുറയ്ക്കുന്നു, ഫലമായുണ്ടാകുന്ന ICMP സന്ദേശം വലിച്ചെറിയുന്ന ഉപകരണം അയച്ചയാളെ ഊഹിക്കാൻ വിടുന്നു. ആ മാതൃകയ്ക്ക് സ്വന്തം പരിശോധന അർഹതയുണ്ട്, കാരണം അറ്റകുറ്റപ്പണി വേഗത ക്രമീകരിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമാണ്. സ്ഥിരമായ താഴ്ന്ന സംഖ്യ ശേഷിയിലേക്ക് വിരൽ ചൂണ്ടുന്നു, അതേസമയം നിശ്ശബ്ദത പിന്തുടരുന്ന സ്ഫോടനം പാത വഹിക്കാനാവാത്ത പേലോഡിലേക്ക് വിരൽ ചൂണ്ടുന്നു.
വിഭജിക്കരുതാത്ത പേലോഡ് ഉപയോഗിച്ച് പാത പരിശോധിക്കുക, തുടർന്ന് ടണൽ ഇന്റർഫേസിന്റെ MTU കടന്നുപോകുന്ന മൂല്യവുമായി താരതമ്യം ചെയ്യുക:
ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"വലിയ പ്രോബ് അപ്രത്യക്ഷമായി ചെറുത് വിജയിക്കുകയാണെങ്കിൽ, ഓരോ പ്രോട്ടോക്കോളിനും ഇന്റർഫേസ് MTU കുറയ്ക്കുന്നതിനുപകരം ടണലിൽ TCP MSS കർശനമാക്കുക. ആ പോയിന്റിന് ശേഷമുള്ള നിരന്തരമായ കുടുങ്ങലുകൾ സ്വീകരിക്കുന്ന ആപ്ലിക്കേഷന്റെ സംഭരണത്തിനോ വേഗതയ്ക്കോ ഉള്ളതാണ്, നെറ്റ്‌വർക്ക് പാതയ്ക്കല്ല.
എന്ത് മാറ്റണം, എന്ത് വിടണം
നിങ്ങൾ നിയന്ത്രിക്കുന്ന കാര്യങ്ങൾ മാറ്റുക: പശ്ചാത്തല കൈമാറ്റങ്ങളുടെ ഷെഡ്യൂളുകൾ, എൻഡ്‌പോയിന്റ് തിരഞ്ഞെടുപ്പ്, കുടുങ്ങുന്ന പാതയ്ക്കുള്ള MSS. ഓരോ മാറ്റവും മടക്കാവുന്നതും ഒരു ജോലിഭാരത്തിൽ മാത്രം പരിമിതപ്പെടുത്തിയതുമാക്കുക. അളവ് നല്ലതെന്ന് പറയുന്ന കാര്യങ്ങൾ വിടുക, ലൈനുമായി ഇതിനകം യോജിക്കുന്ന ഡൗൺലോഡ് വേഗതയും ഉൾപ്പെടെ.
പ്രൊഫൈൽ, എൻഡ്‌പോയിന്റ്, ദിവസത്തിലെ സമയം എന്നിവയോടൊപ്പം മുമ്പും ശേഷവുമുള്ള സംഖ്യകൾ എഴുതുക, കാരണം എൻഡ്‌പോയിന്റിനൊപ്പം നീങ്ങുന്ന അപ്‌ലോഡ് പ്രശ്നം റൂട്ടിംഗ് ചോദ്യമാണ്, ഉപകരണത്തിനൊപ്പം നീങ്ങുന്നത് പ്രാദേശികവുമാണ്. ആ രേഖയാണ് അവ്യക്തമായ പരാതിയെ തീരുമാനമാക്കി മാറ്റുന്നത്, അതിന് അതേ കമാന്റിന്റെ രണ്ട് ഓട്ടങ്ങൾ വേണം.