Auteur Sujet: MultiPath TCP: faire une même connexion TCP vers plusieurs réseaux différents  (Lu 2737 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 29 672
    • Twitter LaFibre.info
MultiPath TCP ou MPTCP est une évolution de TCP qui permet de faire passer une même connexion TCP vers plusieurs réseaux.

Exemple : Vous avez deux box chez vous FAI1 et FAI2. Vous pourrez cumuler le débit de ces deux accès à internet avec une seule connexion TCP.

Il faut bien entendu que le client et le serveur supporte MPTCP.

L'article de Xavier Claude dans LinuxFR :


Internet MPTCP, TCP dans un monde ultra‐connecté

MPTCP un standard en cours de rédaction (et déjà bien avancé) à l’IETF. L’acronyme signifie MultiPath TCP dont le but est de pouvoir utiliser une même connexion TCP au travers de plusieurs interfaces réseau. Le cas typique d’utilisation est de décharger les réseaux GSM 3G/4G via le Wi‐Fi, vous pourrez ainsi utiliser le Wi‐Fi (par exemple, via le réseau FON ou votre réseau chez vous) et dès que vous n’êtes plus à portée, passer de façon transparente sur le réseau GSM. Une autre application est le partage de plusieurs liens (par exemple, deux câbles Ethernet) pour un serveur de manière transparente. L’intérêt est d’être totalement transparent pour les applications ; en revanche, il faut une implèmentation du côté client et serveur pour que ce soit possible.

Même si le standard est en cours d’écriture, il est déjà possible de tester la version actuelle grâce une version modifiée du noyau Linux. Malheureusement, comme il faut un serveur qui implèmente le standard pour que ça fonctionne, vous ne pouvez tester l’accès qu’avec le site de démo en MPTCP (ou vous devez monter votre propre serveur). Sur le site, vous trouverez aussi une vidéo de démonstration dans laquelle on peut voir la conservation d’une session SSH avec différentes combinaisons d’interfaces Ethernet, Wi‐Fi et 3G.

Fonctionnement

Premièrement, il y a une poignée de main — handshake — TCP classique avec le serveur, seulement, le client envoie une option supplèmentaire qui signale qu’il est capable de faire du MPTCP, et le serveur doit répondre avec la même option pour que la communication soit possible. Quand le client dispose d’une nouvelle interface (par exemple, parce qu’il vient de se connecter à un réseau Wi‐Fi), il envoie un SYN classique au serveur via cette nouvelle interface avec l’option JOIN. Pour garder le fonctionnement actuel de TCP et pour ne pas introduire de saut dans les numéros de séquence (que certains équipements réseau n’aiment pas), chaque connexion TCP a son propre numéro de séquence, mais un numéro de séquence global est ajouté dans les options TCP pour reconstruire les messages qui passeraient par les deux interfaces. Garder les numéros de séquence par interface permet de détecter sur quelle interface les paquets sont perdus, et donc d’établir une fenêtre de congestion par interface.

La gestion de la congestion sur MPTCP a pour but que le débit effectif soit au moins aussi bon que le débit maximal sur la meilleure interface. Pour cela, une fenêtre de congestion est gardée pour chaque lien, et, pour chaque ACK, la fenêtre est augmentée d’une certaine valeur (calculée pour permettre une équité avec le trafic TCP normal et le chemin avec le moins de RTT) divisée par la somme de la valeur de toutes les fenêtres disponibles. Pour chaque DROP, la fenêtre est diminuée de la fenêtre de congestion de l’interface divisée par deux (comme pour TCP). Ceci fait que si deux interfaces ont des performances semblables, elles seront toutes les deux utilisées.

L’explication ci‐dessus est une simplification du fonctionnement ; en réalité, c’est un peu plus complexe, car il faut y ajouter une certaine couche de sécurité pour que n’importe qui ne puisse pas se joindre à une connexion MPTCP.

Il est évident que pour les courtes connexions TCP (quelques paquets échangés), MPTCP n’est pas utile, puisque qu’il faut ajouter une deuxième poignée de main TCP (qui ne peut commencer qu’après la fin de la première, car il faut utiliser la commande JOIN). Il y aura sûrement des ajustements à faire dans les implèmentations pour déterminer quand cela vaut la peine d’utiliser plus d’une interface pour une connexion.

La différence par rapport à l’agrégation de liens Ethernet — channel bonding —, que la couche réseau ne voit que comme un seul lien, est de pouvoir utiliser des chemins différents par interface, et donc de pouvoir dynamiquement privilégier l’interface avec le moins de problèmes de congestion.


Source : LinuxFR, le 29 octobre 2012 par Xavier Claude et  galactikboulay.

Liens :
- Working group IETF sur MPTCP
- Implèmentation MPTCP pour Linux

butler_fr

  • Client Bbox adsl
  • Modérateur
  • *
  • Messages: 3 104
  • ADSL sur Marseille (13)
très intéressant comme techno,
merci du partage!

effectivement il y a sans doute pas mal de boulot d'optimisations à faire mais le principe est excellent!

q05

  • Client Proximus (Belgique)
  • *
  • Messages: 49
« Modifié: 25 avril 2015 à 11:46:53 par q05 »

 

Mobile View