J'ai tendance à croire que les interactions sont un tout petit peu moins triviales que ca. Et au passage ta réponse ne satisfait aucune implication logique élémentaire, c'est facile à énoncer mais difficile à démontrer.
Le travail nécessaire ca n'existe pas en pratique. La demande s'adapte à l'offre, soit en consommant plus d'unités soit en ayant de nouvelles exigences.
Je sais pas si tu as remarqué mais le mode de vie de consommation à un tantinet évolué depuis 1800.
commit -a n'est pas dangereux. Ce qui est dangereux ce sont les gens qui ne relisent pas leur commits fait avant de les pousser. -a ou pas, si tu relis pas t'es un boulet.
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.
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.
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…
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…
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.
À 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.
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.
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.
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.
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.
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.
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.
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.
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.
C'est simplement le principe de l'abri à vélo en action (cf. http://bikeshed.com/ )
Émettre un avis subjectif sur des choses triviales est facile donc tout le monde le fait. Dès qu'on passe sur des choses un peu plus techniques, objectives ou constructives y'a beaucoup moins de monde.
800HT c'est un prix avec une belle reduction par rapport au prix publique. Son prédécesseur, le E43X0, était définitivement meilleur que le nouveau cru ;) Dell a baissé en qualité depuis 3 ans, sur les portables comme ailleurs.
Pour ceux qui vantent les thinkpad. J'espère que c'est pas la serie T ou W par ce que c'est des grosses merdes. Jamais gouté à la série X par contre.
Par contre, je viens d'une famille qui habite à la campagne et où ne pas fermer la porte (à clé) était la règle et non l'exception. On est toujours partis du principe qu'il n'y a pas grand chose à voler, qu'on est dans un coin reculé et que, de toutes façons, le mec qui voudra rentrer, y arrivera toujours. Autant qu'il n'explose pas la porte au passage.
Tu vois j'habite dans un endroit où tu peux laisser la porte ouverte et des choses dans les parties communes sans soucis. Dans un magasin d'une centaine de m2 à 8km de là y'a entre 2 et 10 produits de 50 à 200 euros qui disparaissent presque tout les jours. Mais je vois vraiment pas le rapport entre les deux… C'est si difficile d'imaginer que tu n'es pas du tout confronté aux mêmes problèmes que les commerces ? T'as déjà approché le milieu de près ou de loin ? La minorité comme tu dis elle a que ça à foutre. Et la minorité ca part de la racaille à la mamie de 70 ans qui n'a visiblement pas besoin d'argent et qui dit "excusez moi j'ai oublié" quand elle se fait prendre en passant par tout ce qu'il peut y avoir entre ces deux extrêmes.
Votre discours c'est aussi con que de dire, la sécurité informatique ne sert à rien. La plupart des gens sont gentil et les méchants ils arriveront toujours à passer…
On t'a appris des conneries, les caisses ne sont pas forcément à la sortie d'un bâtiment et un bâtiment n'héberge pas forcément un seul magasin. Si un truc aussi simple que ça te pose problème, je me demande comment tu arrives à survivre dans un environnement aussi hostile qu'une galerie marchande.
Tu penses pas que c'est difficile de faire une réponse oui ou non tellement il existe de commerces différents ?
Les camera ça sert pas à grand chose dans un petit magasin mais dans un grand magasin ou un mec peu surveiller ca doit se discuter. Les portiques certainement aussi vu que les mecs qui viennent voler connaissent très bien les endroits défaillants. Mais même quand ils marchent c'est pas très difficile de ne pas les faire sonner. Les vigiles ca permet aux vendeurs de faire uniquement leur job, et ça leur évite aussi les ennuis…
Savoir si c'est rentable c'est une bonne question dont je n'ai pas la réponse. Surtout que paradoxalement pas mal d'enseignes refusent de faire les investissements minimum pour palier aux problèmes connus… Par contre ce dont je suis sur, c'est que si tu enlèves tout ce dont tu parles, les taux vont exploser et tout le monde va s'y mettre.
Le monde n'est pas binaire. Une chose n'annule pas l'autre.
Sans parler du cout pour l'enseigne et de son éventuelle répercussion; j'ai des exemples de vendeurs qui sont content quand on leur délègue un vigile pour quelque temps. Taux de vol énorme et même quand ils repèrent quelque chose c'est pas leur job de jouer avec des jeunes bien élevés…
[^] # Re: Où est passé le gain de performance dû à l'industrialisation ?
Posté par ckyl . En réponse au journal [HS] Politique naïve et incohérences. Évalué à 3.
J'ai tendance à croire que les interactions sont un tout petit peu moins triviales que ca. Et au passage ta réponse ne satisfait aucune implication logique élémentaire, c'est facile à énoncer mais difficile à démontrer.
[^] # Re: Où est passé le gain de performance dû à l'industrialisation ?
Posté par ckyl . En réponse au journal [HS] Politique naïve et incohérences. Évalué à 3.
Le travail nécessaire ca n'existe pas en pratique. La demande s'adapte à l'offre, soit en consommant plus d'unités soit en ayant de nouvelles exigences.
Je sais pas si tu as remarqué mais le mode de vie de consommation à un tantinet évolué depuis 1800.
[^] # Re: Un tuto pour noob ?
Posté par ckyl . En réponse au journal Combattre la crise pétrolière avec Weboob. Évalué à 4.
commit -an'est pas dangereux. Ce qui est dangereux ce sont les gens qui ne relisent pas leur commits fait avant de les pousser.-aou pas, si tu relis pas t'es un boulet.[^] # Re: Hein ?
Posté par ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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 . En réponse au journal Réduire la latence des connections TCP, enfin. É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…
[^] # Re: Hein ?
Posté par ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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 ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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.
[^] # Re: Hein ?
Posté par ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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 ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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 ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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.
[^] # Re: Hein ?
Posté par ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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.
[^] # Re: Petit rappel, Spdy
Posté par ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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.
[^] # Re: Hein ?
Posté par ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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.
[^] # Re: Hein ?
Posté par ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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 ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. Évalué à 0.
Le rapport avec le sujet courant ?
[^] # Re: Hein ?
Posté par ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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: Petit rappel, Spdy
Posté par ckyl . En réponse au journal Réduire la latence des connections TCP, enfin. É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: Troll
Posté par ckyl . En réponse à la dépêche Sortie d'OpenSSH 6.0. Évalué à 10.
C'est simplement le principe de l'abri à vélo en action (cf. http://bikeshed.com/ )
Émettre un avis subjectif sur des choses triviales est facile donc tout le monde le fait. Dès qu'on passe sur des choses un peu plus techniques, objectives ou constructives y'a beaucoup moins de monde.
[^] # Re: Tous les portables n'ont pas (encore) succombé au 1366x768
Posté par ckyl . En réponse au journal La crise des pixels : régression des résolutions. Évalué à 2.
800HT c'est un prix avec une belle reduction par rapport au prix publique. Son prédécesseur, le E43X0, était définitivement meilleur que le nouveau cru ;) Dell a baissé en qualité depuis 3 ans, sur les portables comme ailleurs.
Pour ceux qui vantent les thinkpad. J'espère que c'est pas la serie T ou W par ce que c'est des grosses merdes. Jamais gouté à la série X par contre.
[^] # Re: Ce que je ferai.
Posté par ckyl . En réponse au journal Ikéa, paranoland à deux pas de Paris. Évalué à 4.
[…]
T'es bien parti non ?
[^] # Re: Ce que je ferai.
Posté par ckyl . En réponse au journal Ikéa, paranoland à deux pas de Paris. Évalué à 9.
Tu vois j'habite dans un endroit où tu peux laisser la porte ouverte et des choses dans les parties communes sans soucis. Dans un magasin d'une centaine de m2 à 8km de là y'a entre 2 et 10 produits de 50 à 200 euros qui disparaissent presque tout les jours. Mais je vois vraiment pas le rapport entre les deux… C'est si difficile d'imaginer que tu n'es pas du tout confronté aux mêmes problèmes que les commerces ? T'as déjà approché le milieu de près ou de loin ? La minorité comme tu dis elle a que ça à foutre. Et la minorité ca part de la racaille à la mamie de 70 ans qui n'a visiblement pas besoin d'argent et qui dit "excusez moi j'ai oublié" quand elle se fait prendre en passant par tout ce qu'il peut y avoir entre ces deux extrêmes.
Votre discours c'est aussi con que de dire, la sécurité informatique ne sert à rien. La plupart des gens sont gentil et les méchants ils arriveront toujours à passer…
[^] # Re: Ce que je ferai.
Posté par ckyl . En réponse au journal Ikéa, paranoland à deux pas de Paris. Évalué à 5.
Et les galleries lafayette, le printemps & co c'est du poulet ? Des exemples comme ça t'en as des pelletées…
[^] # Re: Ce que je ferai.
Posté par ckyl . En réponse au journal Ikéa, paranoland à deux pas de Paris. Évalué à 10.
On t'a appris des conneries, les caisses ne sont pas forcément à la sortie d'un bâtiment et un bâtiment n'héberge pas forcément un seul magasin. Si un truc aussi simple que ça te pose problème, je me demande comment tu arrives à survivre dans un environnement aussi hostile qu'une galerie marchande.
IKEA n'a rien inventé…
[^] # Re: Crache ton venin
Posté par ckyl . En réponse au journal Ikéa, paranoland à deux pas de Paris. Évalué à 3.
Tu penses pas que c'est difficile de faire une réponse oui ou non tellement il existe de commerces différents ?
Les camera ça sert pas à grand chose dans un petit magasin mais dans un grand magasin ou un mec peu surveiller ca doit se discuter. Les portiques certainement aussi vu que les mecs qui viennent voler connaissent très bien les endroits défaillants. Mais même quand ils marchent c'est pas très difficile de ne pas les faire sonner. Les vigiles ca permet aux vendeurs de faire uniquement leur job, et ça leur évite aussi les ennuis…
Savoir si c'est rentable c'est une bonne question dont je n'ai pas la réponse. Surtout que paradoxalement pas mal d'enseignes refusent de faire les investissements minimum pour palier aux problèmes connus… Par contre ce dont je suis sur, c'est que si tu enlèves tout ce dont tu parles, les taux vont exploser et tout le monde va s'y mettre.
[^] # Re: Crache ton venin
Posté par ckyl . En réponse au journal Ikéa, paranoland à deux pas de Paris. Évalué à 4.
Le monde n'est pas binaire. Une chose n'annule pas l'autre.
Sans parler du cout pour l'enseigne et de son éventuelle répercussion; j'ai des exemples de vendeurs qui sont content quand on leur délègue un vigile pour quelque temps. Taux de vol énorme et même quand ils repèrent quelque chose c'est pas leur job de jouer avec des jeunes bien élevés…