FR2954029A1 - Procede de transmission de paquets d'un flux de donnees bidirectionnel passager, dispositif gestionnaire, produit programme d'ordinateur et moyen de stockage correspondants - Google Patents

Abstract

Il est proposé un procédé de transmission de paquets d'un flux de données bidirectionnel passager établi entre des premier et second dispositifs terminaux, ledit flux passager étant conforme à un protocole de transport passager avec acquittement définissant une pluralité de catégories de paquet, ledit flux passager étant destiné à être encapsulé par un dispositif gestionnaire selon un protocole de transport encapsulant avec acquittement. Le dispositif gestionnaire effectue des étapes consistant à : - obtenir (500) un paquet dudit flux passager transmis depuis le premier vers le second dispositif terminal ; - effectuer (501) une première vérification de si le paquet obtenu appartient à au moins une catégorie prédéterminée parmi ladite pluralité de catégories de paquet ; en cas de première vérification positive, encapsuler (504, 510, 505, 509) au moins une partie des données dudit paquet obtenu, selon un protocole de transport encapsulant sans acquittement.

Description

Procédé de transmission de paquets d'un flux de données bidirectionnel passager, dispositif gestionnaire, produit programme d'ordinateur et moyen de stockage correspondants 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. Plus précisément, l'invention concerne une technique de transmission de paquets d'un flux de données bidirectionnel passager, établi entre des premier et second dispositifs terminaux (aussi appelés dispositifs émetteur/récepteur), la transmission s'effectuant par encapsulation des paquets du flux passager. On suppose que le flux passager est conforme à un protocole de transport passager avec acquittement (TCP par exemple). On suppose également que le flux passager est destiné à être encapsulé, par un dispositif gestionnaire, selon un protocole de transport encapsulant avec acquittement (TCP par exemple). La présente invention s'applique notamment, mais non exclusivement, dans la mise en oeuvre de tunnels de communication pour la création de réseaux privés virtuels via le réseau Internet (c'est-à-dire dans le cas où les paquets du flux de données bidirectionnel passager sont encapsulés pour être transmis via un tunnel de communication). La technologie des réseaux de type VPN (pour « Virtual Private Networks » en anglais, ou « Réseaux Privés Virtuels » en français) permet de communiquer de manière transparente en temps réel et en continu, de manière sécurisée entre des individus partageant un même centre d'intérêt tout en utilisant l'infrastructure réseau Internet, peu sûre mais bon marché. Pour communiquer de manière transparente et s'affranchir des adresses non routables, les réseaux de type VPN utilisent une encapsulation particulière (appelée « tunnellisation » en français, ou « tunneling » en anglais) mettant en oeuvre un tunnel de communication. Cette opération consiste à encapsuler un protocole de niveau A (appelé protocole embarqué ou véhiculé ou passager) dans un protocole de niveau B (appelé protocole de transport ou véhiculant, ou encore protocole de transport encapsulant) grâce à un protocole d'encapsulation C. Ainsi, le protocole de transport B traite le protocole embarqué A comme s'il s'agissait de données utiles. La figure 3, décrite en détail par la suite, présente un exemple d'encapsulation de paquets dans un réseau de type VPN de niveau 2, ce qui signifie que le protocole embarqué A est un protocole de la couche 2 du modèle OSI. On parle aussi de tunnel de niveau 2. De tels tunnels de communication sont utilisés pour interconnecter deux réseaux LAN (pour « Local Area Networks » en anglais, ou « réseaux locaux » en français) afin de créer un réseau LAN virtuel composé de l'union des deux réseaux LAN originaux. Une illustration de configuration de réseau de type VPN basée sur une technique de tunnellisation est illustrée sur la figure 1 (décrite en détail par la suite). Dans cet exemple, les têtes de tunnel (ou TEP pour « Tunnel End Point » en anglais) 101 et 102 ne sont pas intégrées aux passerelles 105 et 106. Le tunnel 100 est établi entre deux têtes de tunnel, et chaque paquet (aussi appelé trame) issu d'un premier réseau LAN est envoyé au second réseau LAN après avoir été encapsulé par la tête de tunnel située sur le premier réseau LAN. La tête de tunnel sur le second réseau LAN reçoit le paquet via le tunnel, dés-encapsule le paquet et l'envoie sur le second réseau LAN. Du point de vue des équipements connectés à chacun des premier et second réseaux LAN 103 et 104, ils sont virtuellement connectés à un même réseau LAN (c'est-à-dire que ces équipements ne savent pas que leurs communications sont véhiculées via un tunnel sur un réseau global). Une communication entre deux équipements via le tunnel est appelée communication de bout en bout (« end-to-end communication » en anglais). 2. ARRIÈRE-PLAN TECHNOLOGIQUE Le protocole TCP (pour « Transmission Control Protocol » en anglais) est un protocole de transport « fiable », orienté connexion (c'est-à-dire que le protocole TCP fonctionne en mode connecté (« Connection-oriented » en anglais)). Ainsi, le protocole TCP fournit un flux d'octets (« byte-stream» en anglais) fiable assurant l'arrivée des données sans altérations et dans l'ordre, avec retransmission en cas de perte, et élimination des données dupliquées. Le protocole TCP essaie de délivrer toutes les données correctement et en séquence. C'est son but et son principal avantage sur le protocole UDP, même si ça peut être un désavantage pour des applications de transfert ou de routage de flux en temps-réel, avec des taux de perte élevés au niveau de la couche réseau. Les protocoles applicatifs FTP (transfert de fichiers) et HTTP (web) par exemple sont basés sur le protocole TCP.

Lors d'une communication selon le protocole TCP, deux machines doivent établir une connexion afin d'échanger des paquets de données, appelés segments de données, de manière bidirectionnelle. La machine émettrice d'une demande de connexion est appelée client (ou dispositif client), tandis que la machine réceptrice de la demande de connexion est appelée serveur (ou dispositif serveur). On dit qu'on est alors dans un environnement Client-Serveur. Les machines dans un tel environnement communiquent en mode connecté, c'est-à-dire que la communication se fait dans les deux sens. Il est important de noter que le client et le serveur sont tous les deux des dispositifs terminaux (dispositifs émetteurs/récepteurs), dans le sens où chacun d'eux émet et reçoit des segments de données. Dans la suite de la description, pour qualifier une machine ou un dispositif, on utilisera les adjectifs émetteur et récepteur seulement en rapport avec l'émission ou la réception de segments de données (afin d'éviter toute confusion avec les notions d'émission ou réception d'une demande de connexion).

Comme présenté plus en détail par la suite, en relation avec la figure 7, le protocole TCP distingue plusieurs catégories de segment (un même segment pouvant appartenir à plusieurs catégories, un ou plusieurs drapeaux compris dans l'en-tête du segment indiquant la ou les catégories à laquelle ou auxquelles appartient le segment), et notamment : • les segments d'acquittements, aussi appelés segments ACK (pour « Acknowledgement » en anglais), permettant au client et au serveur de s'assurer de la bonne réception mutuelle des données. Un segment ACK contient un numéro d'accusé de réception (aussi appelé numéro de séquence d'acquittement) égal au numéro de séquence de données du prochain segment attendu par la machine (client ou serveur) qui émet ce segment ACK ; et • les segments de transmission complète de données, aussi appelés segments PUSH (ou segments PSH), permettant à une première machine (serveur par exemple) qui a émis un segment PUSH d'indiquer à une seconde machine (client par exemple) qu'une fonction PUSH doit être mise en oeuvre, c'est-à-dire que les données collectées par cette seconde machine (y compris les données contenues dans ce segment PUSH), et stockées dans la mémoire tampon de réception TCP de cette seconde machine, sont à transférer immédiatement à une application de destination sans attendre d'éventuelles autres données qui suivent. En d'autres termes, la première machine qui émet le segment PUSH émet un besoin de consommation des données par la seconde machine (ce besoin découlant par exemple du fait qu'on est arrivé à la fin des données à transmettre, ou du fait d'un engorgement de la mémoire tampon d'émission TCP de la première machine). Le protocole UDP (pour « User Datagram Protocol » en anglais) est un protocole de transport simple, sans connexion (c'est-à-dire qu'il fonctionne en mode paquet (mode « Datagram » en anglais)), permettant un débit optimal mais « non fiable » : le protocole UDP ne vérifie pas que les paquets sont arrivés à destination, et ne garantit pas leur arrivée dans l'ordre. Si une application a besoin de ces garanties, elle doit les assurer elle-même, ou bien utiliser le protocole TCP. Le protocole UDP est généralement utilisé par des applications de diffusion multimédia (audio et vidéo, etc) pour lesquelles le temps requis par le protocole TCP pour gérer les retransmissions et l'ordonnancement des paquets n'est pas disponible. Dans le cas d'une transmission à travers un tunnel de niveau 2, la session TCP passagère (par exemple pour le transport d'un flux vidéo passager via HTTP/TCP selon les recommandations UPnP (pour « Universal Plug and Play » en anglais) ou DLNA (pour « Digital Living Network Alliance » en anglais)) est encapsulée (en toute transparence pour le flux passager) dans une nouvelle session du tunnel (session TCP, UDP, ou autre). C'est cette nouvelle session qui assure la communication entre les deux têtes de tunnel, permettant ainsi de traverser un réseau de nature différente (comme l'Internet par exemple). Les équipements (par exemple de type UPnP ou DLNA) du réseau LAN 103 ou 104 sont généralement dimensionnés en vue d'une utilisation sur ce réseau LAN. Par exemple, la mémoire d'émission TCP (c'est-à-dire la mémoire de stockage tampon pour l'émission selon le protocole TCP) d'un serveur UPnP 113 est généralement dimensionnée pour gérer de manière fluide une connexion sur un réseau LAN (65 koctets sont adaptés à un « temps de boucle » (ou RTT, pour « Round-Trip Time » en anglais, c'est-à-dire le temps que met un paquet pour arriver à destination, et à l'acquittement correspondant d' être émis en retour et d' être reçu par l'émetteur) de 5 msec, et un débit de 100 Mbps. Le RTT augmente très significativement lors de l'acheminement à travers un tunnel de niveau 2 (plusieurs centaines de millisecondes). Le flux TCP (flux passager du tunnel) est alors émis par « rafales » (« burst ») par les équipements du réseau LAN. Chaque rafale est due à l'attente de réception par le serveur 113 des acquittements (segments ACK) d'un client 108 pour les données émises au préalable par le serveur 113 : chaque acquittement reçu libère de la place dans la mémoire d'émission TCP du serveur 113 pour les futures données à transmettre. Les sessions TCP passagères du tunnel ne profitent donc pas de toute la capacité de transport disponible, leur vitesse de transmission est alors considérablement réduite. Ainsi, la latence pour la réception des paquets d'acquittement TCP (segments ACK) est critique dans les performances des sessions TCP passagères du tunnel. Lors d'une congestion temporaire du tunnel RPV établi sur un réseau de communication étendu (appelé ci-après réseau WAN, pour « Wide Area Network » en anglais), comme l'Internet par exemple, si la porteuse de ce tunnel utilise un protocole de communication fiable par acquittements (c'est-à-dire par exemple un canal de transport de ce tunnel selon le protocole TCP), elle va entrer en retransmission automatique. Ceci aura pour effet de suspendre tous les flux passagers véhiculés via ce canal de transport du tunnel (même ceux qui ne sont pas concernés directement par la perte du paquet encapsulant (c'est-à-dire embarquant) de la porteuse du tunnel). En effet, plusieurs flux passagers peuvent être véhiculés par un même canal de transport (c'est-à-dire une même porteuse, ou encore une même session de communication) du tunnel. De plus, par construction, le protocole TCP mis en oeuvre sur la porteuse TCP du tunnel garantit l'ordre d'arrivée des paquets et ne fournit pas par avance à l'entité réceptrice 102 les paquets du tunnel suivant le paquet perdu sur ce tunnel. C'est-à-dire qu'il n'y aura pas transfert par la tête de tunnel réceptrice 102 sur le réseau LAN distant 104, mais mémorisation (dans la mémoire de réception de la porteuse TCP du tunnel, comprise dans la tête de tunnel réceptrice 102), des paquets passagers reçus dont le numéro de séquence de données du paquet véhiculant de la porteuse est supérieur à celui correspondant au paquet perdu de cette porteuse du tunnel. Le déblocage de ces paquets passagers mémorisés ne s'effectuera qu'une fois le paquet perdu retransmis par la tête de tunnel émettrice 101 et reçu par la tête de tunnel réceptrice 102. Dans le cas du transport de flux TCP passagers du tunnel, on rappelle que ces paquets TCP mémorisés et bloqués (en attente dans la mémoire de réception de la porteuse TCP, comprise dans la tête de tunnel réceptrice 102) peuvent être de toute nature (notamment segments ACK sans données, segment ACK avec données, segment ACK et PUSH avec données, segment PUSH avec données...). Le fait que des paquets d'un flux passager soient mémorisés et bloqués semble être raisonnable pour les données contenues dans ces paquets. En effet, cela permet de garantir leur ordre d'arrivée. Mais, dans le cas où ces paquets mémorisés et bloqués contiennent des informations d'acquittement (c'est-à-dire si ces paquets sont des segments ACK), ceci est dommageable pour les informations d'acquittement qui sont bloquées et donc retardées. En effet, l'émetteur des segments de données auxquels sont relatives les informations d'acquittement retardées (c'est-à-dire le serveur 113 dans notre exemple), du fait qu'il attend ces informations d'acquittement, est limité dans sa possibilité d'émission (fenêtre de congestion non mise à jour, empêchant l'émission de nouveaux paquets de données par le serveur 113 et provoquant une saturation de la mémoire d'émission TCP du serveur 113). Ainsi, en considérant (voir figure 1) une connexion FTP ou HTTP (au dessus de TCP) entre le serveur 113 et un client 108, une retransmission sur la porteuse TCP du tunnel 100 (par exemple pour les segments tunnel transmis de la première tête de tunnel 101 vers la seconde tête de tunnel 102) retardera les segments ACK issus du client 108 à destination du serveur 113 (pour le flux TCP passager transitant sur le tunnel 100). Or, le serveur 113 est en attente de ces segments ACK afin d'être autorisé à transmettre de nouvelles données selon le protocole TCP. Ceci est également dommageable dans le cas où les paquets mémorisés et bloqués sont des segments PUSH. En effet, le récepteur d'un segment PUSH retardé (c'est-à-dire le serveur 113 dans notre exemple) prend connaissance avec retard de la requête qui lui est faite de transférer immédiatement les données collectées à la couche d'application de destination locale.

La plupart des principes des protocoles à connexion de bout-en-bout reposent sur l'adjonction d'un agent spécialisé de type PEP (pour « Performance Enhancing Proxy » en anglais) sur l'équipement d'infrastructure séparant les réseaux de types hétérogènes (typiquement des têtes de tunnel pour des réseaux WAN ou des stations de base pour des réseaux sans-fil). Par exemple, la norme RFC 3135 décrit un mécanisme de suppression d'acquittements (ou «ACK filtering » en anglais) pour réduire la congestion des acquittements. Une telle technique de suppression d'acquittements n'est cependant pas complètement satisfaisante pour résoudre le problème précité. Le document de brevet US 7,315,515 explique que plusieurs problèmes ont été relevés lorsque le chemin de retour d'une connexion TCP ne possède pas assez de bande passante pour faire passer tous les acquittements (ACK) générés par le dispositif destination. C'est le cas des utilisateurs téléchargeant des informations de l'Internet à travers un lien haut débit dans le sens descendant (comme un lien satellite ou bien un câble), et envoyant les requêtes et les segments d'acquittement (segments ACK) sur un lien bas débit en remontée. Une congestion apparaît sur le chemin de retour causant une détérioration du débit de la connexion et un problème d'iniquité dans le cas de plusieurs connexions en compétition pour le chemin de retour. Le filtrage des segments ACK à l'entrée du goulot d'étranglement a été proposé dans le document de brevet US 7,315,515 pour éliminer cette congestion. Dans un dispositif modem ou passerelle, un segment ACK qui arrive à une mémoire tampon de réception de ce dispositif modem ou passerelle, en vue d'être transmis depuis un réseau LAN vers un dispositif de l'Internet, est comparé avec les segments ACK précédemment stockés dans cette mémoire tampon de réception. S'il est trouvé un certain nombre d'autres segments ACK de la même connexion, la technique proposée dans le document de brevet précité consiste à effacer (c'est-à-dire supprimer) quelques uns de ces segments ACK, et le nouveau segment ACK reçu prend leur place. Ce mécanisme repose sur la propriété d'acquittement cumulatif du protocole TCP (pour un flux de données TCP donné, un acquittement pour une séquence «n+l » acquitte par défaut la séquence « n »). Ainsi, la suppression de segments ACK « redondants » libère de l'espace dans la mémoire tampon de réception du dispositif modem ou passerelle.

Cependant, l'application de la technique proposée dans le document de brevet US 7,315,515 est limitative car dans le cas où un quelconque segment ACK comporte d'autre(s) information(s), alors il est prévu que ce segment ACK annihile le mécanisme proposé. Ceci est particulièrement dommageable car une connexion TCP est par essence bidirectionnelle, et il est courant d'associer un envoi de données d'un premier flux (par exemple une commande HTTP ou FTP) avec un acquittement pour un second flux dans la direction opposée (par exemple le flux HTTP en téléchargement), les premier et second flux formant ensemble un flux de données bidirectionnel. La technique proposée dans le document de brevet US 7,315,515 offre de mauvaises performances sur de courts transferts ou suite à une récupération sur perte. Ceci notamment parce que la phase de démarrage lent (« slow start» en anglais) du protocole TCP repose sur le nombre de segments ACK reçus. Effacer tous les segments ACK est une opération très agressive qui a de mauvaises conséquences sur cette phase de démarrage lent, au cours de laquelle les segments ACK arrivent en rafales et où le plus grand nombre possible de segments ACK doit être passé au dispositif source pour l'aider à augmenter vite sa fenêtre de congestion. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.

Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de transmission de paquets d'un flux de données bidirectionnel passager, établi entre des premier et second dispositifs terminaux, la transmission s'effectuant par encapsulation des paquets du flux passager, cette technique permettant d'accélérer la connexion de bout-en-bout entre les premier et second dispositifs terminaux, dans le cas où ce flux est conforme à un protocole de transport passager avec acquittement (TCP par exemple). Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique permettant d'accélérer le vidage des mémoires tampons d'émission des premier et second dispositifs terminaux.

Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant d'accélérer la transmission d'informations liées à une ou plusieurs catégories de paquets particulières définies par le protocole de transport passager avec acquittement (en particulier les informations liées aux segments ACK et/ou aux segments PUSH, dans le cas où le protocole de transport passager avec acquittement est le protocole TCP).

Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique ayant un impact limité sur la consommation processeur du dispositif gestionnaire (par exemple une tête de tunnel) dans lequel cette technique est mise en oeuvre. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique pouvant être mise en oeuvre dans le cas où un tunnel est mis en oeuvre entre les premier et second dispositifs terminaux. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de transmission de paquets d'un flux de données bidirectionnel passager établi entre des 15 premier et second dispositifs terminaux, ledit flux passager étant conforme à un protocole de transport passager avec acquittement définissant une pluralité de catégories de paquet, ledit flux passager étant destiné à être encapsulé par un dispositif gestionnaire selon un protocole de transport encapsulant avec acquittement. Le dispositif gestionnaire effectue des étapes consistant à : - obtenir un paquet dudit flux passager transmis depuis le premier vers le second dispositif terminal ; - effectuer une première vérification de si le paquet obtenu appartient à au moins une catégorie prédéterminée parmi ladite pluralité de catégories de paquet ; - en cas de première vérification positive, encapsuler au moins une partie des données dudit paquet obtenu, selon un protocole de transport encapsulant sans acquittement. Le principe général est de sélectionner un paquet du flux passager, en fonction de son contenu protocolaire (par exemple, un paquet est sélectionné s'il s'agit d'un segment ACK et/ou PSH), puis d'encapsuler au moins une partie (prioritaire) de ce 30 paquet sélectionné, selon un protocole de transport encapsulant qui est sans acquittement (comme par exemple le protocole de transport encapsulant UDP), et non pas comme 20 25 prévu selon un protocole de transport encapsulant qui est avec acquittement (comme par exemple le protocole de transport encapsulant TCP). Ainsi, ce mode de réalisation particulier repose sur une approche tout à fait nouvelle et inventive, tirant profit de ce que le protocole de transport encapsulant sans acquittement est plus rapide que le protocole de transport encapsulant avec acquittement, car il est plus simple (en-tête plus léger, pas de contrôle de congestion ni de gestion du séquencement) et n'est pas sujet aux blocages dus à des retransmissions (pas de service de fiabilisation). En effet, on accélère la transmission d'une partie des données du paquet sélectionné en les encapsulant selon le protocole de transport encapsulant sans acquittement. De façon avantageuse, le dispositif gestionnaire effectue une étape consistant à effectuer une deuxième vérification de si le paquet obtenu comprend des données utiles. En cas de première et deuxième vérifications positives, le dispositif gestionnaire effectue une phase de création de paquet comprenant des étapes consistant à, pour ledit paquet obtenu ou au moins un desdits paquets obtenus : - créer un nouveau paquet dans lequel a été copiée une partie du paquet obtenu liée à ladite au moins une catégorie prédéterminée ; - encapsuler le nouveau paquet selon le protocole de transport sans acquittement ; - encapsuler les données utiles selon le protocole de transport avec acquittement.

Ainsi, (au moins) les données utiles continuent à bénéficier de la fiabilisation associée au protocole de transport encapsulant avec acquittement. Avantageusement, dans une première mise en oeuvre, l'étape consistant à encapsuler les données utiles selon ledit protocole de transport avec acquittement comprend une étape consistant à encapsuler le paquet obtenu selon le protocole de transport avec acquittement. Cette première mise en oeuvre est très simple car le paquet obtenu (paquet d'origine) est encapsulé intact selon le protocole de transport encapsulant avec acquittement. En outre, elle optimise la fiabilisation puisque tout le paquet d'origine est encapsulé selon le protocole de transport encapsulant avec acquittement.

Avantageusement, dans une deuxième mise en oeuvre, l'étape consistant à encapsuler les données utiles selon le protocole de transport avec acquittement comprend des étapes consistant à : - modifier le paquet obtenu en extrayant du paquet obtenu ladite partie copiée ; - encapsuler le paquet modifié selon le protocole de transport avec acquittement. Cette deuxième mise en oeuvre permet de limiter la charge du médium de transport utilisé avec le protocole de transport encapsulant avec acquittement (tout le paquet d'origine n'est pas transmis sur ce médium). En contrepartie, elle nécessite plus de ressources processeur que la première mise en oeuvre puisqu'il faut modifier le paquet d'origine avant de l'encapsuler selon le protocole de transport encapsulant avec acquittement. Selon une caractéristique avantageuse, en cas de première vérification positive et deuxième vérification négative, le dispositif gestionnaire effectue une étape consistant à encapsuler le paquet obtenu, selon le protocole de transport sans acquittement.

Dans ce cas, il n'est pas nécessaire de créer et transmettre un nouveau paquet, ce qui ne demande aucune ressource processeur. En outre, le paquet obtenu (paquet d'origine) n'étant pas encapsulé selon le protocole de transport encapsulant avec acquittement, on réduit la charge du médium de transport utilisé par celui-ci. De façon avantageuse, ladite au moins une catégorie prédéterminée appartient au groupe comprenant : - une catégorie regroupant des paquets d'acquittement, transmis par le premier dispositif terminal pour indiquer au second dispositif terminal la réception d'un ou plusieurs paquets préalablement transmis par le second dispositif terminal ; et - une catégorie regroupant des paquets de transmission complète de données, transmis par le premier dispositif terminal pour indiquer au second dispositif terminal que des données utiles collectées par le second dispositif terminal doivent être transmises à une application de destination sans attendre d'éventuelles données utiles qui suivent. Pour chaque paquet d'acquittement (c'est-à-dire chaque segment ACK), la partie encapsulée selon le protocole de transport encapsulant sans acquittement comprend des informations d'acquittement, mais pas d'éventuelles données utiles comprises dans le segment ACK. En revanche, pour chaque paquet de transmission complète de données (c'est-à-dire chaque segment PUSH), la partie encapsulée selon le protocole de transport encapsulant sans acquittement comprend des informations de PUSH ainsi que des données utiles. Un paquet peut appartenir à la fois à la catégorie « ACK » et à la catégorie «PUSH ». Si c'est le cas, la partie encapsulée selon le protocole de transport encapsulant sans acquittement comprend les différents éléments cités ci-dessus et liés à chacune de deux catégories précitées. Dans le cas d'un paquet de la catégorie ACK, l'accélération de la transmission des informations d'acquittement permet à l'émetteur (des segments de données auxquels sont relatives les informations d'acquittement) de libérer plus vite sa mémoire tampon d'émission. En d'autres termes, on accélère la connexion de bout-en-bout pour le flux passager. En outre, dans le cas où les informations d'acquittement sont copiées et envoyées deux fois (une fois dans le nouveau paquet encapsulé selon le protocole de transport encapsulant sans acquittement, et une fois dans le paquet (d'origine) encapsulé selon le protocole de transport encapsulant avec acquittement), cette augmentation du nombre de paquets de la catégorie ACK transmis est très utile. En effet, en supposant que le protocole de transport encapsulant sans acquittement utilise un premier medium (porteuse UDP par exemple) et que le protocole de transport encapsulant avec acquittement utilise un deuxième medium (porteuse TCP par exemple) : • s'il n'y a pas eu de perte sur la première porteuse, l'émetteur (des segments de données auxquels sont relatives les informations d'acquittement) recevra deux paquets de la catégorie ACK identiques au mieux, ce qui ne pose pas de problème (par exemple, si le protocole de transport passager est le protocole TCP, ce nombre est inférieur au seuil de déclenchement d'une retransmission, à savoir trois segments DUP-ACK et un segment ACK d'origine, soit quatre segments ACK identiques). Il est donc émis plus de paquets de la catégorie ACK que dans l'état de la technique, ce qui amène à la possibilité d'un accroissement plus rapide de la fenêtre de congestion de l'émetteur précité ; • si tout un ensemble de nouveaux paquets de la catégorie ACK (créés et envoyés sur le premier medium) sont perdus, on retombe quand même (grâce à la transmission sur le deuxième medium) dans le contexte habituel d'une transmission sur un medium utilisant un protocole de transport avec acquittement (protocole TCP par exemple) ; • si au moins un paquet de la catégorie ACK arrive via le premier medium (les autres étant perdus), il aura permis de libérer plus rapidement la mémoire tampon d'émission de l'émetteur précité, et alors les autres paquets de la catégorie ACK reçus via le deuxième medium seront perçus comme désordonnés (en retard) mais ils contribueront quand même à augmenter la fenêtre de congestion de l'émetteur précité. Il est à noter que pour un même taux de perte sur le réseau, l'émetteur (la source) reçoit plus de paquets de la catégorie ACK que par la technique connue de filtrage d'acquittements. En effet, un paquet créé et émis sur le premier medium est uniquement soumis au taux de perte sur la section correspondante du réseau (entre une tête de tunnel et une passerelle Internet par exemple), ce qui est bien inférieur au nombre de paquets de la catégorie ACK supprimés par la technique connue de filtrage d'acquittements. Or, chaque paquet de la catégorie ACK reçu par l'émetteur lui permet d'accroître sa capacité d'émission. En émettant plus de paquets de la catégorie ACK (et en respectant la limite du seuil de déclenchement de retransmission selon le protocole passager avec acquittement), on multiplie d'autant la capacité d'émission de la source. Dans le cas d'un paquet de la catégorie PUSH, l'accélération de la transmission des informations de PUSH et des données utiles associées permet à l'émetteur (de ce paquet de la catégorie PUSH) d'alerter plus vite le récepteur (de ce paquet de la catégorie PUSH) de l'action à mener (à savoir le transfert immédiat des données collectées à l'application de destination). En d'autres termes, on accélère la connexion de bout-en-bout pour le flux passager. Avantageusement, si le paquet obtenu est un paquet d'acquittement, le dispositif gestionnaire une étape consistant à effectuer une troisième vérification de si une des deux conditions suivantes est vérifiée : - vu du côté d'un équipement destination, ayant généré ledit paquet d'acquittement, une retransmission de données selon le protocole de transport passager est ou doit être enclenchée ; - vu du côté d'un équipement source, une retransmission de données selon le protocole de transport passager ne doit pas être enclenchée, même si ledit équipement source reçoit ledit paquet d'acquittement ainsi qu'un nouveau paquet créé par ladite phase de création de paquet, et ladite phase de création de paquet est effectuée seulement en cas de première, deuxième et troisième vérifications positives. Ainsi, on gère le nombre de paquets d'acquittement identiques (DUP ACK selon le protocole TCP) transmis vers le second dispositif terminal. On n'envoie un paquet d'acquittement supplémentaire que si une retransmission est ou doit être enclenchée, ou bien si l'envoi d'un tel paquet d'acquittement supplémentaire ne provoque pas un déclenchement non souhaité d'une retransmission. De façon avantageuse, le dispositif gestionnaire effectue une étape consistant à effectuer une quatrième vérification de si les deux conditions suivantes sont vérifiées : - vu du côté dudit équipement destination, ayant généré ledit paquet d'acquittement, une retransmission de données selon le protocole de transport passager ne doit pas être enclenchée ; 20 - vu du côté dudit équipement source, une retransmission de données selon le protocole de transport passager va devoir être enclenchée, si ledit équipement source reçoit ledit paquet d'acquittement, et, en cas de quatrième vérification positive, le dispositif gestionnaire effectue des étapes consistant à : 25 - modifier le paquet obtenu en extrayant du paquet obtenu ladite partie copiée, pour obtenir un paquet modifié qui n'est pas un paquet d'acquittement ; - encapsuler le paquet modifié selon le protocole de transport avec acquittement. Ainsi, on évite que l'équipement source entre en retransmission alors que l'équipement destination ne requiert pas une telle retransmission. En effet, en modifiant 30 le paquet obtenu (paquet d'origine) pour lui ôter son caractère de paquet d'acquittement, on effectue une compensation, en nombre de paquets d'acquittement envoyés vers le 10 15 second dispositif terminal, avec un nouveau paquet d'acquittement préalablement créé et transmis vers le second dispositif terminal. Avantageusement, le dispositif gestionnaire effectue une étape consistant à effectuer une cinquième vérification de si le paquet obtenu appartient à au moins une catégorie différente de ladite au moins une catégorie prédéterminée. Ladite phase de création de paquet est effectuée seulement en cas de première, deuxième et cinquième vérifications positives. Des paquets appartenant à la au moins une catégorie déterminée mais aussi à au moins une autre catégorie particulière doivent être fiabilisés et donc être transportés via un medium selon un protocole de transport encapsulant avec acquittement. Il n'y aurait pas de sens d'émettre deux copies de ces paquets, l'une via un premier medium selon un protocole de transport encapsulant avec acquittement et l'autre via un second medium selon un protocole de transport encapsulant sans acquittement. De façon avantageuse, ladite au moins une catégorie différente appartient au groupe comprenant : - une catégorie regroupant des paquets d'initialisation de connexion entre lesdits dispositifs terminaux ; - une catégorie regroupant des paquets d'indication de fin de transmission. Par exemple, dans le cas du protocole TCP, des segments appartenant à la fois à la catégorie SYN et à la catégorie ACK, ou bien à la fois à la catégorie FIN et à la catégorie ACK, sont des paquets nécessitant d'être fiabilisés. De façon avantageuse, le dispositif gestionnaire effectue une étape consistant à effectuer une sixième vérification de s'il n'est pas déterminé une congestion sur un réseau transmettant ledit flux passager. Ladite phase de création de paquet est effectuée seulement en cas de première, deuxième et sixième vérifications positives. Ainsi, en cas de congestion, on n'alourdit pas inutilement le nombre de paquets transmis (pas de nouveau paquet créé), et on évite de créer et envoyer de nouveaux acquittements qui accéléreraient encore la transmission de paquets par le second dispositif terminal.

Avantageusement, le dispositif gestionnaire effectue une étape consistant à effectuer une septième vérification de si un taux d'utilisation de ressources processeur dudit dispositif gestionnaire est inférieur ou égal à un seuil prédéterminé. Ladite phase de création de paquet est effectuée seulement en cas de première, deuxième et septième vérifications positives. De cette façon, on optimise l'utilisation des ressources du dispositif gestionnaire.

Par exemple, pour trouver un compromis entre le taux d'utilisation des ressources processeur du dispositif gestionnaire et le taux d'accélération (que permet la présente invention), on peut limiter l'application de l'invention à la création d'un nouveau paquet pour n paquets obtenus (paquets d'origine). De façon avantageuse, un tunnel comprenant des première et deuxième porteuses est mis en oeuvre entre lesdits premier et second dispositifs terminaux. Ledit protocole de transport encapsulant avec acquittement est utilisé avec ladite première porteuse et ledit protocole de transport encapsulant sans acquittement est utilisé avec ladite deuxième porteuse. Ledit dispositif gestionnaire est une tête de tunnel placée entre le premier dispositif terminal et le tunnel.

Ainsi, la présente invention s'applique particulièrement, mais non exclusivement, dans le cas où un tunnel est mis en oeuvre entre les premier et second dispositifs terminaux. Dans ce cas, l'invention propose un mécanisme PEP de copie d'informations prioritaires comprises dans le paquet d'origine (informations d'acquittement et/ou de PUSH par exemple) pour des connexions (par exemple TCP) passagères du tunnel. Ce mécanisme PEP vise à améliorer les performances de ces connexions de bout-en-bout. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation).

Dans un autre mode de réalisation, l'invention concerne un dispositif gestionnaire apte à participer à une transmission de paquets d'un flux de données bidirectionnel passager établi entre des premier et second dispositifs terminaux, ledit flux passager étant conforme à un protocole de transport passager avec acquittement définissant une pluralité de catégories de paquet, ledit flux passager étant destiné à être encapsulé par un dispositif gestionnaire selon un protocole de transport encapsulant avec acquittement. Le dispositif gestionnaire comprend : - des moyens d'obtenir un paquet dudit flux passager transmis depuis le premier vers le second dispositif terminal ; - des moyens d'effectuer une première vérification de si le paquet obtenu appartient à au moins une catégorie prédéterminée parmi ladite pluralité de catégories de paquet ; - des moyens, activés en cas de première vérification positive, d'encapsuler au moins une partie des données dudit paquet obtenu, selon un protocole de transport encapsulant sans acquittement. Avantageusement, le dispositif gestionnaire comprend des moyens de mise en oeuvre des étapes qu'il effectue dans le procédé tel que décrit précédemment, dans l'un quelconque de ses différents modes de réalisation. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 illustre schématiquement une configuration classique d'un réseau privé virtuel (VPN) mettant en oeuvre un tunnel de communication ; - la figure 2 illustre schématiquement un modèle classique en couches protocolaires d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon un mode de réalisation de l'invention ; - la figure 3 illustre schématiquement un format classique de trame Ethernet dans le cadre de la mise en oeuvre d'un tunnel de niveau 2 ; - la figure 4 illustre schématiquement les blocs fonctionnels compris dans les têtes de tunnel selon un mode de réalisation de l'invention ; - la figure 5 présente un organigramme d'un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par une tête de tunnel ; - la figure 6 présente un organigramme détaillant un mode de réalisation particulier de l'étape de test 503 de la figure 5 ; et - la figure 7 illustre schématiquement la structure classique d'un segment TCP. 6. DESCRIPTION DÉTAILLÉE On rappelle maintenant, en relation avec la figure 7, quelques caractéristiques essentielles du protocole TCP (pour « Transmission Control Protocol », tel que défini par la norme RFC 793). Il s'agit d'un protocole de type ARQ (pour « Automatic Repeat reQuest » en anglais) qui a été créé dans le but d'assurer des transferts de données sur l'Internet selon des critères forts de vitesse et qualité. Au moins deux mécanismes sont utilisés pour gérer l'excès de trafic arrivant sur un récepteur : le premier consiste à utiliser des mémoires tampon de réception, et le second met en place un contrôle de flux. Le protocole TCP permet d'assurer le transfert des données de façon fiable, bien qu'il utilise le protocole IP, qui n'intègre aucun contrôle de livraison de datagramme. En effet, le protocole TCP possède un système d'accusé de réception, aussi appelé système d'acquittement (« acknowledgement » en anglais ou ACK), permettant à deux machines (l'une étant appelée client ou dispositif client, et l'autre serveur ou dispositif serveur) de s'assurer de la bonne réception mutuelle de données échangées de manière bidirectionnelle. On rappelle que le client et le serveur sont tous les deux des dispositifs terminaux (ou dispositifs émetteur/récepteur, ou encore machines émettrices/réceptrices), au sens où chacun d'eux émet et reçoit des segments de données (le flux de données entre le client et le serveur est bidirectionnel). Lors de l'émission d'un segment de données (aussi appelé paquet de données), un numéro d'ordre de données (appelé aussi numéro de séquence de données) est associé. A la réception d'un segment de données, la machine réceptrice de ce segment de données va retourner un autre segment de données dont le drapeau ACK est à 1 (afin de signaler qu'il s'agit d'un accusé de réception) accompagné d'un numéro d'accusé de réception (aussi appelé numéro de séquence d'acquittement) égal au numéro de séquence de données du segment reçu incrémenté de 1. En effet, le numéro de séquence d'acquittement correspond au numéro de séquence de données du prochain segment attendu (et non le numéro de séquence de données du dernier segment reçu).

L'établissement d'une connexion TCP entre un client et un serveur s'effectue en trois temps : • dans un premier temps, le client envoie un segment de données dont le drapeau SYN est à 1 (un tel segment est aussi appelé «message SYN ») pour signaler qu'il s'agit d'un segment de synchronisation, avec son numéro de séquence de données initial (ISN = x) ; • dans un second temps, le serveur reçoit le segment de synchronisation provenant du client, puis lui envoie un accusé de réception, c'est-à-dire un segment de données dont le drapeau ACK est à 1 et le drapeau SYN est à 1, comprenant son propre numéro de séquence de données (ISN = y), mais il doit également acquitter le paquet précédent, ce qu'il fait avec un numéro d'accusé de réception (numéro de séquence d'acquittement) qui contient le numéro d'ordre (numéro de séquence de données) initial du client incrémenté de 1 (ack = x + 1) ; • dans un troisième temps, le client transmet au serveur un accusé de réception, c'est-à-dire un segment dont le drapeau ACK est à 1 et le drapeau SYN est à 0, car il ne s'agit plus d'un segment de synchronisation. Son numéro d'ordre (numéro de séquence de données) est incrémenté (seq = x + 1) et le numéro d'accusé de réception (numéro de séquence d'acquittement) représente le numéro d'ordre (numéro de séquence de données) initial du serveur incrémenté de 1 (ack =y+1). Une fois achevée cette phase nommée « three-way handshake », les deux applications (coté client et côté serveur) sont en mesure d'échanger les octets qui justifient l'établissement de la connexion. Pour un sens de transmission donné du flux de données bidirectionnel entre le 25 client et le serveur, l'une de ces deux machines est appelée la source (générant les données principales du flux) et l'autre la destination (recevant les données principales du flux et les acquittant auprès de la source. Le contrôle de flux gère l'allocation de ressources, telles que les ressources mémoire et les ressources processeur (ressources CPU), au niveau de la destination. En 30 général, conformément au contrôle de flux, la destination fixe une limite au débit de transmission mis en oeuvre par la source qui envoie des données à la destination. La 10 15 20 source et la destination coordonnent le transfert de données grâce à un échange de messages comprenant des requêtes et des accusés de réception. Avant que la source ne commence à envoyer des paquets, elle envoie une requête à la destination visant à obtenir la permission de commencer la transmission. En réponse à cette requête, la destination envoie un message comprenant une identification du nombre de paquets que la source peut transmettre à la destination sans autorisation supplémentaire. Ce nombre est communément appelé "taille de fenêtre". Alors, la source transmet le nombre de paquets autorisés à la destination et attend que la destination vérifie leur réception. Après que la destination a reçu avec succès un paquet, elle envoie un message en retour à la source comprenant un accusé de réception (acquittement) indiquant que le paquet a été reçu avec succès et, dans certains cas, autorisant la source à envoyer un autre paquet. De cette façon, le nombre de paquets sur le réseau transitant depuis la source vers la destination ne dépasse jamais la taille de fenêtre autorisée. Ainsi, ce mécanisme de contrôle du flux est basé sur une fenêtre d'émission flottante appelée fenêtre de congestion (notée Cwnd, pour « Congestion window » en anglais). Cette fenêtre de congestion contient l'ensemble des trames émises par la source TCP et non encore acquittées par la destination TCP. La taille de cette fenêtre conditionne donc le débit maximum de la session TCP en cours. En effet, la source TCP ne peut émettre plus de Cwnd octets sans recevoir d'acquittement, or cet acquittement ne peut intervenir avant un « temps de boucle » (ou RTT, pour « Round-Trip Time » en anglais) (c'est-à-dire le temps que met un paquet pour arriver à la destination, et à l'acquittement correspondant d'être émis en retour et d'être reçu par la source). La source ne peut donc émettre plus de Cwnd/RTT octet par seconde. Des numéros de séquence sont utilisés pour décompter les données dans le flux d'octets. On trouve toujours deux de ces nombres dans chaque segment TCP, qui sont le numéro de séquence (représentant le propre numéro de séquence de la source TCP), et le numéro d'acquittement (représentant le numéro de séquence de la destination). La figure 7 illustre schématiquement la structure classique d'un segment TCP 700. Le segment TCP comprend deux parties : la première correspond à l'en-tête TCP 701, la seconde correspond aux données utiles (aussi appelées données à transportées) 702. La deuxième partie est de longueur nulle à l'établissement de la connexion, elle peut également être nulle par choix de l'application. L'en-tête TCP 701 comprend les champs suivants : • un champ 703 pour le numéro de port de l'application source ; • un champ 704 pour le numéro de port de l'application destination ; • un champ 705 pour un numéro de séquence de données (aussi appelé numéro d'ordre de données), identifiant la position des données à transmettre par rapport au segment original ; • un champ 706 pour un numéro d'acquittement (aussi appelé numéro de séquence d'accusé de réception), identifiant la position du dernier octet reçu dans le flux entrant. Il doit s'accompagner du drapeau ACK à 1 (voir plus loin) ; • un champ 707 indiquant la longueur de cet en-tête TCP. Une valeur supérieure à 20 octets indique la présence d'options (voir le champ 712 décrit ci-après) ; • un champ de contrôle 708 comprenant six bits de contrôle 7081 à 7086, définissant chacun un drapeau différent (URG, ACK, PSH, RST, SYN et FIN), pour influer sur le comportement du protocole TCP en caractérisant l'usage de ce segment TCP 700 (voir le tableau ci-dessous). En d'autres termes, les six bits de contrôle 7081 à 7086 permettent de définir six catégories de segment : segments URG, segments ACK, segments PSH (ou PUSH), segments RST, segments SYN et segments FIN (un même segment peut appartenir à plusieurs de ces catégories). Drapeau Signification (si le drapeau est à I) URG Le champ « Pointeur d'urgence » 711 doit être exploité. ACK Le champ « numéro d'acquittement » 706 est valide et doit être exploité. PSH (ou C'est une notification de la source à la destination, pour lui PUSH) indiquer que toutes les données collectées doivent être transmises à l'application sans attendre les éventuelles données qui suivent (soit du fait d'une fin de donnée, ou du fait d'un engorgement de la mémoire tampon de transmission). RST Réinitialisation de la connexion.

SYN Initialisation de la connexion. Le champ « numéro de séquence de données » 705 contient la valeur de début de connexion. FIN La source qui a émis ce segment TCP a fini d'émettre. • un champ 709 pour la taille de la fenêtre de congestion : chaque partie (c'est-à- dire chaque machine) annonce ainsi la taille de sa mémoire tampon de réception ; • un champ 710 pour une somme de contrôle (« checksum » en anglais), contenant le résultat d'un calcul d'intégrité qui porte sur la totalité du segment (en-tête et données) ; • un champ 711 pour un pointeur d'urgence, qui n'est valide que si le drapeau URG est armé (c'est-à-dire à 1). Ce champ 711 contient alors un décalage (« offset » en anglais) à ajouter à la valeur du numéro de séquence de données (contenue dans le champ 705) du présent segment 700 pour délimiter une zone des données urgentes à transmettre à l'application ; • un champ 712 d'options, pour un paramétrage particulier du protocole TCP ; et • une éventuelle zone de remplissage (« padding » en anglais), pour caler la longueur totale du présent segment TCP 700 sur un mot de 32 bits. Une option d'acquittements sélectifs (aussi appelée « option SACK », pour « Selective Acknowledgments » en anglais) du protocole TCP permet de mettre en oeuvre une politique de retransmission sélective [RFC 2018]. Cette option vise à offrir une information plus riche pour les reprises de pertes. En effet, les acquittements (ACKs) positifs cumulatifs fournissent une information limitée : une source TCP 20 n'apprend l'existence que d'une seule perte de paquet par RTT. L'option SACK donne au protocole TCP les moyens de dépasser cette limitation. Dans la suite de la description, la technique selon un mode de réalisation particulier de l'invention est plus amplement décrite, dans le cadre d'une mise en oeuvre d'un tunnel de communication entre deux réseaux LAN, afin de permettre l'échange de 25 données multimédia entre des équipements réseaux de chacun de ces réseaux LAN. La figure 1 illustre schématiquement une configuration classique d'un réseau privé virtuel (VPN) mettant en oeuvre un tunnel de communication (appelé aussi plus simplement « tunnel »). 10 15 Un tunnel 100 est établi entre une première tête de tunnel 101 et une seconde tête de tunnel distante 102 via un réseau de communication 107, tel que l'Internet par exemple. Le tunnel 100 interconnecte un réseau LAN A 103 et un autre réseau LAN B 104. Chacun des réseaux LAN 103 et 104 comporte un équipement d'accès Internet haut débit de type passerelle domestique (ou « Home Gateway » en anglais), respectivement 105 et 106, pouvant intégrer un pare-feu (ou « Firewall » en anglais), respectivement 105a et 106a. Chacun des réseaux LAN 103 et 104 comporte en outre des équipements de type ordinateur (ou « PC » pour « Personal Computer » en anglais) 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage de données multimédia numériques (de type audio, vidéo, photo), ainsi que des équipements de restitutions des données numériques 108 et 112. Une tête de tunnel peut être un équipement dédié (comme représenté sur la figure 1), ou bien intégrée dans un équipement à vocation audiovisuelle, comme par exemple un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un jeu d'instructions informatiques (ou programme) réalisant les fonctions associées à celle-ci. Une fois que le tunnel 100 est établi, les équipements 108, 109, et 110, connectés au réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au réseau LAN B 104. Par exemple, le client 108 connecté au réseau LAN A 103 peut communiquer, de manière transparente, avec le serveur 113 connecté au réseau LAN B 104. Sur la figure 1 est représenté un réseau de communication ne comportant qu'un seul tunnel, mais il est bien entendu qu'un même réseau LAN peut comporter plusieurs têtes de tunnel et/ou qu'une même tête de tunnel peut gérer plusieurs tunnels (à destination d'autant de têtes de tunnel) pour interconnecter un premier réseau LAN à plusieurs autres réseaux LAN. En outre, dans un souci de simplification, n'ont pas été représentés les équipements d'infrastructure (routeurs,...) du réseau Internet. La figure 2 illustre schématiquement un modèle classique en couches protocolaires d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon un mode de réalisation de l'invention.

La description suivante propose un modèle en couches protocolaires nécessaires à la mise en oeuvre du tunnel 100 par la tête de tunnel 101. Une description analogue s'applique à la tête de tunnel 102. Dans le modèle présenté sur la figure 2 ne sont pas représentés les éléments protocolaires nécessaires aux fonctions autres que la mise en oeuvre du tunnel, comme par exemple les éléments protocolaires associés au standard UPnP (pour « Universal Plug and Play » en anglais). Le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110 (connectés au réseau LAN A 103) et à acheminer via le tunnel 100 jusqu'au réseau LAN B 104, s'effectue comme suit. Le modèle en couches protocolaires présenté sur la figure 2 comporte une couche d'interface physique Ethernet 208 qui remet les trames Ethernet issues des équipements 108, 109, 110 à une couche liaison de données Ethernet 207 pour routage vers une couche réseau 206 (pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel) ou vers une couche de pont Ethernet (« bridge layer » en anglais) 209, pour les autres trames Ethernet. La couche de pont Ethernet 209 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relais de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Sur la couche de pont Ethernet 209 sont attachées la couche liaison de données Ethernet 207 et au moins une couche d'interface de réseau virtuelle 210 émulant un contrôleur Ethernet. Une couche d'interface virtuelle 210 est créée pour chaque tunnel instancié par l'application 200. L'application 200 remet à cette couche virtuelle 210 les trames Ethernet qui doivent être diffusées dans l'ensemble du réseau privé virtuel. D'une manière générale, le protocole d'encapsulation du tunnel représenté par l'application 200 réalise les opérations nécessaires à la mise en oeuvre de chaque tunnel, parmi lesquelles on trouvera notamment la configuration, le filtrage et l'encapsulation (formation d'un paquet tunnel) et l'extraction d'une trame. Dans un mode de réalisation préféré s'y trouvent aussi les mécanismes spécifiques à l'invention, tels que plus amplement décrits par la suite, en particulier en relation avec les figures 4 à 6.

Les trames reçues de la couche d'interface virtuelle 210, après traitement par l'application 200, sont remises sous la forme de paquets à travers une couche d'interface applicative (« socket layer » en anglais) 201 à une couche de protocole de transport fiable TCP 203 ou une couche de protocole de transport non fiable UDP 205, respectivement sécurisées par les couches de protocoles SSL/TLS 202 et DTLS 204. Après traitement par l'une des deux couches de protocole de transport TCP 203 ou UDP 205, pour former un paquet tunnel 250 (figure 3), celui-ci est passé à la couche réseau 206. Le datagramme IP ainsi formé avec le paquet tunnel peut maintenant être transmis sur le réseau LAN à travers les couches liaison 207 et physique 208, pour être ensuite propagé sur le réseau Internet via la passerelle 105. La réception d'une trame en provenance du tunnel 100 suivra dans la tête de tunnel le cheminement inverse à celui présenté ci-dessus. La figure 3 illustre schématiquement un format classique de trame Ethernet dans le cadre de la mise en oeuvre d'un tunnel de niveau 2, tel que le tunnel 100 de la figure 1. La trame Ethernet 260 véhicule un paquet tunnel de niveau 2. La trame Ethernet 260 est une trame transitant par exemple sur le réseau LAN A 103 de la figure 1 entre la tête de tunnel 101 et la passerelle 105, pour les données en provenance ou à destination du réseau LAN B 104. La trame Ethernet 260 comporte : - un champ d'en-tête Ethernet 261, - un premier datagramme IP 262 véhiculant lui-même un paquet tunnel 250 de niveau 2, et - un champ de séquence de contrôle de trame FCS 263 (pour « Frame Check Sequence » en anglais). Le paquet tunnel 250, contenu dans le datagramme IP 262, comporte : - un champ d'en-tête du protocole de transport (aussi appelé protocole de transport encapsulant) 251, à savoir TCP ou UDP dans l'exemple décrit en détail ici ; - un champ d'en-tête du protocole d'encapsulation 252, à savoir L2TP ou TLS dans l'exemple décrit ici. De tels protocoles d'encapsulation sont notamment décrits dans la norme RFC-3931 (« Layer two tunneling protocol û version 3 (L2TPv3) », J. Lau and all, March 2005) et la norme RFC-2246 (« The TLS Protocol Version 1.0 ») ; 25 30 - un champ d'en-tête du protocole embarqué 253, à savoir Ethernet dans l'exemple ici (car sont transportées via le tunnel les trames Ethernet émises par les dispositifs connectés au réseau LAN A 103 ou B 104) ; et - un champ de données utiles 254 (aussi appelées données utilisateur ou données applicatives), qui lui-même comporte un second datagramme IP complet si aucune fragmentation n'a été opérée lors de son transit depuis le dispositif l'ayant généré. Dans la suite du document, les algorithmes d'un mode de réalisation de l'invention sont décrits selon une mise en place sur une tête de tunnel 101 (ou 102).

La figure 4 illustre schématiquement les blocs fonctionnels compris dans les têtes de tunnel selon un mode de réalisation de l'invention. L'architecture fonctionnelle de chaque tête de tunnel (TEP) 101 ou 102 est composée d'un bloc émetteur 410 et d'un bloc récepteur 420, permettant respectivement l'émission et la réception de données via le tunnel 100 multi-transport (c'est-à-dire via un tunnel comprenant plusieurs porteuses utilisant chacune un protocole de transport, comme par exemple une porteuse TCP et une porteuse UDP). Dans un souci de simplification, sur la figure 4, on a représenté uniquement le bloc émetteur 410 de la tête de tunnel 101 et le bloc récepteur 420 de la tête de tunnel 102.

Les différentes couches protocolaires présentées en relation avec la figure 2 sont représentées ici de manière simplifiée, dans un souci de lisibilité de la représentation. De même, les passerelles 105 et 106 sont omises. Il convient aussi de noter que dans un souci de lisibilité, seules deux porteuses UDP 100B et TCP 100A sont représentées sur le schéma : ceci ne limite en rien le nombre de porteuses du tunnel, qui peut être constitué de porteuses : selon d'autres protocoles de couche transport du modèle OSI (tels que les protocoles DCCP et SCTP, discuté brièvement ci-dessous), et ayant ou non des protocoles de sécurisation associé (tel que les protocoles TLS et DTLS). Outre les protocoles TCP et UDP, d'autres protocoles de transport ont été créés pour des usages divers, notamment : • le protocole SCTP (pour « Stream Control Transmission Protocol » en anglais) est un protocole défini par l'IETF dans la RFC 4960. Il fournit des services similaires au protocole TCP, assurant la fiabilité, la remise en ordre des séquences, et le contrôle de congestion. Ce protocole SCTP de transport du tunnel est assimilé à un protocole de transport avec acquittement et ordonnancement, comme c'est le cas pour le protocole TCP ; • le protocole DCCP (pour « Datagram Congestion Control Protocol » en anglais) est un protocole de communication de couche de transport orienté « message ». Il a été défini par l'IETF dans le RFC 4340. Il fournit des connexions bidirectionnelles de type envoi individuel (« unicast » en anglais) avec le support d'un contrôle de congestion (comme TCP) pour un service de messages non fiable (comme UDP). Ce protocole DCCP de transport du tunnel est assimilé à un protocole de transport sans acquittement, comme c'est le cas pour le protocole UDP.

La description suivante porte uniquement sur la transmission d'un flux de données 401 via le tunnel 100, depuis la tête de tunnel 101 vers la tête de tunnel 102. Une description analogue s'applique pour une transmission de flux, dans le sens inverse, c'est-à-dire depuis la tête de tunnel 102 vers la tête de tunnel 101. Il convient aussi de noter qu'un seul flux 401 de données, transporté via le tunnel 100 depuis la tête de tunnel 101 vers la tête de tunnel 102, est considéré pour les besoins illustratifs. Cependant, plusieurs flux semblables au flux 401 peuvent simultanément bénéficier des avantages de la présente invention. Le bloc émetteur 410 de la tête de tunnel 101 reçoit en entrée un flux 401, en provenance du réseau LAN A 103, et est en charge de transporter les données de ce flux 401 via le tunnel 100, en tirant profit des porteuses TCP 100A et UDP 100B. Le bloc récepteur 420 de la tête de tunnel 102 reçoit les données depuis le tunnel 100, et restitue, sur le réseau LAN B 104, un flux 402 de données correspondant au flux 401 original (par exemple, le flux 402 est identique au flux 401 s'il n'y a pas eu de perte sur l'Internet, mais la distribution des paquets du flux 402 est probablement différente de celle du flux 401, du fait des latences fluctuantes entre les porteuses du tunnel mufti- transport 100).

Dans le cadre d'un mode de réalisation de l'invention, le flux 401 passager est formaté selon le protocole TCP : par exemple un transport FTP sur TCP est une solution privilégiée de l'état de la technique pour le transfert de fichier ; le transport HTTP sur TCP est une solution privilégiée de l'état de la technique pour les données Web (par exemple les standards UPnP/DLNA utilisent HTTP pour le transfert de vidéos). Le bloc émetteur 410 de la tête de tunnel 101 comprend les éléments suivants : - un module d'identification de flux 411, en charge de détecter et sélectionner les nouveaux flux reçus du réseau LAN 103 ; - un module d'aiguillage 412, en charge d'aiguiller chacun des paquets des flux 401 du réseau LAN 103 vers l'une des porteuses du tunnel 100 ; - un module PEP 415 manipulant les flux sélectionnés par le module d'identification de flux 411. Ce module PEP 415 est en charge de copier, si besoin, des informations contenues dans certains des segments TCP du flux 401 afin par la suite que les informations copiées (c'est-à-dire celles résultant de la copie) soient transmises plus rapidement sur le tunnel et à terme vers la destination concernée par la connexion de bout-en-bout pour le flux 401 ; - des empaqueteurs 413 et 414, chacun dédié à une porteuse du tunnel 100, en charge d'encapsuler les données issues du module d'aiguillage 412 (les segments du flux 401 d'origine et les éventuelles informations copiées de ce flux 401). Le module d'identification de flux 411 effectue une sélection des nouveaux flux à fournir au module PEP 415, et sur lesquels le procédé selon l'invention est appliqué. Au final, le module d'identification de flux 411 sélectionne, par exemple en fonction de la classe de service des flux détectés, au moins un flux 401 de type TCP et envoie chaque paquet de ce flux au module PEP 415. Dans la suite de la description, on suppose que le flux sélectionné 401 est destiné à être encapsulé, par le bloc émetteur 410 de la tête de tunnel 101, selon un protocole de transport encapsulant avec acquittement (par exemple le protocole TCP) pour transmission sur la porteuse utilisant ce protocole (porteuse TCP dans l'exemple précité).

Le module PEP 415 est adapté à déterminer la nature des segments reçus, et l'opportunité de manipuler des informations particulières de ces segments (notamment les informations relatives à des segments ACK et PSH). Le module PEP 415 est en outre en charge de créer (via un module de génération 4151) de nouveaux segments TCP passagers (aussi appelés, selon le mode de réalisation considéré, segments créés) correspondant à une partie des informations véhiculées par des segments sélectionnés du flux 401 d'origine. Ces segments TCP passagers créés sont alors destinés à être transmis via la porteuse UDP. Le module PEP 415 est enfin apte à proposer cette décision de routage, pour les segments créés, au module d'aiguillage 412 qui exécute alors l'aiguillage de ces segments sur la porteuse indiquée par le module PEP 415. Un mode de réalisation particulier de l'algorithme mis en oeuvre par le module PEP 415 est plus amplement décrit par la suite, notamment en relation avec les figures 5 et 6. Le bloc récepteur 420 de la tête de tunnel 102 comprend les éléments suivants : - des dé-paqueteurs 421 et 422 chacun dédié à une porteuse du tunnel 100, en charge de dés-encapsuler les données en provenance du tunnel 100 ; - un séquenceur de flux 425 en charge de délivrer et de cadencer sur le réseau LAN 104 les paquets du flux 402 obtenu en sortie du tunnel. La figure 5 représente un organigramme d'un mode de réalisation particulier du procédé selon l'invention, mis en oeuvre par une tête de tunnel. A titre d'exemple, on considère à nouveau uniquement la transmission du flux de données 401 via le tunnel 100, depuis la tête de tunnel 101 vers la tête de tunnel 102, et dans ce contexte la figure 5 illustre le fonctionnement du bloc émetteur 410 de la tête de tunnel 101.

Toutes les étapes de l'algorithme de la figure 5 peuvent être mises en oeuvre indifféremment : • par exécution d'un jeu d'instructions informatiques exécuté par une machine de calcul reprogrammable, tel qu'un équipement de type PC, un DSP (« Digital Signal Processor » en anglais) ou un microcontrôleur. Dans ce cas, le programme correspondant (c'est-à-dire la séquence d'instructions) peut être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur ; ou bien • par une machine ou un composant dédié, tel qu'un FPGA (« Field-Programmable Gate Array » en anglais) ou un ASIC (« Application-Specific Integrated Circuit » en anglais). L'étape 500, réalisée par le module d'identification de flux 411, consiste à avertir le module PEP 415 de l'arrivée d'un paquet (aussi appelé segment) d'un flux multimédia 401 utilisant un protocole de transport avec acquittement. Cette détection de nouveau flux 401 est personnalisée selon le protocole de transport du flux 401 : par exemple, tout flux selon le protocole TCP est susceptible d'être sélectionné. Cette sélection de flux TCP peut être réduite selon : • des critères de qualité de service (classe de service véhiculée dans le flux 401) ; • une sélection par l'utilisateur des services à améliorer (par exemple le transport de vidéos sur HTTP) ; • une sélection par l'utilisateur des équipements des réseaux LAN 103 et 104 sur lesquels il est souhaité une accélération du transport (par exemple les équipements UPnP) ; • etc. Les étapes suivantes sont réalisées par le module PEP 415.

L'étape 501 consiste à déterminer à quelle(s) catégorie(s) de segment appartient le segment reçu. Dans un mode de réalisation particulier de cette étape 501, on détecte la présence des bits de contrôle (drapeaux) ACK et PSH dans le segment reçu, afin de déterminer si ce dernier est un segment ACK et/ou PSH. Ceci est réalisé par analyse des champs 7082 et 7083 de l'en-tête TCP présenté à la figure 7. Si aucun de ces drapeaux ACK et PSH n'est positionné (un drapeau positionné signifie que le bit correspondant est mis à 1), on passe à une étape 507 dans laquelle le segment TCP reçu est directement transmis au module d'aiguillage 412. Dans un mode particulier de l'invention, si le drapeau ACK est positionné en même temps que le drapeau SYN ou FIN, alors le segment reçu est simplement envoyé au module d'aiguillage 412 (les drapeaux SYN ou FIN indiquent des segments de connexion TCP, qui sont uniques et dont le transport est préférablement fiabilisé, ce qui ne requiert pas l'utilisation de la porteuse UDP du tunnel à la place de la porteuse TCP du tunnel, pour certaines informations ou données contenues dans segment reçu). Sinon (c'est-à-dire si le segment reçu est un segment ACK et/ou PSH, mais pas un segment SYN ou FIN), l'étape de test 502 est exécutée et consiste à déterminer la présence de données utiles (aussi appelées données transportées) dans le segment reçu (champ 702 non vide). Pour cela, la valeur « total length » (indiquée en nombre d'octets) de l'en-tête IP ne doit pas dépasser la somme de la taille de l'en-tête IP (indiquée en nombre de mots de 4 octets qui composent l'en-tête) avec la taille de l'en-tête TCP (indiquée en nombre de mots de 4 octets qui composent l'en-tête). La taille standard de l'en-tête IP fait 5 mots (soit 20 octets), celle de TCP sans option est aussi de 5 mots. Donc, un segment TCP indiquant une taille « total length » dans l'en-tête IP supérieure à 40 octets contient des données (zone 702 non vide selon la figure 7). Si l'étape de test 502 conduit à déterminer que le segment reçu ne contient pas de donnée utile, on vérifie à l'étape 511 s'il s'agit d'un segment ACK et/ou d'un segment PSH : - s'il s'agit d'un segment ACK seul (sans PSH), on passe à l'étape 509 dans laquelle on prépare la transmission du segment sur la porteuse UDP du tunnel : le segment est envoyé au module d'aiguillage 412 avec la consigne d'envoi sur la porteuse UDP. Ceci ne demande aucun traitement supplémentaire, et peut être exécuté à tout moment (pas de charge CPU requise) ; - s'il s'agit d'un segment PSH (ou d'un segment ACK et PSH), ce segment avec le drapeau PSH positionné sert à signaler à la destination TCP qu'elle doit transmettre les données reçues aux couches supérieures, afin de libérer la mémoire tampon d'émission TCP de la source TCP. Il est important que ce segment arrive rapidement à la destination, mais en conservant une fiabilité. C'est pourquoi l'étape 510 vise à dupliquer entièrement ce segment (c'est-à-dire créer un nouveau segment identique à ce segment) pour émettre deux segments identiques sur chacune des deux porteuses TCP et UDP du tunnel. Ensuite, l'étape 505 est exécutée. Si l'étape de test 502 conduit à déterminer que le segment TCP reçu contient des données utiles, l'étape de test 503 est mise en oeuvre. Cette étape de test 503, détaillée en rapport avec la figure 6, conduit à l'exécution du processus de création et émission d'un nouveau segment, selon un mode de réalisation de l'invention (étapes 504 ou 510, et 505, 506), si une ou plusieurs conditions sont vérifiées. Si le résultat de l'étape de test 503 est positif, on passe à l'étape 508. Sinon, on passe à l'étape 507 dans laquelle le segment TCP est transmis directement au module d'aiguillage 412. Dans l'étape 508, on vérifie si le segment reçu contient un drapeau PSH positionné (bit correspondant 7083 mis à 1), indiquant ainsi qu'il s'agit d'un segment PSH : - s'il s'agit d'un segment PSH (ou d'un segment ACK et PSH), ce segment avec le drapeau PSH positionné sert à signaler à la destination TCP qu'elle doit transmettre les données reçues aux couches supérieures (afin de libérer la mémoire tampon d'émission TCP de la source TCP, ou en fin de transmission d'un bloc de données). On passe alors à l'étape 510 précédemment décrite, qui vise à dupliquer entièrement ce segment. Ensuite, les étapes 505 et 506 sont exécutées ; - s'il ne s'agit pas d'un segment PSH, il s'agit donc d'un segment ACK (puisque l'étape de test 501 a préalablement indiqué qu'il s'agissait d'un segment ACK et/ou PSH), alors l'étape 504 est mise en oeuvre, puis les étapes 505 et 506. Dans l'étape 504, un nouveau segment doit être créé. Pour cela, l'en-tête du segment reçu est recopié (c'est-à-dire dupliqué) dans un nouveau paquet (comme il s'agit d'un tunnel de niveau 2, les en-têtes Ethernet, IP, et TCP sont considérées), mais les données utiles du paquet d'origine ne sont pas recopiées (c'est-à-dire dupliquées) dans le nouveau paquet. Puis une mise à jour de l'en-tête TCP est effectuée, ainsi qu'une mise à jour de l'en-tête TCP. Le segment d'origine est laissé intact. La mise à jour de l'en-tête TCP comprend les actions suivantes : • conservation uniquement du drapeau ACK (bit de contrôle 7082), parmi les drapeaux de l'en-tête TCP ; • modification de la valeur contenue dans le champ de numéro de séquence 705, en soustrayant de la valeur courante le nombre d'octets de données utiles que contient le segment reçu d'origine ; • calcul de la somme de contrôle (« checksum ») de l'en-tête TCP 701, et mise à jour du champ « somme de contrôle » 710.

On notera qu'avant d'être mis à jour, tout l'en-tête TCP 701 est copié, y compris le champ d'options 712. Ceci permet notamment de supporter l'option SACK du protocole TCP. La mise à jour de l'en-tête IP comprend les actions suivantes : • calcul de la longueur totale du paquet au niveau IP, et mise à jour d'un champ correspondant ; • calcul de la somme de contrôle de l'en-tête IP, et mise à jour d'un champ correspondant. Dans l'étape 505, le nouveau segment créé à l'étape 504 ou 510 est transmis sur la porteuse UDP du tunnel. Pour cela, le nouveau segment créé est envoyé au module d'aiguillage 412 avec la consigne d'envoi sur la porteuse UDP. L'avantage est d'assurer la rapidité du transfert sur le tunnel. Dans l'étape 506, le segment d'origine est transmis sur la porteuse TCP du tunnel. Pour cela, le segment d'origine est envoyé au module d'aiguillage 412 avec la consigne d'envoi sur la porteuse TCP. L'avantage est d'assurer la fiabilité du transfert sur le tunnel. Il est aussi possible, dans une variante de réalisation de l'étape 504, de : • ne pas recopier (c'est-à-dire dupliquer) certaines informations contenues dans le paquet d'origine (pour les mettre dans un nouveau paquet à transmettre sur la porteuse UDP), mais de les extraire du paquet d'origine ; • construire un premier nouveau paquet, avec les informations extraites (et en recalculant la somme de contrôle associée), et transmettre ce premier nouveau paquet via la porteuse UDP du tunnel, et • construire un second nouveau paquet, avec les informations et données utiles restantes (et en recalculer la somme de contrôle associée), et transmettre ce second nouveau paquet via la porteuse TCP du tunnel. Cependant, avec le mode de réalisation présenté auparavant (cas de la «recopie d'informations ») est plus facile à mettre en oeuvre que cette variante car il est nécessaire de construire qu'un seul nouveau paquet (il n'y a pas à construire le second nouveau paquet précité). C'est également plus fiable car tout le contenu (informations et données utiles) du paquet d'origine est transmis via la porteuse TCP.

La figure 6 présente un organigramme détaillant un mode de réalisation particulier de l'étape de test 503 de la figure 5. L'étape 5031 consiste à déterminer le nombre global d'acquittements (segments ACK d'origine reçus et segments ACK supplémentaires créés par l'invention) pour un même numéro d'acquittement, afin de vérifier que les segments ACK supplémentaires créés par l'invention ne produisent pas un trop grand nombre de segments ACK qui conduirait la source TCP à entrer en retransmission (en cas de réception de trois segments ACK dupliqués, aussi nommés DUP-ACK selon le protocole TCP). Pour cela, on gère une table de référencement des flux 401 contenant le nombre de segments ACK d'origine reçus et le nombre de segments ACK supplémentaires créés par l'invention, pour tout flux 401 identifié par le 4-uplet {adresse source SA, adresse destination DA, port source S.Port, port destination D.Port}. Une nouvelle entrée de flux 401 dans cette table correspond à la réception d'un segment TCP provenant du réseau local avec le drapeau SYN à 1.

Les informations contenues dans cette table d'information des flux de données 401 sont extraites des datagrammes IP du flux 401. On y trouve pour chaque flux de données, l'adresse source « SA » (correspondant au champ d'adresse source du datagramme IP), l'adresse de destination « DA » (correspondant au champ de destination du datagramme IP), le port source « S.Port », et le port de destination « D.Port » contenu dans le datagramme IP. Pour chaque entrée de la table, on dispose d'informations complémentaires, à savoir : • le dernier numéro de séquence acquittée par les segments ACK reçus (mis à jour par l'étape 502, par lecture du champ «Numéro d'acquittement» 706) ; • le nombre de fois que ce segment ACK a été reçu (mis à jour par l'étape 502), noté NR ; et • le nombre de fois que l'on a créé un segment ACK supplémentaire comprenant les mêmes informations d'acquittement que ce segment ACK (mis à jour par l'étape 505), noté ND. Ainsi, l'étape de test 5031 est positive, et on passe à l'étape 5032, si l'une des conditions suivantes est vérifiée : • condition 1 : « NR S+l » (ce qui signifie que, vu du côté de la destination TCP, une procédure de retransmission selon le protocole de transport passager est ou doit être enclenchée), alors la destination TCP du flux passager veut avertir la source TCP qu'il y a des erreurs de transmission : pas de limitation à la génération d'un nouveau segment ACK pour accélération selon l'invention ; • condition 2 : « NR + ND < S » (ce qui signifie que, vu du côté de la source TCP, la procédure de retransmission n'a pas besoin d'être enclenchée, même si elle reçoit un segment ACK créé supplémentaire), alors la source TCP ne considère pas encore qu'il y a eu une erreur de transmission, et un segment ACK créé selon l'invention ne créera pas de retransmission non voulue. S est une valeur seuil pour la détermination, selon le protocole TCP, du besoin de retransmission d'un segment considéré comme perdu suite à la réception d'un nombre de segments DUP ACK égal à cette valeur seuil. Communément, cette valeur seuil S est appelée « dup ack threshold », et a pour valeur 3.

Si l'étape de test 5031 est négative, on passe à l'étape 507 : il y a suspension de la création de segments DUP ACK, pour éviter que la source TCP ne parte en retransmission. Par exemple, on peut appliquer la procédure suivante (pour un même segment ACK) : Index de NR Action ND Nmax Segment ACK d'origine reçu Condition 2 vérifiée : autorisation d'exécuter #1 1 l'étape 508 (transmission du segment ACK 0 2 d'origine et d'un segment ACK créé) #2 2 Conditions 1 et 2 non vérifiées : exécution de 1 3 (1" DUP ACK) l'étape 507 (pas de création de segment ACK supplémentaire, et transmission du segment ACK d'origine). #3 3 Conditions 1 et 2 non vérifiées : modification du 1 3 (2eme DUP ACK) segment ACK d'origine (drapeau ACK mis à 0, retrait des informations liées à l'acquittement et calcul de somme de contrôle de l'en-tête TCP uniquement) puis exécution de l'étape 507 (pas de création de segment supplémentaire et aucun segment ACK transmis). #4 4 Condition 1 vérifiée : exécution de l'étape 508 1 5 (3eme DUP ACK) (transmission du segment ACK d'origine et d'un segment ACK créé) Nmax est le nombre maximal de segments ACK perçus (après l'itération courante du processus de décision, menant à l'envoi ou non d'un segment ACK supplémentaire) par la source TCP des données auxquelles correspond le segment ACK. Nmax est un nombre théorique, en supposant qu'il n'y a pas de perte de transport sur la porteuse UDP. ND est compté ici avant l'itération courante du processus de décision précité. On notera que le segment ACK #3 est géré de manière particulière car l'envoi du segment ACK créé selon l'invention lors de l'itération précédente du processus de décision (avec les mêmes informations d'acquittement que le segment ACK #2), a incrémenté le compteur de DUP ACK de la destination TCP : ce filtrage du segment ACK #3 a donc pour effet de rétablir les compteurs de la destination TCP comme si l'invention n'avait pas été mise en place. Le filtrage du segment ACK #3 peut être résumé comme suit : - si les deux conditions suivantes sont vérifiées : * « NR < S+1 », ce qui signifie que, vu du côté de la destination TCP, une procédure de retransmission selon le protocole de transport passager n'a pas besoin d'être enclenchée (même en comptant le segment ACK #3), et * « NR + ND S+l », ce qui signifie que, vu du côté de la source TCP, cette procédure de retransmission va devoir être enclenchée si elle reçoit le segment ACK #3, 20 - alors on transmet sur la porteuse TCP un segment modifié (non ACK) obtenu à partir du segment ACK d'origine reçu (on extrait du segment ACK #3 les informations liées à l'acquittement, pour obtenir un segment modifié qui n'est pas un segment d'acquittement).

L'étape 5032 consiste à vérifier s'il y a une congestion sur le réseau WAN. Si ce n'est pas le cas, on passe à l'étape 5033, sinon on passe à l'étape 507 (arrêt de l'algorithme de création et émission de segments supplémentaires) car il est inutile d'augmenter le nombre de paquets transmis (pas de segment ACK supplémentaire) et inutile aussi d'accélérer la source du flux TCP dans sa transmission. Par exemple, l'ECN (ou «Notification Explicite de Congestion ») est une extension au protocole Internet (IP) qui permet la notification préalable de la congestion du réseau (RFC 3168), par exemple en présence de surcharge sur le chemin entre les deux hôtes (tels que les têtes de tunnel). Ainsi, une tête de tunnel est mise au courant d'une congestion temporaire via la remontée d'information 430 des porteuses du tunnel.

L'étape 5033 consiste à vérifier que les ressources processeur (ressources CPU) de la tête de tunnel ne sont pas complètement utilisées. Par exemple, si le taux d'occupation des ressources CPU avoisine les 80%, la tête de tunnel n'a que peu de marge de manoeuvre. On rappelle que la charge principale d'une tête de tunnel (en implémentation logicielle pure) est relative aux opérations d'encapsulation et/ou de décapsulation de donnée. Dans ce cas, il est inutile de vouloir accélérer un flux passager TCP, ce qui aurait pour conséquence de surcharger la tête de tunnel. Par contre, un CPU chargé à moins de 50% peut être considéré comme une condition permettant de traiter tous les paquets (passage à l'étape 508). Entre ces deux valeurs (50% et 80%), l'application de l'étape 5034 permet d'accélérer le flux 401 sans dépasser les contraintes de CPU. On rappelle que ces valeurs de seuil sont données à titre informatif, et que ces valeurs sont fortement liées au mode d'implémentation de l'ensemble des algorithmes d'encapsulation et/ou de décapsulation des têtes de tunnel : soit sous forme logicielle (software), avec accélération matérielle (hardware) de certaines fonctions, soit complètement sous forme matérielle (hardware). En alternative, une définition de ces seuils peut être fournie par un utilisateur (via une interface Web de configuration de la tête de tunnel par exemple). L'étape 5034 sert alors à déterminer un ratio 1/n d'application de l'étape 508 pour les paquets reçus : chaque segment reçu est compté, et un parmi n de ces paquets est dirigé vers l'étape 508 (les autres vers l'étape 507). Ce ratio 1/n est préférentiellement déterminé par intervalle de temps régulier en décrémentant n (de 10 à 1). Par exemple, on vérifie qu'en utilisant une valeur de 1/10 de paquets transmis pour traitement vers l'étape 508, on respecte toujours le seuil maximal d'occupation de ressources CPU précité. Si oui, on teste alors la valeur supérieure 1/9 par exemple, puis 1/8 et ainsi de suite. Si on dépasse le seuil maximum d'occupation des ressources CPU, on peut alors décider de diminuer d'une unité le taux de création de segments supplémentaires (par exemple passer de 1/6 à 1/7) et ainsi de suite.

Claims (16)

1. REVENDICATIONS1. Procédé de transmission de paquets d'un flux de données bidirectionnel passager établi entre des premier et second dispositifs terminaux (108, 113), ledit flux passager étant conforme à un protocole de transport passager avec acquittement définissant une pluralité de catégories de paquet, ledit flux passager étant destiné à être encapsulé par un dispositif gestionnaire (101, 102) selon un protocole de transport encapsulant avec acquittement, caractérisé en ce que le dispositif gestionnaire effectue des étapes consistant à : - obtenir (500) un paquet dudit flux passager transmis depuis le premier vers le second dispositif terminal ; - effectuer (501) une première vérification de si le paquet obtenu appartient à au moins une catégorie prédéterminée parmi ladite pluralité de catégories de paquet ; - en cas de première vérification positive, encapsuler (504, 510, 505, 509) au moins une partie des données dudit paquet obtenu, selon un protocole de transport encapsulant sans acquittement.
2. 2. Procédé selon la revendication 1, caractérisé en ce que le dispositif gestionnaire effectue une étape consistant à effectuer (502) une deuxième vérification de si le paquet obtenu comprend des données utiles ; 20 et en en ce que, en cas de première et deuxième vérifications positives, le dispositif gestionnaire effectue une phase de création de paquet comprenant des étapes consistant à, pour ledit paquet obtenu ou au moins un desdits paquets obtenus : - créer (504, 510) un nouveau paquet dans lequel a été copiée une partie du paquet obtenu liée à ladite au moins une catégorie prédéterminée ; 25 - encapsuler (505) le nouveau paquet selon le protocole de transport sans acquittement (UDP) ; - encapsuler (506) les données utiles selon le protocole de transport avec acquittement (TCP).
3. 3. Procédé selon la revendication 2, caractérisé en ce que l'étape consistant à 30 encapsuler (506) les données utiles selon ledit protocole de transport avec acquittement 15comprend une étape consistant à encapsuler le paquet obtenu selon le protocole de transport avec acquittement.
4. 4. Procédé selon la revendication 2, caractérisé en ce que l'étape consistant à encapsuler (506) les données utiles selon le protocole de transport avec acquittement comprend des étapes consistant à : - modifier le paquet obtenu en extrayant du paquet obtenu ladite partie copiée ; - encapsuler (506) le paquet modifié selon le protocole de transport avec acquittement.
5. 5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que, en cas de première vérification positive et deuxième vérification négative, le dispositif gestionnaire effectue une étape consistant à encapsuler (509) le paquet obtenu, selon le protocole de transport sans acquittement.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite au moins une catégorie prédéterminée appartient au groupe comprenant : - une catégorie (ACK) regroupant des paquets d'acquittement, transmis par le premier dispositif terminal pour indiquer au second dispositif terminal la réception d'un ou plusieurs paquets préalablement transmis par le second dispositif terminal ; et - une catégorie (PUSH) regroupant des paquets de transmission complète de données, transmis par le premier dispositif terminal pour indiquer au second dispositif terminal que des données utiles collectées par le second dispositif terminal doivent être transmises à une application de destination sans attendre d'éventuelles données utiles qui suivent.
7. 7. Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce que, si le paquet obtenu est un paquet d'acquittement, le dispositif gestionnaire effectue une étape consistant à effectuer (5031) une troisième vérification de si une des deux conditions suivantes est vérifiée : - vu du côté d'un équipement destination, ayant généré ledit paquet d'acquittement, une retransmission de données selon le protocole de transport passager est ou doit être enclenchée ;- vu du côté d'un équipement source, une retransmission de données selon le protocole de transport passager ne doit pas être enclenchée, même si ledit équipement source reçoit ledit paquet d'acquittement ainsi qu'un nouveau paquet créé par ladite phase de création de paquet (504, 510, 505, 506), et en ce que ladite phase de création de paquet (504, 510, 505, 506) est effectuée seulement en cas de première, deuxième et troisième vérifications positives.
8. 8. Procédé selon la revendication 7, caractérisé en ce que le dispositif gestionnaire effectue une étape consistant à effectuer (5031) une quatrième vérification de si les deux conditions suivantes sont vérifiées : - vu du côté dudit équipement destination, ayant généré ledit paquet d'acquittement, une retransmission de données selon le protocole de transport passager ne doit pas être enclenchée ; - vu du côté dudit équipement source, une retransmission de données selon le protocole de transport passager va devoir être enclenchée, si ledit équipement source reçoit ledit paquet d'acquittement, et en ce que, en cas de quatrième vérification positive, le dispositif gestionnaire effectue des étapes consistant à : - modifier le paquet obtenu en extrayant du paquet obtenu ladite partie copiée, pour obtenir un paquet modifié qui n'est pas un paquet d'acquittement ; - encapsuler le paquet modifié selon le protocole de transport avec acquittement.
9. 9. Procédé selon l'une quelconque des revendications 2 à 8, caractérisé en ce que le dispositif gestionnaire effectue une étape consistant à effectuer une cinquième vérification de si le paquet obtenu appartient à au moins une catégorie différente de ladite au moins une catégorie prédéterminée, et en ce que ladite phase de création de paquet (504, 510, 505, 506) est effectuée seulement en cas de première, deuxième et cinquième vérifications positives.
10. 10. Procédé selon la revendication 9, caractérisé en ce que ladite au moins une catégorie différente appartient au groupe comprenant : - une catégorie (SYN) regroupant des paquets d'initialisation de connexion entre lesdits dispositifs terminaux ; - une catégorie (FIN) regroupant des paquets d'indication de fin de transmission.
11. 11. Procédé selon l'une quelconque des revendications 2 à 10, caractérisé en ce que le dispositif gestionnaire effectue une étape consistant à effectuer (5032) une sixième vérification de s'il n'est pas déterminé une congestion sur un réseau transmettant ledit flux passager, et en ce que ladite phase de création de paquet (504, 510, 505, 506) est effectuée seulement en cas de première, deuxième et sixième vérifications positives.
12. 12. Procédé selon l'une quelconque des revendications 2 à 1l, caractérisé en ce que le dispositif gestionnaire effectue une étape consistant à effectuer (5033, 5034) une septième vérification de si un taux d'utilisation de ressources processeur dudit dispositif gestionnaire est inférieur ou égal à un seuil prédéterminé, et en ce que ladite phase de création de paquet (504, 510, 505, 506) est effectuée seulement en cas de première, deuxième et septième vérifications positives.
13. 13. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce qu'un tunnel comprenant des première et deuxième porteuses est mis en oeuvre entre lesdits premier et second dispositifs terminaux, en ce que ledit protocole de transport encapsulant avec acquittement est utilisé avec ladite première porteuse et ledit protocole de transport encapsulant sans acquittement est utilisé avec ladite deuxième porteuse, et en ce que ledit dispositif gestionnaire est une tête de tunnel placée entre le premier dispositif terminal et le tunnel.
14. 14. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 13, lorsque ledit programme est exécuté sur un ordinateur.
15. 15. Moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 13.
16. 16. Dispositif gestionnaire apte à participer à une transmission de paquets d'un flux de données bidirectionnel passager établi entre des premier et second dispositifs terminaux (108, 113), ledit flux passager étant conforme à un protocole de transport passager avec acquittement définissant une pluralité de catégories de paquet, ledit flux passager étant destiné à être encapsulé par un dispositif gestionnaire selon un protocole de transport encapsulant avec acquittement, 5caractérisé en ce que le dispositif gestionnaire comprend : - des moyens d'obtenir un paquet dudit flux passager transmis depuis le premier vers le second dispositif terminal ; - des moyens d'effectuer une première vérification de si le paquet obtenu appartient à au moins une catégorie prédéterminée parmi ladite pluralité de catégories de paquet ; - des moyens, activés en cas de première vérification positive, d'encapsuler au moins une partie des données dudit paquet obtenu, selon un protocole de transport encapsulant sans acquittement.