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

Le , 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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Freem 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é.
Avatar de Jay13mhsc 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.
Avatar de kolodz 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.
Avatar de Tab 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.
Avatar de deathness 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.
Avatar de spyserver spyserver - Membre averti 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.

Avatar de MiaowZedong MiaowZedong - Membre émérite 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.
Avatar de Patatarte Patatarte - Membre à l'essai https://www.developpez.com
le 25/01/2012 à 18:45
sur la page de base http://google.fr
en 15 secondes de traitement et sans chercher des outils exeptionnels
et en ne traitant que les 3 images disponible (nav_logo101.png , close_sm.gif, chrome-48.png)
il est possible de gagner 362 octets, ce qui represente 9.1% des données images transmise...

sur une page chargée des millions de fois, il est curieux que ces optimisations ne soit pas faite...

Bon a coté il y a env 400Ko de java a transmettre
Avatar de Farnsworse 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...
Avatar de merill 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.
Offres d'emploi IT
Ingénieur développement fpga (traitement vidéo) H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil