Résumé

  • Multipath TCP présente à l’application un seul flux fiable et ordonné, même lorsque les extrémités le transportent sur plusieurs sous-flux TCP.
  • MP_CAPABLE négocie la connexion, MP_JOIN authentifie un sous-flux supplémentaire et la numérotation au niveau de la connexion permet de renvoyer les mêmes octets sur un autre chemin.
  • Deux interfaces ne prouvent pas la résilience : les chemins peuvent partager un goulet d’étranglement, un boîtier intermédiaire peut supprimer les options et la politique des extrémités décide si le second chemin est actif, de secours ou inutilisé.

Un seul socket au-delà du Wi-Fi

Le changement visible paraît simple : une adresse disparaît, une autre devient disponible. Mais l’objet utile pour l’application n’est pas l’adresse. C’est la suite d’octets déjà échangée avec son correspondant. Recommencer une connexion signifierait refaire de l’état, parfois une authentification ou une opération dont le résultat n’est pas aisément rejouable.

RFC 8684 sépare la connexion de ses chemins. Une connexion MPTCP correspond à un socket d’application, mais elle peut contenir plusieurs sous-flux. Chacun se comporte comme une connexion TCP sur son propre chemin. Le niveau supérieur conserve l’ordre et la fiabilité attendus par l’application. La disparition d’un sous-flux n’impose donc pas, à elle seule, la fin de la connexion.

Cette possibilité reste conditionnelle. Les deux hôtes doivent accepter MPTCP, un sous-flux utilisable doit subsister ou pouvoir être créé, et l’état de la connexion doit rester valide. Le protocole offre un mécanisme de continuité ; il ne certifie ni la couverture radio, ni l’indépendance des accès, ni la qualité de l’autre chemin.

Chaque chemin supplémentaire doit être admis

Le premier sous-flux porte l’échange MP_CAPABLE. Les extrémités y signalent leur capacité et échangent le matériel de clé associé à la connexion. Si l’autre hôte ne comprend pas MPTCP, ou si un équipement intermédiaire empêche les options de passer, la connexion peut revenir à TCP ordinaire.

Un second sous-flux passe par MP_JOIN. Un jeton indique la connexion visée ; des nombres aléatoires et un HMAC fondé sur les clés initiales permettent de vérifier que le nouveau chemin relie les mêmes correspondants. L’hôte peut malgré tout le refuser pour des raisons de politique locale. Posséder une autre adresse n’accorde donc aucun droit automatique à rejoindre la connexion.

ADD_ADDR et REMOVE_ADDR permettent d’annoncer ou de retirer une adresse pendant la vie de la connexion. Des identifiants d’adresse évitent qu’une traduction NAT ne rompe toute la logique. Une adresse annoncée demeure cependant une candidate : elle ne démontre ni l’accessibilité, ni la séparation physique, ni le prix, ni la supériorité du chemin obtenu.

Le contrôle est ainsi partagé, mais pas confondu. Le réseau fournit la joignabilité et influence les routes. Les extrémités négocient MPTCP, authentifient les sous-flux et appliquent les règles qui les autorisent. Une application non adaptée peut ne voir qu’un socket TCP normal, alors que la décision de chemin se prend sous son interface.

Le grand livre commun des octets

Chaque sous-flux conserve les numéros de séquence de TCP. MPTCP ajoute une numérotation de 64 bits pour toute la connexion. Le signal DSS relie une plage d’octets d’un sous-flux à cette suite commune et peut confirmer leur réception au niveau de la connexion.

C’est ce double niveau qui rend le changement de chemin utile. Si un sous-flux ne livre pas certaines données, les mêmes octets peuvent être retransmis sur un autre sous-flux avec une nouvelle correspondance. L’application reçoit toujours un seul flux ordonné ; elle n’a pas à fusionner deux connexions indépendantes.

L’ordre crée aussi une contrainte. Un chemin lent peut retarder la remise à l’application alors qu’un chemin rapide continue d’acheminer des octets plus récents. L’ordonnanceur de paquets, la réinjection et le contrôle de congestion décident si les chemins se complètent ou se gênent. RFC 8041 traite ces choix comme des problèmes d’exploitation, pas comme une conséquence automatique de la présence de deux interfaces.

Le chemin de secours a un coût

Un sous-flux peut être déclaré normal ou de secours, et MP_PRIO peut demander un changement de priorité. Ce bit concentre une décision économique. Une liaison cellulaire peut protéger la session tout en étant facturée au volume. Un accès satellite peut être disponible mais trop lent. Deux accès fixes peuvent converger vers le même conduit ou le même transit.

RFC 6182 précise que plusieurs couples d’adresses ne donnent pas nécessairement des chemins disjoints. L’architecture vise davantage de débit et de résilience tout en préservant le modèle de service TCP et l’équité aux goulets partagés. Ces objectifs ne sont pas une preuve de performance pour une installation donnée.

Il faut donc mesurer la connexion négociée : sous-flux établis, rôles actif ou secours, domaines de panne réellement distincts, progression des accusés de réception au niveau de la connexion et octets renvoyés ailleurs. Le nombre d’icônes réseau n’est pas un indicateur de service.

Le repli fait partie du résultat

Les boîtiers intermédiaires peuvent retirer des options TCP, modifier des adresses ou altérer les données. RFC 8684 prévoit des issues sûres : repli du premier sous-flux vers TCP classique, fermeture d’un sous-flux additionnel invalide ou retrait d’un chemin devenu inutilisable.

Une application peut donc fonctionner normalement alors que MPTCP n’a jamais été établi. Si la supervision ne voit que le succès applicatif, elle confondra la continuité obtenue par un autre sous-flux avec une simple connexion TCP qui n’a fourni aucune diversité. MPTCP agrandit la connexion au-delà d’un chemin ; il oblige en retour à prouver quels chemins ont réellement porté le flux.

Sources