«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 windu.2b . Ă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 :
[^] # Re: Une dĂ©pĂȘche ! Une dĂ©pĂȘche !
PostĂ© par netsurfeur . ĂvaluĂ© Ă 7.
Et ne pas oublier
(ćé€) connection (ćé€ăăăŸă§)=> connexion (plusieurs occurrences)# Activation
PostĂ© par Spack . Ă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 barmic . Ă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 windu.2b . Ă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 Seb . Ă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 Milridor . Ă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 Larry Cow . Ă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 Milridor . ĂvaluĂ© Ă 3.
Certes
Oui, surtout si le navigateur n'a pas de certificat « de confiance » pour le site en question.
[^] # Re: Varnish
PostĂ© par Antoine . ĂvaluĂ© Ă 5.
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 Larry Cow . Ă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 neil . ĂvaluĂ© Ă 5.
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 barmic . ĂvaluĂ© Ă 0.
Pour moi il y a 2 cas d'usage de HTTP qui constituent un détournement de HTTP :
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 psychoslave__ (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 Milridor . Ă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 Buf (Mastodon) . ĂvaluĂ© Ă 10.
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 đČ Tanguy Ortolo (site web personnel) . ĂvaluĂ© Ă 4.
En HTTP aussi il me semble.
[^] # Re: Téléchargement et webservice
PostĂ© par Milridor . ĂvaluĂ© Ă 4.
Hum… en effet…
Ăa m'apprendra Ă Ă©crire avant de vĂ©rifier…
[^] # Re: Téléchargement et webservice
PostĂ© par Volnai . ĂvaluĂ© Ă 4.
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 Juke (site web personnel) . ĂvaluĂ© Ă 4.
Pourquoi est ce plus rapide ?
[^] # Re: Téléchargement et webservice
PostĂ© par đČ Tanguy Ortolo (site web personnel) . ĂvaluĂ© Ă 6.
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 Milridor . ĂvaluĂ© Ă 2.
Le commentaire sur les pare-feux ne concernait pas que le FTP. (En rĂ©sidence universitaire oĂč j'Ă©tais, le fournisseur d'accĂšs interdisait toute les connexions sortante vers autre chose que le port 443 et 80…)
[^] # Re: Téléchargement et webservice
PostĂ© par barmic . ĂvaluĂ© Ă 2.
Oui enfin tout le monde parle de FTP, mais si tu veux un peu de sĂ©curitĂ© il faut aller voir SFTP plutĂŽt que de tenter de faire quelque chose avec FTP. Et lĂ d'un coup c'est firewall bien configurĂ© compliant et sĂ©curisĂ© (mais je n'ai aucune idĂ©e de l'intĂ©rĂȘt face Ă HTTP ou plus exactement HTTPS).
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 Enzo Bricolo đ âđ . ĂvaluĂ© Ă 1.
et l'EDIINT AS3, c'est fait pour qui ?
https://linuxfr.org/users/enzo_bricolo/journaux/quatre-as-dans-la-manche
[^] # Re: Téléchargement et webservice
PostĂ© par Didrik Pining . Ă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 Buf (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 Didrik Pining . Ă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 Buf (Mastodon) . ĂvaluĂ© Ă 10.
Oui, mais c'est exactement à cause de ce "détail" que FTP est un protocole pourri.
[^] # Re: Téléchargement et webservice
PostĂ© par M . ĂvaluĂ© Ă 5.
Sauf qu'avec ftp tu peut transférer des fichiers de serveur a serveur sans devoir les faire transiter par chez toi.
A l’Ă©poque c’Ă©tait pas nĂ©gligeable…
[^] # Re: Téléchargement et webservice
PostĂ© par totof2000 . ĂvaluĂ© Ă 4.
man wget.
[^] # Re: Téléchargement et webservice
PostĂ© par ckyl . Ă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 Buf (Mastodon) . ĂvaluĂ© Ă 3.
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 barmic . Ă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 Milridor . ĂvaluĂ© Ă 0.
C'est marrant j'ai fait exactement la mĂȘme erreur :-/
[^] # Re: Téléchargement et webservice
PostĂ© par Maz . Ă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 Laurent J (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 Aissen . ĂvaluĂ© Ă 9.
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 lolop (site web personnel) . ĂvaluĂ© Ă 3.
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 Juke (site web personnel) . ĂvaluĂ© Ă 5.
source ?
[^] # Re: Sujet du commentaire
PostĂ© par Frank-N-Furter . ĂvaluĂ© Ă 2.
http://www.davidicke.com/
Depending on the time of day, the French go either way.
[^] # Re: Sujet du commentaire
PostĂ© par lolop (site web personnel) . ĂvaluĂ© Ă 1.
De ma part, aucune, juste une supputation.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Sujet du commentaire
PostĂ© par Guillaume Knispel . Ă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 Larry Cow . ĂvaluĂ© Ă 3.
Si, mais correctement. I.e. en fournissant les certificats aux deux bouts, par un échange préalable.
[^] # Re: Sujet du commentaire
PostĂ© par Guillaume Knispel . Ă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 bubarđŠ„ . ĂvaluĂ© Ă 4.
Croustillant. Merci de cet ajout. :-)
# Support par Firefox
PostĂ© par bubarđŠ„ . Ă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.