Discussion :

[Hinault Romaric]

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


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 ?

[Freem]

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

[Jay13mhsc]

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.

[kolodz]

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.

[Tab]

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.

[deathness]

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.

[spyserver]

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.

[MiaowZedong]

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.

[Patatarte]

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

[Farnsworse]

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

[merill]

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.

[Tab]

Merci merill je comprends mieux

[guix69]

Chouette on retourne 10 ans en arrière !
http://grotto11.com/blog/slash.html

(merci @sebsauvage pour l'info)

[slifeur]

a mon avis réduire le temps d'ACK de 3seconde en 1 seconde mettra en péril les connexion a bas débit qui , peut être, n'auront pas assez de débit pour recevoir l'ACK en mois d'une seconde et la couche transport considérera que les paquets sont perdu alors qu'ils ne le sont pas

[Screamer]

L'idée est plutôt bonne ...
Si on considère le modèle OSI qui découpe en différente couche afin de gérer des ré-émissions et des cas dégradés et en même temps l'amélioration des réseau télécom c'est juste logique.
Les ré-émissions étaient utiles lorsqu'il y avait beaucoup de pertes, or, si on réduit le nombre de perte on réduit la nécessité de ré-émission ... on comprend vite qu'une grande partie de TCP (dont le principe est de garantir l'intégrité des données) devient non pas désuet ni obsolète mais beaucoup moins utile ...

Et pour revenir à une remarque si TCP et UDP pouvaient s'unifier et ne devenir qu'un autant sauter dessus (même s'il reste encore des différences fondamentales, comme le mode connecté de TCP).

Toujours en rapport au modèle OSI on sait que la stack IP est un gros mick mack entre les couches 3 et 4; pourquoi ne pas les comprimées et même intégrer la 5 de façon à ne faire qu'une seule couche; les performances n'en seront que plus grande ... et cela se justifie aussi par le fait que TCP/IP est le protocole le plus utilisé en télécom filaire. Le sans fil posant des problèmatiques de ré-émissions et de roaming qui diffère pas mal.

Tout ça pour dire qu'on à fait suffisamment de progrès sur le matériel (fibre optique, etc) pour adapter le soft qui s'en sert.

Et comme le dit Lafontaine: "rien ne sert de courir, il faut partir à point"

[Invité]

Et pour revenir à une remarque si TCP et UDP pouvaient s'unifier et ne devenir qu'un autant sauter dessus (même s'il reste encore des différences fondamentales, comme le mode connecté de TCP).

C'est justement **la** différence fondamentale. Un protocole de transport est soit en mode connecté, soit en mode non connecté...
D'autre part, il faut garder en tête qu'on embarque des stacks IP dans des ASIIC, des EEPROMS, etc. Un code monolithique unifiant TCP et UDP serait trop volumineux. Et toute communication s'appuyant sur IP devrait de toute façon commencer par une négociation entre les extrémités, et là, on commence à mettre un pied dans le mode connecté...

Toujours en rapport au modèle OSI on sait que la stack IP est un gros mick mack entre les couches 3 et 4; pourquoi ne pas les comprimées et même intégrer la 5 de façon à ne faire qu'une seule couche; les performances n'en seront que plus grande ...

Si on intègrait en plus la couche 5, les programmeurs perdraient les interrupts sur les couches TCP et UDP.


Concernant l'accélération TCP préconisée par Google, elle s'appuie sur 2 nouveautés :
1) TCP Fast Open (le serveur génère un Cookie lors du 3-Way handshake),
2) Une meilleure gestion des timeouts notamment qui améliore les performances du protocole (mais c'est toujours l'algorithme de Van Jacobson qui est en background).

Draft TCP Fast Open
http://tools.ietf.org/html/draft-cheng-tcpm-fastopen-02

Draft PPR
http://datatracker.ietf.org/doc/draf...include_text=1

En tout cas, les constructeurs qui ont misé sur les appliances d'accélération WAN ont du mouron à se faire. C'est encore à l'état de draft mais dans les années à venir, ce sera intégré dans les stacks TCP/IP et on ne gagnera plus grand chose en compression TCP...

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

Steph

[Invité]

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