Google veut augmenter la vitesse du Web

Et propose des solutions pour accélérer la couche TCP

Le 2012-01-25 15:17:23, par Hinault Romaric, Responsable .NET

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 ?

Discussion forum

16 commentaires

Jay13mhsc
Membre du Club

Envoyé par Freem

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.

le 25/01/2012 à 16:18
Tab
Membre averti

Envoyé par kolodz

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.

le 25/01/2012 à 16:35
spyserver
Membre confirmé

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.

le 25/01/2012 à 17:09
Farnsworse
Futur Membre du Club

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...

le 25/01/2012 à 19:42
merill
Membre habitué

Envoyé par Tab

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.

le 26/01/2012 à 11:40
Envoyé par IP_Steph

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

le 14/02/2012 à 18:32
Freem
Membre émérite

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é.

le 25/01/2012 à 15:36
kolodz
Modérateur

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.

le 25/01/2012 à 16:20
deathness
Membre émérite

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.

le 25/01/2012 à 17:00
MiaowZedong
Membre extrêmement actif

Envoyé par spyserver

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.

le 25/01/2012 à 17:19

Poster une réponse