Gros téléchargements et VPN : choisir le chemin au niveau de la requête

« Envoyez les gros téléchargements à côté du VPN et gardez les petites réponses dessus » ressemble à une politique de routage, et n’en est pas une. Un routeur décide avec les informations disponibles à cet instant : adresses, ports, protocole, marques de pare-feu, un flux identifié. La taille finale d’une réponse n’est pas dans cet ensemble, car elle n’est pas encore arrivée, et lorsque le routeur pourrait mesurer les octets, il les transporte déjà. Si vous voulez piloter par tâche, la décision doit migrer vers un point qui connaît la tâche, et la liste de contrôle ci-dessous indique si votre conception possède un tel point.

Pourquoi un routeur ne peut pas mesurer une réponse

À l’instant où un paquet a besoin d’une route, le routeur a vu au plus les premiers paquets d’un flux. Il peut dire qui parle à qui, via quel protocole, avec quelle marque et combien d’octets ont circulé jusqu’ici. Les octets écoulés décrivent le passé. La taille de la réponse est une propriété d’une réponse qui n’a pas encore été produite, et pour des réponses fragmentées ou en flux, elle peut n’être jamais connaissable à l’avance.

Même les métadonnées du protocole lui-même sont plus faibles qu’elles n’en ont l’air. HTTP autorise des réponses dont la longueur n’est pas annoncée avant le corps, et une seule action utilisateur peut produire de nombreuses requêtes dont le coût cumulé ne ressemble à aucune valeur d’en-tête. Traiter un en-tête comme la taille d’une tâche est une erreur de modélisation avant d’être une erreur de routage.

Contrôle 1 : existe-t-il un point de décision capable de choisir un chemin ?

Nommez le composant qui fera le choix, puis nommez ce qu’il sait au moment du choix. Un programme de mise à jour qui récupère depuis un ensemble documenté d’hôtes connaît son but avant le début du transfert. Un service de téléchargement qui consulte des métadonnées puis ouvre la requête connaît la tâche avant que la connexion existe. Un proxy coopératif peut appliquer une politique au niveau de la requête ou mettre la réponse en cache sans prétendre être un routeur.

Si la réponse est « la passerelle », la liste a déjà échoué. Une passerelle peut classer des flux connus par destination, marque ou segment client et les envoyer sur un chemin défini dès le premier paquet, ce qui suffit souvent pour un programme de mise à jour approuvé et ne suffit jamais pour une taille de réponse inconnue.

Contrôle 2 : que vous disent réellement les métadonnées ?

Le pilotage conscient de l’application ne vaut que ce que valent les champs qu’il lit. Les règles de longueur de réponse de la sémantique HTTP autorisent des cas où la longueur n’est pas disponible au départ, et les codages de contenu rendent de toute façon le nombre d’octets transférés différent de la taille de la représentation. Une politique qui change de chemin quand un en-tête franchit un seuil se comportera donc de façon incohérente, et surtout précisément sur les gros transferts qu’elle était censée attraper.

Ce que les métadonnées applicatives peuvent soutenir, c’est une décision sur une tâche : ce flux de travail est une synchronisation massive, celui-ci est interactif, celui-là est une mise à jour logicielle depuis une origine connue. C’est une politique écrite en termes d’intention, et elle est assez stable pour être testée. « Cette réponse dépassera quarante mégaoctets » n’est pas ce genre de politique.

Contrôle 3 : le flux existe-t-il déjà ?

Le routage peut changer pour un flux sans changer l’identité de la connexion, et cette distinction mérite d’être gardée nette. Une connexion TCP est identifiée par les adresses et les ports de ses extrémités, et les paquets peuvent emprunter un autre chemin si la table de routage change en dessous. Ce qui ne peut pas changer invisiblement, c’est l’état de traduction d’adresses réseau : déplacer le trafic vers une autre sortie change généralement le tuple source public, et l’extrémité distante verra un pair différent sans état correspondant.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

La règle pratique est donc qu’un déplacement en cours de connexion d’une sortie à une autre est une relation nouvelle, pas une migration. Si la conception exige que la même connexion continue, la décision devait être prise avant le premier SYN, et aucune règle de paquets ajoutée ensuite ne peut la reconstruire proprement.

Contrôle 4 : l’exigence réelle est-elle la latence, et non la sortie ?

Un très grand nombre de demandes « envoyez le trafic massif ailleurs » sont en réalité des plaintes selon lesquelles un gros transfert rend le travail interactif lent. C’est un problème d’ordonnancement, et il a une réponse d’ordonnancement : une file équitable ou une politique de bande passante prise en charge sur le chemin existant empêche un flux massif d’affamer un message de discussion sans déplacer ni l’un ni l’autre.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Traiter le symptôme ainsi garde la décision de sortie là où la politique de sécurité l’a placée, et elle est réversible en une commande. Changer la sortie pour toute une classe de trafic est un changement de politique avec des conséquences d’authentification, de journalisation et de règles d’accès, donc cela ne devrait pas être le premier outil saisi pour une plainte de latence.

Si l’exigence est réellement une autre sortie Internet, dites-le avec ces mots et mettez-le en œuvre à une frontière prise en charge : une nouvelle connexion depuis un flux de travail approuvé, ou une application qui ouvre sa propre requête via une sortie choisie. Consignez ensuite quelles tâches utilisent quelle sortie, afin que la personne suivante n’ait pas à le déduire d’une table de routage.

Gardez la liste de contrôle dans l’enregistrement du changement : le point de décision, le champ ou la tâche qui le pilote, si le flux existe déjà et si le symptôme mesuré était la latence ou la sortie. Quatre questions, et une politique qui répond aux quatre est une politique que vous pouvez exploiter plutôt que défendre.