Fixez un budget de délai pour le trafic en temps réel sur un VPN
Partez de l’échéance que l’application doit respecter, puis mesurez le délai aller simple et la gigue dans des conditions énoncées. Une moyenne sans seuil de retard ne prouve rien.
Les plaintes sur les VPN en temps réel ont besoin d’une échéance à laquelle se heurter, et « faible latence » n’en est pas une. Décidez ce que la conversation ou la session distante doit fournir, puis mesurez le chemin contre cette exigence dans des conditions énoncées. Sans seuil de paquets en retard, chaque résultat est discutable. La répartition ci-dessous est une décision de conception, et elle existe pour que la mesure ait quelque chose à quoi répondre.
Écrivez l’échéance avant de toucher une sonde
L’échéance vient de l’application et de ses utilisateurs, pas de la page marketing d’un fournisseur. Un appel vocal en direct, une session de bureau à distance et une sauvegarde nocturne tolèrent des temps d’attente complètement différents, et la défaillance qui compte est généralement la queue plutôt que la médiane. Écrivez le chiffre avec la charge de travail à laquelle il appartient.
Répartissez-la ensuite. La capture et la mise en paquets consomment une part du budget, la liaison d’accès et le tunnel une autre part, le tampon de désengorgement du récepteur retient des paquets exprès, et le traitement de l’application prend le reste. Nommer ces étapes maintient le chiffrement du tunnel proportionné au lieu d’en faire le suspect par défaut de chaque paquet lent.
Enfin, définissez le contrat de mesure en quatre lignes : extrémités et direction, forme du trafic, conditions pendant l’exécution et le résultat que vous rapporterez. Un échantillon d’un dimanche calme et un échantillon d’un mardi chargé répondent à des questions différentes, alors précisez lequel vous avez collecté. Si vous ne pouvez pas remplir les quatre lignes, l’exécution n’est pas prête à commencer. Cette liste de contrôle est aussi ce qui rend deux rapports comparables des mois plus tard, quand plus personne ne se souvient de ce que la liaison transportait d’autre.
Répartissez le budget sur chaque étape
Le tableau est une aide à la planification, pas des données capturées. Renseignez le propriétaire de chaque ligne avant la première sonde, car le propriétaire est la personne que vous appelez quand cette étape dépasse sa part.
| 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 |
Deux lignes surprennent généralement les gens. Le tampon du récepteur n’est pas un défaut quand il ajoute du délai, car il fait le travail pour lequel il a été configuré. Et la part du tunnel est souvent plus petite que la file devant lui, surtout sur une liaison montante saturée pendant les téléversements.
Quand une étape n’a pas de propriétaire, le budget est une fiction. Désignez-en un avant de mesurer, sinon vous passerez la réunion suivante à disputer quel chiffre est faux.
Mesurez le délai aller simple avec une horloge honnête
Le délai aller simple est le chiffre qui compte pour l’échéance, et il exige des horloges synchronisées aux deux extrémités. La métrique de délai aller simple vous demande de rapporter la méthode de synchronisation, la résolution et le décalage estimé à côté du résultat. Deux hôtes non synchronisés peuvent produire un chiffre très précis pour la mauvaise grandeur.
Capturez quelques centaines de paquets plutôt qu’une poignée, et notez l’état de l’horloge en même temps :
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3Le temps aller-retour est une mesure distincte, pas deux valeurs aller simple additionnées. Diviser un RTT par deux suppose des chemins symétriques et des files symétriques, et un tunnel sur une liaison montante mobile casse régulièrement ces deux hypothèses. Rapportez le RTT comme RTT et gardez-le hors du budget aller simple.
Rapportez la queue et les paquets en retard
Résumez la distribution : médiane, 95e et 99e centile, pire cas, perte et le nombre de paquets arrivés plus tard que l’échéance ne le permet. La moyenne est le moins utile de ces chiffres pour une charge de travail en temps réel, car une moyenne lisse peut cacher une queue qui ruine chaque troisième appel.
La variation du délai alimente directement le tampon du récepteur. Plus de mise en tampon masque la variation et ajoute de l’attente, si bien qu’un flux peut sembler stable tout en dépassant son échéance. Choisissez une formulation de la variation, indiquez l’intervalle sur lequel vous avez mesuré et gardez-la cohérente entre les exécutions.
Répétez l’exécution avec un trafic croisé représentatif. Un chemin qui respecte le budget au repos et le manque pendant une fenêtre de sauvegarde vous a dit quelque chose d’utile sur l’ordonnancement, qu’aucune mesure silencieuse isolée ne révélerait. Notez les conditions à côté du résultat, sinon l’ingénieur suivant comparera deux échantillons qui n’ont jamais été comparables.
Acceptez la conception quand la queue mesurée tient dans le budget sous la charge de travail que vous exécutez réellement, et rejetez-la en nommant dans le rapport l’étape qui a dépassé.