Journal Réduire la latence des connections TCP, enfin

Posté par  . Licence CC By‑SA.
Étiquettes :
23
4
mai
2012

La plupart des interactions avec les sites web se font avec des échanges très court: un paquet pour la requête, un ou deux paquets pour la réponse, comme l'échange est très court, l'ouverture de la connexion avant l'échange ajoute une latence très importante.
Il n'est pas si simple d'éviter cette durée de connexion sans réduire la sécurité (il faut valider l'adresse de l'émetteur, autrement on est vulnérable à l'usurpation d'adresse source: T/TCP n'est pas utilisé à cause de ce problème), ni utiliser trop de ressource sur le serveur (maintenir des sessions TCP ouverte en permanence avec l'option keep-alive doit être restreint autrement cela consomme trop de ressources sur les serveurs).

L'alternative "évidente", que j'attendais depuis longtemps, est l'utilisation d'une connexion anticipée pour récupérer une clef cryptographique afin de pouvoir réutiliser cette clef ensuite: cela permet d'avoir des "pseudo connexions" permettant un échange rapide avec peu d'utilisation de ressource sur le serveur, et bonne nouvelle Google travaille dessus!

Ceci est détaillé de manière très claire (comme d'habitude) sur le blog de Stephan Bortzmeyer: http://www.bortzmeyer.org/tcp-ouverture-rapide.html

  • # Reno ? TCP ?

    Posté par  (site web personnel) . Évalué à 5.

    Pure curiosité, y a un lien entre le sujet et le pseudo ?

    Cf http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm#TCP_Tahoe_and_Reno

  • # Petit rappel, Spdy

    Posté par  (site web personnel) . Évalué à 2.

    Je suppose que vous le savez déjà, mais pour rappel google travaille/est déjà également sur un autre projet pour rendre plus rapide le web: Spdy.
    Dans le whitepaper ca parle egalement de réduire la latence.

    Ces solutions seront-elles compatibles l'une avec l'autre?

    http://dev.chromium.org/spdy/spdy-whitepaper

    • [^] # Re: Petit rappel, Spdy

      Posté par  . Évalué à -1.

      c'est exactement ca, le blog explique ce que fait spdy (mais en francais)

      • [^] # Re: Petit rappel, Spdy

        Posté par  . Évalué à 7.

        Non spdy ne fait pas ca.

        Ce qu'explique l'article c'est un moyen d'éviter le cout du 3-way handshake pour les connexions TCP faisant suite à une connexion préalable à la même IP. C'est une solution au niveau TCP et ça à un impact sur tout les protocoles de couche supérieur.

        HTTP a été très mal conçu d'un point de vue réseau, il n'a pas du tout pris en compte que c'était du TCP en dessous. Du coup on a passé les 10 dernières années à contourner sa conception bancale (sharding des ressources en différents domaines par les sites web, connexions parallèles par les navigateurs, pipelining dans HTTP/1.1 mais jamais activé par les navigateurs etc.). Un fast open TCP permet de gagner sur la phase du handshake mais ne change rien au fait que le slow-start de TCP ruine aussi les performances d'HTTP.

        Ce que fait spdy c'est de modifier la facon dont HTTP utilise le réseau pour prendre en compte que c'est du TCP en dessous et accroître les performances. Basiquement spdy multiplexe tout dans une seule connexion TCP pour gagner sur le 3-way handshake (y'en a plus qu'un) mais surtout sur la phase de slow start et de la gestion de congestion.

        Bref les deux propositions sont totalement différentes, et complémentaires.

        • [^] # Re: Petit rappel, Spdy

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          Et il y a beaucoup d'autres propositions d'améliorations dans la besace de Google, dont une qui accélère le « slow start », nommée IW10

          • [^] # Re: Petit rappel, Spdy

            Posté par  . Évalué à 2.

            En même temps, 10% de gain ("avec une latence de 100 ms, entre 6 et 16 % de gain"), c'est assez dérisoire vu le temps qu'il faudra pour que cette fonctionnalité se généralise ; d'ici là, le paysage du Web et de l'Internet aura encore changé et la complication n'en vaudra peut-être pas la chandelle (vu qu'apparemment il faut une collaboration du protocole applicatif avec TCP pour lui dire « tu peux envoyer les données dès le SYN » : est-ce un ajout à l'API socket POSIX ?).

            Dans le cas du Web je ne comprends même pas la problématique, puisque la page HTML moyenne tire pas mal de ressources (feuilles de style, images, scripts…) et que le keep-alive HTTP devrait éviter les ouvertures de sessions multiples. J'ai l'impression que Google a une culture de micro-optimisation qui est un peu stérile ici ; en anglais on dit "pound-foolish and penny-wise" à propos des gens qui économisent des centimes en oubliant le tableau d'ensemble.

            • [^] # Re: Petit rappel, Spdy

              Posté par  . Évalué à 1.

              En même temps, 10% de gain ("avec une latence de 100 ms, entre 6 et 16 % de gain"), c'est assez dérisoire vu le temps qu'il faudra pour que cette fonctionnalité se généralise ; d'ici là, le paysage du Web et de l'Internet aura encore changé et la complication n'en vaudra peut-être pas la chandelle (vu qu'apparemment il faut une collaboration du protocole applicatif avec TCP pour lui dire « tu peux envoyer les données dès le SYN » : est-ce un ajout à l'API socket POSIX ?).

              Sur Android et ChromeOS ça doit pas non plus mettre des plombes à mettre en place (et Android c'est la plateforme sur laquelle ça aurait le plus d'impact).

              • [^] # Re: Petit rappel, Spdy

                Posté par  . Évalué à 1.

                Sur Android et ChromeOS ça doit pas non plus mettre des plombes à mettre en place (et Android c'est la plateforme sur laquelle ça aurait le plus d'impact).

                Il faut la collaboration du serveur, non ?

                • [^] # Re: Petit rappel, Spdy

                  Posté par  . Évalué à 3.

                  Il faut la collaboration du serveur, non ?

                  Google maitrise ses TCP endpoints. C'est comme pour SPDY, si ils gagnent quelques millisecondes sur google.com ça leur fait des "happy eyeballs".

                  • [^] # Re: Petit rappel, Spdy

                    Posté par  . Évalué à 2.

                    Oui, donc ça marche entre les clients Google et les serveurs Google. Mais bon, ça fait quand même une portion assez faible des sessions TCP, à mon avis :-)

        • [^] # Re: Petit rappel, Spdy

          Posté par  . Évalué à 2.

          Je ne suis pas sur de bien comprendre en quoi c'est complémentaire.
          Si spdy réduit toutes les connexions TCP à une seule, le mécanisme de fast open TCP ne peux jamais jouer. Voire meme, si fast open TCP est activé en plus de spdy, on perd légèrement du temps, puisque le serveur se fait chier à créer et envoyer un cookie qui ne servira jamais.
          Ou alors, j'ai rien compris, ce qui est aussi très probable.

          • [^] # Re: Petit rappel, Spdy

            Posté par  . Évalué à 3.

            Tu as parfaitement compris, c'est ma formulation qui est mauvaise. Par complémentaire tu peux comprendre: un passage à spdy ou HTTP/2.0 prendra du temps donc on peut gagner sur les anciens protocoles tout en proposant de nouveaux. Il n'est pas impossible de trouver d'autres cas d'utilisation pour un fast open. On peut aussi supposer que les nouveaux protocoles tirent partie de cette fonctionnalité (j'ai pas d'idée en tête pour spdy).

            Bref c'est l'histoire des réseaux. On fait de petit incrément aux protocoles pour les améliorer en fonction de leur usage et de leur environnement actuels.

  • # Commentaire supprimé

    Posté par  . Évalué à 4.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Hein ?

      Posté par  . Évalué à 4.

      Ta vision de la situation d'HTTP est très très loin de la réalité pratique actuelle. Vu qu'ils l'écrivent bien mieux que je le ferais ici; je te conseil de lire les papiers publié par SPDY c'est assez intéressant sur tu as une bonne connaissance des réseaux.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 10.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Hein ?

          Posté par  . Évalué à 0.

          Le rapport avec le sujet courant ?

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 10.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Hein ?

              Posté par  . Évalué à 4.

              Tu veux dire qu'Amazon devrait être une appli lourde et s'inventer des protocoles customs ? Moi je trouve que c'est un bon exemple de site web. Pourtant mon test de tout à l'heure me dit qu'une petite visite d'une dizaines de pages donne presque 50 connexions TCP vers le port 80…

              Pourtant je pense qu'ils ont un peu réfléchi à avoir la meilleure latence possible, et qu'avec la spec actuelle d'HTTP le meilleur compromis c'est d'utiliser pleins de connexions TCP.

              Les travaux en court, ça à un intérêt pour tout le monde.

              • [^] # Re: Hein ?

                Posté par  . Évalué à 10.

                Tu veux dire qu'Amazon devrait être une appli lourde et s'inventer des protocoles customs ?

                Non. Par contre, comme au bon vieux temps où l'idée était de coopérer pour construire Internet, les centaines de web marchand pourraient se mettre d'accord sur un protocole, des formats, et des RFC qui vont bien, pour faire système dédié aux sites marchands, et optimisé pour ça. Comme ça, on lancerait son "client lourd d'achat", celui qu'on choisit, en Gtk ou en Qt ou le truc Windows moisi par défaut, on le connecterait aux services auxquels on est intéressés (par exemple, en cliquant sur un lien trading://amazon.com depuis un site Web), et on ferait ses achats. Avec une API dédiée au paiement (on pourrait stocker ses coordonnées bancaires dans l'appli, avec une passphrase), un rendu unifié et modulable côté client (ce que le Web, avec son apparence décidée côté service, ne permet pas), un suivi centralisé de nos commandes (la même interface indiquerait que le livre chez Amazon est expédié, la commande chez Wexim est en cours de préparation, le colis LDLC m'attend à la Poste). C'est comme ça que fonctionnent un client Torrent, un client mail, un client IRC, un client XMPP, un client NNTP, et ça marche mieux que cette bouse de Web.

                Mais ça date d'une époque où les gens qui faisaient évoluer les protocoles techniques étaient mus par une volonté de coopération, pas du "chacun pour soi" purement mercantile.

                THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

                • [^] # Re: Hein ?

                  Posté par  . Évalué à 1.

                  Ce qui n'empêcherait d'ailleurs pas Amazon de proposer via un serveur Heavy-clienT ersaTz Protocol une applet AdaScript qui parle le protocole en question pour ceux qui n'auraient pas de client lourd installé.

        • [^] # Re: Hein ?

          Posté par  . Évalué à 3.

          Tout à fait d'accord, et grâce à tous ces wordarround, plus personne ne voit l'intérêt d'ipv6 …

    • [^] # Re: Hein ?

      Posté par  (site web personnel, Mastodon) . Évalué à 9.

      Vous pouvez ne pas le croire mais l'article de Google sur TCP Fast Open donne de nombreux chiffres, issus de l'analyse du trafic chez Google qui montrent que, si, le temps d'établissement de connexion a une contribution essentielle. (Et ils expliquent pourquoi les connexions persistentes de HTTP 1.1 ne résolvent pas le problème.)

      • [^] # Re: Hein ?

        Posté par  . Évalué à 10.

        En fait, le truc non dit dans ce qui ressemble à un débat de sourds, et qui mérite d'être explicité, c'est la différence entre LinuxFR et un merdier Web habituel.

        Sur LinuxFR on a un seul domaine à contacter (Linuxfr.org), avec un peu de javascript, quelques images, une CSS et c'est tout.

        Le problème, c'est que la plupart des sites Web sont conçus comme un patchwork inbitable de plusieurs services différents. C'est très visible avec l'extension "Noscript" : sur certaines pages courantes du Web on peut se retrouver avec 10 ou 15 sources différentes de javascript, en termes de domaines : google.com, facebook.net, google-analytics, twitter, 4 ou 5 régies de pub…

        C'est une évolution un peu délirante qui donne l'impression que HTTP est lent.

        Mais, en fait, c'est comme si en arrivant sur un salon IRC, il y avait des "hacks" autour d'IRC qui faisaient que le salon puisse envoyer notre client se connecter à une dizaine de services IRC différents, afin d'y récupérer des scripts, de la pub, d'informer les réseaux asociaux de nos allées et venues.. on aurait également l'impression que IRC est un protocole lent.

        Il faudrait peut-être simplement se réveiller et comprendre que, non, HTTP n'est pas le mieux pour faire du streaming vidéo à coup de "GET partial content", que HTTP n'est pas le mieux pour faire du chat en temps réel, que HTTP n'est pas le mieux pour un flux d'information rapide (type Twitter). Au lieu de chercher à tout prix à bricoler ce pauvre protocole dans tous les sens pour en faire une usine à gaz.

        J'en ai un peu marre que, chaque fois que je lance un navigateur Web, j'ai l'impression de lancer un Windows. Tout comme sous Windows, ça bouffe de la RAM et c'est lent. Tout comme sous Windows, j'exécute du code propriétaire (du javascript obfusqué). Tout comme sous Windows, il faut un antivirus, un parefeu et un nettoyeur de registre.. je veux dire, il faut un Noscript, un Add-Block et un Cookie Monster. Le navigateur Web est devenu le Windows du linuxien, lent, lourd, fenêtre ouverte sur des menaces, des atteintes à la vie privée.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 5.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Hein ?

          Posté par  . Évalué à 6.

          Pour 1), quel est l'intérêt de HTTP/1.1 si c'est pour ouvrir autant de connexions ?

          Premierement le pipelining il existe uniquement dans la spec aucun navigateur ne l'active à ma connaissance.

          Mais même avec le pipelining, le problème c'est que HTTP est séquentiel. C'est à dire que si un élément prend un 500ms a être généré bha pendant ce temps ta connexion elle sert plus à rien. Du coup on se retrouve à devoir avoir plusieurs connexions. Pour réduire la latence.

          Pour le 2), cela me semble plus un problème de gestion d'architecture qu'un problème de pile TCP/IP.

          Pas du tout. C'est une conséquence du design d'HTTP. Tu reprends le point 1, mais tu prends aussi en compte que les navigateurs ne se sont mis à utiliser plusieurs connexions par domaine qu'assez récemment. Du coup les sites web on contourné le problème de leur côté en faisant du sharding.

          Tu peux critiquer la dérive du tout web autant que tu veux. Mais sur le plan technique, les différentes propositions de Google en ce moment sont très pertinentes techniquement et s'appliquent aussi bien à ta vision du web qu'à la leur. Je pense aussi qu'il te manque des pièces du puzzle pour comprendre où on en est arrivé à cause d'HTTP qui n'a pas du tout évolué. Y'a pas que des branques hein.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 4.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Hein ?

              Posté par  . Évalué à 5.

              A ma connaissance, le protocole n'interdit pas de commencer à générer les différents éléments en parallèle. Ils doivent par contre être retournés en séquence. C'est très différent de ce que tu dis.

              C'est exactement ce que je dis. Si tu fais trois requêtes de suite mais que la deuxième met 200ms à se générer alors ton réseau est vide pendant 200ms. La solution dégueulasse c'est celle qui est utilisée actuellement: connexions parallèles. Dans la théorie et dans l'implémentation c'est crado, en pratique ça diminue la latence (même avec la duplication des handshake, slow start & co).

              spdy par exemple utilise un unique stream, et multiplexe les requêtes en permettant leur entremêlement et une gestion de la priorité. C'est beaucoup plus propre d'un point de vue réseau, et ça marche mieux. Je vois pas comment on peut nier le problème et être contre ça.

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 0.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Hein ?

                  Posté par  . Évalué à 4. Dernière modification le 05 mai 2012 à 15:48.

                  T'es sérieux ?

                  On s'en fou du temps de génération. C'est le temps que ça met pour arriver au client qui est important. Ton exemple est flagrant. Pour recevoir le dernier morceau le client va devoir attendre 1s + temps_tx(index.php) + temps_tx(banner.php) + temps_tx(banner.php). Avec speedy ce sera sûrement 1s + temps_tx(index.php). Pouf tu viens de gagner temps_tx(banner.php) + temps_tx(banner.php) en latence. Bha oui ton réseau il a pas passer son temps à rien faire pendant que tu passais une seconde à générer index.php…

                  Note qu'au passage pendant les 1s de génération, ta fenêtre TCP elle a commencé à grandir alors qu'en HTTP après 1s tu commences tout juste à envoyer balancer des octets t'es au début de ton slow start.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 4.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: Hein ?

                      Posté par  . Évalué à 4.

                      Par magie, banner et trailer ne seront plus transférés ?

                      Si ils sont transférés entre 0.1s et 1s. Je fais la supposition (cf. mon sûrement) que leur transfert prend moins de 0.9 secondes. Contrairement à HTTP avec une seule connexion où leur transfert ne pourra s'effectuer qu'après que index.php ait été généré ET transmis.

                      Utiliser plusieurs connexions ou speedy permet d'utiliser le réseau pendant les 0.9s où ton réseau serait inutilisé avec une seule connexion HTTP/1.1 avec le pipelining activé. C'est un problème connu, cf. head of line blocking.

                      Ça na rien a voir avec la compression de spdy qui vient en plus.

                      Si tu n'arrives pas à voir le problème j'abandonne. Tu es quelqu'un d’intelligent, je vois pas comment tu peux passer à côté de ça.

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 4.

                        Ce commentaire a été supprimé par l’équipe de modération.

                        • [^] # Re: Hein ?

                          Posté par  . Évalué à 2.

                          Balance tes trois requêtes exemples dans trois connexions plutôt qu'une pipelinée, tu vas obtenir le même comportement que spdy (sur ce point). C'est à dire que banner et trailer seront balancé sur le réseau et reçu avant que l'index ait fini de se générer. Au final tu obtiens une meilleure latence.

                          L'overhead d'avoir trois connexions est compensé par une meilleur utilisation du réseau en évitant les temps morts. Pour avoir les meilleurs perfs possible, activer le pipelining HTTP n'implique pas de désactiver les connexions concurrentes (à priori on peut quand même diminuer leur nombre). Ca ne marche évidement pas tout le temps et il y a des contres exemples, mais à priori dans le cas général ça reste en moyenne meilleur même si c'est inélégant. Fais le test avec ton browser sur cette page que tu dis être parmi les bons élèves des sites webs…

        • [^] # Re: Hein ?

          Posté par  (site web personnel) . Évalué à 2.

          Pour le problème 3), ça ne concerne pas que les équipements intermédiaires. Les serveurs (hosts) sont aussi impactés. C'est relativement coûteux en ressources de maintenir des connexions keep-alive et c'est souvent un des premiers paramètres pour optimiser un serveur web pour qu'il soit capable d'encaisser de plus fortes charges.

          Pour 1), quel est l'intérêt de HTTP/1.1 si c'est pour ouvrir autant de connexions ? On se retrouve à peu de chose près dans la situation de HTTP/1.0. D'un coté, on se plaint que les délais de connexion sont grands et de l'autre, on s'arrange pour créer un maximum de connexions en //. C'est un peu contradictoire, non ?

          Les navigateurs ont bien d'autres problèmes à traiter que juste les délais de connexion. L'un de ces problèmes est le TCP slow start. Une connexion TCP ne permet pas d'utiliser tout de suite beaucoup de bande passante, il faut attendre qu'elle "chauffe". Les navigateurs font donc appel à plusieurs connexions en parallèle pour pouvoir télécharger plus vite les différentes ressources d'une page web et donc l'afficher plus vite.

          Pour le 2), cela me semble plus un problème de gestion d'architecture qu'un problème de pile TCP/IP. Le problème est la dispersion des ressources. Une page déterminée devrait être chargée au maximum via la même IP.

          Si tu te places du coté client, tout pouvoir charger depuis une même adresse IP serait effectivement idéal. Mais il faut également voir l'autre coté. Quand on se place du coté serveur, il y a pas mal de bonnes (ou mauvaises) raisons de vouloir faire autrement. par exemple, on veut souvent pouvoir servir le HTML généré dynamiquement depuis nos serveurs, mais laisser des CDN s'occuper des images, css et js pour des raisons économiques.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -1.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Hein ?

              Posté par  (site web personnel) . Évalué à 3.

              Dans tes formules, la vitesse, c'est un débit ou une latence ?

              Pour les navigateurs web, l'important est la latence, afin de pouvoir afficher le plus vite possible la page. Si tu veux des formules simplifiées, ça donnerait quelque chose comme :

              Avec une connexion, la première seconde, tu vas télécharger un 1/4 des données (slow start), puis la deuxième seconde, tu vas télécharger les 3/4 restants (passage de slow start à full speed). Il faut donc 2 secondes en tout.

              Avec 4 connexions, chaque connexion va télécharger un 1/4 des données en 1 seconde (slow start). Mais comme ces 4 téléchargements se font en parallèle, au bout d'une seconde, c'est fini. Ça a donc été deux fois plus rapide.

              Je t'invite à lire http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and-the-lower-bound-of-web-performance/ pour mieux comprendre le TCP slow start.

              • [^] # Re: Hein ?

                Posté par  . Évalué à 3.

                Avec 4 connexions, chaque connexion va télécharger un 1/4 des données en 1 seconde (slow start)

                Oui, mais tu te tapes en échange 4 fois le tcp handshake. C'est justement le sujet du papier de google.

    • [^] # Re: Hein ?

      Posté par  (site web personnel) . Évalué à 5.

      Ouch, c'est moche de mettre autant de termes techniques sans comprendre mieux que ça comment ça marche derrière. Voici quelques unes de tes erreurs :

      • Tu omets les connexions TCP utilisées pour la résolution DNS dans tes calculs.

      • Les navigateurs web sont loin d'ouvrir une seule connexion TCP quand ils se connectent à un serveur web. En pratique, ils ouvrent généralement jusqu'à 6 connexions HTTP en parallèle pour télécharger plus vite les ressources (à cause du TCP slow start).

      • Si tu as une connexion ouverte quasiment en permanence sur le serveur LinuxFr.org quand tu es sur la tribune, ça n'est absolument pas à cause du keep-alive. C'est juste que l'on utilise du EventSource dont le principe même est de garder la connexion ouverte.

      • Le timeout d'une connexion HTTP en keep-alive ne vient pas du navigateur mais du serveur dans la vraie vie. Par exemple, sur LinuxFr.org, c'est configuré à 5 secondes (oui, on est loin des 115s de firefox).

      • LinuxFr.org n'est pas forcément représentatif du web. Je ne connais plus les chiffres exacts, mais il me semble qu'un site web inclut en moyenne des ressources provenant de 7 ou 8 domaines différents. Pour chacun d'eux, le navigateur devra faire une résolution DNS, puis ouvrir une ou plusieurs connexions HTTP. Au final, ça fait un paquet de connexions TCP ouvertes à chaque page web visitée.

      • [^] # Re: Hein ?

        Posté par  (site web personnel) . Évalué à 5.

        Je ne connais plus les chiffres exacts, mais il me semble qu'un site web inclut en moyenne des ressources provenant de 7 ou 8 domaines différents.

        Raté, c'est en fait 12 ou 13 domaines d'après http://httparchive.org/trends.php

      • [^] # Re: Hein ?

        Posté par  . Évalué à 5.

        Tu omets les connexions TCP utilisées pour la résolution DNS dans tes calculs.

        C'est de l'UDP, sauf entre serveurs.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Hein ?

          Posté par  (site web personnel) . Évalué à 4.

          Oui, autant pour moi. Je voulais surtout dire qu'avant de pouvoir ouvrir sa connexion vers le serveur web, il faut attendre d'avoir résolu son adresse IP. Mais tu as raison, ça ne compte pas dans les connexions TCP.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Hein ?

          Posté par  (site web personnel) . Évalué à 4. Dernière modification le 05 mai 2012 à 15:17.

          2) Le slow start s'amplifie avec plusieurs connexions. Le slow-start est fait pour chacune des connexions en lieu et place d'une seule

          Certes, mais si tu veux transférer quelques centaines de ko (une page web avec quelques images, css et js typiquement), tu iras quand même bien plus vite avec plusieurs connexions qu'avec une seule. C'est pour ça que les navigateurs font plusieurs connexions en parallèle : pour récupérer plus vite les ressources.

          3) La connexion reste ouverte car il y a du trafic dessus via le SSE. Le keep-alive n'est nécessaire que quand il n'y en a pas. Il n'y a plusieurs méthodes pour le faire, je n'ai pas regardé la situation précise pour DLFP. EventSource ne défini pas la façon de faire mais juste une API

          Je dis juste que la connexion reste ouverte pour un visiteur de la tribune car il a toujours une reponse HTTP qui n'a pas fini d'arriver et que cela n'a rien à voir avec le keep-alive.

          4) Cela dépend, vous avez fait ce choix mais ce n'est pas le défaut.

          La valeur par défaut d'Apache est de 15s, ce qui est toujours bien en-dessous des 115s du firefox. Je maintiens que dans la vraie vie, c'est le serveur et non pas le navigateur qui ferme les connexions keep-alive.

          Note aussi que ton exemple avec time ne mesure pas du tout le keep-alive, mais le client_header_tiemout dans la terminologie nginx.

          5) Attention, il ne faut pas confondre domaines différents et IP différentes. Les connections TCP sont ouvertes vers une IP et il peut y avoir plusieurs domaine par IP (virtualhost). Lors d'un get en HTTP/1.1, c'est « GET /index.html\n\rHost: moncomaine.com » donc ce n'est pas parce que tu as plusieurs domaines que tu ne peux pas ré-utiliser.

          Sauf que dans la vraie vie, que le nouveau nom de domaine soit sur la même IP ou pas, le navigateur va quand même ouvrir une nouvelle connexion TCP au serveur.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Hein ?

              Posté par  (site web personnel) . Évalué à 3.

              Une seule connexion TCP est plus rapide que plusieurs connexions TCP

              Non, ce n'est pas toujours pas le cas. Par exemple, pour charger une page de LinuxFr.org, ça va bien plus vite en ouvrant 6 connexions qu'une seule à cause du TCP slow start. Même en activant le pipelining, ça reste plus rapide avec plusieurs connexions (même si la différence sera probablement moins marquée).

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 0.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Hein ?

                  Posté par  (site web personnel) . Évalué à 4.

                  Forcément, si tu attends d'avoir fini la première requête pour lancer la deuxième, ça va aller moins vite. Les navigateurs font ça en parallèle, hein !

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 4.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 2.

                      Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: Hein ?

                        Posté par  (site web personnel) . Évalué à 3.

                        Si le slow-start est significatif. Dans certains cas, spdy est plus lent que HTTP malgré les tas d'autres optimisations apportées à cause de ça. Mais je te rassure, d'autres personnes travaillent aussi sur ce problème.

                        Un lien sur le sujet : http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=11&ved=0CHIQFjAAOAo&url=http%3A%2F%2Fordinarysky.cn%2Fwp-content%2Fuploads%2F2011%2F04%2FAn_Argument_For_Changing_TCP_Slow_Start.pdf&ei=lVilT4uSNseZ0QX0hsDrAw&usg=AFQjCNGuI5ppVEySFJBS3E5uSQZbd4uEQQ

                        • [^] # Commentaire supprimé

                          Posté par  . Évalué à 2.

                          Ce commentaire a été supprimé par l’équipe de modération.

                          • [^] # Re: Hein ?

                            Posté par  . Évalué à 2.

                            Ca serait intéressant d'avoir les stats de quelques sites sur le sujet. Avoir des latences dans les 50ms c'est uniquement possible pour des sites à très gros moyens, où qui ont des visiteurs venant uniquement à un petit pays type linuxfr. Si 200ms semble un poil élevé c'est pas du tout irréaliste.

                            • 100ms: est-ouest USA
                            • 200ms: europe-USA
                            • Ca donne quoi les ping en 3G ?

                            Au final les sites qui ont le plus à profiter c'est justement ceux qui ont un publique géographiquement distribué et qui ne sont pas dans la poignée qui peut se permettre le multi-datacenter. J'ai 130ms de latence pour atteindre stack overflow par exemple, gros site de techos pour des techos…

                            • [^] # Commentaire supprimé

                              Posté par  . Évalué à 4.

                              Ce commentaire a été supprimé par l’équipe de modération.

                              • [^] # Re: Hein ?

                                Posté par  . Évalué à 3.

                                Par exemple, selon mes calculs dans ces conditions pour une transmission de 400ms (et init_cwnd = 4012) avec du 50ms de RTT, on peut transférer plus d'un 1 Megabyte. Pour du 200ms de RTT, on tombe à 12kilobyte de transféré.

                                Ouai c'est un des premiers trucs que t'apprends quand tu étudies TCP.

                                Pour les expérimatation pratiques cf. More Bandwidth Doesn’t Matter (much).

                                Tiens d'ailleurs ils donnent une info Keep in mind that the worldwide average RTT to Google is over 100ms today. In the US, RTTs are lower, but 60-70ms is still common. Et pourtant quand tu vois leur densité de datacenter…

                                Vers slashdot, j'ai du 135ms.

                                T'aimes vraiment la pignole. 130ms c'est ce que tu as entre la France et la côte est (slashdot semble être vers chicago) soit presque le meilleur cas possible pour europe-USA (Londres doit être meilleur). 200ms c'est pour atteindre la côte ouest depuis la France. Si tu pars de budapest tu dois pouvoir rajouter 40ms. 200ms c'est un ordre de grandeur.

            • [^] # Re: Hein ?

              Posté par  . Évalué à 3.

              Y'a la théorie et la pratique. Je viens de faire le test sur cette page en visiteur et HTTP (de manière absolument pas rigoureuse et sur un échantillon d'une page).

              Pas de pipelining, 1 cnx par serveur: 1.7s
              Pas de pipelining, 6 cnx par serveur: 980ms
              Pipelining (6), 1 cnx par serveur: 1.51s
              Pipelining (6), 6 cnx par serveur: 1.02s

              Et si on pouvant le faire avec spdy je prends les paris qu'on bas tout les scores ici. Vu qu'il cumule tout les bons principes dont tu parles.

              Tu peux facilement refaire le test toi même et obtenir les traces correspondantes.

              Les protocoles réseaux c'est comme beaucoup de choses, on les améliore en les observant dans les cas d'utilisation réels et en trouvant les points bloquants. Pas en supposant de comment ils vont se comporter. On design, puis on mesure, puis on redisgn, puis on remuse etc.

      • [^] # Re: Hein ?

        Posté par  . Évalué à 1.

        Tu omets les connexions TCP utilisées pour la résolution DNS dans tes calculs.

        À ce rythme, il faudrai aussi compter l'ARP vers la passerelle et aussi de la loi de Murphy des réseaux Wi-Fi surchargés.

        • [^] # Re: Hein ?

          Posté par  (site web personnel) . Évalué à 5.

          La résolution DNS est loin d'être négligeable quand on parle du temps de chargement d'une page. C'est d'ailleurs pour ça que des outils comme Firebug donnent cette information mais pas l'ARP vers la passerelle ;-)

        • [^] # Re: Hein ?

          Posté par  . Évalué à 3.

          À ce rythme, il faudrai aussi compter l'ARP vers la passerelle et aussi de la loi de Murphy des réseaux Wi-Fi surchargés.

          Bha oui. Une fois qu'on a un truc qui marche bien, on essai aussi qu'il se comporte le mieux possible quand ton réseau est surchargé et qu'il y a des pertes de paquets. D'après les mesures des grands de l'internet, ils tournent dans les 1% de perte de paquets pour HTTP. Gratter de la latence quand tu es en error recovery ça fait partie du job même si c'est pas le premier truc à faire.

          L'utilisateur il s'en fou du pourquoi, il veut que ca aille vite et tout le temps.

    • [^] # Re: Hein ?

      Posté par  . Évalué à 1.

      37 ms de RTT n'est pas un chiffre représentatif, mais celui d'un ADSL haut débit français, où nous sommes privilégiés.

      Tous les accès 3G, wimax, satellite ont un RTT bien supérieur où le temps d'établissement TCP devient prépondérant.

      De plus 115 sec, c'est très court devant la durée de visite d'un site web : cela signifie que d'une page à l'autre, le temps de la lire la page, la connexion TCP sera fermée.

  • # Où suis-je ?

    Posté par  . Évalué à 3.

    Défois, je me demande où je suis. Le problème n'est pas que TCP est trop lent. C'est que HTTP n'a ni été fait pour télécharger plein de fichier à la fois (multiplexage), faire des connections persistantes (pousser des informations du serveur vers le client, donc on fait du « polling »).

    Le problème n'est pas le temps de connections des connections TCP, le problème c'est qu'on veux tout faire avec HTTP qui n'a pas été fait pour ça.

    Typiquement dans notre cas soyons franc, c'est pour le système de messagerie instantannée en web de google. Puisque vu que HTTP ne fait pas de connections persistantes, on ne peux pas pousser un nouveau message vers le serveur. Donc, ce qu'on fait (en gros, je simplifie), on demande en http toutes les secondes « est-ce qu'il y a un nouveau message ? », « est-ce qu'il y a un nouveau message ? ». Et oui ça sert à rien d'ouvrir des connections TCP pour ça (les requêtes/réponses font à peine un paquet). Mais la solution existe depuis longtemps, ça s'appelle XMPP.

    Le problème aujourd'hui, c'est pas que HTTP est pourri, c'est qu'on veux tout faire avec HTTP. J'ai l'impression que les gens cherchent des faux problèmes, alors qu'il y a des vraies solutions.

    Knowing the syntax of Java does not make someone a software engineer.

    • [^] # Re: Où suis-je ?

      Posté par  (site web personnel) . Évalué à 4.

      Défois, je me demande où je suis. Le problème n'est pas que TCP est trop lent.

      Si, TCP est trop lent. Quelque soit le protocole au-dessus, tu ne vas pouvoir utiliser qu'un très faible partie de ta bande passante lors de la première seconde d'une connexion en TCP. Les latences sur Internet ne vont plus pouvoir baisser beaucoup (on est déjà proche de la vitesse de la lumière), or c'est principalement ça qui impacte les connexions TCP sur les premières secondes (à cause du 3ways-handshake et du TCP slow start).

      Donc, oui, dans un monde où l'on veut de l’instantané, TCP est trop lent.

      Donc, ce qu'on fait (en gros, je simplifie), on demande en http toutes les secondes « est-ce qu'il y a un nouveau message ? », « est-ce qu'il y a un nouveau message ? ».

      On faisait ça il y a quelques années et on le fait encore pour les vieux navigateurs (cough IE cough). Mais, on peut aussi faire ça proprement en HTTP avec une seule connexion TCP : ça s'appelle EventSource. Tu peux par exemple aller sur la tribune de LinuxFr.org et ouvrir Firebug, tu verras qu'il n'y a pas de polling.

      Mais la solution existe depuis longtemps, ça s'appelle XMPP.

      La solution à quel problème ? Si tu veux remplacer HTTP par XMPP comme protocole à tout faire, désolé, mais je préfère encore HTTP. XMPP est un très bon protocole pour de la messagerie instantanée, mais ça s'arrête là. Et il n'est pas présent dans les navigateurs, donc ce n'est pas possible de l'utiliser dans un contexte web.

      • [^] # Re: Où suis-je ?

        Posté par  . Évalué à 1.

        Les latences sur Internet ne vont plus pouvoir baisser beaucoup (on est déjà proche de la vitesse de la lumière), or c'est principalement ça qui impacte les connexions TCP sur les premières secondes (à cause du 3ways-handshake et du TCP slow start).

        Euh, carrément pas !!
        Exemple : l'adsl ou le RTC. Ca a beau se circuler à la vitesse de la lumière, l'entrelacement te pourrit la latence. Deuxième facteur important, l'état des routeurs entre toi et la cible (génération, charge, etc…)

        • [^] # Re: Où suis-je ?

          Posté par  (site web personnel) . Évalué à 6.

          Je ne dis pas que la latence n'a pas baissé ces dernières années, juste qu'elle ne baissera plus beaucoup dans le futur. En informatique, il n'est pas rare de doubler les performances tous les 2 ans. Pour la latence, on est déjà en-dessous de 2x la latence minimale théorique (la distance x la vitesse de la lumière), au moins pour les connexions ADSL en France. Du coup, même sur les 10 prochaines années, on ne pourra pas diviser par 2 la latence.

    • [^] # Re: Où suis-je ?

      Posté par  (site web personnel) . Évalué à -3.

      (…) alors qu'il y a des vraies solutions.

      Je pense que tout le monde adorerait avoir tes idées sur le sujet. Des vraies solutions, donc de trucs qui marcheraient vraiment, hein, pas des théories fumeuses inapplicables. Toi, tu es le dieu des vraies solutions, et les autres sont des idiots. Ou alors les autres regardent tous les problèmes réels du vrai monde, et toi un utopiste qui ne regarde qu'une partie du problème.

  • # TCP Sucks

    Posté par  (site web personnel) . Évalué à 3.

    Un autre lien à propos de TCP : TCP sucks, par Bram Cohen.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.