Résumé

  • RFC 3135 recensait des proxies d’amélioration de performance pour les liaisons satellitaires et radio : espacement ou filtrage d’ACK, acquittements locaux, retransmissions proches de la perte, connexions scindées, compression et dissimulation des coupures.
  • Un ACK émis par le proxy prouvait au mieux que cet intermédiaire avait pris les octets en charge. Il ne prouvait ni leur arrivée dans la pile TCP distante, ni leur remise à l’application.

Une réponse rapide, venue du mauvais témoin

Le scénario paraît d’abord idéal. Une connexion TCP traverse un satellite géostationnaire. Au lieu d’attendre qu’un acquittement fasse l’aller-retour complet, une machine placée avant le saut difficile répond à l’émetteur. Celui-ci augmente son volume en vol. La liaison cesse d’imposer son délai physique à chaque boucle de contrôle.

Le détail décisif se trouve derrière l’ACK. Les octets peuvent être toujours stockés dans le proxy. Il leur reste à franchir le satellite, à atteindre l’autre composant éventuel, puis la pile TCP et enfin l’application destinataire. Si une perte survient après l’acquittement local, l’émetteur d’origine croit déjà cette partie du travail reçue. Quelqu’un d’autre doit conserver les données, surveiller l’aval et retransmettre.

RFC 3135, publié en juin 2001 à titre informatif, dressait l’inventaire de ces Performance Enhancing Proxies, ou PEP. Il ne proposait pas un produit type et ne proclamait pas qu’un intermédiaire était toujours souhaitable. Il examinait pourquoi des réseaux satellitaires, des WAN radio et des LAN sans fil employaient des fonctions intermédiaires lorsque la latence, l’asymétrie, les erreurs ou les interruptions rendaient TCP peu performant.

Son apport historique tient à la précision de la contrepartie. En raccourcissant la boucle, le réseau n’avait pas raccourci la distance factuelle. Il avait changé l’auteur de l’acquittement.

« Proxy » recouvrait plusieurs architectures

Tous les PEP ne terminaient pas une connexion. Tous ne lisaient pas le protocole applicatif. Tous ne brisaient pas les mêmes propriétés.

Un PEP de transport pouvait observer TCP, modifier l’espacement des ACK ou effectuer une récupération locale sans toucher aux messages applicatifs. Un PEP applicatif pouvait comprendre HTTP ou une autre syntaxe, transformer des données, compresser des en-têtes ou terminer le dialogue au nom d’un service. Un dispositif intégré se trouvait à un point de transition. Une paire distribuée encadrait la liaison à optimiser et pouvait traiter différemment les deux sens d’un chemin asymétrique.

La connexion scindée constituait le cas le plus net. Le proxy terminait le TCP reçu et en ouvrait un autre vers la destination. Dans une paire, un troisième transport, parfois propriétaire et posé sur UDP, pouvait relier les deux intermédiaires. Plusieurs connexions d’utilisateurs pouvaient partager ce canal. L’hôte croyait parler selon le comportement ordinaire de TCP, tandis que le tronçon difficile suivait une logique adaptée à la liaison.

D’autres techniques conservaient davantage la sémantique de bout en bout. Espacer des ACK déjà produits par le destinataire modifiait leur calendrier, pas leur auteur. Filtrer des acquittements redondants économisait une voie retour étroite. Un mécanisme de type Snoop mettait des segments en cache près de la radio et réparait une perte locale. La compression diminuait le volume transmis. Il fallait connaître la fonction exacte avant de conclure quoi que ce soit sur la fiabilité.

Le document séparait aussi la transparence de la sémantique. Un proxy pouvait être invisible aux hôtes tout en terminant leur transport. Inversement, un service connu de l’utilisateur pouvait préserver un accusé de réception applicatif véritablement distant. La transparence disait qui savait qu’un intermédiaire existait. Elle ne disait pas ce que son ACK prouvait.

Prendre en charge n’est pas livrer

Même sans proxy, un ACK TCP possède une portée limitée. Il atteste que l’implémentation TCP du pair a reçu des données. Il ne garantit pas que l’application les a lues, validées, enregistrées durablement ou transformées en résultat. RFC 3135 rappelait donc qu’une application exigeant une fiabilité complète devait posséder son propre contrôle de bout en bout.

L’acquittement local ajoutait une étape en amont. Il signifiait que le PEP avait pris en charge les données. Le texte lui imposait alors la responsabilité de récupérer tout ce qui serait perdu après cet ACK. Pour tenir cette promesse, l’intermédiaire devait garder des octets, des numéros de séquence, des temporisations et une connaissance des réponses venues de l’aval.

Ce transfert pouvait améliorer énormément l’usage. Une perte radio n’obligeait plus l’émetteur lointain à refaire toute sa boucle de congestion. Une brève coupure pouvait être masquée : le proxy fermait la fenêtre annoncée, conservait l’état et reprenait après le retour de la liaison. Une priorité locale pouvait suspendre longtemps un transfert de fond sans déclencher chez l’émetteur les mêmes temporisations qu’un silence inexpliqué.

Mais le stockage intermédiaire devenait alors une composante de la vérité. Un ACK honnête et rapide ne suffisait pas. Il fallait encore savoir si le tampon était volatil, si le proxy avait réellement gardé les octets, s’il pouvait survivre à un redémarrage et quel événement prouverait la remise finale.

Cinq événements, cinq autorités

Une seule courbe de débit ne permet pas de reconstituer le trajet. Il faut distinguer au moins cinq événements.

L’application émettrice confie d’abord les octets à son transport local. Ensuite, le PEP peut les accepter et les acquitter. Puis ils franchissent la sous-partie dégradée du chemin. La pile TCP distante confirme ensuite leur arrivée. Enfin, l’application destinataire exprime la sémantique qui compte : commande comprise, objet mis en file, message écrit sur disque, transaction validée ou tâche achevée.

Ces événements ne sont pas des synonymes. Même l’ACK applicatif doit être défini. « Reçu » peut signifier analysé, mis en mémoire, stocké durablement ou exécuté. L’exemple du relais de courrier donné par RFC 3135 était instructif : un MTA intermédiaire pouvait écrire le message sur un stockage non volatil, en accuser réception au niveau applicatif et assumer explicitement les tentatives ultérieures. Il ne promettait pas une livraison instantanée au destinataire final ; il rendait visible la reprise de responsabilité.

Un PEP de transport laisse en général l’ACK applicatif parcourir le chemin complet. Cette propriété protège la vérification finale, mais elle n’autorise pas à interpréter le premier ACK TCP observé comme cette vérification. La télémétrie qui s’arrête à la proximité du proxy mesure précisément le point où le risque change de gardien.

L’optimiseur ajoutait son propre destin

Le placement d’état dans le réseau modifiait le partage du sort. Quand seuls les terminaux conservent l’état indispensable, la panne d’un routeur peut être contournée si une autre route existe. Les paquets changent de chemin ; les extrémités gardent la mémoire de la connexion.

Un proxy qui détient des octets déjà acquittés et l’état d’une connexion scindée ne se remplace pas comme un routeur sans état. S’il tombe, la connexion peut mourir alors qu’un autre chemin IP est disponible. Le réseau demeure joignable, mais la mémoire de la promesse a disparu avec l’intermédiaire.

RFC 3135 ne disait pas que ce risque était toujours inacceptable. Sur un dernier saut radio sans alternative, la même panne de liaison pouvait déjà rendre la session inutile. Un utilisateur pouvait préférer une connexion généralement plus efficace malgré un point de défaillance supplémentaire. Le principe essentiel était le choix informé : connaître le compromis, pouvoir contrôler l’emploi du PEP et conserver, lorsque cela était possible, l’option du fonctionnement IP de bout en bout.

Dans une exploitation opaque, ce choix peut se dissoudre. L’opérateur voit un meilleur débit agrégé. Le fournisseur du proxy maîtrise les tampons et la récupération. L’application supporte les données manquantes. Si aucun journal ne relie ces plans, une panne du proxy ressemble à une faute de l’extrémité qui avait pourtant reçu un ACK.

IPsec fermait la fenêtre d’observation

L’optimisation exigeait souvent de voir. L’espacement d’ACK demandait de reconnaître les paquets concernés. La retransmission locale demandait d’interpréter les séquences. La connexion scindée supposait de terminer TCP. Une transformation applicative demandait davantage encore.

Avec ESP de bout en bout, IPsec rendait l’en-tête TCP et la charge utiles inintelligibles à l’intermédiaire. Beaucoup de PEP ne pouvaient alors plus fonctionner correctement. RFC 3135 présentait le conflit sans l’adoucir : pour ces mécanismes, il fallait fréquemment choisir entre le traitement du proxy et la protection IPsec réellement de bout en bout.

On pouvait établir des associations de sécurité séparées entre chaque terminal et le PEP. Le trafic restait chiffré sur les liaisons, mais il était déchiffré dans l’intermédiaire. Les extrémités devaient lui faire confiance. Deux segments pouvaient négocier des protections différentes, donnant à une extrémité une vision exagérée du niveau appliqué à l’ensemble du trajet.

Un tunnel entre les deux PEP, un contournement sélectif ou une sécurité placée plus haut pouvaient réduire certains risques. Aucune de ces solutions ne transformait les deux segments en preuve cryptographique de bout en bout. Elles déplaçaient la frontière de confiance et augmentaient la configuration à vérifier.

Les textes ultérieurs confirment la permanence de cette tension. RFC 3449 exigeait, pour plusieurs traitements liés à l’asymétrie, des en-têtes IP/TCP visibles et l’identification des flux. RFC 8404 et RFC 8517 ont documenté bien plus tard le conflit entre chiffrement et fonctions de transport dans le réseau. RFC 8684 a dû considérer les ACK proactifs de PEP dans les règles de retransmission de Multipath TCP. Ces références ne prouvent pas un déploiement de 2001 ; elles montrent que la frontière avait une descendance technique.

Le dispositif qui cachait la panne pouvait aussi cacher sa cause

Masquer une coupure était une fonction, pas nécessairement un défaut. Une liaison radio momentanément indisponible pouvait revenir avant que l’application ait besoin d'abandonner. Geler la progression évitait une reconstruction coûteuse.

La même fonction retardait cependant l’observation de la panne. Un terminal pouvait rester dans un état apparemment viable alors que le sous-chemin était interrompu. Une application critique pouvait attendre trop longtemps avant de basculer vers une autre voie. L’intermédiaire décidait implicitement quel silence était tolérable et quand l’échec devenait visible.

Ping et traceroute ne résolvaient pas automatiquement l’ambiguïté. Les paquets ICMP pouvaient contourner le PEP, le traverser sans subir le traitement de TCP, ou recevoir une réponse de l’intermédiaire lui-même. Un ping réussi pouvait seulement démontrer l’accès au proxy. Un traceroute pouvait montrer les routeurs tout en ignorant la terminaison de connexion et les tampons qui déterminaient le sort des données.

Le routage asymétrique pouvait, de son côté, écarter un sens du trafic d'une paire distribuée. La mobilité pouvait imposer le transfert rapide de l’état vers un nouveau nœud. La montée en charge demandait plus de processeur et de mémoire qu’un simple transfert IP, puis parfois plusieurs proxies parallèles et un dispositif supplémentaire pour maintenir l’affinité des flux.

L’outil chargé de rendre la mauvaise liaison invisible devait donc posséder son propre mécanisme de visibilité.

Une enquête informative, pas un verdict universel

Le statut de RFC 3135 borne l’histoire. Le document recensait des architectures et des exemples : réseaux VSAT, WAN radio, WAP, Snoop et autres techniques. Il ne mesurait pas un parc mondial, ne comparait pas des produits dans un laboratoire commun et ne promettait pas un pourcentage de gain.

Les auteurs maintenaient le principe de bout en bout comme approche dominante. Ils recommandaient de concevoir, si possible, les nouvelles technologies de liaison de façon à ne pas exiger ces corrections. En même temps, ils reconnaissaient qu’une latence physique ne disparaît pas par conviction architecturale et que certains environnements privés acceptaient délibérément les compromis.

RFC 3234 a ensuite replacé les PEP dans la famille plus vaste des middleboxes. RFC 3426 a utilisé RFC 3135 comme étude de cas : bénéfice de performance d’un côté ; sécurité IP de bout en bout, nouveau point de panne, diagnostic, routage asymétrique et mobilité de l’autre. La question n’était pas de refuser l’optimisation. Elle était de comptabiliser tout ce qu’elle déplaçait.

Conserver la chaîne de garde

Une évaluation moderne devrait d’abord décrire la difficulté : topologie, direction, latence native, asymétrie, erreurs, coupures, charge et critère de réussite de l’application. Elle devrait ensuite identifier le proxy : propriétaire, version, position, mécanismes, transparence, connexions scindées, paire distribuée et possibilité de contournement.

Pour chaque opération importante, il faut horodater l’émission, l’ACK local, les octets mis en tampon, l’envoi aval, la retransmission locale, l’ACK TCP distant, l’ACK applicatif et la validation durable. Il faut enregistrer qui retransmet, quel minuteur a expiré, combien de données restent sous garde, et ce qu’un redémarrage détruit.

La sécurité demande son propre plan : extrémités cryptographiques, en-têtes visibles, données déchiffrées dans le proxy, politiques de contournement et différence de protection entre segments. Le chemin demande les deux sens, l’affinité, le basculement, les déplacements de mobile et la survie de l’état.

Les contradictions doivent déclencher l’enquête : ACK local avant garde fiable ; perte d’octets acquittés après redémarrage ; ping vert et TCP bloqué ; chiffrement qui neutralise silencieusement l’optimisation ; retour qui évite la paire ; débit en hausse et achèvement applicatif en baisse.

Le gain de RFC 3135 était réel dans son domaine : une boucle de contrôle plus courte. Sa leçon durable est que la boucle ne peut recevoir une autorité plus grande que son auteur. Le proxy pouvait dire honnêtement « je les ai ». Tant que l’application distante ne répondait pas, il ne pouvait pas dire « elle les a reçus ».

Sources

  1. https://www.rfc-editor.org/rfc/rfc3135.txt
  2. https://www.rfc-editor.org/info/rfc3135
  3. https://www.rfc-editor.org/rfc/rfc3135.html
  4. https://www.rfc-editor.org/rfc/rfc793.html
  5. https://www.rfc-editor.org/rfc/rfc1122.html
  6. https://www.rfc-editor.org/rfc/rfc2401.html
  7. https://www.rfc-editor.org/rfc/rfc2488.html
  8. https://www.rfc-editor.org/rfc/rfc2760.html
  9. https://www.rfc-editor.org/rfc/rfc2775.html
  10. https://www.rfc-editor.org/rfc/rfc3234.html
  11. https://www.rfc-editor.org/rfc/rfc3426.html
  12. https://www.rfc-editor.org/rfc/rfc3449.html
  13. https://www.rfc-editor.org/rfc/rfc8404.html
  14. https://www.rfc-editor.org/rfc/rfc8517.html
  15. https://www.rfc-editor.org/rfc/rfc8684.html