Brevet FR3051090A1 — publié le 20171110

La présente invention se rapporte au domaine de la mesure de performances d'une connexion Internet d'un terminal. L'invention concerne plus particulièrement des moyens de mesure, pour une connexion de type Internet sur un terminal, d'un débit montant, d'un débit descendant et d'un temps de réponse. Il existe de nombreuses situations pour lesquelles l'obtention de mesures de performances fiables d'une connexion Internet d'un terminal s'avère importante. On peut notamment citer la conduite d'opérations de maintenance et/ou de diagnostics de problèmes de connexion, ou encore le déploiement et la planification d'infrastructures réseau. Plus précisément, trois métriques, relatives à la connexion Internet d'un terminal, sont généralement employées: une mesure d'un débit montant sur la connexion Internet depuis le terminal vers un serveur distant accessible par Internet; une mesure d'un débit descendant sur la connexion Internet depuis un serveur distant accessible par Internet vers le terminal une mesure d'un temps de réponse sur la connexion Internet, correspondant à la durée entre l'instant où le terminal envoie une requête à un serveur distant accessible par Internet et l'instant où le terminal reçoit une réponse dudit serveur distant. Typiquement, les outils de mesure de performance peuvent être mis en 20 oeuvre au moyen d'un module de mesure de performance, compris dans une page Web, apte à être affichée par un navigateur Web s'exécutant sur le terminal. Or, le déploiement des outils de mesure de performance de l'état de l'art pose généralement de nombreux problèmes. Ainsi, il est fréquent, notamment dans le cas de terminaux déployés dans un réseau d'entreprise, que la connexion Internet soit 25 établie au travers d'un dispositif de filtrage - typiquement désigné par le terme anglo-saxon « firewall » et/ou d'un portail de sécurité, du type a ntivirus en particulier. Aussi, certains outils de mesure de performance ne sont pas adaptés à être déployés dans ce type de configuration réseau, car le dispositif de filtrage peut bloquer partiellement ou totalement le fonctionnement de ces outils et les analyses conduites 30 par le dispositif de filtrage et/ou du portail de sécurité sur les données échangées au moyen de la connexion Internet peuvent fausser les résultats. En outre, l'installation de ces outils de mesure de performance peut s'avérer complexe et coûteuse, car la comptabilité des technologies employées pour la mise en oeuvre de ces outils avec celles des navigateurs Web généralement déployés n'est pas toujours optimale. En 35 outre, pour atteindre un niveau de fiabilité suffisant, il est courant que les outils de 3051090 2 mesure de performance de l'état de l'art nécessitent de conduire les mesures sur des durées longues, typiquement plus de 10 secondes pour chaque type de mesures. C'est pourquoi il existe encore un besoin pour des moyens de mesure, 5 pour une connexion de type Internet sur un terminal, d'un débit montant, d'un débit descendant et d'un temps de réponse, adapté à être déployé sur des terminaux utilisant des technologies standardisées et répandues, fiable y compris lorsque des logiciels antivirus sont déployés dans le réseau, apte à fonctionner sur de nombreuses topologies réseaux y compris derrière un dispositif de filtrage. 10 L'invention vise à fournir des moyens de mesure, pour une connexion de type Internet sur un terminal, d'un débit montant, d'un débit descendant et d'un temps de réponse. L'invention a également pour objet de fournir des moyens aptes à être déployés sur des terminaux utilisant des technologies standardisées et 15 répandues, fiables y compris lorsque des logiciels antivirus sont déployés dans le réseau, apte à fonctionner sur de nombreuses topologies réseau y compris derrière un dispositif de filtrage. Un ou plusieurs de ces objets sont remplis par le procédé et le module objets des revendications indépendantes. Les revendications dépendantes fournissent 20 en outre des solutions à ces objets et/ou d'autres avantages. Plus particulièrement, selon un premier aspect, l'invention se rapporte à un procédé pour déterminer au moins une mesure de performance d'une connexion Internet d'un terminal. Le procédé comporte: 25 - une première étape d'établissement, selon un protocole sécurisé, au moyen de la connexion Internet du terminal, d'un canal de communication bidirectionnel avec un serveur de débit ; - une deuxième étape de détermination d'au moins une mesure de performance, en fonction d'informations collectées relatives à au moins un 30 échange de données, sur le canal de communication, entre le terminal et le serveur de débit. Le canal de communication bidirectionnel peut être établi en employant le protocole de transfert hypertexte sécurisé. Ledit au moins un échange de données, sur le canal de communication, entre le terminal et le serveur de débit, peut être réalisé en 35 employant le protocole WebSocket. L'utilisation du protocole WebSocket permet d'établir des connexions persistantes avec le serveur. Une fois la connexion établie, les 3051090 3 en-têtes HTTP ne sont plus nécessaires, un protocole spécifique, optimisé pour mesurer les débits et temps de réponse, peut alors être utilisé. Le serveur peut envoyer des données au client sans avoir au préalable reçu une requête du client. Le procédé peut en particulier être mis en oeuvre au moyen des 5 interfaces de programmation standards, présentes dans les navigateurs Web, comme les interfaces de programmation JavaScript, natives au HTML5, et WebSocket. Le protocole HTTPS peut être mis en oeuvre en utilisant le port 443 standard du HTTPS . Le port 443 est autorisé dans de nombreux réseaux, y compris en entreprise, car il est aujourd'hui indispensable pour consulter les sites Web. 10 L'utilisation d'un canal de communication sécurisé (crypté en particulier) vise non pas à empêcher l'accès aux données échangées, mais à la création d'un tunnel opaque entre le terminal et serveur de débit. Ainsi, les antivirus et les proxys opérateur ne voient pas le contenu échangé et ne les analysent donc pas. Par ailleurs, le cryptage n'augmente pas la taille des données échangées. 15 Le canal de communication bidirectionnel avec le serveur de débit peut être établi au moyen d'un ensemble d'informations de connexion, reçu d'un système d'information central. Ladite au moins une mesure peut être une mesure d'un débit descendant, sur le canal de communication sécurisé, depuis le serveur de débit vers le terminal; la mesure du débit descendant étant déterminé en: recevant, sur le terminal, des blocs de données, transmis par le serveur de débit, sur le canal de communication sécurisé, pendant une première période de 25 durée déterminée; déterminant un rapport entre un premier volume de données relatif aux blocs de données reçus par le terminal et la durée de la première période. Les blocs de données, sur le canal de communication sécurisé, peuvent être transmis dans des paquets comportant des en-têtes, le premier volume de données étant en 30 outre déterminé sans tenir compte des en-têtes desdits paquets. La durée de la première période est par exemple de sensiblement 10 secondes. Ladite au moins une mesure peut être une mesure d'un débit montant, sur le canal de communication sécurisé, depuis le terminal, vers le serveur de débit ; la mesure du 35 débit montant étant déterminé en: 3051090 4 transmettant, depuis le terminal vers le serveur de débit, des blocs de données, sur le canal de communication sécurisé, pendant une deuxième période de durée déterminée ; déterminant un rapport entre un deuxième volume de données relatif 5 aux blocs de données transmis par le terminal et la durée de la deuxième période. La taille de chacun des blocs de données peut être fonction d'une mesure instantanée du débit montant, sur le canal de communication sécurisé, depuis le terminal vers le serveur de débit. La durée de la deuxième période est par exemple de sensiblement 10 secondes. 10 Ladite au moins une mesure peut être une mesure d'un temps de réponse du serveur de débit à une requête du terminal, sur le canal de communication sécurisé; la mesure du temps de réponse étant déterminé en: transmettant, depuis le terminal vers le serveur de débit, des requêtes de 15 données, sur le canal de communication sécurisé, pendant une troisième période de durée déterminée ; déterminant une durée moyenne entre l'instant de transmission de chacune des requêtes de données et l'instant de la réception d'une réponse du serveur de débit à ladite requête. 20 Le terminal peut cesser de transmettre des requêtes de données, si une des réponses du serveur de débit est reçue après plus de sensiblement 100 millisecondes après la transmission de la requête correspondante. La durée de la troisième période est par exemple de sensiblement 10 secondes. Selon un deuxième aspect, l'invention se rapporte à un programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon le premier aspect, lorsque ledit programme est exécuté par un processeur. Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code 30 intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.filEn particulier, il est possible d'utiliser le langage C/C++, le langage JavaTM, des langages de script, tels que notamment tcl, JavaScript, python, Perl qui permettent une génération de code «à la demande » et ne nécessitent pas de surcharge significative pour leur génération ou 35 leur modification. 3051090 5 Selon un troisième aspect, l'invention se rapporte à un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon le premier aspect. Le support d'informations peut être n'importe quelle entité 5 ou n'importe quel dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD-ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou 10 optique, qui peut être acheminé par un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau Internet ou Intranet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 15 Selon un quatrième aspect, l'invention se rapporte à un module, adapté à mettre en oeuvre le procédé selon le premier aspect, pour déterminer au moins une mesure de performance d'une connexion Internet d'un terminal, comportant: - des moyens d'établissement, selon un protocole sécurisé, au moyen de la 20 connexion Internet du terminal, d'un canal de communication bidirectionnel avec un serveur de débit ; - des moyens de détermination d'au moins une mesure de performance, en fonction d'informations collectées relatives à au moins un échange de données, sur le canal de communication, entre le terminal et le serveur de 25 débit. Le canal de communication bidirectionnel peut être établi en employant le protocole de transfert hypertexte sécurisé. Ledit au moins un échange de données, sur le canal de communication, entre le terminal et le serveur de débit, peut être réalisé en employant le protocole WebSocket. D'autres particularités et avantages de la présente invention apparaîtront, dans la description ci-après de modes de réalisation, en référence aux dessins annexés, dans lesquels : la figure 1 est un schéma d'architecture d'un système de mesure de performances d'une connexion Internet d'un terminal, selon un mode de réalisation; 3051090 6 la figure 2 est un synoptique des étapes d'un procédé de mesure de performances d'une connexion Internet d'un terminal, selon un mode de réalisation; la figure 3 est un synoptique des sous-étapes du procédé de mesure, 5 selon un mode de réalisation, pour mesurer le débit de la voie montante depuis le terminal vers le serveur de débit; la figure 4 est un synoptique des sous-étapes du procédé de mesure, selon un mode de réalisation, pour mesurer le débit de la voie descendante depuis le serveur de débit vers le terminal; 10 la figure 5 est un synoptique des sous-étapes du procédé de mesure, selon un mode de réalisation, pour mesurer le temps de réponse du serveur de débit sur requête du terminal. On se réfère à la figure 1. Le système de mesure selon l'invention 15 comporte au moins un terminal 10 adapté à être couplé à un réseau 15 de communication. Le terminal 10 est pourvu d'un module de mesure de performance 12. Le système de mesure comporte également au moins un serveur de débit 20 accessible par l'intermédiaire du réseau de communication 15 et un système d'information central 30 accessible par l'intermédiaire du réseau de communication 20 15. Le terminal 10 comporte des moyens d'établissement de connexions avec des dispositifs distants couplé à Internet. Le terminal 10 est par exemple un ordinateur, un téléphone mobile, une tablette, un serveur, et plus généralement tout dispositif apte à échanger des données par l'intermédiaire du réseau 15. Le terminal 25 10 est adapté pour exécuter un jeu d'instructions formant un logiciel, afin de mettre en oeuvre les étapes du procédé devant être exécutées par le terminal 10 et décrites ci-après en regard des figures 2, 3, 4 et 5. Le terminal peut en particulier être adapté pour exécuter un jeu d'instructions formant un logiciel de navigation Web, apte à exécuter une application Web adaptée pour mettre en oeuvre les étapes du procédé 30 devant être exécutées par le module de mesure de performance 12 décrite ci-après en regard des figures 2, 3, 4, et 5. Le réseau 15 de communication est par exemple un réseau de type Ethernet comportant un point d'accès à Internet. Le réseau 15 comprend typiquement des moyens d'interconnexion usuels pour permettre l'acheminement des données, tel 35 que des routeurs, des ponts, des pare-feu, des commutateurs, etc. Aussi, l'accès à Internet par l'intermédiaire du réseau 15 de communication peut être réalisé au 3051090 7 travers d'un ou plusieurs dispositifs de filtrage ou pare-feu, passerelles de sécurité, systèmes antivirus et/ou anti-menaces. Le réseau 15 de communication peut être un réseau d'entreprise. Le module de mesure de performance 12 est configuré pour permettre 5 l'échange bidirectionnel, par l'intermédiaire du réseau 15 de communication, de requêtes et/ou de données avec le serveur de débit 20. Le module de mesure de performance 12 est configuré pour permettre la mise en oeuvre du protocole WebSocket, tel que décrit notamment dans le document Request For Comments 6455 (http://tools.ietf.org/html/rfc6455), et plus particulièrement, le support de la mise à 10 niveau vers le protocole WebSocket, la gestion des trames masquées, le support de la fragmentation et le support des trames fermées dites « close frames » en anglais. De plus, le module de mesure de performance 12 est configuré pour permettre l'établissement de canaux de communication sécurisés vers le serveur de débit 20, en particulier en employant le protocole de transfert hypertexte sécurisé, plus 15 communément désign par l'acronyme anglo-saxon HTTPS pour « HyperText Transfer Protocol Secure ». Chaque serveur de débit 20 comporte un module de services 14 apte à permettre la réalisation de mesures de performances, sur réception de commandes transmises par le terminal 10. Le module de services 14 est configuré pour permettre 20 l'échange bidirectionnel, par l'intermédiaire du réseau 15 de communication, de requêtes et/ou de données avec le terminal 10. Le module de services 14 est configuré pour permettre la mise en oeuvre du protocole WebSocket, tel que décrit notamment dans le document Request For Comments 6455 (http://tools.ietf.org/html/rfc6455), et plus particulièrement, le support de la mise à 25 niveau vers le protocole WebSocket, la gestion des trames masquées, le support de la fragmentation et le support des trames fermées dites « close frames » en anglais. Le serveur de débit 20 est configuré pour permettre la transmission de flux de données aléatoires, au moyen du protocole Websocket, de façon continue et simultanée sur plusieurs connexions, à destination de plusieurs clients simultanément, 30 et à très haut débit. L'utilisation du protocole WebSocket permet notamment au serveur de débit 20 de transmettre au terminal 10 des paquets de données sans interruption et de façon illimitée. De plus, le module de services 14 est configuré pour permettre l'établissement de canaux de communication sécurisés vers le terminal 20, en 35 particulier en employant le protocole de transfert hypertexte sécurisé, plus communément désigné par l'acronyme anglo-saxon HTTPS pour « HyperText Transfer 3051090 8 Protocol Secure ». Le module de services 14 embarque un certificat numérique, délivré par une autorité de certification reconnue, apte à permettre l'authentification du serveur de débit 20 et le chiffrement des données échangé au moyen de canaux sécurisés HTTPS. 5 Dans un mode de réalisation, tous les serveurs de débit 20 sont accessibles au moyen d'un même nom de domaine et partagent un même certificat numérique CERT. À titre d'exemple, si, le nom de domaine est « domain.net », et si le système de mesure de performance comporte deux serveurs de débits, ces derniers seront accessibles respectivement via les sous-domaines « a.domain.net » et 10 « b.domain.net ». Le certificat numérique CERT est valide pour le nom de domaine domain.net, et les sous-domaines correspondant, c'est-à-dire dans notre exemple « a.domain.net » et « b.domain.net ». Le certificat numérique CERT est dit certificat joker, ou « wildcard » en anglais. 15 Les étapes du procédé décrit ci-après en regard des figures 2, 3, 4 et 5 peuvent être mises en oeuvre dans un logiciel par l'exécution d'un jeu d'instructions ou d'un programme par un dispositif de traitement programmable, tels un ordinateur personnel, un processeur de traitement du signal et/ou un microcontrôleur ; ou alternativement de manière matérielle par une machine ou un composant dédié, tel 20 un circuit logique programmable - par exemple de type couramment désigné par l'acronyme anglo-saxon « FPGA » pour « Field-Programmable Gate Array », ou un circuit intégré propre à une application désigné plus couramment par l'acronyme anglo-saxon « ASIC » pour « Application-Specific Integrated Circuit ». 25 On se réfère maintenant à la figure 2. Le procédé de mesure de performances d'une connexion Internet d'un terminal, selon un mode de réalisation, est notamment adapté à être mis en oeuvre par le système de mesure de performance, selon l'invention, représenté sur la figure 1. Les étapes du procédé de mesures de performances, mises en oeuvre par le terminal 10, peuvent être 30 accomplies par le module de mesures de performances 12 exécutant, dans un navigateur Web, une application. Une demande d'information de connexion 10, émise par le terminal 10, est transmise au système d'information central 30, dans une étape 110. Après réception de la demande d'information de connexion 10, le 35 système d'information central 30, détermine au moins un ensemble d'informations de connexions à un des serveurs de débit 20 disponibles, et transmet ledit au moins 3051090 9 ensemble d'informations au terminal 120, au cours d'une étape 120. Si plusieurs serveurs de débit 20 sont disponibles dans le système de mesure de performance, le système d'information central 30 peut transmettre un ensemble d'informations de connexion pour chacun des serveurs de débits disponibles. L'ensemble d'informations 5 de connexion pour un des serveurs de débits 20 comporte les informations nécessaires pour que le terminal 10 puisse établir un canal de communication sécurisé avec le serveur de débit 20 correspondant. Typiquement, l'ensemble d'informations de connexion pour un des serveurs de débits 20 peut comporter une ou plusieurs informations parmi la liste non exhaustive suivante: une adresse IP, un localisateur 10 uniforme de ressource - plus couramment désigné par l'acronyme anglo-saxon URL pour « Uniform Resource Locator » -, des informations d'identifications, une liste de services disponible sur le serveur de débit concerné, une liste de protocoles supportés. Pour la maintenance de la liste des serveurs de débit disponibles, les serveurs de débits 20 peuvent transmettre, au système d'information central 30, à 15 intervalles réguliers, leurs états respectifs (étape non représentée sur la figure 2). L'ensemble d'informations est reçu par le terminal 120, au cours d'une étape 130. Si le terminal 10 a reçu, au cours de l'étape 130, une pluralité d'ensembles d'informations de connexion, le terminal 10 sélectionne un des 20 ensembles d'informations de connexion au serveur de débit 20. Le terminal 10 établit, au moyen d'un protocole sécurisé, en fonction de l'ensemble reçu ou choisi d'informations de connexion au serveur de débit 20, un canal de communication sécurisée Cs avec ledit serveur de débit 20 et détermine: - au cours d'une étape 200, une mesure MDL d'un débit descendant sur le canal de 25 communication sécurisé Cs, depuis le serveur de débit 20 vers le terminal 10; et/ou, - au cours d'une étape 300, une mesure MuL d'un débit montant sur le canal de communication sécurisé Cs, depuis le terminal 10 vers le serveur de débit 20; et/ou, 30 - au cours d'une étape 400, une mesure MLp d'un temps de réponse sur le canal de communication sécurisé Cs, correspondant à la durée entre l'instant où le terminal 10 envoie une requête au serveur de débit 30 et l'instant où le terminal 10 reçoit une réponse du serveur de débit 30. 35 Dans un mode de réalisation, au cours d'une étape 170, les mesures MDL, MUL et MLp sont transmises par le terminal 10 au système d'information centrale 30. Le 3051090 10 système d'information centrale 30 peut alors stocker les mesures MDL, MuL et MLp reçues et accuser réception de ces dernières au cours d'une étape 180. Le terminal 10 reçoit alors l'accusé de réception transmis par le système d'information centrale 30 au cours de l'étape 190. 5 On se réfère à la figure 3. L'étape 200 de détermination de la mesure MDL comporte les sous-étapes détaillées ci-après. Au cours d'une étape 210, en fonction de l'ensemble reçu ou choisi d'informations de connexion au serveur de débit 20, le terminal 10 établit le canal de 10 communication sécurisé Cs avec le serveur de débit 20. Le canal de communication sécurisé Cs est établi, en employant le protocole de transfert hypertexte sécurisé HTTPS. En cas de succès, le serveur de débit 20 retourne, au cours d'une étape 220, un message de confirmation de l'établissement du canal de communication sécurisé Cs est transmis au terminal 10. 15 Au cours d'une étape 230, le terminal 10 transmet au serveur de débit 20 une demande de substitution - «a switching protocol request » en anglais - du protocole HTTPS vers le protocole WebSocket, pour le canal de communication sécurisé Cs. En cas de succès, au cours d'une étape 240, le serveur de débit renvoie une confirmation de la substitution du protocole HTTPS vers le protocole Websocket 20 pour le canal de communication sécurisé Cs. Aussi, au cours de l'étape 200, à partir de la sous-étape 240, les échanges de données pour le canal de communication sécurisé Cs sont réalisés au moyen du protocole Websocket. Au cours d'une étape 240, à un instant initial t10, le terminal 10 transmet une demande d'envoi de blocs de données au serveur de débit 20. 25 Au cours d'une étape 250, à la suite de la réception de la demande d'envoi de blocs de données, le serveur de débit 20 transmet, au terminal 10, en continu, des blocs de données sur le canal de communication sécurisé Cs, au moyen du protocole websocket. Les blocs de données comportent typiquement une quantité prédéterminée Qb de données aléatoires. L'utilisation du protocole WebSocket 30 permet notamment au serveur de débit 20 de transmettre au terminal 10 des paquets de données sans interruption et de façon illimitée. Ainsi, à la suite de l'envoi par le terminal 10 d'une seule demande, le terminal 10 peut recevoir une quantité illimitée de données pendant toute la durée de la mesure MDL, quel que soit le débit. Ainsi, il est possible de proposer une méthode particulièrement fiable pour déterminer la 35 mesure MDL. 3051090 11 Au cours d'une étape 260, à un instant t11, le terminal 10 transmet une demande de clôture du test, au serveur de débit 20. Avantageusement, le terminal 10 peut transmettre la demande de clôture du test, au serveur de débit 20, sensiblement 10 secondes après l'instant tO. 5 Aussi, au cours de l'étape 260, la mesure MDL est déterminée en: - déterminant une quantité Ca relative à la taille des blocs de données reçus, du serveur de débit 20, entre l'instant t10 et l'instant t11; - déterminant une durée D1 écoulée entre l'instant t10 et l'instant t11; - déterminant un rapport entre la quantité Ca et la durée Dl. 10 Dans un mode de réalisation, l'utilisation du protocole WebSocket entraînant un ajout d'un en-tête pour chaque bloc de données transmis, la quantité Ca est déterminée en retirant à la taille des blocs de données reçus, la taille des entêtes utilisés pour la transmission entre le serveur de débit et le terminal. Le serveur de débit 20 peut en particulier comptabiliser le volume de données réellement 15 transféré, et le transmettre au terminal 20 après réception de la demande de clôture du test. Le terminal 10 peut déterminer précisément la mesure MDL, en tenant compte des octets d'en-têtes et ceux liés à la fragmentation des messages. Au cours d'une étape 270, après réception de la demande de clôture du test, le serveur de débit 20 cesse de transmettre des blocs de données au terminal 10, 20 et transmet un accusé de réception au terminal correspondant à la fin du test. On se réfère à la figure 4. L'étape 300 de détermination de la mesure MuL comporte les sous-étapes détaillées ci-après. Au cours d'une étape 310, en fonction de l'ensemble reçu ou choisi 25 d'informations de connexion au serveur de débit 20, le terminal 10 établit le canal de communication sécurisée Cs avec le serveur de débit 20. La connexion sécurisée Cs est établi, en employant le protocole de transfert hypertexte sécurisé HTTPS. En cas de succès, le serveur de débit 20 retourne, au cours d'une étape 320, un message de confirmation de l'établissement du canal de communication sécurisé Cs est transmis 30 au terminal 10. Au cours d'une étape 330, le terminal 10 transmet au serveur de débit 20 une demande de substitution - « a switching protocol request » en anglais - du protocole HTTPS vers le protocole WebSocket, pour le canal de communication sécurisé Cs. En cas de succès, au cours d'une étape 340, le serveur de débit renvoie 35 une confirmation de la substitution du protocole HTTPS vers le protocole Websocket pour le canal de communication sécurisé Cs. Aussi, au cours de l'étape 300, à partir de 3051090 12 la sous-étape 340, les échanges de données pour le canal de communication sécurisé Cs sont réalisés au moyen du protocole Websocket. Au cours d'une étape 350, à partir d'un instant initial t20 jusqu'à un instant t2N, le terminal 10 transmet un nombre N de blocs Bn de données au serveur 5 de débit 20, sur le canal de communication sécurisé Cs, au moyen du protocole websocket. Au cours d'une étape 360, entre l'instant initial t20 et l'instant t2N, le serveur de débit 20 reçoit les blocs Bn de données, et transmet au terminal 10 pour chaque bloc Bn reçu un message d'acquittement ACQn. Dans un mode de réalisation avantageux, la taille On de chaque bloc Bn 10 est fonction d'une mesure instantanée du débit MIDL de la voie descendante depuis le serveur de débit 20 vers le terminal 10. La mesure instantanée du débit MIDL est par exemple déterminée en: - obtenant la taille On du bloc Bn envoyé à l'instant t2n; - déterminant la durée Dn écoulée entre l'instant t2n et l'instant t2nacq où le 15 message d'acquittement ACQn correspondant au bloc Bn est reçu sur le terminal 10; - déterminant un rapport entre la quantité On et la durée Dn. La taille On de chaque bloc Bn peut ainsi être choisi en fonction de la mesure instantanée du débit MIDL, en maximisant la taille On pour limiter l'impact de la 20 latence sur la mesure MuL, tout en étant augmentant progressivement la taille On par rapport la taille On-1 de sorte à avoir une augmentation régulière de la taille. Au cours d'une étape 370, après l'instant t2N, le terminal 10 transmet une demande de clôture du test, au serveur de débit 20. Avantageusement, le terminal 10 peut transmettre la demande de clôture du test, au serveur de débit 20, 25 sensiblement 10 secondes après l'instant t20. Aussi, au cours de l'étape 370, la mesure MuL est déterminée en: - déterminant une quantité 02 relative à la taille des blocs de données transmis au serveur de débit 20, entre l'instant t20 et l'instant t2N; - déterminant une durée D2 écoulée entre l'instant t20 et l'instant t2N; 30 - déterminant un rapport entre la quantité 02 et la durée D2. Au cours d'une étape 380, après réception de la demande de clôture du test, le serveur de débit 20 transmet un accusé de réception au terminal correspondant à la fin du test. 35 On se réfère à la figure 5. L'étape 400 de détermination de la mesure NALp comporte les sous-étapes détaillées ci-après. 3051090 13 Au cours d'une étape 410, en fonction de l'ensemble reçu ou choisi d'informations de connexion au serveur de débit 20, le terminal 10 établit le canal de communication sécurisé Cs avec le serveur de débit 20. Le canal de communication sécurisée Cs est établi, en employant le protocole de transfert hypertexte sécurisé 5 HTTPS. En cas de succès, le serveur de débit 20 retourne, au cours d'une étape 420, un message de confirmation de l'établissement du canal de communication sécurisée Cs est transmis au terminal 10. Au cours d'une étape 430, le terminal 10 transmet au serveur de débit 20 une demande de substitution - « a switching protocol request » en anglais - du 10 protocole HTTPS vers le protocole WebSocket, pour le canal de communication sécurisé Cs. En cas de succès, au cours d'une étape 440, le serveur de débit renvoie une confirmation de la substitution du protocole HTTPS vers le protocole Websocket pour le canal de communication sécurisé Cs. Aussi, au cours de l'étape 400, à partir de la sous-étape 440, les échanges de données pour le canal de communication sécurisé 15 Cs sont réalisés au moyen du protocole Websocket. Au cours d'une étape 450, à partir d'un instant initial t30 jusqu'à un instant t3N, le terminal 10 transmet un nombre N de requête Rn au serveur de débit 20, sur le canal de communication sécurisé Cs, au moyen du protocole websocket. Au cours d'une étape 460, entre l'instant initial t30 et l'instant t3N, le serveur de débit 20 20 reçoit les requêtes Rn de données, et transmet, au terminal 10, pour chaque requête Rn, un message de réponse REPn reçu sur le terminal 10 à un instant t3REPn. Dans un mode de réalisation avantageux, adapté en particulier lorsque la durée Dln entre une requête Rn et la réponse REPn correspondante est courte, tant que la durée Dln est inférieure ou égale sensiblement à 100 ms, à partir de l'instant 25 initial t30 jusqu'à l'instant t3N, le terminal 10 transmet le nombre N de requête Rn au serveur de débit 20. En revanche, si la durée Dln est supérieure sensiblement à 100 ms, le terminal 10 cesse de transmettre les requêtes Rn au serveur de débit 20, la dernière requête envoyée étant notée RF. De cette façon il nous est possible d'obtenir une mesure fiable même pour les temps de réponse inférieurs à 10 ms et ce, quel que 30 soit le navigateur utilisé. Au cours d'une étape 470, après l'instant t3N, le terminal 10 transmet une demande de clôture du test, au serveur de débit 20. Avantageusement, le terminal 10 peut transmettre la demande de clôture du test, au serveur de débit 20, sensiblement 10 secondes après l'instant t30. 35 Aussi, au cours de l'étape 470, la mesure NALp est déterminée en: 3051090 14 - pour chaque réponse REPx, déterminant la durée D3x écoulée entre l'instant t2x où la requête Rx correspondante a été envoyée, et l'instant t3REPx où la réponse a été reçue; - déterminant la moyenne des durées D3x. 5 Au cours d'une étape 480, après réception de la demande de clôture du test, le serveur de débit 20 transmet un accusé de réception au terminal correspondant à la fin du test. REVENDICATIONS1. Procédé pour déterminer au moins une mesure de performance d'une connexion Internet d'un terminal (10), caractérisé en ce qu'il comporte: une première étape d'établissement, selon un protocole sécurisé, au moyen -de la connexion Internet du terminal, d'un canal de communication bidirectionnel avec un serveur de débit (20) ; une deuxième étape de détermination d'au moins une mesure de performance, en fonction d'informations collectées relatives à au moins un échange de données, sur le canal de communication, entre le terminal et le serveur de débit. 2. Procédé selon la revendication 1, dans lequel, au cours de la première étape, le canal de communication bidirectionnel est établi (210; 310; 410), en employant le 15 protocole de transfert hypertexte sécurisé. 3. Procédé selon l'une quelconque des revendications précédentes, dans lequel ledit au moins un échange de données, sur le canal de communication, entre le terminal et le serveur de débit, est réalisé en employant le protocole WebSocket. 20 4. Procédé selon l'une quelconque des revendications précédentes, le canal de communication bidirectionnel avec le serveur de débit (20) est établi au moyen d'un ensemble d'informations de connexion, reçu (110) d'un système d'information central (30). 25 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel, ladite au moins une mesure est une mesure d'un débit descendant, sur le canal de communication sécurisé (Cs), depuis le serveur de débit (20) vers le terminal (10); la mesure du débit descendant étant déterminé en: 30 recevant (250), sur le terminal (10), des blocs de données, transmis par le serveur de débit (20), sur le canal de communication sécurisé, pendant une première période de durée déterminée; déterminant (260) un rapport entre un premier volume de données relatif aux blocs de données reçus par le terminal et la durée de la première période. -35 3051090 16 6. Procédé selon la revendication 5, dans lequel les blocs de données, sur le canal de communication sécurisé, sont transmis dans des paquets comportant des en-têtes, le premier volume de données étant en outre déterminé sans tenir compte des en-têtes 5 desdits paquets. 7. Procédé selon la revendication 5 ou 6, dans lequel la durée de la première période est de sensiblement 10 secondes. 10 8. Procédé selon l'une quelconque des revendications précédentes, dans lequel, ladite au moins une mesure est une mesure d'un débit montant, sur le canal de communication sécurisé (Cs), depuis le terminal (10) vers le serveur de débit (20); la mesure du débit montant étant déterminé en: transmettant (350), depuis le terminal (10) vers le serveur de débit (20), 15 des blocs de données, sur le canal de communication sécurisé, pendant une deuxième période de durée déterminée; déterminant (360) un rapport entre un deuxième volume de données relatif aux blocs de données transmis par le terminal et la durée de la deuxième période. 20 9. Procédé selon la revendication 8, dans lequel la taille (On) de chacun des blocs de données est fonction d'une mesure instantanée du débit montant, sur le canal de communication sécurisé (Cs), depuis le terminal (10) vers le serveur de débit (20). 25 10. Procédé selon la revendication 8 ou 9, dans lequel la durée de la deuxième période est de sensiblement 10 secondes. 11. Procédé selon l'une quelconque des revendications précédentes, dans lequel, ladite au moins une mesure est une mesure d'un temps de réponse du serveur de 30 débit (20) à une requête du terminal (10), sur le canal de communication sécurisé (Cs), la mesure du temps de réponse étant déterminé en: transmettant (450), depuis le terminal (10) vers le serveur de débit (20), des requêtes de données, sur le canal de comniunication sécurisé, pendant une troisième période de durée déterminée ; 3051090 17 déterminant (460) une durée moyenne entre l'instant de transmission de chacune des requêtes de données et l'instant de la réception d'une réponse du serveur de débit à ladite requête. 5 12. Procédé selon la revendication 11, dans lequel, le terminal (10) cesse de transmettre des requêtes de données, si une des réponses du serveur de débit est reçue après plus de sensiblement 100 millisecondes après la transmission de la requête correspondante. 10 13. Procédé selon la revendication 11 ou 12, dans lequel la durée de la troisième période est de sensiblement 10 secondes. 14. Programme d'ordinateur comportant des instructions pour l'exécution des étapes d'un des procédés selon l'une quelconque des revendications 1 à 13, lorsque ledit 15 programme est exécuté par un processeur. 15. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes des procédés selon l'une quelconque des revendications 1 à 13. 20 16. Module adapté pour déterminer au moins une mesure de performance d'une connexion Internet d'un terminal (10), caractérisé en ce qu'il comporte: - des moyens d'établissement, selon un protocole sécurisé, au moyen de la connexion Internet du terminal, d'un canal de communication bidirectionnel 25 avec un serveur de débit (20); - des moyens de détermination d'au moins une mesure de performance, en fonction d'informations collectées relatives à au moins un échange de données, sur le canal de communication, entre le terminal et le serveur de débit. 30