De ce un VPN pare lent în timpul încărcărilor: întârziere de coadă
Un transfer rapid poate totuși face apelurile să tremure când pachetele așteaptă într-o coadă. Comparați timpii dus-întors în repaus și sub sarcină înainte de a da vina pe punctul final al VPN-ului.
Începe încărcarea unei copii de siguranță, contorul de transfer arată sănătos, iar apelul video se transformă în terci. Legătura nu duce lipsă de lățime de bandă în sensul sugerat de acel număr; pachetele așteaptă într-o coadă undeva, iar cele interactive stau în spatele datelor mari. Aceasta este întârzierea de coadă, numită de obicei bufferbloat. Un VPN poate adăuga propria coadă, dar rareori creează problema singur.
Lățimea de bandă și întârzierea sunt măsurători diferite
Debitul răspunde cât de multe date se mișcă pe secundă, în timp ce întârzierea răspunde cât durează un pachet să parcurgă calea. O legătură saturată poate ține un restant mare și totuși raporta un debit bun, pentru că coada se golește la viteza liniei când rafala se termină. Traficul interactiv are de suferit primul, deoarece un apel are nevoie de un pachet la fiecare câteva milisecunde, nu de un fișier mare la final. De aceea, măsurarea doar a rezultatului unui test de viteză ascunde simptomul care v-a făcut să priviți.
Observați și direcția sub sarcină. Un buffer de încărcare plin poate întârzia tot restul în timp ce capacitatea de descărcare stă nefolosită.
Măsurați dus-întors sub sarcină
Luați o linie de bază pe o legătură liniștită, apoi repetați aceeași măsurătoare cât timp rulează un transfer controlat. Comparați cele două rulări, nu numerele absolute.
ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"Prima comandă eșantionează timpul dus-întors, iar a doua creează o încărcare susținută fără a avea nevoie de un serviciu de test de viteză. O linie de bază care rămâne plată, urmată de o rulare sub sarcină ce urcă cu sute de milisecunde, este semnătura pe care trebuie să o căutați. Unele rețele scad prioritatea ICMP, așa că tratați pingul ca indiciu și confirmați cu afișajul de latență al aplicației înseși. Țineți testul scurt pe legăturile cu limită de date, pentru că un contrast repetabil contează mai mult decât o saturație lungă.
Mutați coada acolo unde este gâtul de sticlă
Gestionarea cozilor ajută doar pe dispozitivul care ține într-adevăr restantul. Inspectați ce face interfața înainte de a adăuga reguli.
tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codelComanda show raportează disciplina curentă plus contoarele de restant și de eliminare, ceea ce vă spune dacă această interfață este gâtul de sticlă sau doar lasă traficul să treacă. Înlocuirea disciplinei rădăcină cu un algoritm de coadă echitabilă le dă fluxurilor scurte propria rundă în locul unei singure FIFO partajate cu datele mari. Aplicați-o pe interfața WAN a routerului când routerul este gâtul de sticlă, nu pe dispozitivul tunelului din obișnuință. Păstrați configurația anterioară și retestați atât receptivitatea sub sarcină, cât și viteza de transfer, pentru că o viteză de masă puțin mai mică este un schimb bun pentru apeluri utilizabile.
Ce schimbă tunelul și ce ascunde
Un VPN adaugă criptare și încă un salt, și ascunde de asemenea fluxurile individuale față de echipamentele din afara tunelului. Acest lucru contează când un dispozitiv din amonte oferă prioritate pe aplicație, deoarece vede pachete criptate în locul conversațiilor originale. Un router care termină singur tunelul are o viziune și o încărcare de lucru diferite și poate clasifica în interiorul lui. Niciuna dintre cele două aranjamente nu elimină coada de pe legătura de acces, unde de obicei se acumulează întârzierea.
Dacă întârzierea nu urmează sarcina, opriți reglarea cozilor și priviți în altă parte: condiții Wi-Fi, probleme de dimensiune a pachetului sau o singură ieșire proastă. Setările de coadă aplicate fără măsurătoare doar mută misterul.