Bakit hindi hinuhulaan ng rating ng Wi-Fi ng router ang throughput ng VPN

Ang router na may Wi-Fi badge na 3,000 Mbps ay maaari pa ring maglipat ng naka-encrypt na trapiko sa maliit na bahagi lamang ng numerong iyon, at walang mapanlinlang sa dalawang numero. Inilalarawan ng rating ng radyo ang pinakamabuting modulasyon ng wireless link na sinusuportahan ng chipset; inilalarawan ng numerong VPN kung gaano kabilis maipupush ng isang device ang naka-encrypt na packet sa processor ng router at palabas ng iyong access circuit. Magkaibang layer ang mga ito, magkaibang laki ng packet at magkaibang paraan ng pagsukat. Ituring ang numero sa kahon bilang kisame na walang nakakaabot, hindi bilang hula sa bilis ng iyong tunnel.

Hakbang 1: Imapa ang apat na layer na naglilimita sa numero

Halos lahat ng reklamo tungkol sa mabagal na router na hinawakan ko ay bumabagsak sa isa sa apat na antas: ang wireless link, ang bilis ng access sa WAN, ang daan ng pagpapasa (NAT, firewall, pagsubaybay sa koneksyon) o ang daan ng crypto ng VPN. Nagpapatong-patong ang mga ito, at ang pinakamabagal na antas ang nagtatakda ng resulta. Ang inihayag na bilis ng Wi-Fi ay nagsasalita lamang tungkol sa unang antas, at nagsasalita tungkol dito nang bukas-palad.

Ang numerong iyon ay galing sa mga stream na minultiplika sa lapad ng channel at sa pinakamataas na modulasyon na maaaring ipagkasundo ng chipset. Ang 2x2 na radyo sa 5 GHz sa 80 MHz na may 1024-QAM ay inihahayag malapit sa 1,200 Mbps, ngunit ang Wi-Fi ay isang pinagsasaluhang half-duplex na midyum: naghahalinhinan ang mga client, ang mga muling pagpapadala at trapiko ng pamamahala ay nagsusunog ng airtime, at nagdadagdag ang TCP ng sarili nitong overhead. Ang client na nakipagkasundo ng pinakamataas na bilis sa ideal na kondisyon ay karaniwang sumusukat nang malayo sa ilalim ng kalahati, at mas mababa pa kapag lumitaw ang mga kalapit na network.

Kung ang talahanayan ay tumuturo sa radyo, ayusin muna ang wireless na bahagi: band, lapad ng channel, distansya. Kung tumuturo ito sa ilalim ng radyo, mahalaga ang susunod na apat na hakbang, at walang dami ng pagbili ng antenna ang makakabago nito.

Hakbang 2: Kumuha ng baseline na de-kable bago hawakan ang radyo

Ilagay ang laptop sa Ethernet at sukatin muna ang daan na walang tunnel, dahil binibigyan ka nito ng denominator. Patakbuhin ang tool ng throughput sa kabilang dulo, sa VPS o home server na nagtatapos ng VPN, at itutok ang client sa pampublikong address nito upang dumaan ang trapiko sa iyong router at access circuit.

# on the far host (VPN endpoint)
iperf3 -s

# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30

# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4

Dalawang numero mula sa blok na iyon ang sumasagot sa magkaibang tanong. Ang isang stream ay nagpapakita ng kisame sa bawat koneksyon, kasama ang pag-uugali ng TCP window at anumang paghubog sa bawat flow sa daan. Ang apat na stream ay nagpapakita kung may kapasidad ang link na hindi mo ginagamit, dahil kayang punuin ng magkatulad na flow ang isang tubo na hindi kayang punuin ng isang flow.

Panatilihin itong tapat: parehong host, oras ng araw at tagal, at walang ibang nag-stream sa bahay. Ang tatlumpung segundong bulk transfer ang tamang yunit dito, at ang RFC 6349, ang balangkas para sa pagsubok ng TCP throughput, ay itinayo sa ganitong pangangatwiran, dahil pinapaganda ng maiikling pagsabog at maliliit na kahilingan ang isang link. Isulat ang baseline bago ka magbago ng anuman.

Hakbang 3: Patakbuhin ang parehong pagsubok sa tunnel

Ngayon ulitin ito laban sa tunnel address ng endpoint, gamit ang parehong client, tagal at bilang ng stream, bukas ang tunnel at walang ibang trapiko. Ang ratio sa pagitan ng dalawang resulta ay nagsasabi kung magkano ang gastos ng encryption at encapsulation sa hardware na iyon; ang absolute na numero ay nagsasabi kung sapat ito para sa trabaho.

Panoorin ang mga counter habang tumatakbo ang transfer. Sa WireGuard, iniuulat ng wg show ang mga byte na inilipat sa bawat peer; sa OpenVPN, ang status file na isinusulat sa pagitan ay nagbibigay sa iyo ng parehong tanaw.

watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status

Kung malapit ang numero ng tunnel sa baseline na de-kable, ang VPN ay hindi ang iyong bottleneck at maaari mong itigil ang pagsisi dito. Kung maliit na bahagi lamang ito ng baseline, nangyari ang pagkalugi sa loob ng daan ng encryption at pagpapasa ng router, at sinasabi ng susunod na hakbang kung aling bahagi.

Isang babala: kapag nagbago ang exit IP, ang ilang serbisyo ng pagsubok ng bilis ay tahimik na pumipili ng ibang measurement server, kaya nauuwi ka sa paghahambing ng dalawang magkaibang destinasyon. Ikaw mismo ang mag-pin ng address ng server.

Hakbang 4: Basahin ang CPU bilang daan, hindi bilang average

Ang router na nagpapakita ng 30 porsiyentong kabuuang CPU ay maaari pa ring mabusog: ang trabaho ng isang tunnel ay karaniwang lumalapag sa isang core, isang interrupt queue o isang kernel thread, kaya itinatago ng average ang kisame. Tingnan ang mga numero kada core at softirq sa halip na ang gauge sa dashboard.

mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo

Tatlong bagay ang mahalaga sa output na iyon. Ang isang core na naka-pin malapit sa 100 porsiyento habang ang iba ay walang ginagawa ay nagtuturo ng limitasyon sa bawat koneksyon. Ang mabigat na %soft o abalang ksoftirqd sa isang CPU ay nagtuturo ng pagproseso ng packet sa side ng pagtanggap na hindi kumakalat sa mga queue. At ang nawawalang flag ng aes ay nangangahulugang walang AES instruction ang CPU, kaya tumatakbo sa software ang symmetric encryption at mas mahal ito sa bawat packet.

Mahalaga rin ang implementasyon. Ang tradisyunal na OpenVPN instance sa user space ay nagpoproseso ng mga packet ng isang tunnel sa isang lugar lamang, kaya ang mabilis na multicore na kahon ay maaaring kumilos na parang single core para sa tunnel na iyon. Ang WireGuard sa kernel ay nagkakalat ng trabaho sa mga CPU, at ang data channel offload ng OpenVPN ay naglilipat din ng paghawak ng packet sa kernel, ngunit sa mga build at platform lamang na sumusuporta dito. Ang pag-aangkin ng hardware acceleration sa marketing page ay hindi patunay na ginagamit ito ng code path na pinapatakbo mo.

Hakbang 5: Magpasya kung ano ang babaguhin, sa ganoong pagkakasunod-sunod

Dumaan pababa sa listahang ito at huminto sa unang linyang totoo, dahil ang pagbabago ng anuman sa ilalim nito ay hindi makakagalaw ng numero.

1. Ang direktang throughput na de-kable ay mas mababa kaysa sa binabayaran mo: kausapin ang provider, dahil hindi kayang lumikha ng kapasidad ang tunnel na hindi ibinibigay ng access circuit. 2. Maayos ang direktang de-kable ngunit may isang core na naka-pin sa pagsubok ng tunnel: ang crypto path ng router ang limitasyon. 3. Walang ginagawa ang CPU ngunit mabagal ang tunnel: suriin ang MTU at fragmentation, pagkatapos ang sariling kapasidad ng malayong endpoint. 4. Ang mga client ng Wi-Fi lamang ang mabagal: palitan ang band o lapad ng channel, at tanggapin na ang inihayag na bilis ay hindi kailanman naging numerong VPN.

Kapag ang router talaga ang limitasyon, ang tapat na opsiyon ay isang device na may AES instruction at mas mabilis na daan ng pagpapasa, isang tunnel sa side ng kernel tulad ng WireGuard sa halip na nasa user space, o ilipat ang client sa device mismo upang tumigil ang router sa pag-encrypt. Ang pagpatay ng authenticated encryption para manalo sa benchmark ay hindi isa sa mga iyon; ipinagpapalit nito ang isang katangian ng seguridad sa numerong hindi pa rin tutugma sa kahon.

Bago bumili ng anuman, patakbuhin muli ang hakbang 2 at 3 sa bagong device gamit ang parehong server at tagal, pagkatapos ay ihambing ang ratio, hindi ang peak.