Stabiliți un buget de întârziere pentru traficul în timp real prin VPN
Porniți de la termenul pe care aplicația trebuie să îl respecte, apoi măsurați întârzierea unidirecțională și jitterul în condiții declarate. O medie fără prag pentru pachetele întârziate nu dovedește nimic.
Reclamațiile despre VPN în timp real au nevoie de un termen față de care să eșueze, iar «latență scăzută» nu este un termen. Decideți ce trebuie să livreze conversația sau sesiunea la distanță, apoi măsurați calea față de această cerință în condiții declarate. Fără un prag pentru pachetele întârziate, fiecare rezultat este discutabil. Repartizarea de mai jos este o decizie de proiectare și există pentru ca măsurătoarea să aibă la ce răspunde.
Scrieți termenul înainte de a atinge o sondă
Termenul vine de la aplicație și de la utilizatorii ei, nu de la pagina de marketing a unui furnizor. Un apel vocal live, o sesiune de desktop la distanță și o copie de siguranță nocturnă suportă timpi de așteptare complet diferiți, iar defecțiunea care contează este de obicei coada, nu mediana. Scrieți numărul împreună cu volumul de lucru căruia îi aparține.
Apoi repartizați-l. Capturarea și împachetarea consumă o parte din buget, legătura de acces și tunelul alta, bufferul de de-jitter al receptorului reține pachete intenționat, iar procesarea aplicației ia restul. Numirea acestor etape ține criptarea tunelului în proporție, în loc să o facă suspectul implicit pentru fiecare pachet lent.
În final definiți contractul de măsurare în patru linii: puncte de capăt și direcție, forma traficului, condițiile din timpul rulării și rezultatul pe care îl veți raporta. O mostră de duminică liniștită și una de marți încărcată răspund la întrebări diferite, așa că precizați pe care ați colectat-o. Dacă nu puteți completa toate cele patru linii, rularea nu este gata să înceapă. Acea listă de verificare este și ce face două rapoarte comparabile luni mai târziu, când nimeni nu își mai amintește ce altceva transporta legătura.
Repartizați bugetul pe fiecare etapă
Tabelul este un ajutor de planificare, nu date capturate. Completați proprietarul pentru fiecare rând înainte de prima sondă, pentru că proprietarul este persoana pe care o sunați când acea etapă își depășește partea.
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
Două rânduri îi surprind de obicei pe oameni. Bufferul receptorului nu este un defect când adaugă întârziere, pentru că face treaba pentru care a fost configurat. Iar partea tunelului este adesea mai mică decât coada din fața lui, mai ales pe o legătură de încărcare care se saturează în timpul încărcărilor.
Când o etapă nu are proprietar, bugetul este ficțiune. Desemnați unul înainte de a măsura, altfel veți petrece următoarea ședință certându-vă al cui număr este greșit.
Măsurați întârzierea unidirecțională cu un ceas onest
Întârzierea unidirecțională este numărul de care îi pasă termenului și necesită ceasuri sincronizate la ambele capete. Metrica întârzierii unidirecționale cere să raportați metoda de sincronizare, rezoluția și abaterea estimată alături de rezultat. Două gazde nesincronizate pot produce un număr foarte precis pentru mărimea greșită.
Capturați câteva sute de pachete în loc de o mână și înregistrați starea ceasului în același timp:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3
Timpul dus-întors este o măsurătoare separată, nu două valori unidirecționale adunate. Înjumătățirea unui RTT presupune căi simetrice și cozi simetrice, iar un tunel peste o legătură mobilă de încărcare încalcă în mod obișnuit ambele presupuneri. Raportați RTT ca RTT și țineți-l în afara bugetului unidirecțional.
Raportați coada și pachetele întârziate
Rezumați distribuția: mediana, percentila 95 și 99, cel mai rău caz, pierderea și numărul de pachete care au sosit mai târziu decât permite termenul. Media este cea mai puțin utilă dintre aceste numere pentru un volum de lucru în timp real, pentru că o medie netedă poate ascunde o coadă care strică fiecare al treilea apel.
Variația întârzierii alimentează direct bufferul receptorului. Mai mult buffering ascunde variația și adaugă așteptare, așa că un flux poate părea stabil în timp ce își depășește termenul. Alegeți o formulare a variației, indicați intervalul pe care ați măsurat și păstrați-o consecventă între rulări.
Repetați rularea cu trafic încrucișat reprezentativ. O cale care respectă bugetul când este inactivă și îl ratează în timpul unei ferestre de copiere de siguranță v-a spus ceva util despre planificare, pe care nicio măsurătoare liniștită singură nu l-ar dezvălui. Înregistrați condițiile lângă rezultat, pentru că următorul inginer va compara altfel două mostre care nu au fost niciodată comparabile.
Acceptați proiectarea când coada măsurată se încadrează în buget sub volumul de lucru pe care îl rulați efectiv, și respingeți-o numind în raport etapa care l-a depășit.