Per què una VPN sembla lenta durant les càrregues: retard de cua

S’inicia la càrrega d’una còpia de seguretat, el comptador de transferència sembla saludable i la videotrucada es converteix en una pasta. L’enllaç no pateix manca d’amplada de banda en el sentit que suggereix aquest número; els paquets esperen en una cua en algun lloc i els interactius queden darrere de dades massives. Això és el retard de cua, normalment anomenat bufferbloat. Una VPN pot afegir la seva pròpia cua, però poques vegades crea el problema tota sola.

Amplada de banda i retard són mesures diferents

El rendiment respon quanta dada es mou per segon, mentre que el retard respon quant triga un paquet a travessar el camí. Un enllaç saturat pot contenir una gran acumulació i tot i així informar d’un bon rendiment, perquè la cua es buida a la velocitat de la línia quan acaba la ràfega. El trànsit interactiu pateix primer, ja que una trucada necessita un paquet cada pocs mil·lisegons, no un fitxer gran al final. Per tant, mesurar només el resultat d’una prova de velocitat amaga el símptoma que us va fer mirar.

Fixeu-vos també en la direcció sota càrrega. Un buffer de càrrega ple pot retardar tota la resta mentre la capacitat de baixada queda inactiva.

Mesureu l’anada i tornada sota càrrega

Preneu una línia de base en un enllaç tranquil i repetiu la mateixa mesura mentre s’executa una transferència controlada. Compareu les dues execucions, no els números absoluts.

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

La primera ordre mostreja el temps d’anada i tornada, i la segona crea una càrrega sostinguda sense necessitat d’un servei de prova de velocitat. Una línia de base plana seguida d’una execució amb càrrega que puja centenars de mil·lisegons és la signatura que cal buscar. Algunes xarxes rebaixen la prioritat de l’ICMP, així que tracteu el ping com una pista i confirmeu-ho amb la visualització de latència de la pròpia aplicació. Mantingueu la prova curta en enllaços amb límit de dades, perquè un contrast repetible importa més que una saturació llarga.

Moveu la cua on és el coll d’ampolla

La gestió de cues només ajuda al dispositiu que realment conté l’acumulació. Inspeccioneu què fa la interfície abans d’afegir regles.

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

L’ordre show informa de la disciplina actual i dels comptadors d’acumulació i descarts, cosa que us diu si aquesta interfície és el coll d’ampolla o només deixa passar trànsit. Substituir la disciplina arrel per un algorisme de cua justa dona als fluxos curts el seu torn en lloc d’una sola FIFO compartida amb dades massives. Apliqueu-ho a la interfície WAN del router quan el router és el coll d’ampolla, no al dispositiu del túnel per costum. Conserveu la configuració anterior i torneu a provar tant la capacitat de resposta sota càrrega com la velocitat de transferència, perquè una velocitat massiva una mica més baixa és un bon intercanvi per trucades utilitzables.

Què canvia el túnel i què amaga

Una VPN afegeix xifratge i un salt més, i també amaga els fluxos individuals de l’equipament fora del túnel. Això importa quan un dispositiu anterior ofereix priorització per aplicació, ja que veu paquets xifrats en lloc de les converses originals. Un router que acaba el túnel ell mateix té una visió i una càrrega diferents i pot classificar a dins. Cap de les dues disposicions no elimina la cua a l’enllaç d’accés, que sol ser on s’acumula el retard.

Si el retard no segueix la càrrega, deixeu d’ajustar cues i mireu en un altre lloc: condicions del Wi-Fi, problemes de mida de paquet o un camí de sortida dolent. Els paràmetres de cua aplicats sense mesura només mouen el misteri.