Por que unha VPN parece lenta durante as subidas: retardo de cola
Unha transferencia rápida aínda pode facer que as chamadas treman cando os paquetes esperan nunha cola. Compare os tempos de ida e volta en repouso e con carga antes de culpar o extremo da VPN.
Comeza a subir unha copia de seguridade, o contador de transferencia parece saudable e a videollamada convértese nunha papa. A ligazón non carece de ancho de banda no sentido que suxire ese número; os paquetes esperan nunha cola nalgún lugar e os interactivos quedan detrás dos datos masivos. Eso é o retardo de cola, comunmente chamado bufferbloat. Unha VPN pode engadir a súa propia cola, pero raramente inventa o problema soa.
Ancho de banda e retardo son medicións distintas
O rendemento responde cantos datos se moven por segundo, mentres que o retardo responde canto tarda un paquete en cruzar o camiño. Unha ligazón saturada pode manter unha gran acumulación e aínda así informar de bo rendemento, porque a cola baleira á velocidade da liña cando remata a ráfaga. O tráfico interactivo sofre primeiro, xa que unha chamada necesita un paquete cada poucos milisegundos, non un ficheiro grande ao final. Por iso, medir só o resultado dunha proba de velocidade oculta o síntoma que o fixo mirar.
Fíxese tamén na dirección baixo carga. Un búfer de subida cheo pode atrasar todo o demais mentres a capacidade de baixada queda inactiva.
Mida o tempo de ida e volta baixo carga
Tome unha liña base nunha ligazón tranquila e logo repita a mesma medición mentres se executa unha transferencia controlada. Compare as dúas execucións en lugar dos números absolutos.
ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"O primeiro comando mostra o tempo de ida e volta, e o segundo crea unha subida sostida sen necesidade dun servizo de proba de velocidade. Unha liña base que se mantén plana seguida dunha execución con carga que sobe centos de milisegundos é a sinatura que hai que buscar. Algunhas redes baixan a prioridade do ICMP, así que trate o ping como unha pista e confírmeo coa visualización de latencia da propia aplicación. Manteña a proba curta en ligazóns con límite de datos, porque un contraste repetible importa máis que unha saturación longa.
Mova a cola a onde está o colo de botella
A xestión de colas só axuda no dispositivo que realmente contén a acumulación. Inspeccione que fai a interface antes de engadir regras.
tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codelO comando show informa da disciplina actual ademais dos contadores de acumulación e descartes, o que lle di se esta interface é o colo de botella ou só deixa pasar tráfico. Substituír a disciplina raíz por un algoritmo de cola xusta dálles aos fluxos curtos o seu propio quenda en lugar dunha soa FIFO compartida con datos masivos. Aplíqueo na interface WAN do router cando o router sexa o colo de botella, non no dispositivo do túnel por costume. Conserve a configuración anterior e volva probar tanto a capacidade de resposta baixo carga como a velocidade de transferencia, porque unha velocidade masiva un pouco menor é un bo intercambio por chamadas utilizables.
Que cambia o túnel e que esconde
Unha VPN engade cifrado e un salto máis, e tamén oculta os fluxos individuais ao equipamento fóra do túnel. Iso importa cando un dispositivo anterior ofrece priorización por aplicación, xa que ve paquetes cifrados en lugar das conversas orixinais. Un router que remata o túnel por si mesmo ten unha vista e unha carga de traballo distintas e pode clasificar dentro del. Ningunha das dúas disposicións elimina a cola na ligazón de acceso, que adoita ser onde se acumula o retardo.
Se o retardo non segue a carga, deixe de axustar colas e mire noutro sitio: condicións do Wi-Fi, problemas de tamaño de paquete ou unha saída deficiente. Os axustes de cola aplicados sen medición só trasladan o misterio.