Brevet FR3060925A1 — publié le 20180622

Arriere-plan de l'invention L'invention se situe dans le domaine des 1..ekkornmunications et plus particulièrement dans le celui des apOcations client-srveur. Elle vise plus particulièrement un mécanisme permettant à un dispositif client de calculer un temps global d'aller-retour (en anglais RTT, Round-Trip-Time) correspondant à la durée qui s'écoule entre l'instant d'émission d'une requête par ce client et l'instant de réception, par le client, de la réponse émise par le serveur. Dans l'état actuel de la technique, ce mos global d'aller-retour inclut le temps 10 de tri7itement de la requête par le serveur. L'invention propose un mécanisme qui ne présente pas cet inconvénient. Objet et résumé de l'invention 15 Selon un premier aspect, l'invention concerne un procédé de traitement mis en oeuvre par un dispositif serveur pour traiter une requête conforme au protocole HI IP ou HTTPS émise un réseau par un dispositif client. Ce procedé comporte : - une étape de réception de la requête ; - une étape dc génération d'une réponse à cette requête et conforme au même 20 protocole; et - une étape d'envoi de cette réponse à destination du dispositif client, |a réponse comportant l'instant d'envoi de la réponse par le dispositif serveur. Ce procédé est caractérisé en ce que : la réponse comporte en outre l'instant de réception de la requête par le dispositif serveur. 25 Corrélativement, l'invention concerne un dispositif serveur comportant : - un module de réception d'une requête conforme au protocole Hl IP ou H [PS émise par un dispositif client ; - un module de génération d'une réponse à cette requête et conforme au même protocole ; et 30 - un module d'envoi de cette réponse à destination du dispositif client, la réponse comportant l'instant d'envoi de la réponse par le dispositif serveur. Ce dispositif serveur est caractérisé en ce que la réponse comporte en outre l'instant de réception de la requête par le dispositif serveur. 306092 5 2 Selon un deuxième aspect, l'invention concerne un procédé de calcul d'un temps de trajet mis en oeuvre par un dispositif client. Cc procCclé comporte : - une et:ope d'envoi, dans un réseau, d'une conforme au protocole 1-ITTP Ou HTTPS à destination d'un dispositif serveur et de mémorisation de l'instant d'envoi de cette requête par le dispositif client ; et - une étape de réception, en provenance du dispositif serveur d'une réponse à cette requête et conforme au même protocole, la réponse comportant l'instant d'envoi de la réponse par le disposiLif serveur. 10 Ce procédé est ca-actérisé en ce que la réponse comporte en outre l'instant de réception de la requête par le dispositif serveur et en ce qu'il comporte : une étape de calcul d'un temps d'aller-retour associé à ladite requête correspondant au temps de trajet de la requête cumulé au temps de trajet de la réponse dans le réseau à partir : 15 - de l'instant d'envoi de la requête par le dispositif client ; - de l'instant de réception de la requête par ledit dispositif serveur ; - de l'instant d'envoi de la réponse par le dispositif serveur ; et - de l'instant de réception de ladite réponse par ledit dispositif client. Corrélativement, l'invention concerne un dispositif client comportant : 20 - un module d'émission configure pour envoyer, dans un réseau, une requête HTTP ou HTTPS à destination d'un dispositif serveur et pour mémoriser l'instant d'envoi de la requête par le dispositif client; et - un module de réception configure pour recevoir en provenance du dispositif serveur, une réponse H I IP ou HTTPS à la requête, cette réponse comportant l'instant d'envoi de 25 la réponse par le dispositif serveur ; - la réponse comportant en outre l'instant de réception de la requête par le dispositif serveur. Le dispositif client cst caractérisé en ce qu'il comporte : - un module de calcul d'un temps d'aller-retour associé à la requête et correspondant au 30 temps de trajet de la requête cumulé au temps de trajet de la réponse dans ledit réseau à partir : - de l'instant d'envoi de la requête par le dispositif client ; - de l'instant de réception de la requête par ledit dispositif serveur ; - de l'instant d'envoi de la réponse par le dispositif serveur ; et 35 - de l'instant de réception de ladite réponse par ledit dispositif client. 306092 5 Ainsi, et d'une façon générale, l'invention propose un dispositif serveur configure, lorsqu'il reçoit une requête HI IP ou H I I PS, pour insérer dans la réponse à cette requête, l'instant à laquelle ce servear a reçu requête. Cette estampile temporelle peut être insérée clans un champ propriétaire de l'entête H| I P, HTTPS. On peut noter que l'invention se situe dans le contexte du protocole HI IP ou H I PS, ces protoco:es étant remarquables d'une part en ce qu'ils se situent au niveau application du modèle OS1 et d'autre part en ce qu'ils constituent des protocoles de type question/réponse. L'estampille temporelle (instant de réception de la requête par le serveur) 10 ajoutée à la réponse à cette requête permet au dispositif client de calculer précisément le temps d'aller-retour associé à la requête, ce temps d'aller-retour correspondant au temps de trajet de la requée cumulé au temps de trajet de la réponse, sans tenir compte du temps de traitement de la requête par. le serveur. L'invention vise aussi des applications du tem s d'aller-retour calculé 15 conformément à l'invention. Ainsi, l'invention concerne un procédé mis en oeuvre par un dispositif client ayant établi au moins un chemin de communication avec un dispositif serveur. Ce procédé comporte: - pour ce ou chacun de ces chemins, une étape de calcul d'au moins un temps d'aller- 20 retour associé à une requête émise dans ce chemin et correspondant au temps de trajet de la requête entre le client et ledit serveur cumulé au temps de trajet d'une réponse à cette requête émise par le serveur dans le chemin, ce temps d'aller-retour étant calculé selon un procédé de cak_-ul mentionné précédemment; et -une étape d'envoi d'au moins une requête subséquente sur un des chemins à un instant 25 déterminé à partir de ces temps d'aller-retour. Autrement dit, l'invention propose d'utiliser l'information sur l'instant de réception de requêtes reçues précédemment par le serveur sur un ou plusieurs chemins pour ordonnancer les requêtes à venir sur ces différents chemins. Ce procédé s'applique en particulier clans le contexte du pipelining. 30 On rappelle que le pipelining est un mécanisme dans lequel un dispositif client émet des requêtes les unes derrière les autres sans attendre d'acquittement ou de réponse du dispositif serveur. Dans ce mode de communication totalement asynchrone, le dispositif asynchrone peut être débordé s'il ne parvient pas à générer en envoyer les réponses suffisamment 35 rapidement. 306092 5 4 L'invention permet au client de connaître le moment où le serveur a reçu une requête et le moment auquel il a renvoyé sa réponse. Si le temps de traitement augmente au niveau du dispositif serveur, le dispositif client peut diminuer la fréquence d'émission de ses requêtes. Lorsque le dispositif client a établi au moins deux chemins de communication avec le dispositif serveur, le procédé selon l'invention peut comporter une étape de détermination de la bande passante entre le serveur et le client sur chacun des chemins (autrement dit dans le sens descendant), les requêtes subséquenLes ('-2tant émises à des instants déterminés pour que le dernier bit des réponses à ces requêtes soient reçus 10 simultanément par ledit client. Ce mode de réalisation de l'invention est intéressant en particulier pour le téléchargement d'une vidéo par un dispositif client via une pluralité de chemins, car les paquets reçus doivent être communiqués au même moment au décodeur. Dans un mode particulier de réalisation, le dispositif client peul calculer la bande 15 passante entre le dispositif serveur et le dispositif client (sens descendant) à partir de la taille d'une réponse reçue du serveur, de l'instant de réception du premier bit de cette réponse par le dispositif client et de l'instant de réception du dernier bit de la réponse par le dispositif client. Dans un mode particulier de réalisation, les requêtes demandent au serveur des 20 réponses sensiblement de même taille. C'est souvent le cas pour le téléchargement d'une vidéo, par exemple avec des paquets d'environ 200Ko. En variante, le procédé selon l'invention comporte une étape d'ajustement de la taille des réponses pour que lesdits temps d'aller-retour soient identiques sur chacun des chemins. Ce mode de réalisation permet de garantir qu'un chemin lent ne pénalise pas 25 d'autres chemins plus rapides. La faculté offerte par ce mode de réalisation de l'invention de permettre la prise en compte des performances réelles de chacun des chemins est essentielle pour le déploiement des protocoles multi-chemins. Il est notoire en particulier que le protocole .MPTCP tarde à se déployer car H n'offre pas de mécanisme satisfaisant pour évaluer les 30 performances réelles des différents chemins, ce qui se traduit par deux situations connues de l'homme du métier à savoir : la situation dans laquelle des paquets attendus par le client ne sont pas reçus dans le bon ordre out of order packets ») ; la situation dans laquelle des paquets déjà reçus doivent rester dans une. queue 35 de traitement en attente des autres, entrainant au niveau applicatif le problème de/« End of Line blocking »). 3060925 Dans un mode de réalisation, l'étape d'ajustement de la taille desdites réponses prend en compte la quantité de données attendues par le dispositif client et non encore reçues du dispositif serveur. Ce mode de réalisation s'applique en particulier dans le contexte du pipelining multi-chemins. Dans un mode de réalisation, le dispositif client et le disposit:f serveur utilisent des horloges synchronisées et le dispositif client peut calculer séparémeet !es durées des trajets montant et descendant (en anglais OWD, one vvay delay), à savoir : - le temps passé par la requête sur le réseau ; et/ou - le temps passé par la réponse sur le réseau. Ce mode de réalisation de l'invention permet de calculer précisément la durée sur chacun des trajets aller ou retour. Dans l'état actuel de la technique il est usuel d'estimer chacune de ces durées à 50% du temps d'aller-retour global; cette approximation s'avère imprécise, les réseaux étant souvent fort asymétriques. Dans un mode particulier de réalisation, les instants d'env de la requête par le dispositif client, de réception de la requête par le dispositif serveur, d'envoi de la réponse par le dispositif serveur et de réception de ladite réponse par ledit dispositif client ont une précision de l'ordre de la milliseconde. Ceci permet de calculer avec précision, les temps d'aller-retour, les durées des trajets montant et descendant (OWD) et la bande passante sur les différents chemins. On notera que clans l'état actuel de la technique, les estampilles temporelles utilisées dans le protocole HTTP pour marquer l'instant d'émission d'une réponse ne sont précises qu'a la seconde. L'invention permet ainsi d\nMmé|iorer très fortement la précision des calculs précités. Dans un mode particulier de réalisation, les différentes étapes des procédés selon l'invention sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur, sur un support d'informaltions, ce programme comportant des instructions adaptées à la mise en oeuvre cies étapes d'au moins un des procédés mentionnés ci-dessus. Ce programme 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 quel e autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordEnaLeur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 306092 5 6 Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, !e support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit rnicroélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un D'autre part, le support d'informations peut être un 5;upport transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via 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 de type Internet. 10 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 Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures: 20 la figure 1 représente un serveur et un client conformes à un mode particulier de mise en oeuvre de l'invention; la figure 2 représente les principales étapes d'un procédé de traitement de requête et d'un procédé de calcul d'un temps d'ailer-retour conformes à un mode particulier de réalisation de l'invention. 25 Description détaillée d'un mode de réa isation de l'invention Ce mode de réalisation de l'invention est décrit dans le contexte du protocole H I I P. 30 La figure 1 représente un client 100 et un serveur 200 conformes à l'invention. Dans le mode de réalisation décrit ici, le client 100 et le serveur 200 ont l'architecture d'un ordinateur conventionne Ils comportent en particulier un processeur 11, 21, une mémoire vive 12, 22, une mémoire morte 13, 23 et une horloge 14, 24. La mémoire morte 13 du client 100 constitue un support d'enregistrement 35 conforme à l'invention, sur le lequel est peut être enregisiré un programme d'ordinateur PGC conforme à l'invention et dont les principales étapes DO: décrites ci-après. 3060925 7 De même, la mémoire morte 23 du client 100 constitue un support d'enregistrement conforme à l'invention, sur le lequel est peut être enregistré un programme d'ordïnatcur PGS conforme à l'invention et dont les principales éi-npe.7, FXX décrites ci-après. Le client 100 comporte un proxy 120 et trois interfaces r-.:2eau 121, 122, 123. Il peut par exemple s de deux interfaces WiFi (interfaces 121, 122) et d'une interface LTE 123. Le serveur 200 comporte un proxy 220 et trois interfaces réseau 221, 222, 223 compatibles avec les interfaces du client 121, 122, 123. 10 On a représenté sur la figure 2, les axes des temps AT14 et AT24 comptés par les horloges 14 et 24. On suppose que trois chemins Cl, C2, C3 de communication sont établis entre le client 100 et le serveur 200. Dans cot exemple : le chemin Cl est établi entre les interfaces 121 et 221 ; 15 le chemin C2 est établi entre les interfaces 122 et, 222 ; et le chemin C3 est établi entre les interfaces 123 et 223. Ces chemins peuvent être utilisés par le proxy 120 du client 100 pour émettre (au cours d'une étape générale d'émission El des requêtes HIIP RQ1, .RQ2, RQ3 au serveur 200. 20 On notera : RQ1 une requê,':e émise à l'instant tl s sur le chemin 11 ; RQ2 une requête émise à l'instant t2 sur le chemin 12 ; et RQ3 une requête émise à l'instant t3 sur le chemin 13. Au cours de cette même étape E10, le client 100 mémorise les instants ti 25 d'émission des requêtes RQi dans sa mémoire volatile 12, ces instants ti étant calculés par l'horloge 14. Dans le mode de réalisation décrit ici, ces instants ti ne sont pas transmis au serveur 200. On note respectivement ta_1, ta_2, ta_3, les instants mesurés avec l'horloge 24, 30 auxquels le serveur 200 reçoit les requêtes RQ1, RQ2 et RQ3, au cours d'une étape générale de réception F10. Conformément à l'invention, ces instants ta_i sont mémorisés par le serveur 200 au cours d'une étape F20. Au cours d'une étape F30, le serveur 200 prépare la réponse RPi une requête 35 RQi. 3060925 Au cours de cette même étape F30, conformément à l'invention, le serveur 200 insère dans 1,7 réponse RPi, l'instant ta_i auquel il a reçu la requête RQi à l'étape F10. Toujours au cours de cette même étape F30, el- conformément au protocole H I I P, le serveur 200 insère en outre dans la réponse RPi, l'instant tr_i auquel il émet la 5 réponse RPi au client 100. Dans !e mode de réalisation décrit ici, les instants ta_i de réception de la requête RQi et Lr_i d'émission de la réponse RPi sont calculés avec la même horloge 24. En variante, des horloges distinctes peuvent être utilisées par les modules de réception et d'émission du serveur 200 dès lors que ces horloges sont synchrones, 10 Dans |u mode de réalisation décrit ici, le serveur 200 émet (étape F30) une réponse RPi sur le même chemin que celui sur lequel il avait reçu la requête RQi (étape F10). Il n'est pas nécessaire que le serveur attende l'arrivée de l'ensemble des requêtes RQ1, RQ2, RQ3 pour répondre à l'une ou l'autre d'entre elles. Les réponses RP1, RP2 et 15 RP3 sont générées et transmises au client 100 au fur et à mesure de la disponibilité du serveur 700. Les réponses RPi sont reçues par le client 100 au cours d'une étape générale F20, à des instants référencés tf_i calculés par l'horloge 14 du client 100. Dans le mode de réalisation décrit ici, les instants t_i d'émission de la requête 20 RQi ct tr i de réception de la réponse RPi sont calculés avec la même horloge 14. En variante, des horloges distinctes peuvent être utilisées par les modules de réception et d'émission du client 100 dès lors que ces horloges sont synchrones. Au cours d'une étape E30, le client 100 calcule (équation (1)) le temps ullerretour RI I i, correspondant au temps total passé par la requête RQi sur le trajet montant 25 du chemin Ci et par la réponse RPi à cette requête RQi sur le trajet descendant du même chemin Ci. RiTi = (tf_i - ti) - (tr_i - (1) On note que dans cette équation, le deu>dé.rne terme (tr_i - ta_i) correspond au temps de traitement de la requête RQi par le serveur 200. 30 Lorsque les horloges 14 du client el 211 du serveur sont synchronisées entre elles, le client 100 peut en outre calculer, par exemple au cours de cette même étape E30 : - le temps TMi passé par la requête RQi sur le trajet montant du chemin Ci (équation (2)) et ; 3060925 9 le temps TDi passé .per la réponse. RPi à cette requête RQi sur le trajet descendant du même chemin Ci (équation (3)). Tryl_i = ta_i - ti (2) Ces temps TM_i et TD_i sont souvent connus de l'homme du métier des telecommunications sous l'appelation OWD (en ang]ais, One Way Delay). 10 Exemple d'utilisation du temps global RI I par le client 10.'7" Dans un mode particulier de réalisation, le client 100 cherche à décaler temporellement l'envoi des requêtes RQi dans le temps sur les différents chemins de sorte à recevoir les réponses RPi à ces requêtes sensiblement en même temps. 15 On suppose dans cet exemple que les requêtes 1-1.1TP RQi demandent au serveur 200 des paquets HTTP de réponse de même taille, comme c'est souvent le cas dans une application mufti-chemins, par exemple 200 kO. En notant : 20 tui : l'instant de réception du premier bit de la réponse RPi par le client 100, correspondant à l'instant Lf_i déjà mentionné ; l'instant de réception du dernier bit de la réponse RPi par le client 100 ; et 317_1 : la durée entre l'instant d'envoi de la requête RQi et l'instant t8i de réception du dernier bit de la réponse RPi par le client 100, 25 on obtient : i = RI Ii + (tr_i - ta_i) - d) (4) Par application de l'équation (4) aux trois chemins Cl, C2, C3, on obtient : JIT_1 = RTT1 + (tr_l - ta_1) + (tril - tal) (4) J1T_2 = R I 12 + (tr_2 - ta_2) + (tri2 - ta2) (5) ]1T_3 = RTT3 + (tr_3 - ta_3) + (433 - ta3) (6) 30 306092 5 10 Pour que les derniers bits des réponses RP1, RP2 et RP3 soient reçus sensiblement en même temps, on impose la contrainte : t131= 432 = tp3 (7) et on en déduit, par soustraction membre à membre des équations (4), (5), (6) les décalages temporels eXij qu'il faut appliquer entre l'émission de deux requêtes RQi, RO] sur les chemin Ci, Cj pour que le dernier bit des réponses RPi, RP1 soient reçus en même temps. 10 4TX12 = (RTT1 - RTT2) + [(tr_1 - ta_1) ( 2 - ta_2)] + (ta2 - tai) (8) ATX23 = (RTT2 - RTT3) + [(tr_2 - ta_2) - (t 3 - ta_3)] + (ta3 - ta2) (9) 4TX13 = (RTT1 - R113) + [(tr_1 - ta_1) - (tr 3 - ta_3)] + (ta3 - tai.) (10) Par ailleurs, à partir de la connaissance différence temporelle entre la réception 15 du premier bit (tai) et du dernier bit Mi) d'une réponse RPi sur le chemin Ci, et la taille .Qi (mesurée en bits) de cette réponse, on peut en déduire la bande passante BWi (mesurée en bit/s) sur le trajet descendant d'un chemin Ci : 20 Les décalages temporels à-rxij et les bandes passantes BWi peuvent être calculés par le client 100 au cours d'une étape E40. Cette étape E40 peul être constituée par une étape de calibrage destinée à permettre la détermination de la taille optimale des réponses RPi sur chacun des chemins pour que ces les derniers bits de ces différentes réponses soient reçus sensiblement au 25 même instant. En reprenant les équations (4) à (6) et (11), on obtient : JIT_1 = RTT1 + (tr_1 - 1) + Q1 / BW1 (12) JIT_2 = RTT2 + (tr_2 - ta_2) + Q2 / BW2 (13) 30 JIT_3 = RTT3 + (tr_3 - ta_3) + Q3 / BIN3 (14) Si l'on souhaite que la durée Jrr_i entre l'instant d'envoi de la requête RQi et l'instant t.i de réception du dernier bit de la réponse RPi par le client 100 sur chaque 3060925 11 chemin soit identique, on obtient RTT1 + (tr_1 - ta_1) + Q1 / BVV1 = RI I 2 + (tr_2 - ta_2) + Q2 / BW2 = RTT3 + (tr_3 - ta 3) + Q3 / BW3 (15) Plus précisément, le client 100 peut fixer la taille des réponses RP1 sur un premier chemin (par exemple Q1 sur le chemin Cl) puis en calculant régulièrement les valeurs RTTi (comme à l'étape E30) ut la bande passante BWi (comme à l'étape E40) sur 10 chacun des chemins Ci déterminer la taille (Q2, Q3) des réponses (RP2, RP3) sur les autres chemins (C2, C3) pour que les durées JIT_1, JIT_2 et JIT_3 soient identiques : Par exemple : 02 = BW2 . [(RTT1 - RTT2) + [(tr_1 - ta_1) - (tr_2 - ta_2)] + Q1 / BW1] (16) 15 Le calcul de ces tailles de réponses optimisées peut être effectué au cours d'une étape générale E50 d'optimisation. Le client 100 peut en outre, et comme mentionné précédemment, décaler temporellement, en fonction des réponses reçues aux requêtes précédentes, les instants 20 d'émission des requêtes RQi pour que les derniers bits des réponses (RP1, RP2, RP3) soient reçus simultanément par le client 100 (voir décalages L'TX12' ATX23, ATX13 des équations (8), (9), (10). Les étapes E10 à E50 peuvent être opérées en boucle. 25 Dans un mode particulier de réalisation de l'invention, les instants t_i, ta_i, tr_i et tf_i sont exprimés en milliseconde. Autre exernoie d'utilisation du e s loba R ar 00 30 Ce deuxième exemple se situe dans un mode de fonctionnement connu par l'homme du métier sous le nom de « pipelining » dans lequel le client envoie les requêtes unes après les autres sans se préoccuper ni de l'instant ni de l'ordre des réponses. Ce mode de réalisation est par conséquent particulièrement simple à mettre en 35 oeuvre côté client mais il présente un risque importarit d'engorger le serveur si des 306092 5 12 requêtes lui sont envoyées à un rythme tel qu'il n'est pas en mesure de générer des réponses à ces requêtes. Dans cet usage, au lieu de considérer uniquement .a uïqle 5-2i des réponses RPi, le. client 100 peut prendre en compte la quantité QNAi mesurée en bits) de données attendues et non encore reçues. L'équation (15) devient : RTT1 + (tr_1 - ta_1) + (Q1 + QNA1) / BW1 = 10 R I I 2 + (tr_2 - ta_2) + (Q2 + QNA2) / BW2 = R113 + (tr_3 - ta_3) + (Q3 +QNA3) / BV1/3 (18) Dans les exemples décrits précédemment : - les interfaces 221, 222, 223 du serveur 200 constituent des exemples de module de réception de requêtes et de module d'envoi de réponses conformes au 15 protocole HTTP ou HTTPS ; - les interfaces 121, 122, 123 du client 100 constituent des exemples de module d'envoi de requêtes et de module de réception de réponses conformes au protocole HTTP ou HTTPS ; et le processeur 11 du client 100 constitue un exemple de module de calcul d'un 20 temps d'aller-retour RI au sens de l'invention. REVENDICATIONS1. Procédé de traitement mis en oeuvre par un dispositif .... --veur (200) pour traiter une requête confornie au protocole HI IP ou H I I PS (RQi) émise dans un réseau per un dispositif client (100), ce procédé comportant : - une étape (F10) de réception de ladite requête (RQi) ; - une étape (F30) de génération d'une réponse (RPi) à ladite requête et conforme au même protocole ; et 10 - une étape d'envoi de ladite réponse (RPi) à destination dudit dispositif client (100), ladite réponse (RPi) comportant l'instant (tr_i) d'envoi de ladite réponse (RPi) par le dispositif serveur (200), ledit procédé etunt caractérisé en ce que ladite réponse (RPi) comporte en outre l'instant (ta_i) de réception de ladite requête (RQi) par ledit dispositif serveur (RPi). 15 2. Procédé de traitement selon la revendication 1, caractérisé en ce que lesdits instants (tr_i, ta_i) ont une précision de l'ordre de Id millise.conde. 3. Procédé de calcul d'un temps de trajet (R7111) mis en oeuvre par un dispositif 20 client (100), ce procédé comportant : - une étape (E10) d'envoi, clans un réseau, d'une requête conforme au protocole FITTP ou H I |PS (RQi) à destination d'un dispositif' serveur (200) et de mémorisation de l'instant (t_i) d'envoi de !agite requête (RQi) par le dispositif client (100) ; et - une étape (E20) de réception, en provenance du dispositif serveur (200) d'une réponse 25 (RPi) à ladite requête (RQi) et conforme au même protocole, ladite réponse (RPi) comportant l'instant (tr_i) d'envoi de ladite réponse (RPi) par le dispositif serveur (200) ; ledit procédé étant caractérisé en ce que ladite réponse (RPi) comporte en outre l'instant (ta_i) de réception de ladite requête (IN par ledit dispositif serveur (200) et en ce qu'il comporte : 30 - une étape de calcul d'un temps (RTTI) d'aller-retour associé à ladite requête (RTTi) correspondant au temps de trajet de ladite requête (RQi) cumulé au temps de trajet de ladite réponse (RPi) dans ledit réseau à partir : - de l'instant (t_i) d'envoi de ladite reciuê`.: {RQi) par le dispositif client (100) ; - de l'instant (ta_i) de réception de ladite requeto. (I.:(2i) par ledit dispositif serveur (200) ; 35 - de l'instant (tr_j) d'envoi de ladite réponse (P,Pi) par le disposlLif serveur (700) ; - de l'instant (tf_i) de réception de ladite réponse (RPO par ledit dispositif client. (100). 3060925 14 4. Procédé de calcul selon la revendication 3, caractérisé en ce que lesdits instants Ki, tr_i, ta_i, tf_i) ont une précision de l'ordre de la milliseconde. 5. Procédé de calcul selon la revendication 3 ou 4, caractérisé en ce que dispositif client (100) et le dispositif serveur (200) utilisent des horloges 1.4, 24) synchronisées pour calculer lesdits instants (t_i, tr_i, tfA, ledit procédé comportant en outre au moins : le calcul du temps (Tfli) passé par ladite requête (RQi) sur le réseau ; ou le calcul du temps (TDi) passé par ladite réponse (RPi) sur ledit réseau. 6. Procédé de calcul selon l'une quelconque des revendications 3 à 5, caractérisé en ce qu'il comporte une étape (E40) de calcul de la bande passante (BWi) entre le dispositif serveur (200) et le dispositif client (100) à partir de la taille (Qi) de ladite réponse (RPi), de l'instant (tai) de réception du premier bit de ladite réponse (RPi) par ledit dispositif client (100) et de l'instant (tN) de réception du dernier bit de la réponse (RPi) par ledit dispositif" client (100). 7. Procédé mis en oeuvre par un dispositif client (100) ayant établi au moins un chemin (Ci) de communication avec un dispositif serveur (200) caractérisé en ce qu'il comporte : - pour chacun desdits au moins un chemins (Ci), une étape de calcul d'au moins un temps d'aller-retour (RTTi) associé à une requête (RQi) émise dans ledit chemin (Ci) et correspondant au temps de trajet de ladite requête (RQi) entre ledit client (100) et ledit. serveur (200) cumulé au temps de trajet d'une réponse (RPi) à ladite requête (RQD émise par ledit serveur (200) dans ledit chemin (Ci), ledit temps d'aller-retour (R I 11) étant calculé selon un procédé conforme à l'une quelconque des revendications 3 à 5 ; cL -une étape d'envoi d'au moins une requête subséquente sur un desdits chemins (Ci) à un instant déterminé à partir desdits temps d'aller-retour, 8. Procédé selon la revendication 7 dans lequel le dispositif client (100) a établi au moins deux chemins avec le dispositif serveur (200), caractérisé en ce qu'il comporte une étape ([10) de détermination de la bnride passante (LiWi) entre ledit serveur (200) et ledit client (100) sur chacun desdits chemins (Ci), lesdites au moins une requêtes subséquentes étant émises à des instants déterminés pour que |c dernier bit desdites réponses (RPi) soient reçus simultanément par ledit client (100). 3060925 15 9. Procédé selon la revendication 8, dans lequel les requêtes (RQi) demandent au serveur (200) des réponses de même taille (Qi). 10. Procédé selon la revendication 8, caractérisé en ce qu'il comporte une étape (J150) d'ajustement de la taille (Qi) desdites réponses (RPi) pour que lesdits temps d'aller-retour soient identiques sur chacun desdits chemins (Ci). 11. Procédé selon la revendication 10, caractérisé en ce que ladite étape 10 d'ajustement de la taïl[e. (!:,-.11) desdites réponses (RPi) prend en compte la quantité (QNAi) de données attendues par !effit dispositif client (100) et non encore reçues dudit dispositif serveur (200). 12. Dispositif serveur (200) comportant 15 - un module de réception (221, 222, 223) d'une requête conforme au protocole HI IP ou HTTPS (RQi) émise par un dispositif client (100) ; - un module de génération d'une réponse (RPi) à ladite requête et conforme au même protocole ; et - un module d'envoi (221, 222, 223) de ladite réponse (RPi) à destination dudit dispositif 20 client (100), ladite réponse (RPi) comportant l'instant (tr_i) d'envoi de ladite réponse (RPi) par le dispositif serveur (200), ledit dispositif serveur (200) étant caractérisé en ce quo: ladite réponse (RPi) comporte en outre l'instant (réception de ladite requête (RQi) par ledit dispositif serveur (RPi). 25 13. Dispositif client (100) comportant : - un module d'émission (121, 122, 123) configuré pour envoyer, dans un réseau, une requête conforme au protocole HI IP ou HTTPS (RQi) à destination d'un dispositif serveur (200) et pour mémoriser l'instant (t_i) d'envoi de ladite requête (RQi) par le dispositif 30 client (100) ; et - un module de réception (121, 122, 123), configuré pour recevoir en provenance du dispositif serveur (200), une réponse (RPi) à ladite requête (RQi) et conforme au même protocole, ladite réponse (RPi) comportant l'instant (tri) d'envoi de ladite réponse (RPi) par le dispositif serveur (200) ; 35 - ladite réponse (RPi) comportant en outre l'instant (ta_i) de réception de ladite requête (RQi) par ledit dispositif serveur (200), 3060925 16 ledit dispositif client étant caractérisé en ce qu'il comporte : - un module de calcul d'un temps (RTTi) d'aller-retour associé à ladite requête (RQi) correspondant au temps de trajet de ladite requête (RQi) cumulé au temps de trajet de ladite réponse (RPi) dans ledit réseau à partir : - de l'instant (t_i) d'envoi de actil.e requête (RQi) par le dispositif client (100) ; - de l'instant (ta_i) de réception de ladite requête (R(Ji) par ledit dispositif serveur (200) ; - de l'instant (tr_i) d'envoi de lacae réponse (RPi) par le dispositif serveur (200) ; et - de l'instant (tf_i) de réception de ladite réponse (RPi) par ledit dispositif client (100), 10 14. Support d'enregistrement lisible par un dispositif serveur (200) sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé de traitement de requête selon l'une quelconque des revendications 1 ou 2. 15 15. Support d'enregistrement lisible par un dispositif client (100) sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé de calcul de temps de trajet selon l'une quelconque des 20 revendications 3 à 11_