IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google veut augmenter la vitesse du Web
Et propose des solutions pour accélérer la couche TCP

Le , par Hinault Romaric

5PARTAGES

6  0 
Les ingénieurs de Google veulent une refonte de protocole TCP (Transmission Control Protocol) afin de rendre le Web plus rapide et optimisé pour les connexions haut débit.

L’équipe « Make the Web Faster » (rendre le web plus rapide) du géant de la recherche vient de proposer plusieurs recommandations pour améliorer la vitesse de la couche transport TCP en augmentant notamment la fenêtre de congestion TCP initiale.

Selon Yuchung Cheng, ingénieur chez Google, la quantité de données envoyée au début d’une connexion TCP serait actuellement de trois paquets, ce qui implique trois allers-retours pour livrer un contenu minuscule de 15 ko. Les expériences effectuées par ceux-ci montrent qu’IW10 (fenêtre de congestion initiale de 10 paquets) réduit la latence du réseau et des transferts Web de plus de 10%.

En plus, la réduction des délais de transmission serait un autre facteur d’amélioration de TCP. En effet, pour une requête, TCP attend la confirmation du serveur pendant trois secondes avant de considérer les données comme perdues et transmettre une nouvelle requête. Ce temps d’attente était approprié pour le Web il y a une vingtaine d’années selon Google, qui propose de passer à une seconde.

Par ailleurs, L’équipe « Make the Web Faster » de Google encourage l’adoption de son algorithme Proportional Rate Reduction (PRR), permettant de récupérer et retransmettre plus rapidement les pertes en cas de congestion du réseau. L’algorithme serait plus rapide que le mécanisme actuel en ajustant le taux de transmission selon le degré de pertes.

PRR fait actuellement partie du noyau Linux et est en cours d’analyse par l'IETF (Internet Engineering Task Force) pour être une partie de la norme TCP.

Enfin, Google propose le protocole TCP Fast Open, permettant de réduire le temps de chargement d’une page de 10 à 40 % en réduisant la charge par l’inclusion des requêtes HTTP dans le paquet initial TCP SYN.

Tous les travaux de Google sur le Protocol TCP sont publiés sous des licences open source et l’adoption des propositions de la firme pourrait améliorer significativement les performances des réseaux.

Pour rappel Google avait également lancé en 2009 un projet SPDY ayant pour objectif d’améliorer la vitesse du Web en apportant des ajustements au protocole HTTP par une couche supérieure.

Source : Les recommandations de Google

Et vous ?

Qu'en pensez-vous ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Jay13mhsc
Membre du Club https://www.developpez.com
Le 25/01/2012 à 16:18
Citation Envoyé par Freem Voir le message

Surtout qu'a l'époque ou ce protocole à été conçu, la bande passante était plus chère que de nos jours.
Justement, maintenant le problème n'est plus la bande passante, mais la latence.
Or si j'ai bien compris, l'idée est de réduire le plus possible le nombre de trames nécessaires pour échanger des informations, et ainsi réduire l'impact de la latence.
Idem, le fait de passer le plus tôt possible les informations essentielles pour la requête HTTP permettrait de réduire cet impact, en réduisant (plus ou moins considérablement, et c'est là que le chiffre de 40% peut s'expliquer, mais je ne suis pas expert !) le nombre de trames.
1  0 
Avatar de Tab
Membre averti https://www.developpez.com
Le 25/01/2012 à 16:35
Citation Envoyé par kolodz Voir le message

je ne suis pas sûr d'avoir compris la première partie sur le IW10. La logique est de répartir les informations gestion sur 10 paquets au lieu de 3 actuellement ?
J'ai plutôt l'impression qu'il s'agit d'en envoyer 10 à la fois au lieu de 3 mais je peux me tromper.
1  0 
Avatar de spyserver
Membre confirmé https://www.developpez.com
Le 25/01/2012 à 17:09
En regardant de plus près cette info, j'ai retrouvé un memo portant sur cette étude (site : https://datatracker.ietf.org/doc/dra...tcpm-initcwnd/) et voici ce qu'on peut y trouver concernant la difference entre IW3 et IW10 :

The table below compares the number of round trips between IW=3 and
IW=10 for different transfer sizes, assuming infinite bandwidth, no
packet loss, and the standard delayed acks with large delayed-ack
timer.

---------------------------------------
| total segments | IW=3 | IW=10 |
---------------------------------------
| 3 | 1 | 1 |
| 6 | 2 | 1 |
| 10 | 3 | 1 |
| 12 | 3 | 2 |
| 21 | 4 | 2 |
| 25 | 5 | 2 |
| 33 | 5 | 3 |
| 46 | 6 | 3 |
| 51 | 6 | 4 |
| 78 | 7 | 4 |
| 79 | 8 | 4 |
| 120 | 8 | 5 |
| 127 | 9 | 5 |
---------------------------------------

Autrement dit, il semble que le gain soit dans le nombre d'aller retour nécessaire pour acheminer les segments de données, cette fenetre est une sorte de buffer, Google propose donc d'augmenter la taille de ce buffer en partant du principe que la bande passante est illimitée.

1  0 
Avatar de Farnsworse
Futur Membre du Club https://www.developpez.com
Le 25/01/2012 à 19:42
C'est pas une bonne idée d'encapsuler une requête HTTP dans un TCP SYN... Ça rend le mécanisme de handshake complétement inutile et laisse automatiquement le serveur sous-entendre que le paquet vient forcemment du bon client. Bonjour le spoofing, et de ce fait, autant utiliser UDP...
1  0 
Avatar de merill
Membre habitué https://www.developpez.com
Le 26/01/2012 à 11:40
Citation Envoyé par Tab Voir le message
J'ai plutôt l'impression qu'il s'agit d'en envoyer 10 à la fois au lieu de 3 mais je peux me tromper.
en gros:

avant:
j'envoie un paquet
j'envoie un paquet
j'envoie un paquet
j'attend (3 sec max) la confirmation de réception avant d'envoyer autre chose à ce serveur.

A noter qu'il s'agit d'une montée en charge, tant qu'il n'y a pas de détection de congestion, on continue à envoyer des paquets supplémentaire "en même temps".
Si il y a congestion (grosses pertes de paquets), alors on repart avec un nombre de paquets simultané deux fois moindre, et on recommence.

après:
j'envoie un paquet
j'envoie un paquet
j'envoie un paquet
j'envoie un paquet
j'envoie un paquet
j'envoie un paquet
j'envoie un paquet
j'envoie un paquet
j'envoie un paquet
j'envoie un paquet
j'attend (1 sec max) la confirmation de réception avant d'envoyer autre chose à ce serveur.

A noter qu'il s'agit d'une montée en charge, tant qu'il n'y a pas de détection de perte de paquet, on augmente de le nombre de paquets émit "en même temps". Mais quand des paquets commencent à se perdre, on utilise PRR pour ajuster.
1  0 
Avatar de
https://www.developpez.com
Le 14/02/2012 à 18:32
Citation Envoyé par IP_Steph Voir le message

Autre avantage de ces améliorations de la couche TCP : impact sur les vitesses de convergence des protocoles de routage s'appuyant sur TCP (comme OSPF et BGP).
Alors que je regardais des traces OSPF... Je me suis rappelé ce post et j'ai réalisé que j'avais écrit une bêtise...

Non, OSPF ne s'appuie sur TCP ! OSPF est directement encapsulé dans les paquets IP (le paquet possède alors le Protocol Number 89 décimal).

BGP est le seul protocole de routage normalisé qui utilise TCP...

Mes excuses donc pour cette mauvaise info

Steph
1  0 
Avatar de Freem
Membre émérite https://www.developpez.com
Le 25/01/2012 à 15:36
J'en pense que ces chiffres laissent rêveur... Bon, ma connexion est pas vraiment ce qu'on appelle du haut débit, mais justement, une amélioration de 10% des performances globales ne serait pas un mal...

Cela dis, ça me paraît énorme comme valeur... Je sais que TCP est pas tout neuf, mais de la a estimer qu'on pourrait gagner jusqu'a 40% de temps de chargement des pages en ajoutant les en-tête dans un autre paquet...
Surtout qu'a l'époque ou ce protocole à été conçu, la bande passante était plus chère que de nos jours.

Alors soit les gens n'y ont pas pensé à l'origine, soit ça n'a pas été fait pour des raisons précise. Sécurité? Maintenance? Je ne sais pas, mais ce serait pas mal qu'ils n'y aient juste pas pensé et que ce soit adopté.
0  0 
Avatar de kolodz
Modérateur https://www.developpez.com
Le 25/01/2012 à 16:20
Le TCP est à la base simple pour être rapide, mais n'est pas spécifique pour le http.
Donc, si on adapte le TCP pour le http, celui-ci sera plus rapide pour le http.
Il est possible qu'il soit du coup moins rapide pour d'autre type de connexion, mais pas obligatoirement.

je ne suis pas sûr d'avoir compris la première partie sur le IW10. La logique est de répartir les informations gestion sur 10 paquets au lieu de 3 actuellement ?

Cordialement,
Patrick Kolodziejcyzk.
0  0 
Avatar de deathness
Membre émérite https://www.developpez.com
Le 25/01/2012 à 17:00
Que les paramètres du protocole TCP ne soit plus adapté de nos jours (ou du moins améliorable) c'est logique.

Néanmoins une question : les améliorations impacteront la navigation web donc mais par exemple les téléchargements directs ou le streaming seraient-ils pareillement affectés?

Si non, les gains seront à relativiser avec le ratio de bande passante que prend la navigation web.
0  0 
Avatar de MiaowZedong
Membre extrêmement actif https://www.developpez.com
Le 25/01/2012 à 17:19
Citation Envoyé par spyserver Voir le message


Autrement dit, il semble que le gain soit dans le nombre d'aller retour nécessaire pour acheminer les segments de données, cette fenetre est une sorte de buffer, Google propose donc d'augmenter la taille de ce buffer en partant du principe que la bande passante est illimitée.

C'est comme ça que je le conçois aussi, Google semble proposer de mieux exploiter les connections haut débit qui ont de très large bandes passantes.
0  0