Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Réseaux Discussion :

Google veut augmenter la vitesse du Web


Sujet :

Réseaux

  1. #1
    Responsable .NET

    Google veut augmenter la vitesse du Web
    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 ?
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

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

  3. #3
    Membre du Club
    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.

  4. #4
    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.
    Si une réponse vous a été utile pensez à
    Si vous avez eu la réponse à votre question, marquez votre discussion
    Pensez aux FAQs et aux tutoriels et cours.

  5. #5
    Membre averti
    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.

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

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


  8. #8
    Membre extrêmement actif
    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.

  9. #9
    Membre à l'essai
    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

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

  11. #11
    Membre habitué
    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.

  12. #12
    Membre averti
    Merci merill je comprends mieux

  13. #13
    Membre à l'essai
    Chouette on retourne 10 ans en arrière !
    http://grotto11.com/blog/slash.html

    (merci @sebsauvage pour l'info)

  14. #14
    Futur Membre du Club
    temps d'ACK 1seconde
    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

  15. #15
    Futur Membre du Club
    Enfin
    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"

  16. #16
    Invité
    Invité(e)
    Citation Envoyé par Screamer Voir le message

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

    Citation Envoyé par Screamer Voir le message

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

  17. #17
    Invité
    Invité(e)
    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