Journal spdy://

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
43
19
avr.
2012

«Pour accélérer le web, l'augmentation de la bande passante ne devrait pas être la seule solution»
SPDY (speedy) est un protocole visant à accélérer le chargement des pages. Contrairement à quelques essais précédents, SPeeDY ne nécessite pas de modifications de l'infrastructure, se situant au dessus de tcp. Ce projet a démarré début 2011, et finaliser son implémentation à la fin 2011. Aujourd'hui c'est le module au service de Apache qui vient d'arriver dans les bacs… Et c'est ce qu'il vaut ce petit journal. En résumé, SPeeDY propose :

  • Des connections multiples au sein d'une même session TCP.
  • Une compression des en-têtes, ainsi que l'élimination des jugés inutiles.
  • De placer SSL au coeur : en faire le protocole sous-jacent principal.
  • De permettre au serveur d'initier une connection.
  • De permettre au client d'assigner des priorités sur ses requêtes.

On peut constater qu'il s'agit d'une approche où l'intégration et l'usage facile sont les préoccupations premières. SPDY ne demande pas de changement d'infra, il repose sur des briques existantes éprouvées, et propose des solutions sur l'usuel sans remplacement (compression des en-têtes plutôt que de refaire la roue). La seule modification externe est un patch sur SSL, simplement pour permettre de choisir quel protocole utilisé, afin de remplir les différents cas d'usages («avec ou sans spdy, votre site ?») qui est en train d'être travaillé. Enfin, il ne remplace pas http, mais cherche plutôt à augmenter ses possibilités. Cette approche particulière aurait peut être pu déroutée de prime abord, mais semble aujourd'hui efficace : le gestionnaire de services ou l'administrateur système a simplement à ajouter le module Apache. Et c'est tout.

spdy

Firefox depuis la version 11, et Chrome bien sûr (le projet SPeeDY étant un projet hébergé au sein de Chromium) propose un support de SPDY. Les utilisateurs de ces navigateurs trouveront des extensions permettant de lui signaler l'usage de SPDY par un serveur. Ce qui devrait ne pas tarder à connaître une montée en charge…

À noter que des implémentations pour Python, Ruby et Node.js sont déjà disponibles. Pour terminer, un exemple de test «pour accélérer (le chargement de) cette page, on peut utiliser des techniques d'optimisations comme le «CSS spriting», le «inline image», et la fragmentation de domaine… Ou SPeeDY, simplement»

  • # Une dépêche ! Une dépêche !

    Posté par  . Évalué à 10.

    Je vote pour une dépêche (dans ce cas, plus détaillée, si possible) :-)

    Par contre, il faudra commencer par corriger les fautes :

    Ce projet a démarré début 2011, et [a] finaliseré son implémentation à la fin 2011.
    c'est le module au service de Apache d'Apache
    Et c'est ce qu'il qui lui vaut ce petit journal.
    ainsi que l'élimination des celles jugées inutiles.
    il s'agit d'une approche où l'intégration et l'usage facileités sont les préoccupations premières.
    et propose des solutions sur l'usuel (mot à revoir)
    simplement pour permettre de choisir quel protocole utiliséer
    Cette approche particulière aurait peut être pu déroutéante (ou alors, je n'ai pas compris le sens de la phrase…) de prime abord
    Firefox depuis la version 11, et Chrome […] proposent un support de SPDY
    Ce qui devrait ne pas tarder à connaître une montée en charge… (tournure de phrase à revoir)

    • [^] # Re: Une dépêche ! Une dépêche !

      Posté par  . Évalué à 7.

      Et ne pas oublier connection => connexion (plusieurs occurrences)

      une approche où l'intégration et l'usageutilisation faciles sont les préoccupations premières.
      Cette approche particulière aurait peut-être pu déroutéeer
      Les utilisateurs de ces navigateurs trouveront des extensions permettant de luileur signaler

  • # Activation

    Posté par  . Évalué à 5.

    Dans Firefox, il faut d'abord penser à activer SPDY en passant la clé network.http.spdy.enabled à true. Le module SPDY indicator permet de savoir si le protocole est supporté en affichant une petite icône dans la barre d'adresse.

    Sinon la page de test c'est bien, mais vu que la communication est chiffrée, on a un peu de mal à vraiment voir ce qui passe par les fils… :(

    • [^] # Re: Activation

      Posté par  . Évalué à 4.

      Juste histoire de limiter un peu l'usage des moteurs de recherches autant mettre le lien direct : SPDY indicator.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Activation

        Posté par  . Évalué à 3.

        Et sinon, il y a aussi cette about:addons : about:addons, tout simplement ! :-)

        PS : le parser de DLFP ne veut pas la rendre cliquable… :-(

  • # Varnish

    Posté par  . Évalué à 8.

    Hello,

    Voici une réponse de l'équipe Varnish sur SPDY.
    https://www.varnish-software.com/blog/i_dont_like_spdy

    ce point a été abordé lors du Varnish User Group de fin mars, et détaillé par PHK.

    Seb.

    • [^] # Re: Varnish

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

      Leur premier argument (Le problème des certificats) est un peu bancal, plein de site fonctionne avec des certificats auto-signé…

      Le deuxième (La migration) est déjà plus pertinent mais de très peu vu que tout nouveau proto a ce problème

      • [^] # Re: Varnish

        Posté par  . Évalué à 8.

        Les auto-signés, ça va deux minutes. Si chacun des visiteurs de ton site (y compris sa partie publique) doit préalablement installer une CA, ça va être vraiment chiant.

        Sauf à ce que les navigateurs comprennent enfin qu'SSL sert autant à authentifier un tiers qu'à s'assurer qu'il ne change pas dans le temps, et rendent l'ajout de nouvelles CAs beaucoup moins flippant (éventuellement en faisant un distinguo clair entre les CAs d'origine et celles ajoutées à la main).

        • [^] # Re: Varnish

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

          Les auto-signés, ça va deux minutes. Si chacun des visiteurs de ton site (y compris sa partie publique) doit préalablement installer une CA, ça va être vraiment chiant.

          Certes

          Sauf à ce que les navigateurs comprennent enfin qu'SSL sert autant à authentifier un tiers qu'à s'assurer qu'il ne change pas dans le temps, et rendent l'ajout de nouvelles CAs beaucoup moins flippant (éventuellement en faisant un distinguo clair entre les CAs d'origine et celles ajoutées à la main).

          Oui, surtout si le navigateur n'a pas de certificat « de confiance » pour le site en question.

        • [^] # Re: Varnish

          Posté par  . Évalué à 5.

          Sauf à ce que les navigateurs comprennent enfin qu'SSL sert autant à authentifier un tiers qu'à s'assurer qu'il ne change pas dans le temps, et rendent l'ajout de nouvelles CAs beaucoup moins flippant

          Heu, ajouter un certificat pour un site donné est une chose. Ajouter une CA en est une autre, beaucoup plus dangereuse…

          • [^] # Re: Varnish

            Posté par  . Évalué à 4.

            Tout dépend comment c'est fait. Aujourd'hui, c'est exact. Mais si demain, les CAs "ajoutées" ont un niveau de confiance par défaut plus faible que les autres, et que cela se voit lorsqu'on visite un site dont elles vérifient le certificat - quelque-chose d'un peu mieux gaulé que le machin vert du "extended verified" - pourquoi pas?

            Et je sais que le sujet est déjà largement discuté, et je n'ai pas prétention à résoudre le problème de la confiance en SSL tout seul dans mon coin, mais je serais très favorable à une extension des certificats de CA qui indiqueraient le(s) domaine(s) autorisés à la certification.

            Du genre ma CA perso indique d'entrée de jeu qu'elle est habilitée à signer pour *.truc.com, *.machin.fr, et ssl.bidule.net. Et si un certificat est vérifié par elle sur un autre domaine, je pête un joli avertissement (voire je refuse directement).

            Et tant qu'à faire, dans la procédure qui permet d'ajouter une CA, je montre de manière bien visible les domaines pour lesquels elle s'annonce. En rouge vif si la liste est trop longue et/ou contient trop de wildcards.

        • [^] # Re: Varnish

          Posté par  . Évalué à 5.

          Sauf à ce que les navigateurs comprennent enfin qu'SSL sert autant à authentifier un tiers qu'à s'assurer qu'il ne change pas dans le temps

          C'est surtout aux serveurs de comprendre ça, en installant Certificate Patrol on se rend compte que les certificats, y compris leur CA émetteur, changent tout le temps ! Y compris pour Google, Facebook, et d'autres bien connus.

  • # Téléchargement et webservice

    Posté par  . Évalué à 0.

    Pour moi il y a 2 cas d'usage de HTTP qui constituent un détournement de HTTP :

    • le téléchargement : je parle de gros fichiers
    • l'utilisation comme API : webservice et subversion

    Je présume que bien que si un protocole prenait en compte dès sa conception ces deux cas d'utilisation, il y aurait moyen d'être plus simple et/ou plus performant. Est-ce que quelque chose a était prévu dans spdy pour cela ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Téléchargement et webservice

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

      Tu aurais des liens vers de la documentation sur quel protocole pour quel usage ? Quels avantages offre ftp par exemple ?

      • [^] # Re: Téléchargement et webservice

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

        Pour ftp, je dirais la vitesse (sur les gros fichiers) car le transfert peut être fait directement en binaire.

        Clairement le problème, ici, est que certain (la plupart?) des admin sont des incompétents qui bloquent tout sauf le port 80 et 443 en pensant que ça rend leur install sûr.

        Il y a aussi (parfois) le problème des NAT.

        • [^] # Re: Téléchargement et webservice

          Posté par  (Mastodon) . Évalué à 10.

          Pour ftp, je dirais la vitesse (sur les gros fichiers) car le transfert peut être fait directement en binaire

          C'est pareil en HTTP. Aucun avantage de FTP à ce niveau-là (et sur les petits fichiers, FTP est beaucoup plus lent que HTTP)

        • [^] # Re: Téléchargement et webservice

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

          Pour ftp, je dirais la vitesse (sur les gros fichiers) car le transfert peut être fait directement en binaire.

          En HTTP aussi il me semble.

        • [^] # Re: Téléchargement et webservice

          Posté par  . Évalué à 4.

          certain (la plupart?) des admin sont des incompétents qui bloquent tout sauf le port 80 et 443

          La plupart des developpeurs sont trop associaux pour oser demander une ouverture de flux et préférent coder un truc complètement sous optimal 'over http'.

        • [^] # Re:Téléchargementet webservice

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

          Pour ftp, je dirais la vitesse (sur les gros fichiers) car le transfert peut être fait directement en binaire.

          Pourquoi est ce plus rapide ?

        • [^] # Re: Téléchargement et webservice

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

          Clairement le problème, ici, est que certain (la plupart?) des admin sont des incompétents qui bloquent tout sauf le port 80 et 443 en pensant que ça rend leur install sûr.

          Non, parce que ça pose problème même avec des pare-feux intelligemment réglés. Selon le mode (actif ou passif), FTP fait forcément chier au moins un pare-feu (celui du serveur ou celui du client), qui doit intégrer soit un proxy FTP soit un assistant de traque de connexion dédié à FTP.

          Par ailleurs, FTP n'est pas sécurisé. Et tenter de sécuriser la connexion de contrôle le rend totalement incompatible avec les pare-feux, qui ne peuvent plus du tout traquer la connexion secondaire.

      • [^] # Re: Téléchargement et webservice

        Posté par  . Évalué à 10.

        En fait c'est simple:

        Si tu d/l over http,qui est un mauvais protocole pour cette tâche, le serveur d'en face, il ouvre socket et il envoie des données. Avec FTP ou autre chose, c'est beaucoup mieux: Le serveur d'en face, il ouvre une socket et il envoie des donnés dedans. C'est un bon protocole.

        • [^] # Re: Téléchargement et webservice

          Posté par  (Mastodon) . Évalué à 10.

          Pas vraiment.

          Avec HTTP, le client ouvre la connexion, demande les données, et les reçoit du serveur.

          Avec FTP, le client ouvre la connexion, demande les données, puis le serveur ouvre un deuxième socket, envoie son IP et le port au client, qui va ouvrir une deuxième connexion dessus, et finalement recevoir les données.

          Conclusion : HTTP > FTP pour le téléchargement de données (car plus simple, moins d'overhead, et qui évite une gymnastique assez pénible pour gérer le routage ou le firewalling)

          • [^] # Re: Téléchargement et webservice

            Posté par  . Évalué à 1.

            Effectivement, ça se passe exactement comme tu l'as décrit.

            J'ai simplifié au maximum pour mettre en évidence le point suivant: Aux négociations protocolaires près, c'est exactement la même chose, à savoir un tuyau(une socket) dans lequel on écrit des données d'un coté et où on les lit de l'autre. Il n'y a aucune différence fondamentale, ce sont exactement les mêmes mécanismes sous-jacents. Le reste c'est de la littérature.

            Après on peut arguer que le serveur ne s'attend pas à en recevoir autant d'un coup (upload) ou à devoir en envoyer une telle quantité (download), et que ça influe sur son comportement. Il me semble qu'aujourd'hui autant les httpd que les browsers savent que cela peut arriver et qu'ils adopteront le bon comportement.

    • [^] # Re: Téléchargement et webservice

      Posté par  . Évalué à 4.

      Le but de spdy c'est de rendre HTTP TCP friendly. On change juste ce qui passe sur le cable et comment, mais on ne touche pas à la partie visible par les utilisateurs.

    • [^] # Re: Téléchargement et webservice

      Posté par  (Mastodon) . Évalué à 3.

      le téléchargement : je parle de gros fichiers

      C'est quoi le problème d'utiliser HTTP pour ça ? Et tu verrais quoi à la place ?

      • [^] # Re: Téléchargement et webservice

        Posté par  . Évalué à 2. Dernière modification le 19 avril 2012 à 11:10.

        En fait j'ai dis des âneries (j'aurais du vérifier avant de poster), je pensais que HTTP avait besoin d'encoder les binaires par exemple en base64 pour le téléchargement ce qui entraîne une augmentation du volume à télécharger.

        Donc moinssez-moi avec plaisir.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Téléchargement et webservice

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

        Personnellement, je trouve qu'il y a au moins 2 problèmes à utiliser HTTP pour le téléchargement de gros fichiers :
        * Reprise après interruption aléatoire
        * aucune vérification

        Ce serait bien que les différents navigateurs se mettent d'accord sur un protocole mieux foutu pour ça. Il y a bittorrent qui est très utilisé. Mais il existe aussi rsync, zsync et surement plein d'autres, avec des avantages et des inconvénients.

    • [^] # Re: Téléchargement et webservice

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

      J'ai trouvé un comparatif FTP vs HTTP pour le téléchargement des fichiers.

      http://daniel.haxx.se/docs/ftp-vs-http.html

      HTTP semble bien meilleur en fin de compte pour le téléchargement de fichier.

      Après tout, c'est logique aussi : c'est un protocole plus jeune (donc ayant pris en compte des besoins plus modernes), et tout comme FTP, sa principale fonction est de transférer des fichiers aussi. Sauf que les fichiers ne sont pas indiqués par des commandes multiples, mais par une URI. (et que les fichiers soient des vrais fichiers physiques ou générés à la volée avec php, python, whatever, ne changent rien au principe).

      Bref, HTTP est un protocole de transfert de fichier.

  • # Sujet du commentaire

    Posté par  . Évalué à 9.

    et Chrome bien sûr (le projet SPeeDY étant un projet hébergé au sein de Chromium)

    Pas exactement, ça va bien plus loin que ça! Il y a un draft en proposition à l’IETF, dans l’objectif d’en faire une RFC:
    http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00
    Le code source du draft:
    https://github.com/mbelshe/SPDY-Specification

    Et surtout, SPDY a amené au sein de l’IETF à des discussions pour faire HTTP 2.0 ! Seulement Microsoft a décidé de mettre son grain de sel et a annoncé qu’il n’était pas content du tout de l’état actuel du draft, par exemple, il veulent enlever le SSL par défaut (mais pourquoi ? :-( )
    http://www.mnot.net/blog/2012/03/31/whats_next_for_http
    http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/1004.html
    http://www.readwriteweb.com/enterprise/2012/03/microsoft-sees-googles-hand-fo.php

    • [^] # Re: Sujet du commentaire

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

      il veulent enlever le SSL par défaut (mais pourquoi ? :-( )

      Parce qu'ils servent de courroie de transmission à certains services de surveillance qui seraient gênés par cette fonctionnalité.

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: Sujet du commentaire

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

        source ?

      • [^] # Re: Sujet du commentaire

        Posté par  . Évalué à 2.

        Peu probable. Les services dignes de ce nom peuvent se procurer des vrais faux certificats et faire du man in the middle en toute tranquillité. Et ce sera d'autant plus efficace que la cible aura un faux sentiment de sécu. Tout l'écosystème de SSL pousse dans ce sens : entre les gros qui jouent à la valse des certifs rendant vaines les idées de contrôle côté client, et les CA qui se font piquer leur clef secrètes, ça fait fort longtemps que le SSL ne produit plus qu'un epsilon de la sécurité dont il est communément fait la publicité.

        Le SSL c'est mieux que rien pour les choses triviales, mais vous fiez pas à SSL pour des trucs confidentiels.

        • [^] # Re: Sujet du commentaire

          Posté par  . Évalué à 3.

          vous fiez pas à SSL pour des trucs confidentiels

          Si, mais correctement. I.e. en fournissant les certificats aux deux bouts, par un échange préalable.

          • [^] # Re: Sujet du commentaire

            Posté par  . Évalué à 2.

            Pour le commun des mortels, les grands navigateurs ne permettent pas de faire ce genre de chose sans mise en danger par une ergonomie et/ou un fonctionnement automatique inadapté.

    • [^] # Re: Sujet du commentaire

      Posté par  (Mastodon) . Évalué à 4.

      Croustillant. Merci de cet ajout. :-)

  • # Support par Firefox

    Posté par  (Mastodon) . Évalué à 2.

    Firefox se met à SPDY, et par défaut, à partir de la version … de maintenant (enfin, la béta). voir sur leur blog

Suivre le flux des commentaires

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