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 Benoît Sibaud (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
[^] # Re: Reno ? TCP ?
Posté par reno . Évalué à 3.
Aucun!
# Petit rappel, Spdy
Posté par tfeserver tfe (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 NeoX . Évalué à -1.
c'est exactement ca, le blog explique ce que fait spdy (mais en francais)
[^] # Re: Petit rappel, Spdy
Posté par ckyl . É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 Stéphane Bortzmeyer (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 Antoine . É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 ribwund . É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).
[^] # Re: Petit rappel, Spdy
Posté par Antoine . Évalué à 1.
Il faut la collaboration du serveur, non ?
[^] # Re: Petit rappel, Spdy
Posté par ribwund . Évalué à 3.
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 Antoine . É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 ribwund . Évalué à 3.
Mais c'est la portion qui compte pour Google.
[^] # Re: Petit rappel, Spdy
Posté par nerbrume . É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 ckyl . É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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . É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 Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . Évalué à 0.
Le rapport avec le sujet courant ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . É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 Grunt . Évalué à 10.
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 galbolle . É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 xavier Granveaux . É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 Stéphane Bortzmeyer (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 Grunt . É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 Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . Évalué à 6.
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.
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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . Évalué à 5.
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 Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . É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ûrement1s + temps_tx(index.php). Pouf tu viens de gagnertemps_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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . Évalué à 4.
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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . É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 Bruno Michel (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.
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.
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 Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par Bruno Michel (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 Volnai . Évalué à 3.
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 Bruno Michel (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 Bruno Michel (site web personnel) . Évalué à 5.
Raté, c'est en fait 12 ou 13 domaines d'après http://httparchive.org/trends.php
[^] # Re: Hein ?
Posté par Grunt . Évalué à 5.
C'est de l'UDP, sauf entre serveurs.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Hein ?
Posté par Bruno Michel (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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par Bruno Michel (site web personnel) . Évalué à 4. Dernière modification le 05 mai 2012 à 15:17.
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.
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.
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
timene mesure pas du tout le keep-alive, mais le client_header_tiemout dans la terminologie nginx.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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
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 Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par Bruno Michel (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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par Bruno Michel (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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . É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.
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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Hein ?
Posté par ckyl . Évalué à 3.
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…
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 ckyl . É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 Batchyx . Évalué à 1.
À 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 Bruno Michel (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 ckyl . Évalué à 3.
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 symoon . É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 Niniryoku . É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 Bruno Michel (site web personnel) . Évalué à 4.
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.
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.
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 oinkoink_daotter . Évalué à 1.
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 Bruno Michel (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 Zenitram (site web personnel) . Évalué à -3.
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 Bruno Michel (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.