Brevet FR2960372A1 — publié le 20111125

Procédé de gestion d'un flux de données utiles passager, produit programme d'ordinateur, moyen de stockage et dispositif gestionnaire 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 gestion, par un dispositif gestionnaire, d'un flux de données passager transmis par un dispositif source vers un dispositif destination. On suppose que le flux passager est conforme à un protocole de transport passager avec acquittement et retransmission (TCP par exemple) et que des données utiles du flux sont stockées dans une mémoire tampon de retransmission, de taille mémoire prédéterminée, au sein du dispositif source avant transmission vers le dispositif destination. On suppose également que le flux passager est destiné à être encapsulé, par le dispositif gestionnaire, selon au moins un protocole de transport encapsulant (TCP et/ou UDP 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 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 les 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 TECHNOLOGIOUE Le document de brevet EP 2,020,799 décrit un réseau de type VPN comportant plusieurs porteuses, chacune de ces porteuses utilisant un protocole de transport encapsulant distinct. Dans la suite de la description, on désigne ce type de tunnel sous le terme de tunnel multi-transport. Chaque tête de tunnel dispose alors d'un ensemble de porteuses aux caractéristiques distinctes, afin d'adapter la transmission des données d'un réseau LAN à l'autre, aux besoins applicatifs ainsi qu'aux variations de conditions de transmission sur le réseau Internet. Le document de brevet EP 2,020,799 décrit un tunnel constitué de manière préférentielle d'une porteuse de type TCP et une porteuse de type UDP, utilisant respectivement le protocole TCP (pour « Transmission Control Protocol ») et le protocole UDP (pour « User Datagram Protocol ») comme protocoles de transport encapsulant. Le protocole TCP est un protocole de transport « fiable » (avec acquittement et retransmission), 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. Le protocole UDP est un protocole de transport simple (sans acquittement), sans connexion (c'est-à-dire qu'il fonctionne en mode paquet (mode « Datagram » en anglais)), permettant un débit optimal mais de délivrance 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 cadre d'un tunnel multi-transport, si l'on souhaite transmettre un flux passager conforme à un protocole de transport passager avec acquittement et retransmission (par exemple un flux passager TCP), la question qui se pose est de savoir quelle(s) porteuse(s) du tunnel (c'est-à-dire quel(s) protocole(s) de transport encapsulant) il convient d'utiliser. Il convient en effet d'optimiser la transmission du flux passager via le tunnel, notamment pour tenter de résoudre au moins un des problèmes suivants : - éviter des interactions destructrices entre le protocole de transport passager et le protocole de transport encapsulant ; - accélérer la transmission du flux passager, notamment en évitant ou réduisant une congestion d'acquittements. Le problème est que le protocole de transport passager peut interférer avec les mécanismes mis en oeuvre au niveau du protocole de transport encapsulant. Par exemple, si l'on considère le protocole TCP comme protocole de transport encapsulant, et le même protocole TCP comme protocole de transport passager (combinaison connue sous le nom de « TCP sur TCP » (« TCP-over-TCP » en anglais)), on est alors confronté dans certaines situations à des interactions destructrices entre les deux mécanismes de contrôle de congestion TCP. Pour plus de détails, on peut se reporter notamment au document suivant : « Understanding TCP over TCP: effects of TCP Tunnelling on Endto-end throughput and latency (O Honda, H Ohsaki, M. Imase, M. Ishizuka, J. Murayama). (Proceedings of the SPIE, volume 6011, pp 138-146 (Oct 2005) ». Une première réponse au problème des interactions destructrices peut être de dire que la combinaison « TCP sur TCP » n'est pas une bonne solution, et qu'il est préférable d'utiliser la combinaison « TCP sur UDP » (c'est-à-dire utiliser le protocole UDP comme protocole de transport encapsulant). Mais, cette solution n'est pas non plus adaptée à toutes les situations. En effet, sous certaines conditions il est bien connu que la combinaison « TCP sur TCP » dégrade les performances de la communication de bout en bout, mais dans d'autres conditions la même combinaison permet d'améliorer les performances de la communication de bout en bout (voir par exemple le document précité, ainsi que le document suivant : « Avoiding congestion collapse on the internet using TCP tunnels (B.P Lee, R.K Balan, L. Jacob, W.K.G Seah, A.L Ananda) (Computer Networks 39 (2002) pages 207-219, Dec 2002) ». Le document de brevet EP 2,020,799 propose une autre solution au problème des interactions destructrices, consistant à aiguiller dynamiquement les différents flux passagers du tunnel, sur l'une ou l'autre des au moins deux porteuses du tunnel, voire sur toutes à la fois, selon les conditions de communications sur le réseau et en fonction du protocole passager utilisé. Cette solution peut être vue comme un exemple d'agent PEP (pour « Performance Enhancing Proxy» en anglais), c'est-à-dire un exemple d'agent spécialisé destiné à améliorer la transmission via ce tunnel d'un flux passager conforme à un protocole passager avec acquittement et retransmission (TCP par exemple). A ce titre, on peut qualifier cette solution d'agent « PEP TCP ». Cette mise en oeuvre étant dans ce cas effectuée dans une tête de tunnel en entrée d'un tunnel de communication, on peut on peut plus particulièrement qualifier cette solution d'agent « PEP TCP pour tunnel de communication » Comme présenté plus en détail par la suite, en relation avec la figure 13, 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) et les segments de transmission complète de données (aussi appelés segments PUSH ou segments PSH). Les segments ACK permettent à deux machines (généralement appelées client et 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. Les segments PUSH permettent à 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 de retransmission TCP de la première machine). Dans le cas d'une transmission à travers un tunnel de niveau 2, la session TCP passagère 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 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 tampon de retransmission TCP (c'est-à-dire la mémoire de stockage tampon pour l'émission selon le protocole TCP) d'un serveur (113 par exemple) 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 » de 5 msec, et un débit de 100 Mbps. On appelle « temps de boucle » (ou RTT, pour « Round-Trip Time » en anglais) 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. Le RTT augmente très significativement lors de l'acheminement à travers un tunnel de niveau 2 (plusieurs centaines de millisecondes). Le flux passager 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 par exemple) 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 tampon de retransmission 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 VPN é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 transport encapsulant fiable (avec acquittement et retransmission, comme par exemple le protocole TCP), elle va entrer en retransmission automatique. Ceci aura pour effet de suspendre tous les flux passagers véhiculés via cette porteuse 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 une même porteuse 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 de flux TCP passagers, on rappelle que les paquets passagers 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 TCP 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 (du flux passager TCP) 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 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, il 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 tampon de retransmission 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) retarde 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 (du flux passager) 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. D'autres dommages peuvent apparaître de manière similaire pour des protocoles de transport avec acquittement et retransmission des données autres que le protocole TCP, et avec d'autres catégories de segments (ou paquets) que les segments ACK et les segments PUSH. La plupart des principes des protocoles à connexion de bout en bout reposent sur l'adjonction d'un agent PEP 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, 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 (c'est-à-dire un flux passager 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, la technique de filtrage des segments ACK proposée dans le document de brevet US 7,315,515 ne peut pas constituer une solution au problème précité (segments ACK ou PUSH bloqués dans la mémoire tampon de réception de la porteuse TCP, au sein de la tête de tunnel réceptrice 102). En effet, le filtrage des segments ACK réduit la congestion de la voie montante (en supprimant des segments à transmettre), et augmente donc la possibilité de transmettre des données suivant la voie descendante. Toutefois, dans le cas où le flux passager TCP considéré traverse un tunnel, la question de l'encapsulation reste posée. L'homme du métier utilisant classiquement une porteuse TCP pour encapsuler son flux passager, toute perte d'un segment passager quelconque sur le tronçon du tunnel, se traduit par un blocage de la porteuse, et donc un arrêt de la réception des segments ACK par le dispositif distant (et le fait d'en filtrer certains ne va pas débloquer ceux déjà en cours de transmission via la porteuse). Il en résulte donc un blocage du flux descendant, malgré la mise en oeuvre de la technique proposée, ce qui ne répond donc pas au problème posé. On notera en outre que 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 (aussi appelée session 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. Egalement, 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 un grand nombre de segment ACK est une opération agressive qui a des conséquences négatives sur cette phase de démarrage lent, au cours de laquelle le plus grand nombre possible de segments ACK doit être passé au dispositif source pour l'aider à rapidement augmenter sa fenêtre de congestion. Il existe donc un besoin de fournir un agent « PEP TCP pour tunnel de communication », permettant de résoudre le problème précité (segments ACK ou PUSH du flux passager TCP bloqués dans la tête de tunnel réceptrice), et donc d'améliorer la transmission via un tunnel de communication, d'un flux passager conforme à un protocole passager avec acquittement et retransmission (TCP par exemple). Dans la présente description, on appelle agents « PEP TCP pour tunnel de communication » tous les agents permettant d'améliorer la transmission, via un tunnel de communication, d'un flux passager conforme à un protocole passager avec acquittement et retransmission (TCP par exemple). La solution proposée dans le document de brevet EP 2,020,799 n'est qu'un exemple parmi d'autres d'un tel agent. Classiquement, si aucun « PEP TCP pour tunnel de communication » n'est activé, le flux passager TCP est encapsulé sur une unique porteuse du tunnel. Cette dernière, appelée ci-après porteuse par défaut, est généralement la porteuse UDP, mais on peut également envisager d'utiliser uniquement la porteuse TCP. 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. Au moins un mode de réalisation de l'invention a pour objectif de fournir une technique permettant d'accélérer la connexion de bout en bout entre des dispositifs source et destination d'un flux de données. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique permettant d'accroître la vitesse de transmission, après encapsulation, d'un flux de données passager transmis par un dispositif source vers un dispositif destination, le flux passager étant conforme à un protocole de transport passager avec acquittement et retransmission (TCP par exemple). Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant d'accroître la performance des agents de type « PEP TCP ». 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 le vidage de la mémoire tampon de retransmission du dispositif source. 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 dispositifs source et destination. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion d'un flux de données utiles passager transmis par un dispositif source vers un dispositif destination, le flux étant conforme à un protocole de transport passager avec acquittement et retransmission, des données utiles du flux étant stockées dans une mémoire tampon de retransmission, de taille mémoire prédéterminée, au sein du dispositif source avant transmission vers le dispositif destination. Un dispositif gestionnaire effectue des étapes consistant à : - obtenir un paquet relatif au flux et transmis par le dispositif source ou le dispositif destination ; - obtenir une première information, représentative d'un taux de perte de paquets sur au moins une partie d'un chemin de transmission entre les dispositifs source et destination ; - en fonction de la première information et de la taille mémoire, sélectionner un mode de transmission, parmi un premier mode de transmission utilisant un unique protocole de transport encapsulant par défaut, et un second mode de transmission utilisant un protocole de transport encapsulant sans acquittement et un protocole de transport encapsulant avec acquittement et retransmission ; - transmettre le paquet obtenu en activant le mode de transmission sélectionné. Le principe général de l'invention consiste donc à sélectionner un mode de transmission, en fonction au moins des paramètres suivants : le taux de perte de paquets et la taille de la mémoire tampon de retransmission du dispositif source. Ainsi, et comme détaillé par la suite, ces deux paramètres (auquel s'ajoute, dans une variante, la latence de transmission) permettent de prendre en compte les conditions particulières (c'est-à-dire les états de fonctionnement du réseau, pour différentes valeurs de la taille de la mémoire tampon de retransmission du dispositif source) dans lesquelles il est intéressant de sélectionner le second mode de transmission plutôt que le premier mode de transmission. Un tel mécanisme permet ainsi conjointement d'améliorer la vitesse de transmission et l'utilisation des ressources de traitement. En d'autres termes, la prise en compte des conditions du réseau et de la taille de la mémoire tampon de retransmission du dispositif source permet dynamiquement de déterminer l'opportunité d'utiliser le second mode de transmission (qui utilise différents protocoles de transport encapsulant) à la place du premier mode de transmission (mode par défaut utilisant un seul protocole de transport encapsulant). Le second mode de transmission correspond par exemple à l'activation d'un « PEP TCP pour tunnel de communication », s'appuyant sur une porteuse UDP et une porteuse TCP. Le premier mode de transmission correspond par exemple à l'activation d'aucun « PEP TCP pour tunnel de communication », le flux passager étant alors encapsulé sur une porteuse par défaut du tunnel (porteuse UDP ou porteuse TCP). Dans ce cas, la technique proposée permet un déclenchement sous condition d'un agent de type « PEP TCP pour tunnel de communication », prenant en compte les conditions particulières dans lesquelles celui-ci est intéressant. Ceci permet d'optimiser l'utilisation des agents de type « PEP TCP pour tunnel de communication ». La taille de la mémoire tampon de retransmission allouée au dispositif source est une donnée importante pour la performance globale de la transmission. En effet, lorsqu'un acquittement est reçu par le dispositif source, ce dernier réalise deux actions. La première consiste à augmenter sa fenêtre de congestion, ce qui lui permet d'augmenter son débit. La seconde, consiste à supprimer les paquets acquittés de sa mémoire tampon de retransmission (tant qu'un paquet n'est pas acquitté, celui-ci est conservé dans la mémoire tampon de retransmission du dispositif source, pour une éventuelle retransmission). Cette mémoire tampon de retransmission est évidemment de taille limitée. Dans un mode de réalisation particulier, le dispositif gestionnaire effectue une étape consistant à obtenir une deuxième information, représentative d'une latence de transmission sur au moins une partie d'un chemin de transmission entre les dispositifs gestionnaire et destination. L'étape consistant à sélectionner un mode de transmission est également fonction de ladite deuxième information. Ainsi, on améliore la sélection du mode de transmission, et on détermine plus précisément l'opportunité d'utiliser le second mode de transmission. De façon avantageuse, l'étape consistant à sélectionner un mode de transmission comprend des étapes consistant à : - obtenir au moins un seuil de basculement, correspondant à un taux de perte acceptable, variable en fonction de la taille de la mémoire tampon de retransmission ; - effectuer une comparaison de la première information obtenue avec ledit au moins un seuil de basculement obtenu ; - en fonction du résultat de la comparaison, sélectionner un des premier et second modes de transmission. Ceci permet une utilisation améliorée des ressources du dispositif gestionnaire, en ne déclenchant l'utilisation second mode de transmission (qui nécessite plus de ressources au sein du dispositif gestionnaire) que lorsque le bénéfice escompté est supérieur à un certain seuil. Cette valeur de seuil peut être configurée par un utilisateur pour tenir compte par exemple du surcoût d'activation du second mode de transmission, en termes d'utilisation de ressources (comme la mémoire ou le processeur) du dispositif gestionnaire. Avantageusement, ledit au moins un seuil de basculement varie également en fonction de la deuxième information obtenue. Ainsi, on améliore le résultat de l'étape d'obtention du ou des seuils de basculement. Selon une caractéristique avantageuse, deux seuils de basculement sont définis, un premier seuil de basculement étant utilisé pour basculer du premier au second mode de transmission et un second seuil de basculement pour basculer du second au premier mode de transmission. L'utilisation d'un système de type hystérésis, basé sur deux seuils permet de garantir une certaine stabilité du mécanisme de sélection d'un mode de transmission, aux fluctuations des conditions du réseau. Avantageusement, chaque seuil de basculement prend : - une première valeur si la deuxième information obtenue est représentative d'une latence de transmission inférieure à un seuil de latence ; et - une seconde valeur si la deuxième information obtenue est représentative d'une latence de transmission supérieure ou égale audit seuil de latence. Ainsi, on améliore le résultat de l'étape de sélection d'un mode de transmission. Dans mode de réalisation particulier, un tunnel comprenant des première et deuxième porteuses est mis en oeuvre entre le dispositif source et le dispositif destination ; le protocole de transport encapsulant avec acquittement et retransmission est utilisé avec la première porteuse et le protocole de transport encapsulant sans acquittement est utilisé avec la deuxième porteuse ; le dispositif gestionnaire est une tête de tunnel placée entre le dispositif source et le tunnel ou entre le tunnel et le dispositif destination. Ainsi, la présente invention s'applique particulièrement, mais non exclusivement, dans le cas où un tunnel est mis en oeuvre entre les dispositifs source et destination. Dans ce cas, l'invention propose un agent « PEP TCP pour tunnel de communication » pour des flux passagers (par exemple des connexions TCP) transmis via le tunnel. Cet agent vise à améliorer les performances de ces connexions de bout en bout. Dans une mise en oeuvre particulière du second mode transmission, ledit protocole de transport passager avec acquittement et retransmission définissant une pluralité de catégories de paquet. Si le second mode de transmission est sélectionné, l'étape consistant à transmettre le paquet obtenu en utilisant le mode de transmission sélectionné comprend des étapes consistant à : - 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 le protocole de transport encapsulant sans acquittement. Le principe général de cette mise en oeuvre particulière 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 paquet sélectionné, selon un protocole de transport encapsulant qui est sans acquittement (UDP par exemple), et non pas selon un protocole de transport encapsulant qui est avec acquittement et retransmission (TCP par exemple). Ainsi, cette mise en oeuvre particulière tire profit de ce que le protocole de transport encapsulant sans acquittement est plus rapide que le protocole de transport encapsulant avec acquittement et retransmission, 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, si le second mode de transmission est sélectionné, l'étape consistant à transmettre le paquet obtenu en utilisant le mode de transmission sélectionné comprend des étapes consistant à : - effectuer une deuxième vérification de si le paquet obtenu comprend des données utiles d'un autre flux de données utiles passager transmis par le dispositif destination vers le dispositif source, et en cas de première et deuxième vérifications positives : - 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 encapsulant sans acquittement ; - encapsuler les données utiles de l'autre flux, selon le protocole de transport avec acquittement et retransmission. Ainsi, (au moins) les données utiles continuent à bénéficier de la fiabilisation associée au protocole de transport encapsulant avec acquittement et retransmission. Avantageusement, l'étape consistant à encapsuler les données utiles de l'autre flux, selon le protocole de transport avec acquittement et retransmission, comprend une étape consistant à encapsuler le paquet obtenu selon le protocole de transport avec acquittement et retransmission. Cette réalisation basique est très simple car le paquet obtenu (paquet d'origine) est encapsulé intact selon le protocole de transport encapsulant avec acquittement et retransmission. En outre, elle optimise la fiabilisation puisque tout le paquet d'origine est encapsulé selon le protocole de transport encapsulant avec acquittement et retransmission. Avantageusement, l'étape consistant à encapsuler les données utiles de l'autre flux, selon le protocole de transport avec acquittement et retransmission, 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 et retransmission. Cette variante de réalisation permet de limiter la charge du médium de transport utilisé avec le protocole de transport encapsulant avec acquittement et retransmission (tout le paquet d'origine n'est pas transmis sur ce médium). En contrepartie, elle nécessite plus de ressources processeur que la réalisation basique puisqu'il faut modifier le paquet d'origine avant de l'encapsuler selon le protocole de transport encapsulant avec acquittement et retransmission. 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 et retransmission, on réduit la charge du médium de transport utilisé par celui-ci. Avantageusement, ladite au moins une catégorie prédéterminée appartient au groupe comprenant : - une catégorie (appelée ACK dans le cas du protocole TCP) regroupant des paquets d'acquittement, transmis par le dispositif destination pour indiquer au dispositif source la réception d'un ou plusieurs paquets de données utiles préalablement transmis par le dispositif source ; et - une catégorie (appelée PUSH dans le cas du protocole TCP) regroupant des paquets de transmission complète de données utiles, transmis par le dispositif source pour indiquer au dispositif destination que des données utiles collectées par le dispositif destination 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 à au dispositif source (émetteur des segments de données auxquels sont relatives les informations d'acquittement) de libérer plus vite sa mémoire tampon de retransmission. 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 et retransmission), 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 et retransmission utilise un deuxième medium (porteuse TCP par exemple) : - s'il n'y a pas eu de perte sur la première porteuse, le dispositif source (é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 du dispositif source 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 et retransmission (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 de retransmission du dispositif source 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 du dispositif source précité. Il est à noter que pour un même taux de perte sur le réseau, le dispositif 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 le dispositif source 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 et retransmission), on multiplie d'autant la capacité d'émission du dispositif 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 au dispositif source (émetteur de ce paquet de la catégorie PUSH) d'alerter plus vite le dispositif destination (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, le flux est destiné à être encapsulé par le dispositif gestionnaire selon un protocole de transport avec acquittement et retransmission avant d'être transmis au dispositif destination, et en ce que des données d'acquittement du flux sont encapsulées selon un protocole de transport sans acquittement. De manière préférentielle, lesdites données d'acquittement sont dupliquées pour être transmises, par le dispositif gestionnaire, à la fois selon le protocole de transport avec acquittement et retransmission et selon le protocole de transport sans acquittement.. De manière préférentielle, le protocole de transport avec acquittements et retransmission est le protocole TCP (on réalise une transmission du type TCP-sur-TCP) et le protocole de transport sans acquittements est le protocole UDP (on réalise une transmission du type TCP-sur-UDP). Dans un autre mode de réalisation de l'invention, il est proposé un produit programme d'ordinateur comprenant 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 de l'invention, il est proposé 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 de l'invention, il est proposé un dispositif gestionnaire, adapté pour gérer un flux de données utiles passager transmis par un dispositif source vers un dispositif destination, le flux étant conforme à un protocole de transport passager avec acquittement et retransmission, des données utiles du flux étant stockées dans une mémoire tampon de retransmission, de taille mémoire prédéterminée, au sein du dispositif source avant transmission vers le dispositif destination, ledit dispositif gestionnaire étant caractérisé en ce qu'il comprend : - des moyens pour obtenir un paquet relatif au flux et transmis par le dispositif source ou le dispositif destination ; - des moyens pour obtenir une première information, représentative d'un taux de perte de paquets sur au moins une partie d'un chemin de transmission entre les dispositifs source et destination ; - des moyens pour sélectionner, en fonction de la première information et de la taille mémoire, un mode de transmission parmi un premier mode de transmission utilisant un unique protocole de transport encapsulant par défaut, et un second mode de transmission utilisant un protocole de transport encapsulant sans acquittement et un protocole de transport encapsulant avec acquittement et retransmission ; - des moyens pour transmettre le paquet obtenu en activant le mode de transmission sélectionné. Avantageusement, le dispositif gestionnaire comprend des moyens de mise en oeuvre des étapes qu'il effectue dans le procédé de gestion 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 ; 25 - 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 représente une courbe en 3 dimensions représentant, pour une valeur particulière de la taille de la mémoire tampon de retransmission du dispositif source, le gain d'activation d'un module PEP (référencé 415 sur la figure 4) pour différentes conditions réseau ; - la figure 6 représente une courbe de gain nul, séparant deux zones : l'une où l'activation du module PEP apporte un gain positif par rapport à l'utilisation uniquement de la porteuse UDP, et l'autre où c'est l'inverse ; - la figure 7 représente deux courbes de gain nul, obtenues chacune pour une valeur distincte de la taille de la mémoire tampon de retransmission du dispositif source (qui transmet un flux TCP passager), de façon à montrer l'influence de ce paramètre ; - la figure 8 présente un organigramme d'un algorithme de gestion d'une table des flux passagers, mis en oeuvre par une tête de tunnel émettrice de flux de données passagers, selon un mode de réalisation de l'invention ; - la figure 9 présente un organigramme d'un algorithme de gestion de l'activation/désactivation du module PEP, mis en oeuvre par une tête de tunnel émettrice de flux de données passagers, selon un mode de réalisation de l'invention basé sur un mécanisme de type hystérésis ; - la figure 10 illustre le mécanisme de type hystérésis sur lequel est basé l'algorithme de la figure 9 ; - la figure 11 présente un organigramme d'un algorithme de sélection de porteuse mis en oeuvre essentiellement par le module PEP quand il est activé, selon un mode de réalisation de l'invention ; 30 - la figure 12 présente un organigramme détaillant un mode de réalisation particulier de l'étape de test 1103 de la figure 11 ; et - la figure 13 illustre schématiquement la structure classique d'un segment TCP. 6. DESCRIPTION DÉTAILLÉE On rappelle maintenant, en relation avec la figure 13, 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 client et le serveur, l'une de ces deux machines est appelée « dispositif source » (générant les données principales du flux) et l'autre « dispositif destination » (recevant les données principales du flux et les acquittant auprès du dispositif 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 du dispositif destination. En général, conformément au contrôle de flux, le dispositif destination fixe une limite au débit de transmission mis en oeuvre par le dispositif source qui envoie des données au dispositif destination. Le dispositif source et le dispositif 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 le dispositif source ne commence à envoyer des paquets, il envoie une requête au dispositif destination visant à obtenir la permission de commencer la transmission. En réponse à cette requête, le dispositif destination envoie un message comprenant une identification du nombre de paquets que le dispositif source peut transmettre au dispositif destination sans autorisation supplémentaire. Ce nombre est communément appelé "taille de fenêtre". Alors, le dispositif source transmet le nombre de paquets autorisés au dispositif destination et attend que le dispositif destination vérifie leur réception. Après que le dispositif destination a reçu avec succès un paquet, il envoie un message en retour au dispositif source comprenant un accusé de réception (acquittement) indiquant que le paquet a été reçu avec succès et, dans certains cas, autorisant le dispositif source à envoyer un autre paquet. De cette façon, le nombre de paquets sur le réseau transitant depuis le dispositif source vers le dispositif 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 le dispositif source TCP et non encore acquittées par le dispositif destination TCP. La taille de cette fenêtre conditionne donc le débit maximum de la session TCP en cours. En effet, le dispositif 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 au dispositif destination, et à l'acquittement correspondant d'être émis en retour et d'être reçu par le dispositif source). Le dispositif 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 du dispositif source TCP), et le numéro d'acquittement (représentant le numéro de séquence du dispositif destination). La figure 13 illustre schématiquement la structure classique d'un segment TCP 1300. Le segment TCP comprend deux parties : la première correspond à l'en-tête TCP 1301, la seconde correspond aux données utiles (aussi appelées données à transporter) 1302. 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 1301 comprend les champs suivants : - un champ 1303 pour le numéro de port de l'application source ; - un champ 1304 pour le numéro de port de l'application destination ; - un champ 1305 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 1306 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 1307 indiquant la longueur de cet en-tête TCP. Une valeur supérieure à 20 octets indique la présence d'options (voir le champ 1312 décrit ci-après) ; - un champ de contrôle 1308 comprenant six bits de contrôle 13081 à 13086, 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 1300 (voir le tableau ci-dessous). En d'autres termes, les six bits de contrôle 13081 à 13086 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 » 1311 doit être exploité. ACK Le champ « numéro d'acquittement » 1306 est valide et doit être exploité. PSH (ou C'est une notification du dispositif source au dispositif PUSH) destination, pour lui 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 retransmission). RST Réinitialisation de la connexion. SYN Initialisation de la connexion. Le champ « numéro de séquence de données » 1305 contient la valeur de début de connexion. FIN Le dispositif source qui a émis ce segment TCP a fini d'émettre. - un champ 1309 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 1310 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 1311 pour un pointeur d'urgence, qui n'est valide que si le drapeau URG est armé (c'est-à-dire à 1). Ce champ 1311 contient alors un décalage (« offset » en anglais) à ajouter à la valeur du numéro de séquence de données (contenue dans le champ 1305) du présent segment 1300 pour délimiter une zone des données urgentes à transmettre à l'application ; - un champ 1312 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 1300 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 (selon la norme RFC 2018). Cette option vise à offrir une information plus riche pour effectuer les retransmissions de données. En effet, les acquittements (ACKs) positifs cumulatifs fournissent une 20 information limitée : un dispositif source TCP 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 10 15 d'un tunnel de communication entre deux réseaux LAN, afin de permettre l'échange de données multimédia entre des équipements réseaux de chacun de ces réseaux LAN. Néanmoins, l'application de la présente invention n'est nullement limitée à ce scénario de mise en oeuvre. En effet, la présente invention s'applique de manière générale à toute transmission où une encapsulation des données peut être effectuée entre une application génératrice de données selon un protocole de transport avec acquittement et retransmission des données et une application consommatrice de ces données. 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 »). 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 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 virtuel 210 émulant un contrôleur Ethernet. Une couche d'interface de réseau virtuel 210 est créée pour chaque tunnel instancié par l'application 200. L'application 200 remet à cette couche d'interface de réseau virtuel 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 à 12. Les trames reçues de la couche d'interface de réseau virtuel 210, après traitement par l'application 200, sont remises sous la forme de paquets à travers une d'interface applicative (« socket » 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és 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 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 ail, March 2005) et la norme RFC-2246 (« The TLS Protocol Version 1.0 ») ; - 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). 20 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 (le tunnel 100 25 comporte plusieurs porteuses utilisant chacune un protocole de transport encapsulant, 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. 10 15 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 par exemple être constitué de porteuses selon d'autres protocoles de couche transport selon le modèle OSI (tel que les protocoles DCCP, SCTP, discutés brièvement ci-dessous), et ayant ou non des protocoles de sécurisation associés (tels que les protocoles TLS, 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 norme 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 retransmission, 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 la norme RFC 4340. Il fournit des connexions bidirectionnelles de type envoi individuel (« unicast » en anglais) avec le support d'un contrôle de congestion (comme le protocole TCP) pour un service de messages non fiable (comme le protocole 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 passager, transporté via le tunnel 100, est considéré pour les besoins illustratifs. Cependant, plusieurs flux 20 25 30 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 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 le rythme de distribution des paquets 402 peut être différent de celui du flux 401, du fait de possibles latences fluctuantes des porteuses 100A et 100B du tunnel multi-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 du 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. Dans un mode de réalisation préféré (illustré par la suite en relation avec les figures 11 etl2), 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 le dispositif destination concerné 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 ; ^ un module déclencheur 440 ; ^ une base d'expérience 450 ; et ^ une table des flux passagers 451. 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 ce flux 401 au module déclencheur 440. Le module déclencheur 440 permet d'optimiser le déclenchement (c'est-à-dire l'activation) du module PEP 415, en évaluant à l'avance (par exemple grâce à un abaque déterminé en laboratoire par le constructeur et dont les caractéristiques sont stockées dans la tête de tunnel à la fabrication) le gain potentiellement apporté par le module PEP 415 versus la consommation de ressources nécessaire dans la tête de tunnel, et la quantité de ressources disponibles. Le module déclencheur 440 utilise la base d'expérience 450 qui contient les performances de l'utilisation du module PEP 415 pour différentes conditions de réseau (supportant le tunnel 100), et différentes capacités de mémoire tampon de retransmission du dispositif émetteur. Le module déclencheur 440 utilise également la table des flux passagers 451, qui contient tous les flux passagers en cours de transmission sur le tunnel, ainsi que des informations sur ces flux. Un mode de réalisation particulier de l'algorithme mis en oeuvre par le module déclencheur 440 est plus amplement décrit par la suite, en relation avec la figure 9. Un exemple d'algorithme de gestion de la table 451 par le module d'identification de flux 411 est plus amplement décrit par la suite, en relation avec la figure 8. 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, dans un mode de réalisation préféré (illustré par la suite en relation avec les figures 11 etl2), les informations relatives à des segments ACK et PUSH). Dans ce mode de réalisation préféré, le module PEP 415 peut en outre être en charge de créer (via un module de génération 4151) de nouveaux segments TCP passagers (aussi appelés 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 de manière à accélérer la transmission des informations qu'ils contiennent. 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. 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 local les paquets du flux 402 obtenu en sortie du tunnel. La figure 5 représente une courbe en 3 dimensions représentant, pour une valeur particulière de la taille (Cbuff) de la mémoire tampon de retransmission du dispositif source, le gain d'activation du module PEP (référencé 415 sur la figure 4) pour différentes conditions réseau. Cette courbe est donc l'une des courbes stockées dans la base d'expérience 450. Le contenu de cette base d'expérience est par exemple obtenu grâce à une série de mesures effectuées au préalable. Dans une variante, il est possible d'utiliser un mécanisme d'apprentissage mis en oeuvre par la tête de tunnel implémentant l'invention. Dans ce cas, la tête de tunnel comprend un récepteur de statistiques (par exemple au sein du module d'aiguillage 412) capable de déterminer les performances obtenues lors d'une transmission, et est ainsi capable de moduler les valeurs de gain stockées dans la base d'expérience 450. Il suffit pour cela que la tête de tunnel garde en mémoire les performances (débit) d'une transmission entre deux dispositifs, ainsi que les conditions réseaux (latence, taux de perte), et remplisse ainsi une base de données des performances permettant par la suite de déterminer les gains, en comparant les performances avec ou sans activation du module PEP 415 (entre les deux mêmes dispositifs), pour des conditions de réseau proches (mêmes valeurs de latence à 10% près par exemple). La figure 5 décrit une surface en trois dimensions 500, représentative du gain en pourcentage entre : - le temps de transmission d'un fichier (de taille donnée), via le tunnel 100, en utilisant un premier mode de transmission basé sur l'utilisation d'une unique porteuse par défaut (par exemple la porteuse UDP). Dans ce premier mode de transmission, le module PEP 415 est désactivé ; et - le temps de transmission du même fichier, via le tunnel 100, en utilisant un second mode de transmission, dans lequel le module PEP 415 est désactivé, et donc basé sur l'utilisation des porteuses UDP et TCP (voir figures 11 et 12). Sur la figure 5, on trouve en abscisse la latence mesurée entre les deux têtes de tunnel 101 et 102, et en ordonnée le taux de perte de paquet mesuré entre ces mêmes têtes de tunnel. Il est à noter que pour une plus grande clarté de la représentation graphique, une échelle logarithmique a été utilisée à la fois pour l'axe des abscisses et pour l'axe des ordonnées. L'axe des abscisses est gradué en millisecondes (ms) de 0.lms à 200ms. Cette latence correspond au temps mis pas un paquet, émis par une première tête de tunnel, pour atteindre la deuxième tête de tunnel. On peut noter que cette latence correspond à RTT/2. Avec une plage de RTT de 0.2ms à 400ms, l'ensemble des valeurs courantes, de latences constatées sur un réseau, sont couvertes. L'axe des ordonnées est gradué en pourcentage (%) de 0.01% à 5%. Ceci correspond à une plage de taux de perte de paquet couvrant les cas « classiques » d'usage constatés par exemple sur une connexion à l'Internet. Cette figure 5 représente également un plan 501 matérialisant la valeur de gain nul (gain=0%). Pour la partie de la courbe en trois dimensions 500 située au-dessus du plan 501, le gain est supérieur à 0, ce qui signifie que le second mode de transmission (module PEP 415 activé) est plus rapide que le premier mode de transmission (module PEP 415 désactivé ; utilisation de la seule porteuse UDP). Inversement, pour la partie de la courbe en trois dimensions 500 située au-dessous du plan 501, le gain est inférieur à 0, ce qui signifie que le second mode de transmission (module PEP 415 activé) est moins rapide que le premier mode de transmission. Enfin, la projection sur le plan xy de l'intersection entre le plan 501 et la courbe en trois dimensions 500 définit une courbe en deux dimensions 502. Pour la suite de la description, il est important de noter qu'une courbe similaire à la courbe en deux dimensions 502 (mais translatée) est obtenue pour une valeur de gain supérieure (par exemple 10%). Ces deux courbes obtenues pour des gains de 0% et 10%, sont représentées sur la figure 10 (elles y sont référencées 1001 et 1002). La figure 6 représente une courbe de gain nul 502, séparant deux zones : l'une (située au-dessus de la courbe 502) où l'activation du module PEP 415 apporte un gain positif par rapport à l'utilisation uniquement de la porteuse UDP (module PEP 415 désactivé), et l'autre (située entre la courbe 502 et l'axe des abscisses) où c'est l'inverse. La courbe 502 représente donc un ensemble de couples (latence, taux de perte), pour chacun desquels le temps de transmission d'un fichier en utilisant un protocole TCP passager (via FTP par exemple) est le même que l'on utilise le premier mode de transmission (utilisation de la porteuse UDP ; module PEP 415 désactivé) ou le second mode de transmission (utilisation des porteuses UDP et TCP ; module PEP 415 activé). La figure 6 présente également en pointillé, une première façon d'approximer la courbe 502, en utilisant trois segments de droite (deux segment horizontaux 603 et 605, et un segment vertical 604). Dans ce cas, le segment vertical 604 correspond à une valeur de latence définissant un seuil de latence S,atence. On peut bien évidemment concevoir d'autres façons d' approximer cette courbe 502, en utilisant par exemple ses asymptotes, ou bien encore une courbe représentant une expression polynomiale passant par un certain nombre de points de la courbe 502 (voire tous les points de mesure). La figure 7 représente deux courbes de gain nul 502, 602, obtenues chacune pour une valeur distincte de la taille (Cbuff) de la mémoire tampon de retransmission du dispositif source, de façon à montrer l'influence de ce paramètre. La courbe 602 est obtenue avec une valeur de taille mémoire (Cbuff) inférieure à celle avec laquelle est obtenue la courbe 502. Cette figure montre ainsi comment ce paramètre Cbuff est pris en compte dans le stockage des valeurs de gains dans la base d'expérience 450. En effet, pour chaque valeur d'un sous-ensemble de valeurs de Cbuff (par exemple 16 kilo-octets, 32 kilo-octets, 64 kilo-octets, etc. jusqu'à 1Méga-octet par exemple), la base d'expérience 450 contient une courbe de gain nul. La figure 8 présente un organigramme d'un algorithme de gestion de la table des flux passagers 451, mis en oeuvre par la tête de tunnel émettrice du flux de données passager 401, selon un mode de réalisation de l'invention. Plus précisément, l'algorithme de la figure 8 est mis en oeuvre par le module d'identification de flux 411, lorsque ce dernier reçoit un paquet. Comme indiqué auparavant, le module d'identification de flux 411 est en charge de déterminer la nature des flux à transporter, et en particulier, dans le cas qui nous occupe, ce module 411 permet d'identifier les flux passagers de type TCP. Lors de la détection d'un nouveau flux passager TCP, le module d'identification 411 va ainsi ajouter une ligne à la table des flux passagers 451, en indiquant dans cette table, pour le nouveau flux passager TCP, la valeur de la taille de la mémoire tampon de retransmission du dispositif émetteur pour ce flux (cette valeur est transmise dans le champ « windows size » de l'entête TCP lors de la demande d'ouverture d'une nouvelle session TCP (trame avec le bit SYN à 1). Chaque flux pouvant être identifié de façon unique grâce au quadruplet d'informations (adresse IP source, port TCP source, adresse IP destination, port TCP destination) issu de la trame de demande d'ouverture de session TCP. Dans l'étape 820, on détermine, par analyse de l'entête IP, si le paquet courant est un paquet TCP. Si c'est le cas, l'étape 822 est exécutée, sinon, l'algorithme s'arrête. Dans l'étape 822, on détermine, par analyse de l'entête TCP, si le paquet courant est une demande d'ouverture d'un nouveau flux passager (c'est-à-dire une nouvelle session passagère) (bit SYN à 1). Si c'est le cas, l'étape 823 est exécutée, sinon l'étape 824 est exécutée. Dans l'étape 823, on détermine les informations d'identification unique du flux passager (adresse IP source, port TCP source, adresse IP destination, port TCP destination), ainsi que la taille de la mémoire tampon de retransmission du dispositif émetteur, disponible pour le flux passager en cours d'ouverture. Puis, dans cette même étape 823, on ajoute ces informations à la table 451. Dans l'étape 824, on détermine si le paquet courant indique la fin d'un flux TCP passager. Pour cela, le bit FIN de l'entête TCP est analysé (bit FIN à 1 correspond à une 25 30 demande d'acquittement de fin de session). Si l'étape 824 est positive, l'étape 825 est exécutée, sinon l'algorithme s' arrête. Dans l'étape 825, on détermine les informations d'identification uniques du flux (adresse IP source, port TCP source, adresse IP destination, port TCP destination), puis on supprime l'enregistrement (c'est-à-dire la ligne) correspondant dans la table 451. Puis l'algorithme s' arrête. La figure 9 présente un organigramme de l'algorithme de gestion de l'activation/désactivation du module PEP 415, mis en oeuvre par une tête de tunnel émettrice de flux de données passagers, selon un mode de réalisation de l'invention basé sur un mécanisme de type hystérésis. Plus précisément, l'algorithme de la figure 9 est mis en oeuvre par le module déclencheur 440. Pour sa mise en oeuvre, l'algorithme de décision décrit ci après, nécessite l'utilisation d'une valeur MPA (pour « Mode PEP Actif »). MPA est une valeur binaire (vraie ou fausse), utilisée comme moyen de communication entre le module déclencheur 440 et le module d'aiguillage 412. Lorsque le module d'aiguillage 412 doit transmettre un paquet passager de type TCP, cette valeur MPA lui indique s'il doit ou non coopérer avec le module PEP 415 (c'est-à-dire si ce dernier est activé et doit lui indiquer sur quelle porteuse, UDP ou TCP, il doit transmettre le paquet). Lorsque MPA est à vrai, le module PEP 415 est activé, sinon, il est désactivé. Cette valeur MPA peut par exemple être inscrite dans un registre accessible à la fois par le module déclencheur 440 et le module d'aiguillage 412. L'algorithme de décision de la figure 9, mis en oeuvre par le module déclencheur 440, est par exemple exécuté lors de la réception (étape 900) de chaque paquet par le module d'identification 411. Une alternative est de considérer qu'une décision prise (lors de la réception d'un paquet par le module d'identification 411) est valable pendant un intervalle de temps, par exemple fixé par l'utilisateur (typiquement, une valeur de quelques secondes peut être considérée). Durant cet intervalle, la réception de nouveaux paquets ne déclenche pas à nouveau l'algorithme de décision, et la valeur de MPA n'est donc pas modifiée. L'objectif de cette variante est d'éviter une surconsommation des ressources de calcul. Dans l'étape 901, on détermine la valeur courante du RTT sur le tunnel 100, en interrogeant par exemple la porteuse TCP 100A. Suivant la méthode utilisée pour stocker les informations dans la base d'expérience 450, la valeur du RTT pourra être approximée à la valeur la plus proche connue dans la base d'expérience (cas où la base d'expérience est constituée de tableaux stockant les données de performances pour chaque couple : latence (c'est-à-dire RTT/2), taux de perte. Si, suivant la variante discutée plus haut, les courbes de types 502 sont approximées par des fonctions mathématiques (segments de droites, ou fonctions polynomiales par exemple), dont les caractéristiques sont stockées dans la base d'expérience 450, la valeur du RTT ne sera pas approximée. Dans l'étape 902, on détermine le taux de perte sur le tunnel, encore une fois, par exemple, en interrogeant la porteuse TCP 100A, ou par la mise en place de retour d'informations de pertes subies par les transmissions effectuées sur la porteuse UDP 100B. Dans l'étape 903, on détermine la taille (Cbuff) de la mémoire tampon de retransmission du dispositif émetteur, qui est définie pour le flux passager TCP en cours (c'est-à-dire le flux auquel appartient le paquet reçu à l'étape 900), par lecture de la table des flux passagers 451. Ensuite, dans l'étape 904, on détermine, pour la valeur de RTT courante sur le tunnel, deux seuils Thl et Th2, correspondant respectivement à une valeur minimale de taux de perte de paquet Emaxl et Emax2. Emaxl est la valeur d'une fonction Fcbuff,gain(RTT) pour la valeur de Cbuff déterminée à l'étape 903, et une première valeur de gain G1 (typiquement, G1=0). Ce premier seuil Thl indique donc au-dessus de quelle valeur de taux de perte, un gain supérieur à G1 peut être obtenu. De façon similaire, le seuil Th2 est déterminé comme étant la valeur minimale de taux de perte de paquet au-dessus de laquelle un gain supérieur à une deuxième valeur de gain G2 (typiquement, G2=10%) peut être obtenu. Ces deux seuils Thl et Th2 permettent de mettre en place un mécanisme permettant de déterminer si l'on doit ou non changer le mode de transmission du tunnel (module PEP 415 Actif ou pas). Ce mécanisme se rapproche d'un mécanisme de type hystérésis. Il permet de garantir une certaine stabilité de la décision. Pour cela, les étapes 905 à 909 sont réalisées. Bien sûr, il est possible de décider l'activation du PEP 415 en utilisant un seuil unique Th. Dans un premier mode de réalisation, les valeurs de gain peuvent être fixées par l'utilisateur. Dans un second mode de réalisation, on peut rendre ces valeurs dynamiques, en corrélant par exemple le gain aux ressources disponibles (plus les ressources sont importantes, et plus on peut se permettre d'activer le module PEP 415 pour un faible gain ; si les ressources sont rares, seul un gain important pourra justifier d'activer le module PEP 415). Dans l'étape 905, on détermine si le module PEP 415 est actif ou non (par examen de la variable MPA). Si l'étape 905 a déterminé que le module PEP 415 est actif, l'étape 907 est réalisée, sinon l'étape 906 est réalisée. Dans l'étape 907, on détermine si la valeur courante du taux de perte de paquet est inférieure au premier seuil Thl. Si cette condition est réalisée, le mode de transmission reste inchangé, sinon le module PEP 415 est désactivé (passage de la variable MPA à faux) grâce à l'étape 909. Puis l'algorithme s'arrête. Dans l'étape 906, on détermine si la valeur courante du taux de perte de paquet est supérieure au deuxième seuil Th2. Si cette condition est réalisée, le mode de transmission reste inchangé, sinon l'étape 908 est réalisée, et le module PEP 415 est activé (variable MPA passe à vrai). Ensuite, l'algorithme s'arrête. La figure 10 illustre le mécanisme de type hystérésis sur lequel est basé l'algorithme de la figure 9. Les courbes 1001 et 1002 représentent respectivement des courbes de type 502 (voir figure 5 à 7), pour des valeurs de gain de 0% et 10%. La courbe 1003 représente l'évolution des conditions réseau au cours du temps (ensemble de couples : latence (c'est-à-dire RTT/2), taux de perte. La courbe 1003 est constituée de deux types de pointillés, indiquant l'état du module PEP 415 (voir légende). On voit donc, sur cette figure 10, l'effet de l'invention, puisque dans un premier temps le seuil de 10% de gain n'étant pas atteint, le module PEP 415 est désactivé, malgré une évolution des conditions réseau (RTT et taux de perte), puis, en passant par le point A (point situé à l'intersection des courbes 1001 et 1003) la courbe 1003 change de type de pointillé, indiquant ainsi que le module PEP 415 est activé. Enfin, dans cet exemple, le module PEP 415 sera désactivé plus tard, lorsque le gain escompté de l'activation du module PEP 415 repassera sous la barre des 0% au point B. La figure 11 présente un organigramme d'un algorithme de sélection de porteuse mis en oeuvre par le module PEP 415 quand il est activé (à l'exception de l'étape 1100, qui réalisée par le module d'identification de flux 411), selon un mode de réalisation de l'invention. A titre d'exemple, on considère à nouveau uniquement la transmission du flux passager TCP 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 11 illustre le fonctionnement du bloc émetteur 410 de la tête de tunnel 101. L'étape 1100, 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 de données 401 utilisant un protocole de transport avec acquittement et retransmission. 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 1101 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 1101, 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 13082 et 13083 de l'en-tête TCP présenté à la figure 13. 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 1107 dans laquelle le segment TCP reçu est directement transmis au module d'aiguillage 412 (qui utilise alors par exemple une porteuse par défaut, de type TCP ou UDP). 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 1102 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 1302 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 1302 non vide selon la figure 13). Si l'étape de test 1102 conduit à déterminer que le segment reçu ne contient pas de donnée utile, on vérifie à l'étape 1111 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 1109 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 de retransmission TCP du dispositif source TCP. Il est important que ce segment arrive rapidement au dispositif destination, mais en conservant une fiabilité. C'est pourquoi l'étape 1110 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 1105 est exécutée. Si l'étape de test 1102 conduit à déterminer que le segment TCP reçu contient des données utiles, l'étape de test 1103 est mise en oeuvre. Cette étape de test 1103, détaillée en rapport avec la figure 12, 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 1104 ou 1110, et 1105, 1106), si une ou plusieurs conditions sont vérifiées. Si le résultat de l'étape de test 1103 est positif, on passe à l'étape 1108. Sinon, on passe à l'étape 1107 dans laquelle le segment TCP est transmis directement au module d'aiguillage 412 (qui utilise alors par exemple une porteuse par défaut, de type TCP ou UDP). Dans l'étape 1108, on vérifie si le segment reçu contient un drapeau PSH positionné (bit correspondant 13083 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 au dispositif destination TCP qu'il doit transmettre les données reçues aux couches supérieures (afin de libérer la mémoire tampon de retransmission TCP du dispositif source TCP, ou en fin de transmission d'un bloc de données). On passe alors à l'étape 1110 précédemment décrite, qui vise à dupliquer entièrement ce segment. Ensuite, les étapes 1105 et 1106 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 1101 a préalablement indiqué qu'il s'agissait d'un segment ACK et/ou PSH), alors l'étape 1104 est mise en oeuvre, puis les étapes 1105 et 1106. Dans l'étape 1104, 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 13082), parmi les drapeaux de l'en-tête TCP ; - modification de la valeur contenue dans le champ de numéro de séquence 1305, 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 1301, et mise à jour du champ « somme de contrôle » 1310. On notera qu'avant d'être mis à jour, tout l'en-tête TCP 1301 est copié, y compris le champ d'options 1312. 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 1105, le nouveau segment créé à l'étape 1104 ou 1110 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 1106, 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 1104, 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, 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 12 présente un organigramme détaillant un mode de réalisation particulier de l'étape de test 1103 de la figure 11. L'étape 11031 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 quadruplet {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 1102, par lecture du champ « Numéro d'acquittement » 1306) ; - le nombre de fois que ce segment ACK a été reçu (mis à jour par l'étape 1102), 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 1105), noté ND. Ainsi, l'étape de test 11031 est positive, et on passe à l'étape 11032, si l'une des conditions suivantes est vérifiée : - condition 1 : « NR S+1 » (ce qui signifie que, vu du côté du dispositif destination TCP, une procédure de retransmission selon le protocole de transport passager est ou doit être enclenchée), alors le dispositif destination TCP du flux passager veut avertir le dispositif 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 Par exemple, on peut appliquer la procédure suivante (pour un même segment ACK) : Index de NR Action ND Nmax Segment ACK d')rigine reçu #1 1 Condition 2 vérifiée : autorisation d'exécuter 0 2 l'étape 1108 (transmission du segment ACK d'origine et d'un segment ACK créé) #2 2 Conditions 1 et 2 non vérifiées : exécution de 1 3 (i DUP ACK) l'étape 1107 (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 1 3 (2'' DUP ACK) du 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 1107 (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 1 5 (3'' DUP ACK) 1108 (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 le dispositif 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 du dispositif 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 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 1108, 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. Toutes les étapes des algorithmes des figures 8, 9, 11 et 12 peuvent être mises en oeuvre indifféremment : - par exécution d'un jeu d'instructions informatiques exécuté par une machine de calcul reprogrammable, telle 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).5 REVENDICATIONS1. Procédé de gestion d'un flux de données utiles passager transmis par un dispositif source vers un dispositif destination, le flux étant conforme à un protocole de transport passager avec acquittement et retransmission, des données utiles du flux étant stockées dans une mémoire tampon de retransmission, de taille mémoire prédéterminée, au sein du dispositif source avant transmission vers le dispositif destination, caractérisé en ce qu'un dispositif gestionnaire effectue des étapes consistant à : - obtenir (900) un paquet relatif au flux et transmis par le dispositif source ou le dispositif destination ; - obtenir (902) une première information, représentative d'un taux de perte de paquets sur au moins une partie d'un chemin de transmission entre les dispositifs source et destination ; - en fonction de la première information et de la taille mémoire, sélectionner (904 à 909) un mode de transmission, parmi un premier mode de transmission utilisant un unique protocole de transport encapsulant par défaut, et un second mode de transmission utilisant un protocole de transport encapsulant sans acquittement (UDP) et un protocole de transport encapsulant avec acquittement et retransmission (TCP) ; - transmettre le paquet obtenu en activant le mode de transmission sélectionné. 2. Procédé selon la revendication 1, caractérisé en ce que le dispositif gestionnaire effectue une étape consistant à obtenir (901) une deuxième information, représentative d'une latence de transmission sur au moins une partie d'un chemin de transmission entre les dispositifs gestionnaire et destination, et en ce que l'étape consistant à sélectionner un mode de transmission est également fonction de ladite deuxième information. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que l'étape consistant à sélectionner un mode de transmission comprend des étapes consistant à : - obtenir (904) au moins un seuil de basculement (1001, 1002), correspondant à un taux de perte acceptable, variable en fonction de la taille de la mémoire tampon de retransmission ;- effectuer une comparaison (906, 907) de la première information obtenue avec ledit au moins un seuil de basculement obtenu ; - en fonction du résultat de la comparaison, sélectionner (908, 909) un des premier et second modes de transmission. 4. Procédé selon les revendications 2 et 3, caractérisé en ce que ledit au moins un seuil de basculement varie également en fonction de la deuxième information obtenue. 5. Procédé selon l'une quelconque des revendications 3 et 4, caractérisé en ce que deux seuils de basculement sont définis, un premier seuil de basculement (1001) étant utilisé pour basculer du premier au second mode de transmission et un second seuil de basculement (1002) pour basculer du second au premier mode de transmission. 6. Procédé selon l'une quelconque des revendications 4 et 5, caractérisé en ce que chaque seuil de basculement prend : - une première valeur si la deuxième information obtenue est représentative d'une latence de transmission inférieure à un seuil de latence (S,atenee) ; et - une seconde valeur si la deuxième information obtenue est représentative d'une latence de transmission supérieure ou égale audit seuil de latence. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'un tunnel (100) comprenant des première et deuxième porteuses (TCP 100A, UDP 100B) est mis en oeuvre entre le dispositif source et le dispositif destination, en ce que le protocole de transport encapsulant avec acquittement et retransmission est utilisé avec la première porteuse et le protocole de transport encapsulant sans acquittement est utilisé avec la deuxième porteuse, et en ce que le dispositif gestionnaire est une tête de tunnel (101, 102) placée entre le dispositif source et le tunnel ou entre le tunnel et le dispositif destination. 8. Procédé selon l'une quelconque des revendications 1 à 7, ledit protocole de transport passager avec acquittement et retransmission définissant une pluralité de catégories de paquet, caractérisé en ce que, si le second mode de transmission est sélectionné, l'étape consistant à transmettre le paquet obtenu en utilisant le mode de transmission sélectionné comprend des étapes consistant à :- effectuer (1101) 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 (1104, 1110, 1105, 1109) au moins une partie des données dudit paquet obtenu, selon le protocole de transport encapsulant sans acquittement (UDP). 9. Procédé selon la revendication 8, caractérisé en ce que, si le second mode de transmission est sélectionné, l'étape consistant à transmettre le paquet obtenu en utilisant le mode de transmission sélectionné comprend des étapes consistant à : - effectuer (1102) une deuxième vérification de si le paquet obtenu comprend des données utiles d'un autre flux de données utiles passager transmis par le dispositif destination vers le dispositif source, et en cas de première et deuxième vérifications positives : - créer (1104, 1110) 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 (1105) le nouveau paquet selon le protocole de transport encapsulant sans acquittement (UDP) ; - encapsuler (1106) les données utiles de l'autre flux, selon le protocole de transport avec acquittement et retransmission (TCP). 10. Procédé selon la revendication 9, caractérisé en ce que l'étape consistant à encapsuler (1106) les données utiles de l'autre flux, selon le protocole de transport avec acquittement et retransmission (TCP), comprend une étape consistant à encapsuler le paquet obtenu selon le protocole de transport avec acquittement et retransmission (TCP). 11. Procédé selon la revendication 9, caractérisé en ce que l'étape consistant à encapsuler (1106) les données utiles de l'autre flux, selon le protocole de transport avec acquittement et retransmission (TCP), 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 et retransmission (TCP). 12. Procédé selon l'une quelconque des revendications 9 à 11, caractérisé en ce que, en cas de première vérification positive et deuxième vérification négative, le dispositifgestionnaire effectue une étape consistant à encapsuler (1109) le paquet obtenu, selon le protocole de transport sans acquittement (UDP). 13. Procédé selon l'une quelconque des revendications 8 à 12, 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 dispositif destination pour indiquer au dispositif source la réception d'un ou plusieurs paquets de données utiles préalablement transmis par le dispositif source ; et - une catégorie (PUSH) regroupant des paquets de transmission complète de données utiles, transmis par le dispositif source pour indiquer au dispositif destination que des données utiles collectées par le dispositif destination doivent être transmises à une application de destination sans attendre d'éventuelles données utiles qui suivent. 14. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que le 15 flux est destiné à être encapsulé par le dispositif gestionnaire selon un protocole de transport avec acquittement et retransmission avant d'être transmis au dispositif destination, et en ce que des données d'acquittement (ACK) du flux sont encapsulées selon un protocole de transport sans acquittement. 15. Procédé selon la revendication 14, caractérisé en ce que lesdites données 20 d'acquittement (ACK) sont dupliquées pour être transmises, par le dispositif gestionnaire, à la fois selon le protocole de transport avec acquittement et retransmission et selon le protocole de transport sans acquittement. 16. Produit programme d'ordinateur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 25 à 15, lorsque ledit programme est exécuté sur un ordinateur. 17. 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 à 15. 18. Dispositif gestionnaire, adapté pour gérer un flux de données utiles passager 30 transmis par un dispositif source vers un dispositif destination, le flux étant conforme à un protocole de transport passager avec acquittement et retransmission, des données 10utiles du flux étant stockées dans une mémoire tampon de retransmission, de taille mémoire prédéterminée, au sein du dispositif source avant transmission vers le dispositif destination, ledit dispositif gestionnaire étant caractérisé en ce qu'il comprend : - des moyens (411) pour obtenir un paquet relatif au flux et transmis par le dispositif source ou le dispositif destination ; - des moyens (440) pour obtenir une première information, représentative d'un taux de perte de paquets sur au moins une partie d'un chemin de transmission entre les dispositifs source et destination ; - des moyens (440) pour sélectionner, en fonction de la première information et de la taille mémoire, un mode de transmission parmi un premier mode de transmission utilisant un unique protocole de transport encapsulant par défaut, et un second mode de transmission utilisant un protocole de transport encapsulant sans acquittement (UDP) et un protocole de transport encapsulant avec acquittement et retransmission (TCP) ; - des moyens (412, 415, 440) pour transmettre le paquet obtenu en activant le mode de transmission sélectionné.