Jitter e perda de paquetes nunha chamada VPN: que comparar

A fala robótica e as sílabas perdidas soan distinto porque son fallos distintos. O jitter cambia cando chegan os paquetes; a perda significa que non chegan en absoluto. Calquera dos dous pode ocorrer mentres unha proba de velocidade informa dunha descarga saudable, porque o caudal e a entrega puntual miden cousas distintas. Faga coincidir as probas co son antes de cambiar calquera axuste.

Por que os paquetes tardíos e os que faltan soan distinto

Os medios saen do emisor a un ritmo constante, e as redes reais entréganos con espazados desiguais. As aplicacións almacenan un pouco en búfer para suavizalo, trocando retardo por continuidade: suba o búfer e a conversa parece lenta, báixeo e aparecen ocos. Un paquete que chega despois do seu prazo de reprodución está efectivamente perdido, aínda que nunca se descartase. Por iso dúas conexións co mesmo ancho de banda poden producir chamadas moi distintas.

A dirección tamén importa. Os medios entrantes e saíntes poden seguir camiños distintos, sobre todo cando un lado está nunha rede móbil.

Os números que hai que ler durante a xanela mala

Use as estatísticas da propia aplicación cando as ofreza, e léaas mentres a chamada vai mal, non cando rematou. Un relé de medios adoita ser un host distinto do sitio web do servizo, así que un ping á páxina de inicio mide un camiño que a chamada non usa. Mire a porcentaxe de perda, o tempo de ida e volta e o jitter por separado, e anote se o cliente envía ou recibe o problema. Unha reconexión de VPN durante a chamada é un terceiro evento que rexistrar, non para fusionar cos demais.

As capturas de pantalla do panel de estatísticas superan un recordo da chamada, porque os números pódense comparar despois. Vinte segundos de porcentaxe de perda dinlle se a ruta está a descartar paquetes agora, pero non se a perda é a ráfagas ou cando comezou.

Para iso, repita a medición nunha segunda condición en lugar de ler unha xanela como veredicto. Dúas xanelas tomadas en condicións distintas din máis que unha xanela longa tomada sen ningunha.

Que fai un búfer de jitter co prazo

Un búfer de jitter retén brevemente os paquetes entrantes para que as chegadas desiguais — a variación de retardo que RFC 3393 define como métrica — se poidan reproducir cun reloxo regular. O tamaño do búfer fixa o prazo de reprodución: todo paquete posterior a ese prazo descártase, sexa cal sexa o seu contido. Os códecs difiren en canto poden ocultar, e un códec que interpola un cadro perdido pode agochar unha perda, pero non unha serie delas. Por iso a mesma porcentaxe de perda dá distinta calidade de chamada con códecs distintos.

Axustar o búfer é un intercambio, non unha solución. Un búfer maior compra continuidade a costa de retardo na conversa, e non pode recuperar paquetes que cheguen despois do prazo.

Compare a radio e a carga antes da saída

Manteña fixos a saída e a aplicación mentres cambia unha condición local cada vez. Unha icona de sinal forte non di nada sobre a conxestión da canle. Se o problema segue unha habitación ou un punto de acceso, a radio é a seguinte investigación.

ping -c 50 -i 0.2 203.0.113.9
mtr -rw -c 20 203.0.113.9

O ping dá un reconto de perdas e unha dispersión que pode comparar entre condicións, e mtr mostra a perda por salto ao longo do camiño. Os saltos intermedios que fallan mentres os posteriores responden adoitan dar menos prioridade a ICMP en lugar de descartar tráfico de usuario. Repita ambos mentres se executa unha subida controlada, porque unha ligazón que vai ben en repouso e é inservible baixo carga apunta á cola de espera, non á VPN. Se só unha condición reproduce o problema, a outra condición acaba de quedar descartada.

Repare só o que respalde a comparación

Cada comparación respalda unha reparación, e aplicar varias á vez destrúe a proba. Un camiño local feble pide unha canle mellor ou Ethernet, o tráfico competidor pide planificación ou unha disciplina de cola, e unha saída mala pide comparar outra saída nas mesmas condicións. Cando cambie o transporte da VPN, manteña o perfil válido e cambie unha variable cada vez. Volva probar a mesma conversa con actividade de fondo normal en lugar de xulgar o éxito por se subiu a puntuación da proba de velocidade.

Anote a dirección, a perda, o jitter, o tempo de ida e volta e a condición na que se mediu cada un. Ese rexistro converte unha queixa vaga sobre a calidade da chamada nun achado sobre o que alguén pode actuar. Gárdeo co tícket para que a seguinte comparación comece desde a mesma liña base.