Journal spdy://

Post√©¬†par¬† . 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…

  • le module pour Apache (source, .deb & .rpm)
  • SPDY, site de r√©f√©rence
  • L'annonce par les d√©velopppeurs

√Ä 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¬† (Mastodon) . √Čvalu√©¬†√†¬†10.

              Aux négociations protocolaires près, c'est exactement la même chose

              Oui, mais c'est exactement à cause de ce "détail" que FTP est un protocole pourri.

    • [^] # 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/04/12 √† 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é.

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # 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¬† . √Čvalu√©¬†√†¬†4.

      Croustillant. Merci de cet ajout. :-)

  • # Support par Firefox

    Post√©¬†par¬† . √Č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.