Cum am maximizat viteza conexiunii mele la internet non-gigabit

Sfaturi de la un inginer de la Ookla

Numele meu este Brennen Smith și, în calitate de inginer de sistem principal la Speedtest de către Ookla, îmi petrec timpul luptând cu servere și infrastructură de internet. Obiectivele mele zilnice variază de la proiectarea aplicațiilor de înaltă performanță care susțin milioane de utilizatori și testarea celor mai rapide conexiuni la internet din lume, până la stoarcerea microsecundelor din stiva noastră – așa că, acasă, mă străduiesc să mă asigur că performanța mea personală pe internet funcționează cât mai repede posibil .

Locuiesc într-o zonă cu un ISP DOCSIS care nu oferă internet gigabit simetric – viteza mea de descărcare și încărcare nu este egală. În schimb, am un plan asimetric cu 200 Mbps de descărcare și 10 Mbps de încărcare – această nuanță a afectat considerabil proiectarea rețelei mele, deoarece serviciul asimetric poate duce mai ușor la bufferbloat.

Vom acoperi bufferbloat într-un articol ulterior, dar pe scurt, este o problemă care apare atunci când bufferele unui dispozitiv de rețea în amonte sunt saturate în timpul încărcării. Acest lucru determină o congestie imensă a rețelei, latența să crească peste 2.000 ms și, în general, o calitate slabă a internetului. Soluția este de a modela traficul de ieșire la o viteză chiar sub maximul de trimitere al dispozitivului din amonte, astfel încât tampoanele sale să nu se umple. ISP-ul meu este renumit pentru că are probleme cu bufferbloat datorită performanței reduse de încărcare și este o problemă predominantă chiar și pe routerele furnizate.

Ca urmare, aveam nevoie de capacitatea de a modela traficul la viteze de peste 200 Mbps – acest lucru m-a împiedicat să folosesc routere bazate pe MIPS sau ARM, deoarece acestea nu au puterea procesorului pentru a ruta peste ~ 150 Mbps fără descărcare hardware (I folosea de fapt Tomato pe un Asus AC68U în acel moment). Foarte puține routere oferă posibilitatea de a modela o singură direcție de trafic în software, așa că a trebuit să găsesc o soluție care să poată gestiona conturarea bidirecțională de peste 200 Mbps. În timp ce mulți dintre echipa Ookla Engineering folosesc routerele Ubiquiti Edge, CPU-ul lor limitează performanța de formare a traficului la următoarele:

Notă editor: de când a fost publicat acest articol, acum este posibil ca firmwarele recente să efectueze conturarea traficului într-o singură direcție pe platforma EdgeRouter.

Cerințe

Astfel, cerințele routerului meu au fost următoarele:

Am luat acest mic server x86-64 și l-am combinat cu 4 GB Kingston DDR3L și un SSD Adata de 32 GB. Punctele cheie ale acestui server sunt nuclee de frecvență mai puține, dar mai mari și NIC-uri Intel de 4x GBE. NIC-urile Intel au unele dintre cele mai bune asistențe din lumea Open Source și este foarte recomandat să rămâneți departe de companiile mai ieftine. Această mașină nu are AES-NI sau Intel Quickassist, dar nu a avut probleme cu criptarea / decriptarea la rata de linie pentru VPN-urile.

Rutare reală

Odată asamblat, am instalat PFSense 2.3 pentru gestionarea rutării reale. Pentru cei care nu au folosit PFSense, este un sistem de operare de rutare incredibil, bazat pe FreeBSD. A îndeplinit cu ușurință cerințele de mai sus și le-a depășit cu mult. Am putut aplica modelarea CodelQ AQM la traficul de ieșire pentru a preveni bufferbloat, împreună cu împărțirea IPv6 / 60 furnizată de ISP în / 64 pentru 3 VLAN-urile mele.

În cercetarea și testarea mea, am evaluat, de asemenea, IPCop, VyOS, OPNSense, Sophos UTM, RouterOS, OpenWRT x86 și Alpine Linux pentru a servi drept sistem de operare de bază, dar niciunul nu a fost la fel de bine acceptat și complet prezentat ca PFSense. Cel mai apropiat de PFSense a fost VyOS, deoarece îmi place interfața CLI declarativă și citesc doar sistemul de partiție primar / de rezervă, dar au existat câteva motive care m-au împiedicat să îl folosesc:

PFSense nu este lipsit de problemele sale, dar este perfect pentru cazul meu de utilizare. Cea mai mare problemă pe care am avut-o a fost configurația DNS implicită. Pe PFSense, serverul DNS ( nelegat ) este setat să funcționeze mai degrabă ca un rezolvator recursiv decât ca un server de redirecționare. În timp ce acest ar putea avea un avantaj de securitate în cazuri marginale, impactul asupra performanței asupra căutărilor este substanțial – navigarea pe web a fost sacadată, deoarece activele distribuite în domeniu au avut căutări lente.

Setări QoS

Unii oameni au întrebat ce setări QoS folosesc în PFSense. Am evitat setările QoS ale asistentului implicit, deoarece, în general, încerc să evit clasificarea proto / port. Majoritatea traficului de pe web-ul modern este TCP 80/443 cu o cantitate mică de UDP 53, astfel încât QoS bazat pe clasa HSFC nu este la fel de eficient ca pe vremuri. Cu toate acestea, fiecare caz este diferit, așa că mi-ar plăcea să aud despre configurările regulilor dvs.

Am imitat în esență FQ-CODEL plasând un programator FAIRQ în fața unei cozi CODELQ. CODEL este capabil să acorde prioritate fluxurilor și să renunțe la pachete atunci când este necesară retragerea, deci a fost extrem de eficient în scenarii cu conținut ridicat. Pentru cei foarte curioși, iată o reprezentare a arborelui QoS pe care l-am configurat în PFSense:

De ce 12.531 Kbps?

Pentru ochii de vultur acolo – de ce viteza mea de încărcare a fost stabilită la 12.531 Kbps când conexiunea mea este cu 10 Mbps în sus?

Răspunsul este de două ori. În primul rând, conexiunile DOCSIS sunt adesea supra-furnizate pentru a vă asigura că, chiar și cu pierderea cablului / modemului, utilizatorii probabil vor atinge viteza pe care o plătesc. Deci, rularea unui Speedtest pe conexiunea mea de 10 Mbps fără formare a dezvăluit de fapt ~ 13 Mbps. Cu toate acestea, trebuia să găsesc punctul care maximiza viteza de încărcare, fără a umple tampoanele dispozitivului din amonte.

Pentru a găsi acest punct, multe tutoriale recomandă „ luați un Speedtest și apoi scădeți 20% ” – Susțin că acest lucru este incorect, deoarece un procent plat poate fi prea mare sau nu suficient. Pentru a găsi punctul optim – în esență am făcut următorul pseudocod:

Acest lucru se poate face cu ușurință manual și durează aproximativ 5 minute de modificări pentru a efectua. Astfel, m-am stabilit la 12.531 Kbps ca fiind cea mai mare viteză de încărcare posibilă, fără niciun impact asupra serviciului meu.

Distribuirea către dispozitivele client

Ruterul se conectează apoi la un comutator HP Procurve 1810G, care trece apoi traficul VLAN etichetat către trei AP-uri Ubiquiti UniFi AC Pro distribuite prin casă. Traficul neetichetat merge apoi către alte dispozitive bazate pe Ethernet.

PFSense are instrumente excelente de monitorizare pentru a măsura starea de sănătate și calitatea unei conexiuni, dar am vrut să urmăresc viteza conexiunii mele. Am construit o mică aplicație Node and React numită speedlogger care durează un Speedtest la fiecare 8 ore și o trasează într-un grafic frumos.

A meritat?

Absolut.

La fel ca în cazul oricărui experiment, orice concluzii trebuie să fie susținute cu date. Pentru a valida rețeaua a funcționat ușor sub sarcină mare, am efectuat următorul experiment:

După cum puteți vedea din graficul de mai jos, fără QoS, latența conexiunii mele a crescut cu ~ 1.235%. Cu toate acestea, cu QoS activat, conexiunea a rămas stabilă în timpul încărcării și nu am putut determina o deltă semnificativă statistic.

Așa am maximizat viteza conexiunii la internet non-gigabit. Ce ai făcut cu rețeaua ta?

Dacă ați ajuns la sfârșitul acestui articol, probabil că sunteți destul de tâmpiți ca noi. Căutăm ingineri și dezvoltatori calificați – dacă asta e treaba dvs., consultați postările noastre pe: Funcțional.