Journal Réduire la latence des connections TCP, enfin

Posté par . Licence CC by-sa
Tags :
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 (page perso) . É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 (page perso) . É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 (page perso) . É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.

  • # Hein ?

    Posté par (page perso) . Évalué à  4 .

    Pour le web ? Sérieusement ? Personnellement, je serais pas mal étonné que l'établissement de connexion impacte significativement les délais en moyenne. On est en 2012 et l'HTTP/1.1 existe depuis 1999. Plus particulièrement, les connexions persistantes et le pipelining mitigent extrêmement ces temps de latence. Si je me connecte sur DLFP et que je surfe pendant plusieurs heures dessus, une seule connexion est établie lors de ma première visite (Je mens un peu la connexion ne reste ouverte que network.http.keep-alive.timeout = 115 sec si je ne clique sur rien - sauf si la tribune est ouverte).

    Calculons :

    $ ping linuxfr.org
    [...]
    rtt min/avg/max/mdev = 37.389/37.536/37.678/0.118 ms
    
    

    Par conséquent, un établissement de la connexion unique devrait prendre environ 38*1.5 = 54 millisecondes. Toutes les autres requêtes n'établiront pas de connexion.

    Aujourd'hui, même en dépassant le keep-alive timout (rappel 115 par défaut pour ff) car je suis un peu lent, la plupart des pages ne sont plus du pur html et donc j'ai un paquet de truc qui sont downloadés sur cette connexion unique : html, css, javascript (avec potentiellement du kikoo lol qui fait des refresh en permanence et donc garde la connexion ouverte), videos, … Pour moi tout au contraire les échanges sont de plus en plus long. Par exemple sur dlfp, ma connexion reste ouverte quasi non-stop (merci la tribune) ; sur youtube, j'en ai pour plusieurs minutes de vidéo…

    Par contre, je vois très bien l'utilité du TCP, Fast Open Cookie pour réduire le nombre de connexions ouvertes sur un serveur et diminuer les ressources utilisées car une connexion tcp cela consomme pas mal (c'est à dire réduire la durée de keep-alive) mais pour les cas d'usages du web à l'heure actuelle j'ai des difficulté à voir ce que cela peut apporter de significatif.

    • [^] # 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.

      • [^] # Re: Hein ?

        Posté par (page perso) . Évalué à  10 .

        Ma vision du HTTP actuel est simple : on converge vers l'implémentation d'IP over HTTP.

        • [^] # Re: Hein ?

          Posté par . Évalué à  0 .

          Le rapport avec le sujet courant ?

          • [^] # Re: Hein ?

            Posté par (page perso) . Évalué à  10 .

            Qu'on résout des problèmes qui n'existeraient pas si on évitait de faire passer n'importe quoi sur du HTTP ?

            • [^] # 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 (page perso) . É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.

      • [^] # Re: Hein ?

        Posté par (page perso) . Évalué à  5 .

        J'en ai lu une partie notamment http://research.google.com/pubs/pub37517.html

        The restricted effectiveness of persistent
        connections is due to several factors. Browsers today often
        open tens of parallel connections to accelerate page down-
        loads, which limits connection reuse. Domain sharding or
        the placement of resources on different domains by content
        providers to increase parallelism in loading web pages also
        exacerbates this issue. In general, hosts and middle-boxes
        (NATs) also terminate idle TCP connections to minimize
        resource usage. The middle-box issue may be partly miti-
        gated by using TCP keepalive probes, but this could be prohibitively power hungry on >mobile devices [32]. Major mobile browsers close idle connections after mere seconds to
        conserve power.

        Donc, les problèmes sont :
        1) Les browsers (chrome dans le cas mesuré) ouvrent beaucoup de connexion en // et n'utilise pas assez la persistance
        2) Les ressources sont éparpillées sur différentes machines (je pense que le « on different domains » dans l'article n'est pas juste cfr. virtual hosting càd on peut utiliser la même connexion pour plusieurs domaines sur la même IP)
        3) Les équipements intermédiaires qui sont statefull et drop les connexions après un certain délai
        4) Les mobiles qui droppent les connexions pour des raisons de consommations de batteries

        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 ?

        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.

        Pour le 3), la plupart des équipements ont un timeout de 2minutes maximum, cela me semble raisonnable cfr. mon comm. précédent.

        Pour le 4), c'est plus problématique. Dans ce cas précis, cela peut aider.

        Pour 2), les

        • [^] # 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.

          • [^] # Re: Hein ?

            Posté par (page perso) . Évalué à  4 .

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

            Merci d'avoir isolé un des problèmes.

            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.

            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.

            mais tu prends aussi en compte que les navigateurs ne se sont mis à utiliser plusieurs connexions par domaine qu'assez récemment.

            Merci d'isoler un 2ème problème.

            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.

            Elles sont pertinentes dans un monde où l'IP over web (websocket et autres horreurs) sont légions. Le problème c'est l'IP over Web. On résout un problème artificiel qui n'a pas lieu d'être.

            • [^] # 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.

              • [^] # Re: Hein ?

                Posté par (page perso) . Évalué à  0 .

                Non, pas du tout, efface !

                3 gets :

                • GET /index.php HTTP/1.1 => génération en 1s
                • GET /banner.php HTTP/1.1 => 0.1s
                • GET /trailler.php HTTP/1.1 => 0.1s

                PHP peut très bien tourner 3x en // donc, temps de génération = max des 3 gets = génération de index.php 1s.

                Par contre, le retour des données = sommes des temps de transfère individuels. Mais c'est pire sur plusieurs connexions du fait du slow-start.

                PS : Je parle du cas avec pipelining sinon HTTP/1.1 est un non-sens (On gagne le temps de connexion et c'est tout, contre un paquet de ressources monopolisées).

                • [^] # Re: Hein ?

                  Posté par . Évalué à  4 . Dernière modification : le 05/05/12 à 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.

                  • [^] # Re: Hein ?

                    Posté par (page perso) . Évalué à  4 .

                    On s'en fou du temps de génération.

                    Je réponds à

                    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.

                    Tu t'en fous ou tu t'en fous pas du temps de génération ?

                    Les temps plus précis sont calculés dans https://linuxfr.org/users/reno/journaux/reduire-la-latence-des-connections-tcp-enfin#comment-1347796 . Plusieurs connexions sur une seule ligne physique sont trivialement moins performantes qu'une sérialisation sur la même connexion.

                    Avec speedy ce sera sûrement 1s + temps_tx(index.php).

                    Par magie, banner et trailer ne seront plus transférés ? Non, ils seront transférés sur la même ligne avec un overhead supérieur (Ici, on ne parle pas de SPDY qui fait de la compression donc ne vient pas avec ça c'est hors sujet : on parle du pipelining http vs connexions multiples HTTP) et impact du slow start supérieur.

                    • [^] # 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.

                      • [^] # Re: Hein ?

                        Posté par (page perso) . Évalué à  4 .

                        Tu reviens encore avec SPDY alors que je parle de HTTP Pipelining contre plusieur connexions en parallèle. Pour moi, il me semble évident que HTTP Pipelining > connexion en //.

                        Mais, on peut aller plus loin c'est ce que propose SPDY (mais je le répète ce n'était pas le sujet). SPDY propose de casser la barrière du in-order qui induit le problème de head of line blocking. Il propose même d'aller plus loin, donc c'est clairement :

                        SPDY > HTTP Pipelining > connexion en //

                        Mais il ne faut pas venir me dire que connexion en // = mieux que Pipelining c'est juste faux.

                        • [^] # 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 (page perso) . É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.

          • [^] # Re: Hein ?

            Posté par (page perso) . Évalué à  -1 .

            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.

            Excepté que cela ne marche pas comme ça. Imaginons que tu ais 3 éléments à charger.

            Sur une seule connexion TCP, tu auras :

            • 1er élément démarrage lent puis full speed
            • full speed pour 2 élements

            Donc approximativement, vitesse = 1/3 slow-start + 2/3 full-speed

            Sur plusieurs connexions (3), tu auras :

            • Tous les éléments en démarrage lent (+ des interférence entre les connexions, un bourrine donc les 2 autres se restreignent un bon gros coup => gaspillage + des ressources monopolisées sur les serveurs pour les buffers).

            Donc approximativement, vitesse = 3 * slow-start + intérférences

            On voit trivialement qu'une connexion est mieux.

            • [^] # Re: Hein ?

              Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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.

      • [^] # Re: Hein ?

        Posté par (page perso) . Évalué à  3 .

        1) C'est de l'UDP pour le DNS
        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
        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
        4) Cela dépend, vous avez fait ce choix mais ce n'est pas le défaut. Par exemple :

        $ time telnet linuxfr.org 80
        Trying 88.191.250.176...
        Connected to linuxfr.org.
        Escape character is '^]'.
        Connection closed by foreign host.
        
        real    0m10.082s
        user    0m0.000s
        sys     0m0.000s
        # MAIS
        $ time telnet google.com 80
        Trying 74.125.132.113...
        Connected to google.com.
        Escape character is '^]'.
        Connection closed by foreign host.
        
        real    4m0.129s
        user    0m0.000s
        sys     0m0.000s
        
        

        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. Mais dans tous les cas, ad-block me blocque une bonne partie de ce qui vient d'autres domaines et les problèmes des images sur un autre serveur est plus un problème d'architecture qu'un problème de pile TCP/IP.

        • [^] # Re: Hein ?

          Posté par (page perso) . Évalué à  4 . Dernière modification : le 05/05/12 à 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.

          • [^] # Re: Hein ?

            Posté par (page perso) . Évalué à  2 .

            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.

            Les bowsers font ça parce qu'ils n'utilisent pas le pipelining par défaut.

            Une seule connexion TCP est plus rapide que plusieurs connexions TCP :

            • Une seule introduit bien moins d'overhead (en-têtes + gestion de ack)
            • Les protocoles de gestion de congestion et autres sont appliqués qu'une seule fois et les différentes connexions ne passent pas à se marcher sur les pieds (slow-start, …)

            Le problème ici n'est pas le TCP mais le fait que le pipelining n'est pas appliqué par défaut. Donc, on se retrouve dans des situation d'attente. La génération des éléments avec pipelining peut être faite en // mais leur transfère est sérialisé (ce qui ne ralenti pas tout au contraire).

            • [^] # Re: Hein ?

              Posté par (page perso) . É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).

              • [^] # Re: Hein ?

                Posté par (page perso) . Évalué à  0 .

                Je viens de faire rapidement un test avec 2 éléments, cela ne semble pas être le cas :

                $ time (echo -e "GET / HTTP/1.1\r\nHost: linuxfr.org\r\nConnection: Close\r\n" | netcat linuxfr.org 80 >/dev/null ; echo -e "GET /images/logos/linuxfr2_codebar.png HTTP/1.1\r\nHost: linuxfr.org\r\nConnection: Close\r\n\r\n"  | netcat linuxfr.org 80 >/dev/null )
                
                real    0m0.472s
                user    0m0.000s
                sys     0m0.000s
                
                
                $ time (echo -e "GET / HTTP/1.1\r\nHost: linuxfr.org\r\n\r\nGET /images/logos/linuxfr2_codebar.png HTTP/1.1\r\nHost: linuxfr.org\r\nConnection: Close\r\n\r\n" ) | netcat linuxfr.org 80 >/dev/null
                
                real    0m0.339s
                user    0m0.004s
                sys     0m0.000s
                
                

                PS : Je ne pense pas que le lancement de 2 netcat dans le premier cas impacte significativement le test. Il faudrait pour bien faire implémenter le truc directement en C.

                • [^] # Re: Hein ?

                  Posté par (page perso) . É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 !

                  • [^] # Re: Hein ?

                    Posté par (page perso) . Évalué à  4 .

                    oups /o\

                    • [^] # Re: Hein ?

                      Posté par (page perso) . Évalué à  2 .

                      J'ai refais en // et effectivement.

                      Je suis quand même étonné…

                      Je pense que la cause majeur est qu'anciennement vers 1999, le web était bien plus statique et le round-trip/latence réseau dominait très fort. Aujourd'hui, un GET bloque beaucoup plus fréquemment car dynamisme (requête SQL, ruby, …) et donc, on se retrouve dans une situation. Ce qui a tendance à dominer c'est la génération de page et donc le pipeline se bloque.

                      Par contre, au niveau de slow-start, je ne suis pas convaincu que cela soit significatif (sinon SPDY aurait aussi ce problème, non ?).

                      • [^] # Re: Hein ?

                        Posté par (page perso) . É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

                        • [^] # Re: Hein ?

                          Posté par (page perso) . Évalué à  2 .

                          Network:
                          100Mbps
                          200ms RTT
                          0% loss

                          200ms de RTT, je suis content de pas avoir cette connexion :/

                          Vu que le slow-start double la taille de la fenêtre tous les RTT, un RTT aussi mauvais impacte un bon coup le débit… J'aurais préféré un exemple plus raisonnable.

                          • [^] # 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…

                            • [^] # Re: Hein ?

                              Posté par (page perso) . Évalué à  4 .

                              Si je ne m'abuse, cela doit donner un débit (pendant la croissance) à un moment t de l'ordre de :

                              throughput = initial_cwnd * 2trunc(t/RTT) / RTT

                              DLFP

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

                              200ms: europe-USA

                              Vers slashdot, j'ai du 135ms.

                              Vers le japon (le pire que j'ai rencontré), j'ai du 300ms…

                              • [^] # 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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à  3 .

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

Suivre le flux des commentaires

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