FR 2926939 A1 20090731 FR 0850561 A 20080130 Procédé de transmission de données avec anticipation des acquittements, dispositif d'entrée, produit programme d'ordinateur et moyen de stockage correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. Plus précisément, l'invention concerne une technique de transmission de paquets de données (aussi appelés datagrammes) selon un premier protocole de transport, avec acquittement, (chaque paquet de données étant associé à un numéro de séquence), lui-même pouvant être transporté (ou encapsulé) sur un segment d'un réseau de communication selon un second protocole de transport, avec ou sans acquittement. L'invention s'applique notamment, mais non exclusivement, dans le cas où le segment de réseau est un tunnel traversant un réseau de communication. La démocratisation d'Internet haut débit d'une part et l'apparition d'équipements audiovisuels grand public ayant une connectivité réseau d'autre part vont créer de nouveaux comportements des utilisateurs. Parmi ces nouveaux comportements, il fait peu de doute que nous verrons apparaître des individus appartenant à des groupes de personnes ayants des domaines d'intérêts communs (loisirs, famille...) que nous pourrions appeler � en liaison permanente �. Ceux-ci établiront des connections quasi permanentes avec les autres individus d'un même domaine d'intérêt en établissant des communications audio et/ou vidéo et partageant des informations de tout type (audio, vidéo, photo, texte ...). La technologie des Réseaux Privés Virtuels (RPV, ou VPN pour � Virtual Private Network � en anglais) offre une solution intéressante pour répondre à cette attente. En effet, elle permet de communiquer de manière transparente en temps réel, de manière sécurisée entre des individus partageant un même domaine d'intérêt tout en utilisant l'infrastructure réseau Internet peu sûr mais bon marché. Pour communiquer de manière transparente et s'affranchir des adresses non routables, les RPVs utilisent une encapsulation particulière (appelée � tunnellisation �, ou � tunneling � en anglais) qui crée ce que l'on appelle un tunnel. Cette opération consiste à encapsuler un protocole de niveau A (protocole embarqué ou véhiculé ou passager) dans un protocole de niveau B (protocole de transport ou véhiculant) 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 RPV de niveau 2, c'est-à-dire dans un tunnel de niveau 2 (tunnel de niveau 2 signifie que le protocole embarqué A est un protocole de la couche 2 du modèle OSI, qui décrit les services offerts par chacune de ces couches et leurs interactions). La tunnellisation peut être utilisée pour transporter un protocole réseau sur un réseau qui ne le supporte pas. Elle peut aussi être utilisée pour fournir différents types de fonctionnalités RPV, comme par exemple l'adressage privé. Les techniques de tunnel sont aujourd'hui de plus en plus utilisées par des fonctionnalités client d'accès à distance, et des interconnexions de réseaux locaux domestiques (appelés ci-après réseaux LAN, pour � Local Area Network � en anglais). Dans la suite de la description, on considère, à titre d'exemple uniquement, les tunnels de niveau 2 ou 3, pour lesquels le niveau du protocole de transport B dans le modèle OSI est égal à celui de la couche de transport (couche de niveau 4 dans le modèle OSI). Il est bien entendu que le cadre de la présente invention n'est nullement limitatif, et que le niveau du protocole de transport B dans le modèle OSI peut être inférieur (cas d'un tunnel avec porteuse Ethernet) ou supérieur (cas d'un tunnel avec porteuse HTTP). Les RPVs (VPN) sont fréquemment utilisés pour interconnecter deux réseaux LAN afin de créer un réseau local virtuel composé de l'union des deux réseaux LAN originaux. Les RPVs sécurisés incluent un algorithme de cryptographie et d'authentification pour garantir le secret des données transportées. Une configuration typique de RPV basé 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 (TEP, pour � Tunnel End Point � en anglais) ne sont pas intégrées aux passerelles. Le tunnel est établi entre deux têtes de tunnel, et chaque paquet (aussi appelé trame) envoyé à un équipement connecté au réseau LAN distant est encapsulé par la tête de tunnel locale, puis envoyé à la tête de tunnel distante qui va la dés-encapsuler et l'envoyer sur le réseau LAN distant. Pour les équipements, ils sont virtuellement connectés à un même réseau LAN. Une communication entre deux équipements via le tunnel est appelée communication de bout en bout (� end-to-end communication � en anglais). De nos jours, on voit émerger des RPVs disposant de techniques de connexions multiples, c'est-à-dire un tunnel formé de plusieurs porteuses ou canaux. Cette technique permet de choisir un premier protocole de transport par exemple pour les données de contrôle, et un second protocole de transport par exemple pour les données utiles, les deux types de données passant dans la même tête de tunnel. Il existe de multiples autres possibilités quand au choix du protocole de transport pour les flux applicatifs passagers (par exemple en fonction des priorités des flux passagers, etc). On parle alors de � canal virtuel � d'un tunnel qui est formé de multiples canaux physiques ayant des protocoles de transport propres, sachant que seule la tête de tunnel a connaissance de ces canaux physiques. Le choix du protocole de transport peut donc être optimisé sur chacun des deux canaux. Dans l'état de l'art, on utilise principalement le protocole IP (� Internet Protocol � en anglais) (couche 3) ou les protocoles TCP (� Transmission Control Protocol � en anglais) / UDP (� User Datagram Protocol � en anglais) (couche 4). Les technologies de tunnellisation basées sur IP ne pouvant pas prendre en compte de mécanisme de traduction d'adresse réseau (NAT, pour � Network Address Translation � en anglais), et n'étant pas entièrement compatibles avec la configuration de tunnellisation typique de la figure 1, on considère (à titre d'exemple uniquement) dans la suite de la description des solutions basées sur la couche 4 (couche de transport), c'est-à-dire sur le protocole TCP ou UDP. Tel qu'expliqué dans l'Annexe qui présente les principes de fonctionnement du protocole TCP, le protocole TCP (défini par la norme RFC793 de l'IETF) est un protocole de type ARQ (� Automatic Repeat Request �, ou protocole de transmission par rafales) qui est basé sur des mécanismes de contrôle de congestion et de retransmission, et assure ainsi la délivrance de chaque paquet vers la destination. Le protocole UDP est un protocole beaucoup plus simple et rapide, qui ne tient pas compte de l'ordre des trames, et ne gère pas d'acquittement. Comme précisé précédemment, le protocole TCP a été conçu pour être flexible et fonctionner dans une large variété d'environnement de communication réseau, incluant des liens lents et rapides, avec une latence élevée ou des liens avec des taux d'erreurs variables. Bien que le protocole TCP fonctionne pour différents environnements, ces performances (en particulier la bande passante) sont affectées par les caractéristiques de chaque lien de communication utilisé. Les performances du protocole TCP en termes de bande passante souffrent dans des environnements avec des délais d'acheminement longs et/ou possédant un taux d'erreur élevé. Un concept de mandataire avancé (ou PEP, pour � Proxy Enhanced Protocol � en anglais), basé sur la norme RFC 3135, peut être utilisé sur des infrastructures qui souffrent de caractéristiques spécifiques aux liens de communication traversés. La norme RFC 3135 décrit différents types de système PEP embarqués dans des équipements réseau sur le chemin d'acheminement d'un flux TCP entre un serveur et un client. Comme il sera décrit par la suite, les systèmes PEP sont particularisés pour chaque environnement afin d'agir sur le contrôle de congestion de flux TCP en conséquence. Dans le cas de l'Internet, les connexions normalement sont de type � best effort �, c'est-à-dire que ces connexions font tout ce qui est possible pour acheminer les informations jusqu'à leur destination, mais sans garantir un certain niveau de qualité de service (QoS). Ainsi, dans le cadre de communication RPV, la couche de transport du tunnel est soumise à de fortes fluctuations de ses capacités de transmission. Les flux TCP passagers de ce tunnel implémentent classiquement un contrôle de congestion de bout-en-bout, c'est-à-dire que les deux dispositifs en communication coopèrent dans la détermination du débit auquel doivent être envoyées les données du dispositif serveur (aussi appelé par la suite dispositif émetteur) vers le dispositif client (aussi appelé par la suite dispositif récepteur). Evidemment, si le dispositif serveur a une connaissance erronée des caractéristiques du réseau, comme pour le cas d'un RPV pour la section de transport du tunnel, il est sujet à émettre trop de données qui seront alors ensuite retardées voire perdues sur le tunnel. Des mécanismes PEP peuvent être mis en place afin d'influencer le contrôle de congestion des flux TCP passagers du tunnel en correspondance avec les limitations intrinsèques de ce tunnel à un instant donné. Ainsi, ces mécanismes PEP sont appliqués principalement au contrôle de congestion et aux problèmes de retransmission sur les différents segments réseau empruntés par une connexion de type TCP. Cependant, lors d'une augmentation de la bande passante disponible (c'est-à-dire des ressources disponibles) sur l'un de ces segments, il n'existe pas de solution afin de profiter quasi-instantanément de cette bande passante disponible. Tout au plus, les systèmes PEP basés sur la mémorisation temporaire (� buffering � en anglais) de paquets peuvent émettre plus rapidement les données stockées dans leur mémoire cache, mais cela a un effet limité dans le temps. Ceci est particulièrement vrai dans le cadre de connexions TCP en transit sur un tunnel RPV de l'Internet. En effet, un phénomène bien connu du protocole TCP en phase de stabilisation réside en la dépendance de l'augmentation de sa fenêtre d'émission (nombre maximal de paquets autorisés à être simultanément en transit entre un dispositif émetteur et un dispositif récepteur) en fonction de la réception d'acquittements des paquets précédents, c'est-à-dire que le protocole TCP émet un paquet de plus par durée aller-retour (� Round-trip-Time �, ou RTT, en anglais) (aussi appelée � temps de boucle �). Le RTT sur un tunnel Internet étant très élevé (10 fois ou 100 fois celui d'un réseau LAN), il est évident qu'un flux TCP ne peut pas réagir aussi rapidement à un accroissement de bande passante disponible sur une connexion Internet. De plus, dans un tunnel RPV agrégeant de multiples flux passagers, il devient vraiment frustrant de ne pas pouvoir consommer la bande passante laissée libre par un flux passager venant de se terminer. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Le protocole TCP, conçu dans un but coopératif, souffre de plusieurs vulnérabilités pouvant être exploitées par des clients non scrupuleux afin d'obtenir un service amélioré par rapport aux autres clients réseaux ou pour effectuer des attaques de type � déni de service �. Parmi les méthodes permettant une allocation plus importante du débit d'émission d'un serveur, on distingue les mécanismes connus de division d'acquittement (� ACK splitting � en anglais) et d'acquittement optimiste (� Optimistic ACK �). Dans le mécanisme de division d'acquittement (� ACK splitting �), à la réception par le client d'un segment de données contenant N octets, le client substitue, à l'acquittement qui devrait correspondre au segment reçu, un ensemble de M acquittements distincts (M N), chacun de ces acquittements couvrant une portion du segment de données reçu. Pour illustration, la demande de brevet US2006/0182025 (� TCP congestion control using multiple TCP ACKs �) utilise une telle technique dans un environnement mixte filaire et sans-fil, afin de limiter l'effet de pertes sur la section sans-fil résultant en une limitation du débit du serveur qui considère les pertes comme signe d'une congestion du réseau. Cette demande de brevet décrit un client mobile avec une couche protocolaire modifiée permettant de générer de multiples acquittements au lieu d'un seul, lors de la détection d'une retransmission du serveur et dans la limite des capacités de réception propres au client. Ce mécanisme de division d'acquittement est cependant assimilé à une attaque par le serveur. Pour se prémunir de ce type d'attaques, des mécanismes sont mis en place dans les serveurs disponibles sur le marché, qui annihilent l'effet cherché par la solution décrite dans cette demande de brevet : la première solution anti-attaque (nommée � byte counting �) consiste à n'augmenter la fenêtre de congestion que proportionnellement à la portion de données acquittées, ayant pour effet de rendre nul le principe de division d'acquittement. Une seconde solution anti-attaque, plus simple, consiste à augmenter la valeur de la fenêtre de congestion de 1 MSS (� Maximum Segment Size �) à chaque acquittement valide (correspondance avec le segment de données transmis). Cette dernière méthode est par exemple implémentée dans les récentes versions du noyau Linux. Dans le mécanisme d'acquittement optimiste (� Optimistic ACK �), on s'appuie sur le fait que le protocole TCP se base sur le principe que le temps entre l'émission d'un segment de données et la réception de son acquittement correspond à au moins un RTT (� round-trip time �). Comme l'augmentation de la fenêtre de congestion dépend du RTT (exponentiellement durant la phase de démarrage lent (� slow-start �) et linéairement durant la phase d'évitement de congestion (� congestion-avoidance ��, plus le RTT est faible, plus les transferts seront rapides. Ainsi, il est possible pour un client de simuler un temps RTT plus court en émettant des acquittements par anticipation pour des données non encore reçues par celui-ci (voire non encore émises par le serveur). Cependant, si un acquittement arrive pour une donnée non encore envoyée, celui-ci est généralement ignoré par le serveur. Le danger de ce mécanisme est de casser le principe de fiabilité bout-en-bout de la connexion entre le serveur et le client. Ce mécanisme est donc lui aussi assimilé à une attaque dont des précautions simples et connues permettent de se prémunir : si le serveur TCP varie aléatoirement la taille des segments émis (aux alentours d'une valeur égale à [MSS û quelques octets]), un client TCP ne pourra plus anticiper les bornes d'acquittement pour des données non encore émises et le serveur TCP pourra aisément rejeter les acquittements optimistes. La demande de brevet US2005/0060426 (� Early generation of acknowledgements for flow control �) présente une version particulière du mécanisme d'acquittement optimiste (� Optimistic ACK �). Il y est présenté un module de contrôle de flux (tel qu'un PEP, ou � Performance Enhanced Proxy �), localisé entre le serveur et le client, qui anticipe l'émission des acquittements de segments de données TCP, une fois que ces segments de données ont été reçus par le module de contrôle de flux. Ces segments sont stockés temporairement jusqu'à réception de l'acquittement réel en provenance du client, permettant ainsi une retransmission en cas d'erreur. Lorsque le module de contrôle de flux est implémenté dans une passerelle VPN, ceci permet d'asservir le débit d'émission du serveur au débit moyen de la section WAN (� Wide Area Network � en anglais, ou � réseau étendu �) et de maintenir un stockage tampon sur la passerelle (en cas de nécessité de retransmission sur la section WAN, en toute transparence pour le serveur). De plus, lorsque la mémoire de stockage tampon devient pleine, une modification de la fenêtre TCP dans le message d'acquittement est effectuée en corrélation avec la mémoire disponible (ceci a pour effet de diminuer le débit d'émission du serveur sans abaisser sa fenêtre de congestion). En conclusion, la technique de la demande de brevet US2005/0060426 n'est pas apte à rapidement augmenter la bande passante consommée par des flux TCP comme décrit dans le problème de la présente invention (libération impromptue et importante de la bande passante WAN attribuée aux flux TCP passagers du tunnel). Les systèmes PEP à acquittement optimiste de l'art antérieur demandent des ressources mémoires conséquentes (car ils sont mis en place en continu), et modifient le comportement normal du protocole TCP selon la capacité de la mémoire tampon disponible. En résumé, dans leurs mises en oeuvre actuelle, les mécanismes connus précités de division d'acquittement (� ACK splitting �) et d'acquittement optimiste (� Optimistic ACK �) permettent une allocation plus importante du débit d'émission d'un serveur, mais ne constituent pas des solutions peu coûteuses en termes de ressources permettant de stimuler le débit d'émission d'un serveur de manière transparente pour le serveur et le client (supportant les principes précités de sécurisation de TCP) tout en étant adaptées à la bande passante évolutive dans un segment de réseau, et plus particulièrement dans un tunnel VPN. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de transmission de paquets de données, via un segment d'un réseau de communication, et les flux de ces paquets de données respectant un protocole de transport avec acquittement, permettant une utilisation optimale de la bande passante de ce segment de réseau (en profitant au plus vite de tout accroissement de bande passante disponible sur ce segment de réseau). Dans au moins un mode de réalisation, l'invention vise à dynamiser les flux de données, transportés selon un protocole de transport avec acquittement, tel que le protocole TCP. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui soit transparente pour les dispositifs émetteurs (serveurs) et les dispositifs récepteurs (clients) dont les flux transitent par le segment de réseau concerné. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui ne soit pas assimilée à une attaque (piratage informatique, ou � hacking � en anglais), et dont l'effet recherché ne soit donc pas annihilé par les solutions actuelles anti-attaque. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit compatible avec une sécurité de bout en bout. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit compatible avec une fiabilité de bout en bout. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit simple à mettre en ouvre et peu coûteuse. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit mise en place dynamiquement, et qui soit limitée dans le temps afin de limiter la consommation de ressources processeur et mémoire utiles. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de transmission de données d'un flux de données, dit flux à stimuler, provenant d'un dispositif émetteur et à destination d'un dispositif récepteur via un segment de réseau compris dans un réseau de communication et selon un protocole de transport par paquets avec acquittement, chaque paquet étant associé à un numéro de séquence. Ledit procédé comprend les étapes suivantes, mises en oeuvre par un dispositif d'entrée dudit segment de réseau pour ledit flux à stimuler : - détermination d'un paquet de début associé à un numéro de séquence supérieur aux numéros de séquence de paquets, dits paquets en transit, transmis par ledit dispositif d'entrée sur le segment de réseau mais pour lesquels le dispositif d'entrée n'a pas encore reçu un message d'acquittement positif provenant du dispositif récepteur ; - sélection, en fonction d'une consommation d'une bande passante cible pour la transmission dudit flux, de paquets dudit flux suivant ledit paquet de début, et pour chacun desquels un message d'acquittement positif anticipé doit être transmis vers le dispositif émetteur ; - sur réception d'un message d'acquittement positif dudit paquet de début, provenant du dispositif récepteur, lancement d'une phase temporaire, de durée 30 fonction du nombre de paquets sélectionnés, comprenant une étape de transmission vers le dispositif émetteur d'un message d'acquittement positif anticipé pour ledit paquet de début et pour chaque paquet sélectionné ; - suppression des acquittements positifs reçus du dispositif récepteur qui correspondent auxdits paquets sélectionnés et pour lesquels un message d'acquittement positif anticipé a été transmis. Le principe général de l'invention consiste donc, sur détection de ressources disponibles du segment de réseau, à sélectionner un ou plusieurs flux et à accélérer temporairement le débit du flux considéré grâce à un mécanisme d'acquittement anticipé, en veillant à temporiser le démarrage de cette phase temporaire pour éviter qu'un dispositif émetteur reçoive des acquittements (anticipés) pour des paquets alors qu'il n'a pas encore reçu les acquittements des paquets précédents. Ainsi, on utilise de façon optimale la bande passante du segment de réseau. Par ailleurs, cette technique est transparente pour les dispositifs émetteurs (serveurs) et les dispositifs récepteurs (clients) dont les flux sont sélectionnés. En effet, elle est entièrement mise en oeuvre par le dispositif d'entrée (tête de tunnel dans le cas, détaillé ci-après, où le segment de réseau est un tunnel) et s'appuie sur des formats de paquets de données conformes aux attentes des dispositifs émetteurs (serveurs). De façon avantageuse, ladite étape de sélection de paquets suivant ledit paquet de début comprend les étapes suivantes : - obtention d'un nombre maximal de paquets autorisés à être simultanément en transit entre le dispositif émetteur et le dispositif récepteur, dite valeur consigne de taille de fenêtre d'émission, en fonction de ladite bande passante cible ; - obtention d'un nombre courant de paquets en transit entre le dispositif émetteur et le dispositif récepteur, dite valeur courante de taille de fenêtre d'émission ; - détermination du nombre de paquets, dits paquets sélectionnés, nécessaires pour permettre un accroissement de ladite valeur courante jusqu'à ladite valeur consigne de taille de fenêtre d'émission. Ainsi, la technique de l'invention prend en compte, pour la détermination des paquets dudit flux pour lesquels un message d'acquittement anticipé est transmis par le dispositif d'entrée, la taille de fenêtre d'émission courante et s'adapte aux conditions courantes de transmission sur le segment de réseau. Avantageusement, ladite phase temporaire est interrompue de façon anticipée en cas de détection d'une utilisation par le dispositif émetteur d'au moins une partie prédéterminée de ladite bande passante cible. Ainsi, une fois une partie donnée (ou certain seuil) de la bande passante cible atteint pour le flux, le dispositif d'entrée arrête la transmission des messages d'acquittement anticipé, de manière à ce que le dispositif émetteur et le dispositif récepteur stabilisent par eux-mêmes les paramètres (pour un flux TCP : RTT, RTO, fenêtre de congestion,...) de transmission du flux jusqu'à atteindre la bande passante cible, en passant par une phase d'évitement de congestion (� congestion avoidance � en anglais). Selon une caractéristique avantageuse, en cas de détection d'une perte d'un desdits paquets en transit, ledit procédé est réinitialisé par retour à ladite étape de détermination d'un paquet de début. Ainsi, sur détection d'erreur de transmission, le procédé redéfinit de nouveaux paramètres adaptés à accélérer le débit du flux par acquittement anticipé dans la situation d'erreur rencontrée, le dispositif émetteur allant retransmettre le(s) paquet(s) manquant(s) et abaisser sa fenêtre de congestion de moitié. De façon avantageuse, un ensemble de flux de données passant par le dispositif d'entrée pour accéder au segment de réseau, le procédé comprend au préalable une étape de : - sélection d'au moins un flux de données parmi ledit ensemble de flux de données, chaque flux sélectionné étant un flux à stimuler. Ainsi, il est possible de sélectionner un flux à stimuler parmi un ensemble de flux de manière à optimiser l'utilisation des ressources du réseau ou l'utilisation des ressources du dispositif d'entrée. Avantageusement, ladite étape de sélection d'au moins un flux de données est basée sur au moins un critère de sélection appartenant au groupe comprenant : - un flux de type TCP en phase de démarrage lent est rejeté de la sélection ; un flux possédant un chiffrement est rejeté de la sélection ; - un flux proposant une marge, supérieure à un seuil prédéterminé, pour un accroissement de ressources réseau consommées pour transmettre ledit flux est favorisé. Ainsi, lorsqu'un flux est un flux (dont le protocole de transport est) TCP en phase de démarrage lent (� slow-start �), il est écarté de la sélection, car pendant cette phase, un flux dispose d'un accroissement important de sa fenêtre de congestion, contrairement à un flux en phase d'évitement de congestion (� congestion avoidance �). De plus, lorsqu'un flux possède au moins une partie ayant subi un chiffrement (par exemple de type IPSec pour un flux TCP), il est écarté de la sélection, car il extrêmement complexe de pouvoir déterminer la valeur de certains champs des paquets (ou trames ou segments) du flux suite au chiffrement. Avantageusement, le segment de réseau étant un tunnel entre un premier sous-réseau auquel est connecté le dispositif émetteur et un second sous-réseau auquel est connecté le dispositif récepteur, ledit tunnel comprenant un ensemble de canaux chacun associé à un protocole de transport, le groupe de critères de sélection comprend en outre : - ladite bande passante cible résultant d'un arrêt d'un flux transitant sur un canal donné du tunnel, un autre flux transitant sur ledit canal donné est favorisé. Ainsi, lorsque le segment de réseau considéré est un tunnel disposant de plusieurs canaux, il est possible de simplifier la conception et la mise en oeuvre du procédé en limitant la sélection au(x) flux qui transite(nt) sur le même canal qu'un flux à l'origine d'une libération de la bande passante sur le tunnel. De façon avantageuse, en cas de détection d'une perte d'un desdits paquets en transit, ledit procédé est réinitialisé par retour à ladite étape de sélection d'au moins un flux de données. Ainsi, sur détection d'erreur de transmission, le procédé sélectionne à nouveau un flux (qui peut être le même) dont le débit est à accélérer par acquittement anticipé, le dispositif émetteur allant retransmettre le(s) paquet(s) manquant(s) et abaisser sa fenêtre de congestion de moitié. Selon une caractéristique avantageuse, ladite phase temporaire comprend une étape de sécurisation de la transmission sur le segment de réseau du paquet de début et de chaque paquet sélectionné. Ainsi, le procédé assure que les paquets sélectionnés (ceux pour lesquels un acquittement anticipé est transmis au dispositif émetteur) sont correctement reçus par le dispositif récepteur, et que le dispositif récepteur transmettra effectivement des acquittements positifs pour ces paquets. Avantageusement, ladite étape de sécurisation comprend au moins une étape appartenant au groupe comprenant : - utilisation d'un mode de transport fiable du segment de réseau pour transmettre le paquet de début et chaque paquet sélectionné ; - augmentation d'un niveau de priorité associé au paquet de début et à chaque paquet sélectionné ; - mémorisation du paquet de début et de chaque paquet sélectionné, afin de pouvoir les retransmettre en cas de mauvaise transmission sur le segment de réseau. Dans un mode de réalisation particulier de l'invention, le segment de réseau étant un tunnel entre un premier sous-réseau auquel est connecté le dispositif émetteur et un second sous-réseau auquel est connecté le dispositif récepteur, ledit tunnel comprenant un ensemble de canaux chacun associé à un protocole de transport, ladite étape de sécurisation comprend une étape de : - transmission d'au moins deux copies, sur au moins deux canaux dudit tunnel, du paquet de début et de chaque paquet sélectionné. Ainsi, il est possible d'augmenter, pour un dispositif de sortie du tunnel, la probabilité de recevoir au moins une copie du paquet considéré et ainsi d'assurer que le dispositif de sortie du tunnel puisse assurer sa fonction de relais de données vers le dispositif récepteur. Dans un mode de réalisation particulier de l'invention, ledit procédé comprend les étapes suivantes : - réception d'un message d'acquittement positif pour ledit paquet de début ou pour un desdits paquets sélectionnés, ledit message reçu comprenant une information envoyée par le dispositif récepteur à destination du dispositif émetteur, ladite information étant une information de protocole encapsulé par ledit protocole de transport auquel ledit flux de données est associé ; - transmission de ladite information dans un message d'acquittement à émettre ultérieurement vers le dispositif émetteur. Ceci permet d'acheminer des informations relatives à la gestion de flux jusqu'au dispositif émetteur bien que le mécanisme d'acquittement anticipé soit activé. Selon une caractéristique avantageuse, ladite information envoyée par le dispositif récepteur est une commande de contrôle dudit flux de données à destination du dispositif émetteur. Avantageusement, ledit procédé comprend une étape de gestion de cadencement de transmission des messages d'acquittement positif anticipé pendant ladite phase temporaire, ladite étape de gestion comprenant l'étape suivante : - pour les paquets sélectionnés dont le numéro de séquence est supérieur ou égal à un nombre déterminé qui est fonction du numéro de séquence dudit paquet de début et d'une estimation d'un nombre desdits paquets en transit entre le dispositif émetteur et le dispositif récepteur, transmission des messages d'acquittement positif anticipé avec un délai qui tient compte d'une estimation d'un temps d'aller-retour entre le dispositif émetteur et le dispositif récepteur.Ainsi, le cadencement des paquets peut permettre, dans une première phase (paquets dont le numéro de séquence est inférieur au nombre prédéterminé) de, par exemple, transmettre rapidement des acquittements anticipés, de manière à permettre un accroissement rapide de la fenêtre de congestion associée au flux. Ensuite, dans une seconde phase, un délai est respecté entre les paquets de manière à maîtriser le calcul du délai avant retransmission (retransmission timeout) appliqué par le serveur sur le flux. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur. Ce produit programme d'ordinateur comprend des instructions de code de programme pour la mise en oeuvre du procédé précité, lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé précité. Dans un mode de réalisation particulier de l'invention, il est proposé un dispositif d'entrée d'un segment de réseau compris dans un réseau de communication, permettant la transmission de données d'un flux de données, dit flux à stimuler, provenant d'un dispositif émetteur et à destination d'un dispositif récepteur via ledit segment de réseau et selon un protocole de transport par paquets avec acquittement, chaque paquet étant associé à un numéro de séquence (SN). Ledit dispositif d'entrée comprend les moyens suivants, permettant de traiter ledit flux à stimuler : - des moyens de détermination, permettant de déterminer un paquet de début associé à un numéro de séquence (INIT) supérieur aux numéros de séquence de paquets, dits paquets en transit, transmis par ledit dispositif d'entrée sur le segment de réseau mais pour lesquels le dispositif d'entrée n'a pas encore reçu un message d'acquittement positif (ACK) provenant du dispositif récepteur ; - des premiers moyens de sélection, permettant de sélectionner, en fonction d'une consommation d'une bande passante cible pour la transmission dudit flux, de paquets dudit flux suivant ledit paquet de début, et pour chacun desquels un message d'acquittement positif anticipé doit être transmis vers le dispositif émetteur ; - des moyens de transmission, activés sur réception d'un message d'acquittement positif dudit paquet de début provenant du dispositif récepteur, permettant de transmettre vers le dispositif émetteur, pendant une phase temporaire de durée fonction du nombre de paquets sélectionnés, un message d'acquittement positif anticipé (pré-ACK) pour ledit paquet de début et pour chaque paquet sélectionné ; - des moyens de suppression, permettant de supprimer des acquittements positifs reçus du dispositif récepteur qui correspondent auxdits paquets sélectionnés et pour lesquels un message d'acquittement positif anticipé a été transmis. 20 25 30 De façon avantageuse, lesdits moyens de sélection de paquets suivant ledit paquet de début comprennent : - des moyens d'obtention d'un nombre maximal de paquets autorisés à être simultanément en transit entre le dispositif émetteur et le dispositif récepteur, dite valeur consigne de taille de fenêtre d'émission, en fonction de ladite bande passante cible ; - des moyens d'obtention d'un nombre courant de paquets en transit entre le dispositif émetteur et le dispositif récepteur, dite valeur courante de taille de fenêtre d'émission ; - des moyens de détermination du nombre de paquets, dits paquets sélectionnés, nécessaires pour permettre un accroissement de ladite valeur courante jusqu'à ladite valeur consigne de taille de fenêtre d'émission. Avantageusement, ledit dispositif comprend des moyens d'interruption, permettant d'interrompre ladite phase temporaire de façon anticipée en cas de détection d'une utilisation par le dispositif émetteur d'au moins une partie prédéterminée de ladite bande passante cible. Selon une caractéristique avantageuse, ledit dispositif comprend des premiers moyens de réinitialisation, activés en cas de détection d'une perte d'un desdits paquets en transit, permettant de réinitialiser lesdits moyens de détermination d'un paquet de début. De façon avantageuse, un ensemble de flux de données passant par le dispositif d'entrée pour accéder au segment de réseau, le dispositif comprend : - des deuxièmes moyens de sélection, permettant de sélectionner au moins un flux de données parmi ledit ensemble de flux de données, chaque flux sélectionné étant un flux à stimuler. Avantageusement, lesdits deuxièmes moyens de sélection d'au moins un flux de données utilisent au moins un critère de sélection appartenant au groupe comprenant : - un flux de type TCP en phase de démarrage lent est rejeté de la sélection ; un flux possédant un chiffrement est rejeté de la sélection ; - un flux proposant une marge, supérieure à un seuil prédéterminé, pour un accroissement de ressources réseau consommées pour transmettre ledit flux est favorisé. Avantageusement, le segment de réseau étant un tunnel entre un premier sous- réseau auquel est connecté le dispositif émetteur et un second sous-réseau auquel est connecté le dispositif récepteur, ledit tunnel comprenant un ensemble de canaux chacun associé à un protocole de transport, le groupe de critères de sélection comprend en outre : - ladite bande passante cible résultant d'un arrêt d'un flux transitant sur un canal donné du tunnel, un autre flux transitant sur ledit canal donné est favorisé. De façon avantageuse, ledit dispositif comprend des deuxièmes moyens de réinitialisation, activés en cas de détection d'une perte d'un desdits paquets en transit, permettant de réinitialiser lesdits deuxièmes moyens de sélection d'au moins un flux de données. Selon une caractéristique avantageuse, ledit dispositif comprend des moyens de sécurisation, activés pendant ladite phase temporaire, permettant de sécuriser la transmission sur le segment de réseau du paquet de début et de chaque paquet sélectionné. Avantageusement, lesdits moyens de sécurisation comprennent au moins un moyen appartenant au groupe comprenant : - un moyen d'utilisation d'un mode de transport fiable du segment de réseau pour transmettre le paquet de début et chaque paquet sélectionné ; - un moyen permettant d'augmenter un niveau de priorité associé au paquet de début et à chaque paquet sélectionné ; - un moyen de mémorisation du paquet de début et de chaque paquet sélectionné, afin de pouvoir les retransmettre en cas de mauvaise transmission sur le segment de réseau. Dans un mode de réalisation particulier de l'invention, le segment de réseau étant un tunnel entre un premier sous-réseau auquel est connecté le dispositif émetteur et un second sous-réseau auquel est connecté le dispositif récepteur, ledit tunnel comprenant un ensemble de canaux chacun associé à un protocole de transport, lesdits moyens de sécurisation comprennent : - des moyens de transmission d'au moins deux copies, sur au moins deux canaux dudit tunnel, du paquet de début et de chaque paquet sélectionné. Dans un mode de réalisation particulier de l'invention, le dispositif comprend : - des moyens de réception d'un message d'acquittement positif pour ledit paquet de début ou pour un desdits paquets sélectionnés, ledit message reçu comprenant une information envoyée par le dispositif récepteur à destination du dispositif émetteur, ladite information étant une information de protocole encapsulé par ledit protocole de transport auquel ledit flux de données est associé ; - des moyens de transmission de ladite information dans un message d'acquittement à émettre ultérieurement vers le dispositif émetteur. Selon une caractéristique avantageuse, ladite information envoyée par le dispositif récepteur est une commande de contrôle dudit flux de données à destination du dispositif émetteur. Avantageusement, ledit dispositif comprend des moyens de gestion de cadencement de transmission des messages d'acquittement positif anticipé pendant ladite phase temporaire, lesdits moyens de gestion comprenant les moyens suivants, activés pour les paquets sélectionnés dont le numéro de séquence est supérieur ou égal à un nombre déterminé qui est fonction du numéro de séquence dudit paquet de début et d'une estimation d'un nombre desdits paquets en transit entre le dispositif émetteur et le dispositif récepteur : - des moyens de transmission des messages d'acquittement positif anticipé avec un délai qui tient compte d'une estimation d'un temps d'aller-retour entre le dispositif émetteur et le dispositif récepteur. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : - la figure 1 illustre une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel ; - la figure 2 présente un exemple de modèle en couche classique d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon l'invention ; - la figure 3 présente un exemple de format classique d'une trame Ethernet véhiculant un paquet tunnel de niveau 2 ; - la figure 4 schématise un scénario d'application d'un mode de réalisation de l'invention, en relation avec l'environnement décrit à la figure 1 ; - la figure 5 présente un organigramme d'un algorithme exécuté par une tête de tunnel, selon un mode de réalisation particulier du procédé selon l'invention ; - la figure 6 présente un organigramme d'un algorithme de détermination des paramètres pour la génération des acquittements anticipés, selon un mode de réalisation particulier du procédé selon l'invention ; et - la figure 7 présente la structure d'un dispositif (tête de tunnel) selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. La figure 1 illustre une configuration typique de réseau privé virtuel (VPN) 20 mettant en oeuvre un tunnel 100 entre une tête de tunnel locale 101 et une tête de tunnel distante 102, à travers un réseau de communication 107 (Internet par exemple). Ce tunnel 100 interconnecte deux réseaux locaux : LAN A 103 et LAN B 104. Chacun des réseaux LAN 103 et 104 comporte un équipement d'accès Internet haut débit (passerelle domestique, ou � Home Gateway �, pouvant intégrer un pare-feu (� Firewall �� 105 et 25 106, des équipements de type PC 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage des media numériques (de type audio, vidéo, photo), ainsi que des équipements de restitutions des médias numériques 108 et 112. Une tête de tunnel peut être intégrée dans un équipement audiovisuel comme un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un programme 30 réalisant les fonctions associées à celle-ci. 10 15 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 avec le serveur 113 connecté au réseau LAN B 104. Dans cette figure 1, on a représenté un réseau de communication simple avec un seul tunnel, mais il est bien entendu qu'une même tête de tunnel peut être amenée à 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 dans le réseau Internet tels que les routeurs Internet. En relation avec la figure 2, nous allons maintenant décrire le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110 (connectés au réseau LAN B 103) et qui va entrer dans le tunnel 100. Pour ce faire, on va utiliser un modèle en couche décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100. Dans ce modèle ne sont pas représentés les éléments de protocole nécessaires aux fonctions autres que la mise en oeuvre du tunnel. Par exemple, ne sont pas représentés les éléments de protocole associés à une architecture UPnP lorsqu'une tête de tunnel 101 est intégrée dans un équipement UPnP. La tête de tunnel 101 comporte une interface physique Ethernet 208 qui remet les trames Ethernet issues des équipements 108, 109, 110 à la couche liaison 207 pour routage : vers la couche réseau 206, pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel, ou vers la couche de pont (� bridge �) 209, pour les autres trames Ethernet. La couche de pont 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 le pont sont attachées une interface Ethernet 207 et au moins une interface virtuelle 210 simulant un contrôleur Ethernet. Une interface virtuelle 210 est créée pour chaque tunnel instancié par l'application 200 à qui elle remet les trames Ethernet qui doivent transiter sur les tunnels respectivement instanciés. 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. Les trames reçues de l'interface virtuelle 210, après traitement par l'application 200, sont remises sous la forme d'un paquet à travers une interface applicative (� socket � en anglais) 201 à un protocole de transport fiable TCP 203 ou non fiable UDP 205, respectivement sécurisés par les protocoles SSL 202 et DTLS 204. On entend par protocole ou mode de transport fiable, un protocole ou mode de transport pour lequel un dispositif émetteur d'une trame ou paquet de données obtient une information de délivrance de la trame ou du paquet de donnée à un dispositif récepteur. La caractéristique principale d'un tel mode est l'assurance de la délivrance de la trame ou de la donnée, et non la latence de transfert entre le dispositif émetteur et le dispositif récepteur. Par la suite, on entendra par canal fiable, un canal de transport de données d'un tunnel entre deux sous-réseaux (aussi appelés réseaux locaux LANs) utilisant un protocole de transport de données (ces données pouvant elles-mêmes être des paquets ou trames selon un protocole de transport déterminé) fiable. Après traitement par un protocole de transport pour former le paquet tunnel 250 (figure 3), on passe celui-ci à 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. 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 présente un exemple de format classique d'une trame Ethernet (référencée 260), transitant par exemple sur le réseau LAN A 103 de la figure 1, et qui comporte : - un champ d'en-tête Ethernet (référencé 261), - un premier datagramme IP (référencé 262) véhiculant lui-même un paquet tunnel de niveau 2 (référencé 250), et - un champ FCS (� Frame Check Sequence �, ou � séquence de contrôle de trame �) (référencé 263). Le paquet tunnel 250 comporte quatre parties : - un champ d'en-tête du protocole de transport 251 (à savoir TCP ou UDP dans cet exemple), - un champ d'en-tête du protocole d'encapsulation 252 (à savoir L2TP ou TLS dans cet exemple, qui sont décrits notamment dans les documents suivants : � IETF RFC3931, "Layer two tunneling protocol û version 3 (L2TPv3)", J. Lau and ail, March 2005 � et � IETF RFC2246, "The TLS Protocol Version 1.0" �), - un champ d'en-tête du protocole embarqué 253 (à savoir Ethernet dans cet exemple), et enfin - un champ de données utilisateurs 254, qui lui-même comporte un second datagramme IP complet si aucune fragmentation n'a été opérée lors de son transit depuis l'équipement source. La figure 4 schématise un scénario d'application d'un mode de réalisation de l'invention, en relation avec l'environnement décrit à la figure 1. La tête de tunnel 101 (ou 102) analyse la bande passante disponible pour émettre dans le tunnel 100 des données provenant du réseau local 103 (ou respectivement 104). Cette bande passante peut correspondre à la somme des caractéristiques propres aux différents canaux qui équipent le tunnel 100. On a représenté pour l'exemple deux canaux dans le tunnel 100 (canal TCP 401 et canal UDP 402), mais l'invention adresse aussi des tunnels simple canal. Ainsi, après détection de l'arrêt d'un flux en provenance du serveur 410, ou bien suite à un accroissement du débit WAN global disponible pour le tunnel, la tête de tunnel évalue la bande passante nouvellement disponible sur un ou l'ensemble de ses canaux et choisit au moins un flux passager à qui donner cette bande passante. Ce ou ces flux choisis sont, au sens de la tête de tunnel, des flux à stimuler auprès du dispositif émetteur (serveur) de manière à utiliser au plus vite la bande passante nouvellement disponible. Des précisions sur les possibilités d'élection seront fournies par la suite. Par exemple, le flux TCP émis du serveur 110 est sélectionné. Afin de permettre à ce flux sélectionné d'utiliser plus rapidement la bande passante, la tête de tunnel entre dans une phase temporaire de génération de messages d'acquittement anticipé de segments de données TCP reçus du serveur 110 par la tête de tunnel, sachant que ces segments de données vont être transférés sur le tunnel et donc que le client destinataire n'a pas encore reçu ces segments de données. Pour l'illustration, les segments TCP de numéros de séquence i et (i+l) (appelés ci-après segments i et segment (i+l) respectivement, et référencés PCKTi et PCKTi+1 sur la figure 4) sont émis par le serveur 110. Le segment i reçu par la tête de tunnel est rapidement acquitté (acquittement anticipé pré-ACKi) par la tête de tunnel, après avoir attendu que tous les paquets déjà transmis sur le tunnel ont bien été reçus par le client (attente de la réception par la tête de tunnel de l'acquittement du paquet de numéro de séquence i-1). Le segment (i+l) le sera par la suite. On suppose que le client n'a reçu à cet instant que les segments jusqu'au numéro de séquence (i-10), et donc que le dernier acquittement envoyé par le client (ACKi-10) l'est pour le paquet de numéro de séquence i-10. La génération des acquittements anticipés pour les segments i et (i+l) va permettre de modifier la mesure du RTT du serveur 110 et donc permettre un envoi immédiat des séquences suivantes (accélération du débit d'émission du serveur 110). Il sera précisé par la suite un algorithme de séquencement pour l'envoi des acquittements anticipés (pré-ACKi et suivants), afin de ne pas modifier trop fortement la valeur calculée d'une temporisation de retransmission (appelée RTO, pour � Retransmission Time Out � en anglais) par le serveur 110, pour ne pas tomber en expiration de ce RTO après l'émission du dernier acquittement anticipé (fin de la phase d'émission temporaire). Dans un mode de réalisation particulier de l'invention, il est considéré qu'il est important de sécuriser le transport des segments TCP pré-acquittés, et la tête de tunnel va aiguiller ces segments pré-acquittés sur un canal fiable (ou plus généralement en utilisant un mode de transport fiable) du tunnel 100 (par exemple, choix du canal TCP 203 même si le reste du flux passe normalement sur le canal UDP 205). Si le tunnel 100 ne dispose pas de canal fiable, une mémoire tampon est activée sur la tête de tunnel pour lesdits segments qui, associée à un protocole de signalisation pour la criticité de ces segments, permet de fiabiliser le transfert entre les têtes de tunnel respectives (têtes de tunnel d'entrée 101 et de sortie 102). La phase temporaire de pré-acquittement se termine après l'envoi du dernier paquet de pré-acquittement (déterminé en relation avec l'étape 602 de l'algorithme 6 expliqué ultérieurement). De plus, cette phase temporaire peut aussi être terminée plus rapidement après détection que le serveur 110 a utilisé la bande passante ciblée ou envisagée (cas d'un serveur avec une augmentation de fenêtre plus optimiste que le standard TCP), ou une partie déterminée de cette bande passante. La figure 5 présente un organigramme d'un algorithme exécuté par une tête de tunnel (TEP) 101, selon un mode de réalisation particulier du procédé selon l'invention. On se place à nouveau dans le cadre de l'environnement décrit à la figure 1, et on considère les segments de données (aussi appelés paquets de données) et acquittements (aussi appelés messages d'acquittement) échangés pendant que la connexion serveur-client TCP (110 et 112 respectivement) est active. Dans une étape 499, on détecte une libération de bande passante sur le tunnel. Il existe plusieurs manières connues d'obtenir cette information de bande passante disponible. Par exemple, une tête de tunnel obtient les caractéristiques des interfaces de connexion (� sockets �) ouvertes pour chaque canal du tunnel (par exemple, utilisation de l'API � Unix Socket Interface �). De plus, une phase de surveillance de la connexion Internet permet d'estimer une bande passante moyenne pour l'accès au WAN, et donc de savoir à un moment donné si une marge raisonnable est théoriquement disponible. Il est pris peu de risque dans ce cas car, même en cas d'erreur d'appréciation, les mémoires tampon (� buffers �) de transmission de chaque canal de la tête de tunnel vont permettre de compenser. C'est pourquoi il est intéressant de corréler une estimation de bande passante disponible avec le taux de remplissage des mémoires tampon des interfaces de connexion (� sockets �) des canaux du tunnel. On se place par exemple dans le cadre d'une tête de tunnel 101 qui gère le routage des flux TCP passagers parmi les différents canaux du tunnel 100, c'est-à-dire que la tête de tunnel sait identifier les flux TCP sur son port d'entrée qui vont transiter dans le tunnel. Par exemple, on peut raisonnablement considérer deux types de flux TCP : les flux TCP correspondants à des transferts importants (et notamment durables) et les flux TCP de commande (quelques messages aller-retour). Ainsi, seule la première catégorie de flux TCP est considérée par l'invention : ceci permet d'allouer une bande passante pour des flux qui peuvent effectivement en bénéficier. De tels flux sont détectables par exemple par réception par la tête de tunnel de requêtes de qualité de service (QoS), telles que des requêtes UPnP QoS ou SBM ou tout autre protocole QoS en activité sur l'un des réseaux locaux LANs. Des requêtes de priorité pour des flux permettent de connaître la nature de ces flux : dans le standard IEEE802.1Q, les priorités 4 à 6 correspondent respectivement à des flux transmis en continu (� streaming �), des flux de transferts vidéo et des flux de transferts audio. Ces requêtes QoS embarquent toutes les références nécessaires par la suite à une identification du flux TCP (adresses source et destination, ports, protocole). Il est bien entendu que seuls les flux de protocole de transport par acquittement tel que TCP sont considérés. De plus, lors de la détection de l'ouverture d'une connexion TCP (segment TCP avec drapeau SYN, voir Annexe), une analyse plus approfondie des protocoles applicatifs permet de connaître les caractéristiques du transfert : par exemple un flux TCP embarquant un protocole applicatif HTTP (253) contient des informations représentant le type de media demandé (message HTTP GET pour une vidéo avec un MIME TYPE � video/mpeg �). Ces exemples sont donnés à titre d'exemple non limitatif. On considère dans un mode particulier de l'invention que tout autre flux TCP non identifié comme précisé ci-dessus est véhiculé dans un canal du tunnel distinct. Ceci a l'avantage de ne pas perturber les flux TCP, passagers du tunnel, sur lesquels peuvent s'appliquer les algorithmes de l'invention. Pour les flux considérés, la tête de tunnel 101 conserve les numéros de séquence TCP des segments (aussi appelés paquets) de données DATA et des segments (aussi appelés paquets ou messages) d'acquittement ACK qui passent par la tête de tunnel. C'est-à-dire qu'à tout moment, la tête de tunnel a connaissance du nombre de segments envoyés sur le tunnel mais non encore acquittés par le client (aussi appelé nombre de segments en transit, ou � flightsize � en anglais). De plus, le type de phase de transmission (démarrage lent (� slow-start �) ou évitement de congestion (� congestionavoidance �) associée à chaque flux TCP est mémorisé. Il est possible de déterminer dans quelle phase est le flux : grâce aux numéros de séquence et aux compteurs précédemment cités, on mesure l'encours des transmissions sur une durée égale à 2 RTT consécutifs. S'il y a une évolution du nombre de paquets supérieure à 1, on est en phase de démarrage lent (� slow-start �). L'étape 499 de détection d'une bande passante disponible est suivie d'une étape 500 de sélection d'un flux parmi ceux éligibles, comme précisé ci-dessus. Plusieurs options sont possibles pour la sélection : - les flux TCP en phase de démarrage lent (� slow-start �) sont rejetés en raison de l'accroissement plus important de leur fenêtre de congestion dans cette phase, dont on ne connaît a priori pas la limite (SSTHRESH pour � steady-state threshold � en anglais) ; - les flux TCP possédant un chiffrement de type IPSec sont aussi éliminés, car il est impossible de faire de la surveillance sur les parties des segments (numéros de séquence) altérées par le chiffrement ; - il est préférablement choisi un flux TCP souffrant de faible fenêtrage (iniquité des autres flux concurrents). La valeur de fenêtre d'acquittement (� advertized-window �) émise par un client (présente dans chacun des messages TCP émis par le client à destination du serveur) permet de connaître les flux proposant la plus grande marge pour l'accroissement du débit ; - dans un souci de simplification de gestion de routage de la tête de tunnel, il est possible de limiter la sélection des flux TCP à ceux transitant sur le canal ayant libéré la bande passante (quand la bande passante nouvellement disponible résulte de l'arrêt de la transmission d'un flux sur le tunnel) ; - plus simplement, les priorités associées aux différents flux (norme IEEE802.1P) peuvent être un critère de sélection supplémentaire. Une fois un ou plusieurs flux TCP sélectionnés, le déroulement des étapes suivantes (501 à 509) se fait indépendamment pour chaque flux sélectionné. L'étape 501 consiste à déterminer, en connaissance de la cible d'accroissement de fenêtre (elle-même fonction de la bande passante disponible détectée à l'étape 499), le nombre de paquets d'acquittements anticipés à émettre. Les internes de cette étape 501 sont présentés ci-après en relation avec la figure 6. L'étape 502 consiste à déterminer le numéro de séquence (INIT) du paquet de début, à partir duquel commencer la phase temporaire de génération des acquittements anticipés, et le numéro de séquence (MAX) du paquet de fin, pour lequel se termine cette phase temporaire. Les derniers segments reçus par la tête de tunnel sont pris en considération pour effectuer cette étape 502. Par exemple, le segment de numéro de séquence INIT correspondra au premier paquet à acquitter par anticipation et est déterminé en relation avec le dernier segment TCP DATA 520 reçu du serveur 110 à ce moment. Cette détermination est réalisée en termes de comptage de paquets arrivant sur la tête de tunnel, ou en termes de séquence de paquet. Par exemple, si le paquet 520 transporte des données pour un numéro de séquence de valeur i, le premier paquet 520 qui comportera la valeur de numéro de séquence (INIT = i + � flightsize �) sera le premier paquet à entrer en phase d'acquittement anticipé. Avec � flightsize � le nombre de segments en transit, comme défini ci-dessus. Selon une variante, on compte le nombre de paquets séparant celui du numéro de séquence i à celui du numéro de séquence INIT en connaissant le MTU (Maximum Transmission Unit) de la connexion TCP. Le dernier paquet à considérer pour la phase d'acquittements anticipés est identifié en relation avec le numéro de séquence MAX (MAX = INIT + [nombre de paquets calculé à l'étape 501] x MTU). Dans l'étape 503, on recherche un canal fiable dans le tunnel afin de convoyer les paquets sélectionnés aux étapes 501 et 502 (c'est-à-dire les paquets du paquet de début jusqu'au paquet de fin). Si le (ou les) canal (canaux) fiable(s) sont engorgé(s), la tête de tunnel pourra procéder à un déroutage des paquets transitant habituellement sur le canal choisi vers un canal non fiable, afin de favoriser la fiabilisation de transport du tunnel pour les paquets sélectionnés (c'est-à-dire ceux de numéro de séquence INIT à MAX) du flux TCP considéré par l'algorithme. Le test de l'étape 504 permet de détecter l'arrivée des paquets sélectionnés (segments TCP DATA 520 dont les numéros de séquence sont compris entre INIT et MAX), afin d'effectuer pour ces paquets sélectionnés les actions des étapes 505 et 506. Dans l'étape 505, vue l'importance des paquets sélectionnés 520, ils ne doivent pas être perdus : c'est pourquoi il est par exemple possible de modifier la priorité classique du paquet en spécifiant une classe de service plus élevée (champ TOS pour � Type-Of-Service � de l'entête IPv4) afin qu'une fois acheminé à l'autre bout du tunnel, le réseau LAN distant prenne plus de précautions pour l'acheminement jusqu'au client 112. De plus, les paquets transporteurs de paquets 520 sélectionnés peuvent avoir une priorité revue à la hausse afin que les routeurs de l'Internet privilégient leur transport. Dans un mode privilégié de l'invention, une information de criticité de paquet est intégrée au paquet transporteur du canal fiable, afin que cette information soit détectée par la tête de tunnel 102 de sortie de tunnel. Cette information peut être de type propriétaire (par exemple un champ d'en-tête du protocole d'encapsulation 252 particularisé), ou supportée par une classe de service précise (une valeur de priorité 7, la plus élevée, alors qu'un flux vidéo/audio/voix ne dépasse pas le niveau 6 dans les spécifications IEEE802.1P). La tête de tunnel 102 sera à même de mettre en place une sécurisation par mécanisme PEP (� Performance Enhanced Proxy �) de mise en mémoire tampon (� bufferisation �), conformément à la norme RFC3135, pour les paquets de flux passagers ainsi désignés. Dans l'étape 506, les paquets sélectionnés sont stockés temporairement dans une mémoire tampon dédiée à ce type de paquets, afin de pouvoir les retransmettre en cas de perte éventuelle. Toujours dans cette étape 506, les paquets sélectionnés 520 sont ensuite acheminés dans le tunnel sur le canal porteur sélectionné à l'étape 503. En option, chaque paquet sélectionné est convoyé sur plusieurs canaux en simultané lorsque de fortes perturbations sont détectées sur le canal fiable (afin d'éviter des coûteux délais de retransmission sur ce canal). En plus du stockage des paquets sélectionnés, on mémorise aussi la date de leur réception afin de disposer d'une base de temps pour la génération des acquittements anticipés (pré-ACK) lors de l'étape 508 décrite ci-après. On notera le caractère temporaire du stockage et sa limitation aux seuls paquets sur lequel s'applique l'algorithme de l'invention. L'étape 507, d'attente de l'acquittement (ACK) du paquet de numéro de séquence INIT (paquet de début), permet de limiter l'exécution des étapes suivantes 508 et 509 aux paquets sélectionnés (dont les numéros de séquences sont compris entre INIT et MAX). Lors de l'arrivée d'un acquittement correspondant au numéro de séquence (INIT û 1xMTU), il peut être procédé à l'envoi anticipé des acquittements pour les paquets suivants. On notera que ce test sert à temporiser le démarrage de la phase d'acquittement anticipé, dans le but de garder une cohérence dans les rapports d'émission des acquittements. En effet, selon le protocole TCP, il n'est pas logique de recevoir des acquittements pour des paquets de numéros de séquence donnés alors que certains des paquets de numéros de séquence précédents n'ont pas encore été reçus. En toute logique, un acquittement pour un paquet de numéro de séquence k ne doit pas avoir lieu si le paquet de numéro de séquence k-1 n'a pas été acquitté : selon la norme TCP, un client doit réémettre un acquittement de numéro de séquence (k-i-1) pour tout segment reçu dont le numéro de séquence est strictement supérieur à k afin d'indiquer la perte ou du moins le retard de la livraison du segment de séquence (k) : ainsi, lorsque le serveur reçoit plusieurs acquittements identiques (numéro k-i-1), il interprète une éventuelle perte lors du transfert des paquets DATA vers le client et réagit en diminuant sa fenêtre de congestion de moitié et en retransmettant les paquets qu'il pense perdus : c'est tout l'inverse du comportement désiré par l'invention (accroissement rapide de la fenêtre de congestion du serveur TCP) ! Dans l'étape 508, on émet des paquets d'acquittement anticipé (positif) 530 (pré-ACK) pour les numéros de séquence INIT à MAX, en armant une temporisation entre chaque émission, cette valeur de temporisation ayant été préalablement déterminée en relation avec l'étape 501 ou sur l'instant pour les paquets DATA 520 non encore reçus lors de l'exécution de l'étape 501. Dans ce second cas, l'étape 508 détermine la valeur de temporisation tel que décrit par le second calcul effectué à l'étape 603 de la figure 6. Dans tous les cas, il n'est pas procédé à un acquittement pour un paquet (segment DATA) non encore reçu du serveur (et donc pas encore stocké dans la mémoire tampon de la tête de tunnel). Dans l'étape 509, lors de la réception d'acquittements 525 (ACK) en provenance du client 112 correspondant aux numéros de séquence déjà acquittés de façon anticipée (� pré-acquittés �), il est procédé à une analyse de ces acquittements. Soit l'acquittement est positif, le segment TCP DATA correspondant est supprimé de la mémoire tampon et le message d'acquittement ACK est détruit (non envoyé sur le réseau LAN 103 car le serveur a déjà reçu un acquittement, de manière anticipée, pour ce numéro de séquence lors de l'étape 508). Soit l'acquittement est négatif (réception de 3 segments TCP DUP ACKS pour un numéro de séquence s INIT), il est procédé au transfert du paquet de numéro de séquence (s+l) sur le canal fiable du tunnel 100 en direction du client 112. Il n'est pas procédé à la destruction du paquet de numéro de séquence (s+l) dans la zone de mémorisation temporaire. Dans le cadre d'un acquittement ACK 525 positif reçu du client, un mode privilégié de l'invention comprend une analyse de la portion � données � (référencée 254 sur la figure 3) du message d'acquittement 525 afin de déterminer la présence ou non d'une éventuelle commande de gestion du flux de données adressée au serveur (par exemple l'acquittement ACK 525 embarque un entête HTTP avec une commande PLAY (lecture) ou PAUSE). Plus généralement, cette analyse vise à déterminer la présence, dans un acquittement ACK 525 positif reçu du client, d'une information du protocole (tel un � cookie � par exemple) qui est encapsulé par ledit protocole de transport par acquittement auquel ledit flux de données est associé. En cas de détermination positive, il est alors procédé à la non filtration de ce message d'acquittement ACK vers le serveur (deux messages d'acquittement ACKs même dé-séquencés n'ont pas d'influence), ou bien à l'extraction de ces commandes du message d'acquittement ACK courant et à la réintroduction de ces commandes dans le message d'acquittement ACK suivant à être envoyé vers le serveur). Il est bien entendu que tout arrêt de transmission (message TCP SYN-FIN détecté, voir Annexe) par le serveur 110 pour un flux sélectionné par l'algorithme décrit en figure 5, arrête automatiquement cet algorithme. De plus, il est procédé à une analyse en tâche de fond (non représentée sur le schéma) de chaque segment d'acquittement ACK 525 reçu du client 112 pour les numéros de séquence i (démarrage de l'algorithme) au numéro de séquence INIT (début de transmission d'acquittements anticipés vers le serveur) pour détecter d'éventuels DUP ACKs : trois messages 525 identiques indiquent une perte de paquets en transit vers le client, qui, comme non encore stockés par la tête de tunnel dans la mémoire tampon, vont mettre le serveur en mode � fast-retransmit � et � fast-recovery � suivant la norme RFC2581. Comme le serveur va retransmettre les paquets manquants et abaisser sa fenêtre de congestion de moitié, il est procédé à la réinitialisation de l'algorithme (redémarrage à l'étape 501 avec la nouvelle valeur estimée de fenêtre de congestion du flux et le numéro de séquence des paquets (segments DATA) est celui convoyé par les paquets DUP ACKs). La figure 6 schématise un exemple d'algorithme détaillant l'étape 501 de détermination des paramètres pour la génération des acquittements anticipés effectuée à l'étape 508. L'étape 600 consiste à obtenir la consigne de bande passante qui est proposée au flux TCP courant. Cette consigne peut être indiquée indifféremment en termes de bande passante (BW) ou de valeur de fenêtrage (WD). On rappelle le facteur qui lie ces deux paramètres : WD = RTT * BW. Dans la suite, on suppose que la consigne de bande passante est exprimée sous la forme d'une valeur consigne de fenêtre de congestion (� target_cwnd �). Dans l'étape 601, on procède à la détermination de la marge de progression (� target_flightsize �) pour le flux TCP, qui correspond à la différence entre la valeur consigne de fenêtre de congestion et une valeur courante de fenêtre de congestion, cette valeur courante étant égale au nombre (� flightsize �) de paquets en transit entre le client et le serveur : target_flightsize = target_cwnd -flightsize Dans l'étape 602, on obtient à partir de cette marge le nombre (N) de paquets permettant l'accroissement de la fenêtre de congestion à la valeur ciblée : N = target_flightsize / MSS, avec MSS la taille de paquet (segment) maximale. C'est ce nombre N qui définira le côté temporaire de la phase d'acquittement anticipé. Dans l'étape 603, on calcule un délai pour la transmission des acquittements anticipés (pré-ACK 530) qui sera utilisé à l'étape 508. Selon les normes RFC1122 et RFC2988, la valeur de RTO pour une connexion TCP est obtenue à partir de valeurs du RTT mesurées ainsi : SRTT(,+l) = (1-a) * SRTT(,) + a *RTT(, où SRTT est une estimation lissée du RTT, RTT est la dernière valeur mesurée du RTT eta=1/8. Et basé sur cette formule, une estimation du RTO est la suivante (selon la norme RFC793) : RTO(i) = (3 * SRTT(,) où (3 est un facteur de variance du délai (généralement égal à 2). Selon le nombre de paquets à générer, il est procédé à la détermination de deux délais de génération distincts, de manière à adapter le cadencement des acquittements anticipés en fonction du numéro de séquence des paquets DATA auxquels ils correspondent. La valeur � flightsize � donnant une estimation des paquets en transit sur le tunnel pour lesquels la tête de tunnel n'a pas encore reçu l'acquittement du client, pour tous les paquets de numéros de séquence inférieurs à (flightsize/(3), il peut être procédé à l'émission immédiate des acquittements anticipés à l'entrée de l'étape 508 (délai = 0). Selon la figure 5, ces paquets correspondent aux numéros de séquence SN = INIT à SN = (INIT + flightsize/(3). Comme l'acquittement du paquet de numéro de séquence INIT (démarrage de la génération des acquittements anticipés) se fait après un RTT, suivant l'algorithme de la figure 5, il n'y a pas lieu de tomber dans un dépassement de temporisation (� timeout �) du serveur pour les paquets suivants ci-dessus désignés. Pour tous les paquets suivants (c'est-à-dire jusqu'au numéro de séquence SN = MAX, en relation avec la figure 5), un second calcul du délai pour la génération des acquittements anticipés (pré-ACKs) tient compte de l'instant de réception du segment DATA correspondant à la séquence désirée. On rappelle que ce second calcul est aussi typiquement mis en place lors de l'exécution de l'étape 508 pour les paquets DATA 520 non encore reçus lors de l'exécution de l'étape 501. Le délai pour la génération des acquittements anticipés (pré-ACKs) est calculé comme suit : Délai = SRTT/(3 ù (current_time ù reception_time) Où: - (3 est le facteur de variance du délai tel que défini selon la norme RFC793 ; - SRTT est une estimation lissée du RTT ; - � Current_time � est l'instant courant ; - � Reception_time � est l'instant de réception du paquet TCP DATA 520 correspondant. La différence (� current_time � û � reception_time �) représente le temps écoulé depuis la réception du paquet TCP DATA 520, et sa prise en compte permet d'émettre un acquittement anticipé le plus proche possible du délai limite SRTT/(3 après la réception du paquet TCP DATA 520, et ainsi sans que cela puisse altérer la valeur du RTO. En effet, la valeur limite de séquencement (SRTT/(3) garantit une valeur de RTO du serveur TCP toujours strictement supérieure à SRTT (donc pas de problème lors de l'arrêt de la phase d'émission d'acquittements anticipés). Dans un mode de réalisation privilégié, après l'émission du premier acquittement anticipé, un paquet sur deux sera concerné par l'activation de la temporisation précitée : c'est-à-dire que deux acquittements (pour deux numéros de séquence consécutifs) pourront être générés consécutivement (sans délai d'attente précité entre ces deux acquittements). La formule lissée d'obtention du SRTT tolère une telle variation de RTT (RTT proche de 0 pour un paquet sur deux) sans impact sur le calcul de RTO. La figure 7 illustre une configuration schématique d'un dispositif de communication générique 1000 adapté pour mettre en oeuvre un mode de réalisation particulier de la technique de l'invention. Par exemple, la tête de tunnel 101 ou 102, précitée en relation avec la figure 1, est identique au dispositif générique 1000. Ce dispositif générique 1000 peut notamment être connecté à tout moyen de stockage d'image, de vidéos, ou de sons reliés à une carte graphique et délivrant au dispositif générique 1000 des données multimédia. Le dispositif générique 1000 comporte un bus de communication 1002 auquel sont reliés : - une unité centrale de traitement 1003 (qui est par exemple un microprocesseur référencé CPU) ; - une mémoire morte 1004 référencée ROM, pouvant comporter le ou les programme(s) précité(s) ; - une mémoire vive 1006 (mémoire cache référencée RAM), comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution du ou des programme(s) précité(s) ; - une interface de communication 1018 reliée à au moins deux réseaux de communication distribué 1020, par exemple (cas de la figure 1) le réseau local 103/104 et l'Internet 107, l'interface étant apte à transmettre et à recevoir des données avec ces réseaux. Le dispositif générique 1000 comprend également (mais ceci est optionnel) : - un écran 1008 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 1010 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 1011 ou un crayon optique, - un disque dur 1012 pouvant comporter le ou les programme(s) précité(s) ; - un lecteur de disque externe 1014, permettant par exemple de lire une clé USB 1016. Le bus de communication 1002 permet la communication et l'interopérabilité entre les différents moyens inclus dans le dispositif générique 1000 ou reliés à ce dispositif. De manière plus générale, grâce au bus de communication 1002, l'unité centrale 1003 est susceptible de communiquer des instructions à tout dispositif inclus dans le dispositif générique 1000 directement ou par l'intermédiaire d'un autre dispositif générique. Le code exécutable de chaque programme précité permettant au dispositif générique 1000 de mettre en oeuvre le procédé selon un mode de réalisation de l'invention, peut être stocké dans une mémoire non volatile, par exemple le disque dur 1012, la mémoire morte 1004 ou la clé USB 1016. L'unité centrale 1003 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programme(s) selon un mode de réalisation de l'invention. Lors de la mise sous tension, le ou les programmes qui sont stockés dans la mémoire non volatile précitée (1012, 1004 ou 1016) sont transférés dans la mémoire vive 1006 qui contiendra alors le code exécutable du ou des programme(s) selon un mode de réalisation de l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de ce mode de réalisation du procédé selon l'invention. Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC). ANNEXE : RAPPELS SUR LE PROTOCOLE TCP Le protocole TCP (pour � Transmission Control Protocol �, tel que défini par la norme RFC 793) est un protocole de type ARQ 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 (� acknowledge � en anglais ou ACK), permettant au client (aussi appelé dispositif client ou machine réceptrice) et au serveur (aussi appelé dispositif serveur ou machine émettrice) de s'assurer de la bonne réception mutuelle des données. Lors de l'émission d'un segment de données (aussi appelé paquet de données), un numéro d'ordre (appelé aussi numéro de séquence) est associé. A la réception d'un segment de données, la machine réceptrice va retourner un 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 égal au numéro d'ordre précédent. Etant donné que ce processus de communication, qui se fait grâce à une émission de données et d'un accusé de réception, est basé sur un numéro d'ordre (ou numéro de séquence), il faut que les machines émettrice et réceptrice (serveur et client respectivement) connaissent le numéro d'ordre initial de l'autre machine (appelé � Initial Sequence Number � en anglais ou ISN). L'établissement d'une connexion TCP s'effectue en trois temps : - dans un premier temps, le client envoie un segment de données comportant le drapeau SYN (ou message SYN) pour signaler qu'il s'agit d'un segment de synchronisation, avec son numéro de séquence 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 (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 qui contient le numéro d'ordre 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, dont le drapeau SYN est à 0, car il ne s'agit plus d'un segment de synchronisation. Son numéro d'ordre est incrémenté (seq = x + 1) et le numéro d'accusé de réception représente le numéro d'ordre initial du serveur incrémenté de 1 (ack = y + 1). Une fois achevée cette phase nommée � three-way handshake �, les deux applications sont en mesure d'échanger les octets qui justifient l'établissement de la connexion. Le contrôle de flux gère l'allocation de ressources au niveau du destinataire, telles que la mémoire et le processus. En général, conformément au contrôle de flux, la destination fixe une limite au débit de transmission mis en oeuvre par toutes les sources qui envoient des données à la destination. Les sources et les destinations coordonnent le transfert de données grâce à un échange de messages comprenant des requêtes et des accusés de réception. Avant que la source commence à envoyer des paquets, elle envoie une requête à la destination visant à obtenir la permission de commencer la transmission. En réponse à cette requête, la destination envoie un message comprenant une identification du nombre de paquets que la source peut transmettre à la destination sans autorisation supplémentaire. Ce nombre est communément appelé "taille de fenêtre". Alors, la source transmet le nombre de paquets autorisés à la destination et attend que la destination vérifie leur réception. Après que la destination a reçu avec succès un paquet, elle envoie un message en retour à la source comprenant un accusé de réception (acquittement) indiquant que le paquet a été reçu avec succès et, dans certains cas, autorisant la source à envoyer un autre paquet. De cette façon, le nombre de paquets sur le réseau transitant depuis la source vers la destination ne dépasse jamais la taille de fenêtre autorisée. On distinguera par la suite différentes appellations pour les fenêtres TCP : - fenêtre TCP (� TCP window � en anglais) : la valeur initiale validée lors de l'établissement de la connexion, qui est la valeur maximale admise durant toute la durée de la connexion ; - fenêtre de congestion (� CWND � ou � Congestion window � en anglais) : la valeur de fenêtre courante émise depuis le serveur dans un paquet TCP en destination du client ; - fenêtre d'acquittement (� acknowledge-window � ou � advertized- window � en anglais) : la valeur de fenêtre envoyée dans un paquet TCP ACK vers le serveur, qui indique l'occupation mémoire dans le client ; - fenêtre glissante (� sliding window � en anglais) : la valeur de fenêtre interne à un serveur lui permettant de connaître le nombre de données à transmettre depuis l'arrivée du dernier segment TCP d'acquittement. Une grande taille de fenêtre TCP encourage l'émission. Si le nombre de données reçues est supérieur à ce que la fenêtre indique, les données hors fenêtre seront rejetées. Cette déperdition entraîne un grand nombre de retransmissions et surcharge inutilement le réseau et les TCP. L'usage d'une petite taille de fenêtre morcelle le débit en ajoutant un certain retard supplémentaire au � temps de boucle � (RTT), mais en limitant la surcharge du réseau due aux retransmissions. L'ouverture d'une toute petite fenêtre réduit aussi les performances en augmentant le poids des en-têtes par rapport aux données. Même avec la mise en place de ces mécanismes, dans un réseau occupé, plusieurs sources envoient simultanément des flux dans le réseau à plus d'une destination. Si trop de tels flux convergent vers un unique routeur dans un laps de temps trop court, alors la capacité limitée en mémoire tampon de ce routeur n'est pas capable de traiter ce volume de flux et ce routeur va rejeter ou détruire une partie des paquets. Lorsqu'une telle situation se produit, le réseau est dit congestionné. Lorsqu'une telle situation se produit, les transferts dans le réseau ralentissent considérablement et le débit du réseau chute. Du fait que certaines ressources du réseau sont dédiées à la mise en oeuvre de retransmissions, au moment où le réseau connaît une surcharge, il existe un risque substantiel d'occurrence de propagations de congestions et de blocage du réseau tout entier. La valeur du champ TCP MSS (� Maximum Segment Size � en anglais, ou � taille de segment maximale) indique la quantité maximale de données TCP par datagramme IP que le système local peut accepter. Lorsqu'il est envoyé, le datagramme IP peut être fragmenté en plusieurs paquets. Théoriquement, cette valeur peut atteindre la valeur de 65495, cependant une valeur aussi importante n'est jamais mise en oeuvre. Typiquement, un système terminal utilise l'interface MTU (pour � outgoing interface Maximum Transfer Unit �) à laquelle est retranchée la valeur 40 comme sa valeur de champ TCP MSS. Par exemple, une valeur de champ TCP MSS pour le protocole Ethernet est 1460 (1500 - 40 = 1460). La valeur du champ TCP MSS est renseignée dans les paquets qui servent à établir la connexion qui sont les paquets qui contiennent le signal SYN. Chaque coté envoie sa propre valeur de champ TCP MSS. Il n'est pas requis que chaque coté utilise la même valeur de champ TCP MSS, mais chaque coté ne peut pas envoyer plus de données que ce qui est autorisé par le poste distant. La valeur du champ TCP MSS est envoyée à la taille de segment maximale (MSS) de l'option de l'entête TCP. On peut noter que la valeur par défaut de la taille de la mémoire tampon de l'interface de connexion diffère beaucoup en fonction de l'implémentation. Les anciennes implémentations dérivées de Berkeley imposent des valeurs par défaut des mémoires tampon TCP de réception et d'envoi à 4KB, alors que les systèmes plus récents mettent en oeuvre des valeurs plus importantes (jusqu'à 64KB). Par exemple, dans WINDOWS XP (marque déposée), la valeur actuelle de la taille de fenêtre en réception s'ajuste automatiquement en fonction des incréments pairs de la taille maximale de segment (MSS) négociée pendant l'établissement de la connexion TCP. Le protocole TCP utilise plusieurs algorithmes pour gérer sa congestion, plus particulièrement un algorithme de démarrage lent (� slow start � en anglais) et un algorithme d'évitement de congestion (� congestion avoidance � en anglais). Chacun de ces algorithmes gère le débit d'émission du serveur en manipulant une fenêtre de congestion (� congestion window �, ou CWND) qui limite le nombre d'octets non acquittés en transit à un instant donné. Le débit possible de TCP pour une valeur de fenêtre de congestion donnée est déterminé par la vitesse à laquelle les acquittements sont reçus. Le temps pour recevoir un acquittement après l'émission d'une donnée est appelé � TCP Round Trip Time � (RTT). Lors du démarrage d'une connexion, l'algorithme de démarrage lent (� slowstart �) est mis en place pour accroître rapidement la fenêtre de congestion (CWND) dans le souci d'atteindre la valeur de la bande passante le plus vite possible. La variable SSTHRESH (� steady-state Threshold �) est maintenue par le serveur afin de distinguer les deux phases. Lors que l'émetteur conclut à une perte d'un segment, il traite cette information comme un signal implicite d'une surcharge réseau et décroît rapidement la fenêtre de congestion. Après avoir déduit approximativement le seuil SSTHRESH d'engorgement du réseau, TCP procède à la mise en place de l'algorithme d'évitement de congestion (� congestion avoidance �) qui accroît la valeur de la fenêtre de congestion plus lentement afin d'occuper la bande passante additionnelle disponible. Durant la phase de démarrage lent (� slow-start �) (au démarrage de la connexion ou après dépassement de temps (timeout)), l'émetteur démarre avec un fenêtrage CWND de 1 MSS, et CWND augmente de 1*MSS après chaque réception d'acquittement. La fenêtre de congestion CWND est approximativement doublée à chaque RTT (croissance exponentielle). Durant la phase d'évitement de congestion (� congestion-avoidance �), l'accroissement de CWND est limité à 1*MSS par RTT (croissance additive). Une baisse des performances est notée dans les réseaux Internet où l'on peut constater un délai long de propagation qui empêche la fenêtre de transmission d'envoyer des nouveaux segments rapidement (les acquittements déterminent l'augmentation de la fenêtre de transmission et ils arrivent après un long délai). 10 15 20 25 30 REVENDICATIONS 1. Procédé de transmission de données d'un flux de données, dit flux à stimuler, provenant d'un dispositif émetteur et à destination d'un dispositif récepteur via un segment de réseau compris dans un réseau de communication et selon un protocole de transport par paquets avec acquittement, chaque paquet étant associé à un numéro de séquence (SN), caractérisé en ce que ledit procédé comprend les étapes suivantes, mises en oeuvre par un dispositif d'entrée dudit segment de réseau pour ledit flux à stimuler : - détermination (501) d'un paquet de début associé à un numéro de séquence (INIT) supérieur aux numéros de séquence de paquets, dits paquets en transit, transmis par ledit dispositif d'entrée sur le segment de réseau mais pour lesquels le dispositif d'entrée n'a pas encore reçu un message d'acquittement positif (ACK) provenant du dispositif récepteur ; - sélection, en fonction d'une consommation d'une bande passante cible pour la transmission dudit flux, de paquets dudit flux suivant ledit paquet de début, et pour chacun desquels un message d'acquittement positif anticipé doit être transmis vers le dispositif émetteur ; - sur réception (507) d'un message d'acquittement positif dudit paquet de début, provenant du dispositif récepteur, lancement d'une phase temporaire, de durée fonction du nombre de paquets sélectionnés, comprenant une étape de transmission (508) vers le dispositif émetteur d'un message d'acquittement positif anticipé (pré-ACK) pour ledit paquet de début et pour chaque paquet sélectionné ; - suppression des acquittements positifs reçus du dispositif récepteur qui correspondent auxdits paquets sélectionnés et pour lesquels un message d'acquittement positif anticipé a été transmis. 2. Procédé selon la revendication 1, caractérisé en ce que ladite étape de sélection de paquets suivant ledit paquet de début comprend les étapes suivantes : obtention d'un nombre maximal de paquets autorisés à être simultanément en transit entre le dispositif émetteur et le dispositif récepteur, dite valeur consigne de taille de fenêtre d'émission, en fonction de ladite bande passante cible ;- obtention d'un nombre courant de paquets en transit entre le dispositif émetteur et le dispositif récepteur, dite valeur courante de taille de fenêtre d'émission ; -détermination du nombre de paquets, dits paquets sélectionnés, nécessaires pour permettre un accroissement de ladite valeur courante jusqu'à ladite valeur consigne de taille de fenêtre d'émission. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite phase temporaire est interrompue de façon anticipée en cas de détection d'une utilisation par le dispositif émetteur d'au moins une partie prédéterminée de ladite bande passante cible. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, en cas de détection d'une perte d'un desdits paquets en transit, ledit procédé est réinitialisé par retour à ladite étape de détermination (501) d'un paquet de début. 5. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, un ensemble de flux de données passant par le dispositif d'entrée pour accéder au segment de réseau, le procédé comprend au préalable une étape de : - sélection (500) d'au moins un flux de données parmi ledit ensemble de flux de données, chaque flux sélectionné étant un flux à stimuler. 6. Procédé selon la revendication 5, caractérisé en ce que ladite étape de sélection (500) d'au moins un flux de données est basée sur au moins un critère de sélection appartenant au groupe comprenant : - un flux de type TCP en phase de démarrage lent est rejeté de la sélection ; - un flux possédant un chiffrement est rejeté de la sélection ; - un flux proposant une marge, supérieure à un seuil prédéterminé, pour un accroissement de ressources réseau consommées pour transmettre ledit flux est favorisé. 7. Procédé selon la revendication 6, caractérisé en ce que, le segment de réseau étant un tunnel entre un premier sous-réseau auquel est connecté le dispositif émetteur et un second sous-réseau auquel est connecté le dispositif récepteur, ledit tunnel comprenant un ensemble de canaux chacun associé à un protocole de transport, le groupe de critères de sélection comprend en outre :- ladite bande passante cible résultant d'un arrêt d'un flux transitant sur un canal donné du tunnel, un autre flux transitant sur ledit canal donné est favorisé. 8. Procédé selon l'une quelconque des revendications 5 à 7, caractérisé en ce que, en cas de détection d'une perte d'un desdits paquets en transit, ledit procédé est réinitialisé par retour à ladite étape de sélection (500) d'au moins un flux de données. 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite phase temporaire comprend une étape de sécurisation de la transmission sur le segment de réseau du paquet de début et de chaque paquet sélectionné. 10. Procédé selon la revendication 9, caractérisé en ce que ladite étape de sécurisation comprend au moins une étape appartenant au groupe comprenant : - utilisation d'un mode de transport fiable du segment de réseau pour transmettre le paquet de début et chaque paquet sélectionné ; - augmentation d'un niveau de priorité associé au paquet de début et à chaque paquet sélectionné ; - mémorisation du paquet de début et de chaque paquet sélectionné, afin de pouvoir les retransmettre en cas de mauvaise transmission sur le segment de réseau. 11. Procédé selon l'une quelconque des revendications 9 et 10, caractérisé en ce que, le segment de réseau étant un tunnel entre un premier sous-réseau auquel est connecté le dispositif émetteur et un second sous-réseau auquel est connecté le dispositif récepteur, ledit tunnel comprenant un ensemble de canaux chacun associé à un protocole de transport, ladite étape de sécurisation comprend une étape de : -transmission d'au moins deux copies, sur au moins deux canaux dudit tunnel, du paquet de début et de chaque paquet sélectionné. 12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce qu'il comprend les étapes suivantes : - réception d'un message d'acquittement positif pour ledit paquet de début ou pour un desdits paquets sélectionnés, ledit message reçu comprenant une information envoyée par le dispositif récepteur à destination du dispositif émetteur, ladite information étant une information de protocole encapsulé par ledit protocole de transport auquel ledit flux de données est associé ;-transmission de ladite information dans un message d'acquittement à émettre ultérieurement vers le dispositif émetteur. 13. Procédé selon la revendication 12, caractérisé en ce que ladite information envoyée par le dispositif récepteur est une commande de contrôle dudit flux de données à destination du dispositif émetteur. 14. Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce qu'il comprend une étape de gestion de cadencement de transmission des messages d'acquittement positif anticipé pendant ladite phase temporaire, ladite étape de gestion comprenant l'étape suivante : pour les paquets sélectionnés dont le numéro de séquence est supérieur ou égal à un nombre déterminé qui est fonction du numéro de séquence dudit paquet de début et d'une estimation d'un nombre desdits paquets en transit entre le dispositif émetteur et le dispositif récepteur, transmission des messages d'acquittement positif anticipé avec un délai qui tient compte d'une estimation d'un temps d'aller-retour entre le dispositif émetteur et le dispositif récepteur. 15. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 14, lorsque ledit programme est exécuté sur un ordinateur. 16. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 14. 17. Dispositif d'entrée d'un segment de réseau compris dans un réseau de communication, permettant la transmission de données d'un flux de données, dit flux à stimuler, provenant d'un dispositif émetteur et à destination d'un dispositif récepteur via ledit segment de réseau et selon un protocole de transport par paquets avec acquittement, chaque paquet étant associé à un numéro de séquence (SN), ledit dispositif d'entrée étant caractérisé en ce qu'il comprend les moyens suivants, permettant de traiter ledit flux à stimuler :- des moyens de détermination, permettant de déterminer un paquet de début associé à un numéro de séquence (INIT) supérieur aux numéros de séquence de paquets, dits paquets en transit, transmis par ledit dispositif d'entrée sur le segment de réseau mais pour lesquels le dispositif d'entrée n'a pas encore reçu un message d'acquittement positif (ACK) provenant du dispositif récepteur ; - des premiers moyens de sélection, permettant de sélectionner, en fonction d'une consommation d'une bande passante cible pour la transmission dudit flux, de paquets dudit flux suivant ledit paquet de début, et pour chacun desquels un message d'acquittement positif anticipé doit être transmis vers le dispositif émetteur ; - des moyens de transmission, activés sur réception d'un message d'acquittement positif dudit paquet de début provenant du dispositif récepteur, permettant de transmettre vers le dispositif émetteur, pendant une phase temporaire de durée fonction du nombre de paquets sélectionnés, un message d'acquittement positif anticipé (pré-ACK) pour ledit paquet de début et pour chaque paquet sélectionné ; -des moyens de suppression, permettant de supprimer des acquittements positifs reçus du dispositif récepteur qui correspondent auxdits paquets sélectionnés et pour lesquels un message d'acquittement positif anticipé a été transmis. 18. Dispositif selon la revendication 17, caractérisé en ce que lesdits moyens de sélection de paquets suivant ledit paquet de début comprennent : - des moyens d'obtention d'un nombre maximal de paquets autorisés à être simultanément en transit entre le dispositif émetteur et le dispositif récepteur, dite valeur consigne de taille de fenêtre d'émission, en fonction de ladite bande passante cible ; - des moyens d'obtention d'un nombre courant de paquets en transit entre le dispositif émetteur et le dispositif récepteur, dite valeur courante de taille de fenêtre d'émission ; - des moyens de détermination du nombre de paquets, dits paquets sélectionnés, nécessaires pour permettre un accroissement de ladite valeur courante jusqu'à ladite valeur consigne de taille de fenêtre d'émission. 30 19. Dispositif selon l'une quelconque des revendications 17 et 18, caractérisé en ce qu'il comprend des moyens d'interruption, permettant d'interrompre ladite phase temporaire de façon anticipée en cas de détection d'une utilisation par le dispositif émetteur d'au moins une partie prédéterminée de ladite bande passante cible. 20. Dispositif selon l'une quelconque des revendications 17 à 20, caractérisé en ce qu'il comprend des premiers moyens de réinitialisation, activés en cas de détection d'une perte d'un desdits paquets en transit, permettant de réinitialiser lesdits moyens de détermination d'un paquet de début. 21. Dispositif selon l'une quelconque des revendications 17 à 20, caractérisé en ce que, un ensemble de flux de données passant par le dispositif d'entrée pour accéder au segment de réseau, le dispositif comprend : - des deuxièmes moyens de sélection, permettant de sélectionner au moins un flux de données parmi ledit ensemble de flux de données, chaque flux sélectionné étant un flux à stimuler. 22. Dispositif selon la revendication 21, caractérisé en ce que lesdits deuxièmes moyens de sélection d'au moins un flux de données utilisent au moins un critère de sélection appartenant au groupe comprenant : - un flux de type TCP en phase de démarrage lent est rejeté de la sélection ; - un flux possédant un chiffrement est rejeté de la sélection ; - un flux proposant une marge, supérieure à un seuil prédéterminé, pour un accroissement de ressources réseau consommées pour transmettre ledit flux est favorisé. 23. Dispositif selon la revendication 22, caractérisé en ce que, le segment de réseau étant un tunnel entre un premier sous-réseau auquel est connecté le dispositif émetteur et un second sous-réseau auquel est connecté le dispositif récepteur, ledit tunnel comprenant un ensemble de canaux chacun associé à un protocole de transport, le groupe de critères de sélection comprend en outre : - ladite bande passante cible résultant d'un arrêt d'un flux transitant sur un canal donné du tunnel, un autre flux transitant sur ledit canal donné est favorisé. 24. Dispositif selon l'une quelconque des revendications 21 à 23, caractérisé en ce qu'il comprend des deuxièmes moyens de réinitialisation, activés en cas de détectiond'une perte d'un desdits paquets en transit, permettant de réinitialiser lesdits deuxièmes moyens de sélection d'au moins un flux de données. 25. Dispositif selon l'une quelconque des revendications 17 à 24, caractérisé en ce qu'il comprend des moyens de sécurisation, activés pendant ladite phase temporaire, permettant de sécuriser la transmission sur le segment de réseau du paquet de début et de chaque paquet sélectionné. 26. Dispositif selon la revendication 25, caractérisé en ce que lesdits moyens de sécurisation comprennent au moins un moyen appartenant au groupe comprenant : - un moyen d'utilisation d'un mode de transport fiable du segment de réseau pour transmettre le paquet de début et chaque paquet sélectionné ; - un moyen permettant d'augmenter un niveau de priorité associé au paquet de début et à chaque paquet sélectionné ; - un moyen de mémorisation du paquet de début et de chaque paquet sélectionné, afin de pouvoir les retransmettre en cas de mauvaise transmission sur le segment de réseau. 27. Dispositif selon l'une quelconque des revendications 25 et 26, caractérisé en ce que, le segment de réseau étant un tunnel entre un premier sous-réseau auquel est connecté le dispositif émetteur et un second sous-réseau auquel est connecté le dispositif récepteur, ledit tunnel comprenant un ensemble de canaux chacun associé à un protocole 20 de transport, lesdits moyens de sécurisation comprennent : - des moyens de transmission d'au moins deux copies, sur au moins deux canaux dudit tunnel, du paquet de début et de chaque paquet sélectionné. 28. Dispositif selon l'une quelconque des revendications 17 à 27, caractérisé en ce qu'il comprend : - des moyens de réception d'un message d'acquittement positif pour ledit paquet de début ou pour un desdits paquets sélectionnés, ledit message reçu comprenant une information envoyée par le dispositif récepteur à destination du dispositif émetteur, ladite information étant une information de protocole encapsulé par ledit protocole de transport auquel ledit flux de données est associé ; - des moyens de transmission de ladite information dans un message d'acquittement à émettre ultérieurement vers le dispositif émetteur. 15 25 30 29. Dispositif selon la revendication 28, caractérisé en ce que ladite information envoyée par le dispositif récepteur est une commande de contrôle dudit flux de données à destination du dispositif émetteur. 30. Dispositif selon l'une quelconque des revendications 17 à 29, caractérisé en ce qu'il comprend des moyens de gestion de cadencement de transmission des messages d'acquittement positif anticipé pendant ladite phase temporaire, lesdits moyens de gestion comprenant les moyens suivants, activés pour les paquets sélectionnés dont le numéro de séquence est supérieur ou égal à un nombre déterminé qui est fonction du numéro de séquence dudit paquet de début et d'une estimation d'un nombre desdits paquets en transit entre le dispositif émetteur et le dispositif récepteur : des moyens de transmission des messages d'acquittement positif anticipé avec un délai qui tient compte d'une estimation d'un temps d'aller-retour entre le dispositif émetteur et le dispositif récepteur.