WO2017191423A1 - Moyens de mesures de performance d'une connexion internet d'un terminal - Google Patents

Moyens de mesures de performance d'une connexion internet d'un terminal Download PDF

Info

Publication number
WO2017191423A1
WO2017191423A1 PCT/FR2017/051086 FR2017051086W WO2017191423A1 WO 2017191423 A1 WO2017191423 A1 WO 2017191423A1 FR 2017051086 W FR2017051086 W FR 2017051086W WO 2017191423 A1 WO2017191423 A1 WO 2017191423A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
communication channel
server
data
measurement
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2017/051086
Other languages
English (en)
Inventor
Renaud KERADEC
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nperf Sas
Original Assignee
Nperf Sas
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nperf Sas filed Critical Nperf Sas
Publication of WO2017191423A1 publication Critical patent/WO2017191423A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Definitions

  • the present invention relates to the field of measuring the performance of an Internet connection of a terminal.
  • the invention relates more particularly to measuring means, for an Internet type connection on a terminal, a rising bit rate, a downstream bit rate and a response time.
  • a measurement of a response time on the Internet connection corresponding to the time between the moment the terminal sends a request to a remote server accessible via the Internet and the moment when the terminal receives a response from said remote server.
  • the performance measurement tools can be implemented by means of a performance measurement module, included in a web page, that can be displayed by a Web browser running on the terminal.
  • the patent document WO 2014/096742 A1 describes means for optimizing the communication between a terminal and a server, in particular in the case of a WebSocket type session, and discloses no means for measuring the overall performance of the connection. Internet of a terminal.
  • the aim of the invention is to provide measuring means, for an Internet type connection on a terminal, of a rising bit rate, a falling bit rate and a response time.
  • the invention also aims to provide means that can be deployed on terminals using standardized and widespread, reliable technologies including when antivirus software is deployed in the network, able to operate on many network topologies including behind a network. filtering device.
  • the invention relates to a method for determining at least one performance measure of an Internet connection of a terminal.
  • the method comprises the following steps, implemented by the terminal:
  • the flow server is for example configured to transmit a data string comprising data blocks, continuously, via the bidirectional communication channel.
  • the data blocks may comprise predetermined data and / or obtained / determined randomly. Transmission of the data packets to the terminal by the debit server is substantially uninterrupted, so that the terminal can receive an unlimited amount of data for the duration of the measurement, regardless of the bit rate of the bidirectional communication channel.
  • the bidirectional communication channel can be established using the secure hypertext transfer protocol. Said at least one data exchange, on the communication channel, between the terminal and the debit server, can be achieved by using the WebSocket protocol. The use of the WebSocket protocol makes it possible to establish persistent connections with the server. Once the connection is established, the HTTP headers are no longer needed, a specific protocol, optimized to measure flow rates and response time, can then be used.
  • the server can send data to the client without first receiving a request from the client.
  • the method can in particular be implemented using standard programming interfaces, present in web browsers, such as HTML5 programming interfaces, native to HTML5, and WebSocket.
  • the HTTPS protocol can be implemented using the standard port 443 of the HTTPS.
  • Port 443 is allowed in many networks, including in enterprise, because it is now essential to consult websites.
  • the use of a secure communication channel is not intended to prevent access to the data exchanged, but to the creation of a opaque tunnel between the terminal and the debit server. Thus, antivirus and proxies operator do not see the content exchanged and therefore do not analyze. In addition, encryption does not increase the size of the data exchanged.
  • the bidirectional communication channel with the debit server can be established by means of a set of connection information received from a central information system.
  • Said at least one measure may be a downstream flow measurement, on the secure communication channel, from the debit server to the terminal; the measurement of the descending flow rate being determined in:
  • the data blocks, on the secure communication channel may be transmitted in packets with headers, the first data volume being further determined without regard to the headers of said packets.
  • the duration of the first period is for example of substantially 10 seconds.
  • Said at least one measurement may be a measurement of a rising bit rate on the secure communication channel from the terminal to the debit server; the measurement of the amount of flow being determined by:
  • the size of each of the data blocks may be a function of an instantaneous measurement of the upstream rate, on the secure communication channel, from the terminal to the debit server.
  • the duration of the second period is, for example,
  • Said at least one measurement may be a measurement of a response time of the debit server to a request from the terminal, on the secure communication channel; the measurement of the response time being determined in:
  • the terminal may stop transmitting data requests, if one of the responses of the debit server is received after more than substantially 100 milliseconds after the transmission of the corresponding request.
  • the duration of the third period is for example of substantially 10 seconds.
  • Each of these programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any form which other desirable form.
  • C / C ++ language the Java TM language
  • scripting languages such as in particular such, JavaScript, python, Perl that allow "on demand” code generation And do not require significant overhead for their generation or modification.
  • the invention relates to a computer-readable recording medium on which is recorded a computer program comprising instructions for executing the steps of the method according to the first aspect.
  • the information carrier may be any entity or any device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a diskette or a hard disk.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed by an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded on an Internet or Intranet network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention relates to a module, for a terminal, adapted to implement the method according to the first aspect, for determining at least one performance measure of an Internet connection of the terminal, comprising:
  • the bidirectional communication channel can be established using the secure hypertext transfer protocol.
  • Said at least one data exchange, on the communication channel, between the terminal and the debit server, can be achieved by using the WebSocket protocol.
  • Figure 1 is an architecture diagram of a system for measuring the performance of an Internet connection of a terminal, according to one embodiment
  • FIG. 2 is a block diagram of the steps of a method for measuring the performance of an Internet connection of a terminal, according to one embodiment
  • FIG. 3 is a block diagram of the substeps of the measurement method, according to one embodiment, for measuring the uplink flow rate from the terminal to the debit server;
  • FIG. 4 is a block diagram of the substeps of the measurement method, according to one embodiment, for measuring the downlink rate from the rate server to the terminal;
  • FIG. 5 is a block diagram of the substeps of the measurement method, according to one embodiment, for measuring the response time of the bit rate server on request of the terminal.
  • the measuring system according to the invention comprises at least one terminal 10 adapted to be coupled to a communication network 15.
  • the terminal 10 is provided with a performance measurement module 12.
  • the measurement system also comprises at least one flow server 20 accessible via the communication network 15 and a central information system 30 accessible by the intermediary of the communication network 15.
  • the terminal 10 includes means for establishing connections with remote devices coupled to the Internet.
  • the terminal 10 is for example a computer, a mobile phone, a tablet, a server, and more generally any device capable of exchanging data via the network 15.
  • the terminal 10 is adapted to execute a set of instructions forming software, in order to implement the steps of the method to be executed by the terminal 10 and described below with reference to FIGS. 2, 3, 4 and 5.
  • the terminal may in particular be adapted to execute a set of instructions forming a web browser software, adapted to execute a web application adapted to implement the process steps to be performed by the performance measurement module 12 described below with reference to Figures 2, 3, 4, and 5.
  • the communication network 15 is for example an Ethernet type network comprising an access point to the Internet.
  • the network typically comprises usual interconnection means to enable the routing of data, such as routers, bridges, firewalls, switches, and so on.
  • access to the Internet via the communication network 15 can be achieved through one or more filtering devices or firewalls, security gateways, antivirus systems and / or anti-threats.
  • the communication network 15 may be an enterprise network.
  • the performance measurement module 12 is configured to allow bidirectional exchange, via the communication network 15, of requests and / or data with the flow server 20.
  • the performance measurement module 12 is configured to enable the implementation of the WebSocket protocol, as described in particular in the document Request For Comments 6455 (http://tools.ietf.org/html/rfc6455), and more particularly, the support of the level to the WebSocket protocol, management of masked frames, fragmentation support and support of closed frames called "close frames" in English.
  • the performance measurement module 12 is configured to allow the establishment of secure communication channels to the rate server 20, in particular by employing the secure hypertext transfer protocol, more commonly known by the acronym HTTPS for "HyperText Transfer Protocol Secure".
  • Each flow server 20 comprises a service module 14 capable of allowing the performance of performance measurements, on receipt of commands transmitted by the terminal 10.
  • the service module 14 is configured to allow bidirectional exchange, via the communication network 15, requests and / or data with the terminal 10.
  • the service module 14 is configured to enable the implementation of the WebSocket protocol, as described in particular in the document Request For Comments 6455 (http: // tools.ietf.org/html/rfc6455), and more particularly, the support for the WebSocket protocol upgrade, the management of masked frames, the fragmentation support and the support of closed frames known as "close frames". English.
  • the flow server 20 is configured to allow the transmission of data strings, using the Websocket protocol, in a continuous stream, simultaneously over several connections, to several clients simultaneously, and at very high speed.
  • the flow server 20 is for example configured to transmit a data string comprising data blocks, continuously, through the use of the WebSocket protocol.
  • the transmission to the terminal 20 of data packets by the debit server is substantially uninterrupted, so that the terminal can receive an unlimited amount of data throughout the duration of the measurement.
  • a data string has data blocks having predetermined data and / or randomly obtained / determined data.
  • the service module 14 is configured to allow the establishment of secure communication channels to the terminal 20, in particular by using the secure hypertext transfer protocol, more commonly referred to by the acronym HTTPS for "HyperText” Secure Protocol Transfer ".
  • the service module 14 embeds a digital certificate, issued by a recognized certification authority, capable of enabling authentication of the debit server 20 and the encryption of the data exchanged using secure HTTPS channels.
  • all the rate servers 20 are accessible by the same domain name and share the same CERT digital certificate.
  • the domain name is "domain.net”
  • the performance measurement system has two streaming servers, the latter will be accessible via the subdomains "a. domain. net “and” b. domain. net “.
  • the CERT digital certificate is valid for the domain.net domain name, and the corresponding subdomains, that is, in our example "a. domain. net “and” b. domain. net “.
  • the digital certificate CERT is called wildcard, or "wildcard" in English.
  • the steps of the method described hereinafter with reference to FIGS. 2, 3, 4 and 5 can be implemented in software by the execution of a set of instructions or a program by a programmable processing device, such as a personal computer, a signal processing processor and / or a microcontroller; or alternatively in a material manner by a dedicated machine or component, such as a programmable logic circuit - for example of the type commonly designated by the acronym "FPGA” for “Field-Programmable Gate Array", or an integrated circuit specific to an application more commonly referred to by the acronym “ASIC” for "Application-Specific Integrated Circuit".
  • a programmable processing device such as a personal computer, a signal processing processor and / or a microcontroller
  • a dedicated machine or component such as a programmable logic circuit - for example of the type commonly designated by the acronym "FPGA” for "Field-Programmable Gate Array", or an integrated circuit specific to an application more commonly referred to by the acronym “ASIC” for "Application
  • the method for measuring the performance of an Internet connection of a terminal is in particular adapted to be implemented by the performance measurement system, according to FIG.
  • the steps of the performance measurement method, implemented by the terminal 10 can be performed by the performance measurement module 12 executing, in a web browser, an application.
  • a connection information request 10, issued by the terminal 10, is transmitted to the central information system 30, in a step 110.
  • the central information system 30 After receiving the connection information request 10, the central information system 30 determines at least one set of connection information to one of the available throughput servers 20 and transmits the at least one set of information to the terminal 120, in a step 120. If multiple flow servers 20 are available in the performance measurement system, the Central information system 30 may transmit a set of connection information for each of the available bit rate servers.
  • the connection information set for one of the rate servers 20 includes the information necessary for the terminal 10 to establish a secure communication channel with the corresponding rate server 20.
  • the set of connection information for one of the bit rate servers 20 may include one or more of the following non-exhaustive list: an IP address, a uniform resource locator, more commonly referred to by the English acronym URL for "Uniform Resource Locator" -, identification information, a list of services available on the relevant debit server, a list of supported protocols.
  • the rate servers 20 can transmit, to the central information system 30, at regular intervals, their respective states (step not shown in Figure 2).
  • the set of information is received by the terminal 120 during a step 130.
  • the terminal 10 selects one of the connection information sets to the flow server 20.
  • the terminal 10 establishes, by means of a secure protocol, according to the received or selected set of connection information to the rate server 20, a secure communication channel Cs with said flow server 20 and determines:
  • a measurement M UL of a rising bit rate on the secure communication channel Cs from the terminal 10 to the bit rate server 20; and or,
  • a measurement M L P of a response time on the secure communication channel Cs corresponding to the duration between the instant when the terminal 10 sends a request to the debit server 30 and the moment the terminal
  • the measurements M D L, M UL and M L p are transmitted by the terminal 10 to the central information system 30.
  • the central information system 30 can then store the received measurements M D L, M UL and M L P and acknowledge receipt of the latter during a step 180.
  • the terminal 10 then receives the acknowledgment transmitted by the central information system 30 in step 190.
  • step 200 of determining the measurement M D L includes the substeps detailed below.
  • the terminal 10 establishes the secure communication channel Cs with the rate server 20.
  • the secure communication channel It is established by using the HTTPS secure hypertext transfer protocol. If successful, the flow server 20 returns, in a step 220, a confirmation message of the establishment of the secure communication channel Cs is transmitted to the terminal 10.
  • the terminal 10 transmits to the rate server 20 a substitution request - "a switching protocol request" in English - from the HTTPS protocol to the WebSocket protocol, for the secure communication channel Cs. If successful, during a step 240, the debit server returns a confirmation of the substitution of the HTTPS protocol to the Websocket protocol for the secure communication channel Cs. Also, in step 200, from the substep 240, the data exchanges for the secure communication channel Cs are performed using the Websocket protocol.
  • the terminal 10 transmits a request to send data blocks to the rate server 20.
  • the rate server 20 transmits, to the terminal 10, continuously, blocks of data on the secure communication channel Cs , using the websocket protocol.
  • the data blocks typically comprise a predetermined amount Qb of predetermined data and / or obtained / determined randomly.
  • the use of the WebSocket protocol allows the debit server 20 to transmit to the terminal 10 uninterrupted and unlimited data packets.
  • the terminal 10 can receive an unlimited amount of data throughout the duration of the measurement M D L, regardless of the flow.
  • the terminal 10 transmits a request for closing the test to the rate server 20.
  • the terminal 10 can transmit the test closure request to the flow server 20, substantially 10 seconds after the instant t0.
  • the measurement M D L is determined by:
  • the use of the WebSocket protocol resulting in the addition of a header for each block of data transmitted, the quantity Q.1 is determined by removing the size of the data blocks received, the size of the headers used for transmission between the debit server and the terminal.
  • the debit server 20 can in particular account for the volume of data actually transferred, and transmit it to the terminal 20 after receiving the request to close the test.
  • the terminal 10 can accurately determine the measurement M D L, taking into account the bytes of headers and those related to the fragmentation of the messages.
  • step 270 after receiving the request to close the test, the rate server 20 stops transmitting blocks of data to the terminal 10, and transmits an acknowledgment to the corresponding terminal at the end of the test.
  • step 300 of determining the M UL measurement comprises the substeps detailed below.
  • the terminal 10 establishes the secure communication channel Cs with the rate server 20.
  • the secure connection Cs is established, using the HTTPS secure hypertext transfer protocol. If successful, the flow server 20 returns, during a step 320, a confirmation message of the establishment of the secure communication channel Cs is transmitted to the terminal 10.
  • the terminal 10 transmits to the rate server 20 a substitution request - "a switching protocol request" in English - from the HTTPS protocol to the WebSocket protocol, for the secure communication channel Cs. If successful, during a step 340, the debit server returns a confirmation of the substitution of the HTTPS protocol to the Websocket protocol for the secure communication channel Cs. Also, during step 300, starting from the sub-step 340, the data exchanges for the secure communication channel Cs are carried out using the Websocket protocol. During a step 350, from an initial time t 2 0 to a time t 2 N, the terminal 10 transmits a number N of data blocks B n to the rate server 20, on the data channel.
  • the rate server 20 receives the data blocks B n , and transmits to the terminal 10 for each block B n received a message ACQ acknowledgment. n -
  • the size Qn of each block Bn is a function of an instantaneous measurement of the bit rate MI D L of the downstream channel from the rate server 20 to the terminal 10.
  • the instantaneous measurement of the bit rate MI D L is for example determined in:
  • the size Qn of each block Bn can thus be chosen according to the instantaneous measurement of the rate MI D L, by maximizing the size Qn to limit the impact of the latency on the measurement M UL, while being progressively increasing the size Qn relative to the size Qn-1 so as to have a steady increase in size.
  • the terminal 10 transmits a request for closure of the test to the debit server 20.
  • the terminal 10 can transmit the request to close the test, to the server of flow 20, substantially 10 seconds after the time t 2 0.
  • step 370 the measurement M UL is determined by:
  • the rate server 20 transmits an acknowledgment to the corresponding terminal at the end of the test.
  • the step 400 of determining the measurement M L P comprises the substeps detailed below.
  • the terminal 10 establishes the connection channel.
  • secure communication Cs with the debit server 20.
  • the secure communication channel Cs is established, using the secure HTTPS hypertext transfer protocol. If successful, the flow server 20 returns, during a step 420, a confirmation message of the establishment of the secure communication channel Cs is transmitted to the terminal 10.
  • the terminal 10 transmits to the rate server 20 a substitution request - "a switching protocol request" in English - from the HTTPS protocol to the WebSocket protocol, for the secure communication channel Cs. If successful, during a step 440, the debit server returns a confirmation of the substitution of the HTTPS protocol to the Websocket protocol for the secure communication channel Cs. Also, during step 400, starting from the sub-step 440, the data exchanges for the secure communication channel Cs are performed using the Websocket protocol.
  • a step 450 from an initial time t 30 to a time t 3 N, the terminal 10 transmits a number N of request R n to the rate server 20, on the secure communication channel Cs, using the websocket protocol.
  • the rate server 20 receives the requests R n of data, and transmits, to the terminal 10, for each request R n , a response message REP n received on the terminal 10 at a time t 3 REP n .
  • the terminal 10 transmits the number N of n request R to the flow server 20.
  • the terminal 10 stops transmitting the requests R n to the debit server 20, the last request sent being denoted R F. In this way we can obtain a reliable measurement even for response times of less than 10 ms, regardless of the browser used.
  • the terminal 10 transmits a request for termination of the test to the debit server 20.
  • the terminal 10 can transmit the request to close the test, to the server of flow 20, substantially 10 seconds after time t 30 .
  • the measurement M L P is determined by:
  • the rate server 20 transmits an acknowledgment to the terminal corresponding to the end of the test.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention a trait à des moyens pour un terminal pour déterminer au moins une mesure de performance d'une connexion Internet du terminal, en établissant, selon un protocole sécurisé, au moyen de la connexion Internet du terminal, un canal de communication bidirectionnel avec un serveur de débit apte à transmettre une chaine de données en flux continu par l'intermédiaire du canal de communication bidirectionnel; déterminant 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.

Description

Moyens de mesures de performance d'une connexion Internet d'un terminal
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 œuvre 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 é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 antivirus 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 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 œuvre de ces outils avec celles des navigateurs Web généralement déployés n'est pas toujours optimale. En outre, pour atteindre un niveau de fiabilité suffisant, il est courant que les outils de 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. Le document de brevet US 2016/088125 Al décrit des moyens de surveillance du trafic réseau applicatif entre un terminal et un serveur applicatif. Ces derniers ne sont donc pas adaptés à mesurer les performances globales de la connexion Internet du terminal, hors du contexte de l'application concernée. Le document de brevet US 2014/173127 Al divulgue des moyens de contrôle de flux de données dans un réseau de communication, déployés sur des dispositifs réseaux, et ne sont donc pas adaptés à être mis en œuvre sur un terminal.
Le document de brevet WO 2014/096742 Al décrit des moyens d'optimisation de la communication entre un terminal et un serveur, notamment dans le cas d'une session de type WebSocket, et ne divulgue aucun moyen de mesure des performances globales de la connexion Internet d'un terminal.
C'est pourquoi il existe encore un besoin pour 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, 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.
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 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 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 les étapes suivantes, mises en oeuvre par le terminal:
· 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 apte à transmettre une chaîne de données en flux continu par l'intermédiaire du canal de communication bidirectionnel ;
• 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.
Le serveur de débit est par exemple configuré pour transmettre une chaîne de données comportant des blocs de données, de manière continue, par l'intermédiaire du canal de communication bidirectionnel. Les blocs de données peuvent comporter des données prédéterminées et/ou obtenues/déterminées de façon aléatoire. La transmission au terminal des paquets de données par le serveur de débit s'effectue sensiblement sans interruption, de sorte que le terminal puisse recevoir une quantité non limitée de données pendant toute la durée de la mesure, indépendemment du débit du canal de communication bidirectionnel. 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. L'utilisation du protocole WebSocket permet d'établir des connexions persistantes avec le serveur. Une fois la connexion établie, les 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 œuvre au moyen des 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 œuvre 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.
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. 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 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 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 débit montant étant déterminé en:
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 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. 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 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.
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 intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.0En particulier, il est possible d'utiliser le langage C/C++, le langage Java™, des langages de script, tels que notamment tel, 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 leur modification.
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é 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 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. Selon un quatrième aspect, l'invention se rapporte à un module, pour un terminal, adapté à mettre en œuvre le procédé selon le premier aspect, pour déterminer au moins une mesure de performance d'une connexion Internet du terminal, comportant:
• des moyens 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 apte à transmettre une chaîne de données en flux continu par l'intermédiaire du canal de communication bidirectionnel ;
• 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.
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;
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, 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; 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 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 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 10 est adapté pour exécuter un jeu d'instructions formant un logiciel, afin de mettre en œuvre 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 œuvre les étapes du procédé 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 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 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 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 œuvre 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 à 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 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 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 œuvre 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 à 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 des chaînes de données, au moyen du protocole Websocket, en flux continu, simultanément sur plusieurs connexions, à destination de plusieurs clients simultanément, et à très haut débit. Le serveur de débit 20 est par exemple configuré pour transmettre une chaîne de données comportant des blocs de données, de manière continue, grâce à l'utilisation du protocole WebSocket. La transmission au terminal 20 des paquets de données par le serveur de débit s'effectue sensiblement sans interruption, de sorte que le terminal puisse recevoir une quantité non limitée de données pendant toute la durée de la mesure. Typiquement, une chaîne de données comporte des blocs de données comportant des données prédéterminées et/ou obtenues/déterminées de façon aléatoire. 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 particulier en employant le protocole de transfert hypertexte sécurisé, plus communément désigné par l'acronyme anglo-saxon HTTPS pour « HyperText Transfer 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.
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 « 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.
Les étapes du procédé décrit ci-après en regard des figures 2, 3, 4 et 5 peuvent être mises en œuvre 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 un circuit logique programmable — par exemple de type couramment désigné par l'acronyme anglo-saxon « FPGA » pour « Field-Programmable Gâte Array », ou un circuit intégré propre à une application désigné plus couramment par l'acronyme anglo-saxon « ASIC » pour « Application-Specific Integrated Circuit ».
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 œuvre 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 œuvre par le terminal 10, peuvent être 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 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 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 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 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, à 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 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 M DL d'un débit descendant sur le canal de 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 M UL 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,
• au cours d'une étape 400, une mesure M LP 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.
Dans un mode de réalisation, au cours d'une étape 170, les mesures M DL , M UL et M Lp Sont transmises par le terminal 10 au système d'information centrale 30. Le système d'information centrale 30 peut alors stocker les mesures M DL , M UL et M LP 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.
On se réfère à la figure 3. L'étape 200 de détermination de la mesure M DL 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 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.
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 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 tiO, le terminal 10 transmet une demande d'envoi de blocs de données au serveur de débit 20.
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 Q.b de données prédéterminées et/ou obtenues/déterminées de façon aléatoire. 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. 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 M DL , quel que soit le débit. Ainsi, il est possible de proposer une méthode particulièrement fiable pour déterminer la mesure M DL-
Au cours d'une étape 260, à un instant til, 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.
Aussi, au cours de l'étape 260, la mesure M DL est déterminée en:
• déterminant une quantité Ql relative à la taille des blocs de données reçus, du serveur de débit 20, entre l'instant tiO et l'instant til;
• déterminant une durée Dl écoulée entre l'instant tiO et l'instant til;
• déterminant un rapport entre la quantité Q.1 et la durée Dl.
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é Q.1 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 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 M DL, 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, 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 M UL 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 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 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 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 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 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 ACQ.n-
Dans un mode de réalisation avantageux, la taille Q.n de chaque bloc Bn est fonction d'une mesure instantanée du débit M I DL de la voie descendante depuis le serveur de débit 20 vers le terminal 10. La mesure instantanée du débit M I DL est par exemple déterminée en:
• obtenant la taille Q.n 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 message d'acquittement ACQ.n correspondant au bloc Bn est reçu sur le terminal 10;
· déterminant un rapport entre la quantité Q.n et la durée Dn.
La taille Q.n de chaque bloc Bn peut ainsi être choisi en fonction de la mesure instantanée du débit M I DL, en maximisant la taille Q.n pour limiter l'impact de la latence sur la mesure M UL, tout en étant augmentant progressivement la taille Q.n par rapport la taille Q.n-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, sensiblement 10 secondes après l'instant t20.
Aussi, au cours de l'étape 370, la mesure M UL est déterminée en:
· déterminant une quantité Q2 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;
• 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.
On se réfère à la figure 5. L'étape 400 de détermination de la mesure M LP comporte les sous-étapes détaillées ci-après.
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é 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 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é 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 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 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 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.
Aussi, au cours de l'étape 470, la mesure M LP est déterminée en:
• 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.
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.

Claims

REVENDICATIONS
1. 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 les étapes suivantes, mises en œuvre par le terminal:
• 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) apte à transmettre une chaîne de données en flux continu par l'intermédiaire du canal de communication bidirectionnel; · 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 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.
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).
5. Procédé selon l'une quelconque des revendications précédentes, dans lequel, ladite au moins une mesure est une mesure (M DL) 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 (M DL) du débit descendant étant déterminé en:
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 (Dl) ;
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.
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 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.
8. Procédé selon l'une quelconque des revendications précédentes, dans lequel, ladite au moins une mesure est une mesure (M UL) 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 (M UL) du débit montant étant déterminé en:
transmettant (350), depuis le terminal (10) vers le serveur de débit (20), des blocs de données (Bn), sur le canal de communication sécurisé, pendant une deuxième période de durée déterminée (D2) ;
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.
9. Procédé selon la revendication 8, dans lequel la taille (Q.n) de chacun des blocs de données est fonction d'une mesure instantanée du débit (M I DL) montant, sur le canal de communication sécurisé (Cs), depuis le terminal (10) vers le serveur de débit (20).
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 (M LP) d'un temps de réponse du serveur de débit (20) à une requête du terminal (10), sur le canal de communication sécurisé (Cs), la mesure (M LP) 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 (Bn), sur le canal de communication sécurisé, pendant une troisième période de durée déterminée (D3) ; 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.
12. Procédé selon la revendication 9, dans lequel, le terminal (10) cesse de transmettre des requêtes de données (Bn), 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.
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 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.
16. Module, pour un terminal (10), adapté pour déterminer au moins une mesure de performance d'une connexion Internet du terminal, 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 avec un serveur de débit (20) apte à transmettre une chaîne de données en flux continu par l'intermédiaire du canal de communication bidirectionnel;
• 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.
PCT/FR2017/051086 2016-05-06 2017-05-05 Moyens de mesures de performance d'une connexion internet d'un terminal Ceased WO2017191423A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1654095 2016-05-06
FR1654095A FR3051090B1 (fr) 2016-05-06 2016-05-06 Moyens de mesures de performance d’une connexion internet d’un terminal

Publications (1)

Publication Number Publication Date
WO2017191423A1 true WO2017191423A1 (fr) 2017-11-09

Family

ID=57045038

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2017/051086 Ceased WO2017191423A1 (fr) 2016-05-06 2017-05-05 Moyens de mesures de performance d'une connexion internet d'un terminal

Country Status (2)

Country Link
FR (1) FR3051090B1 (fr)
WO (1) WO2017191423A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140173127A1 (en) * 2008-10-08 2014-06-19 Citrix Systems, Inc. Systems and methods for real-time endpoint application flow control with network structure component
WO2014096742A1 (fr) * 2012-12-20 2014-06-26 Orange Mecanisme de gestion d'une session de communication
US20160088125A1 (en) * 2014-09-19 2016-03-24 Splunk Inc. Utilizing Packet Headers To Monitor Network Traffic In Association With A Client Device

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140173127A1 (en) * 2008-10-08 2014-06-19 Citrix Systems, Inc. Systems and methods for real-time endpoint application flow control with network structure component
WO2014096742A1 (fr) * 2012-12-20 2014-06-26 Orange Mecanisme de gestion d'une session de communication
US20160088125A1 (en) * 2014-09-19 2016-03-24 Splunk Inc. Utilizing Packet Headers To Monitor Network Traffic In Association With A Client Device

Also Published As

Publication number Publication date
FR3051090A1 (fr) 2017-11-10
FR3051090B1 (fr) 2019-05-17

Similar Documents

Publication Publication Date Title
Rüth et al. Large-scale scanning of TCP's initial window
US20020027884A1 (en) Data transmission control method
EP3087720B1 (fr) Technique de contrôle du routage d'une requête relative a un service
US12368723B2 (en) Method and system for managing secure IoT device applications
US8064356B1 (en) System and methods for measuring network performance
EP3568966B1 (fr) Procédés et dispositifs de délégation de diffusion de contenus chiffrés
EP3216189B1 (fr) Délégation d'intermédiation sur un échange de données chiffrées
EP3162026B1 (fr) Procédé d'autorisation d'établissement d'un flux pair à pair dans un réseau de télécommunications mobiles
EP3568989A1 (fr) Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés
WO2017158272A1 (fr) Procédé de gestion dynamique de chemins de communication entre routeurs en fonction de besoins applicatifs
WO2012042176A1 (fr) Technique d'obtention par un premier nœud d'une information relative a une congestion d'une route
WO2017191423A1 (fr) Moyens de mesures de performance d'une connexion internet d'un terminal
EP1796333B1 (fr) Procédé d'établissement de connexion entre des portions d'une application distribuée dans des noeuds connectés à un réseau de communication à plan de contrôle GMPLS.
WO2020221779A1 (fr) Procedes et dispositifs de mesure de reputation dans un reseau de communication
EP2266279B1 (fr) Partage de contenu multi supports a partir d'une communication audio-video
Kühlewind et al. Challenges in network management of encrypted traffic
EP4409864A1 (fr) Procédé de controle d'un accès à un service applicatif mis en oeuvre dans un réseau de télécommunications, procédé de traitement d'un message de controle d'un accès audit service applicatif, dispositifs, équipement de controle, équipement client, système et programmes d'ordinateur correspondants
EP3149902B1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
FR3030167A1 (fr) Procede d'echanges de donnees entre deux navigateurs internet, equipement de routage, terminal, programme d'ordinateur et support d'informations correspondants
FR3020537A1 (fr) Moyens d’evaluation de performances, dans un reseau de donnees
WO2023078993A1 (fr) Procédé de gestion d'une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d'une valeur d'un paramètre de performance intermédiaire
WO2004091140A2 (fr) Dispositif de mesure de qualite de service et utilisation d’un tel dispositif dans un reseau de transmission de donnees en temps reel
FR2979505A1 (fr) Procede d'insertion d'un equipement intermediaire permettant le controle a distance de la qualite d'une communication
FR2878346A1 (fr) Procede et systeme de mesure de l'usage d'une application
FR2963517A1 (fr) Procede de transmission d'un flux de donnees entre deux equipements appartenant a un reseau de communication

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17726666

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17726666

Country of ref document: EP

Kind code of ref document: A1