HTTP est devenu au cours des dernières années le protocole à tout faire. Au départ prévu pour servir de l'information structurée par lien hypertexte, il est aujourd'hui utilisé pour tout et n'importe quoi. Cette évolution ne va pas sans poser de problèmes. C'est pourquoi sous l'égide de l'IETF un groupe de travail httpbis s'est mis en place.
Une nouvelle mouture du protocole tarte à la crèmeHTTP est donc en route. Faisons un petit tour de son histoire et des projets en cours, avant d'écouter ce qu'à a nous en dire Willy Tarreau qui s'est particulièrement investi dans le groupe de travail httpbis.
NdM : Merci à Nÿco, Florent Zara, patrick_g, Raoul Volfoni, baud123, warwick, Nils Ratusznik, NeoX, zebra3 et Benoît pour leur contributions à cette dépêche.
Sommaire
Un brin d'histoire
GET /
HTTP et son complice le HTML trouvent leur origine dans les travaux de Tim Berners-Lee sur l'hypertexte en 1989. C'est la naissance du WorldWideWeb.
La spécification de base est posée :
- un verbe décrivant l’action (uniquement GET en HTTP/0.9) ;
- une URI désignant la ressource ;
- un code de retour ;
- l’information au format MIME ;
- pas d’état (la connexion est fermée à chaque échange).
On notera que dès le départ HTTP se bat un peu contre lui même, puisque dès 1994 l'usage des cookies se répand sous l'impulsion de Lou Montulli qui les utilise pour l'une des premières boutiques en ligne.
HEAD / HTTP/1.0
Il faut attendre 1996 pour que soit standardisée la première version du protocole (HTTP/1.0 RFC 1945). Elle apporte de nouveaux verbes (POST, HEAD mais aussi PUT, DELETE, LINK, UNLINK).
Elle pose les bases des bonnes pratiques en termes d’en‐têtes et de formatage des réponses, elle normalise les codes d’erreurs ; bref, transforme HTTP en protocole complet. Il est intéressant de constater que cette version du protocole prévoit déjà la possibilité de gérer du cache côté client (en‐têtes Last-modified, Pragma, Expires) et la compression. La problématique d’une utilisation optimale de la bande passante était déjà à l’ordre du jour.
TRACE / HTTP/1.1
À peine un an plus tard la RFC 2068 spécifie une version améliorée du protocole. Complétée en 1999 par la RFC 2616, cette version ajoute les verbes OPTIONS, CONNECT et TRACE (rendant obsolètes au passage LINK et UNLINK), rend obligatoire l'en-tête Host et fixe le protocole dans sa forme actuelle.
L'essentiel des ajouts de HTTP/1.1 concerne avant tout la négociation de contenu et de langage (Accept, Accept-Language, Accept-Charset) ainsi que le pipelining au travers notamment du Keepalive (en-tête Connection). Elle offre en outre la possibilité de découper la réponse en plusieurs morceaux (Transfer-Encoding: chunked).
PATCH / HTTP/1.1
L'évolution du protocole est depuis relativement constante, mais mesurée. On notera la standardisation en 2000 du HTTPS, l'usage des en-têtes (Etag et Vary) pour la gestion du cache côté client et de la compression, l'ajout non normalisé du verbe PURGE utilisé par les proxies cache. Plus récemment, l'ajout du verbe PATCH (RFC 5789) qui n'a pas remué les foules ainsi que de quelques codes d'erreur (RFC 6585). D'autres possibilités viennent de l'évolution de protocoles tiers comme TLS (en particulier SNI qui met fin à l'obligation d'avoir une IP par site pour le HTTPS et favorise des initiatives comme HTTPS Everywhere).
Oui mais
Au vu de ce rapide tour d'horizon, il apparaît clairement que le protocole HTTP s'il a été largement adopté pour sa simplicité, a également toujours cherché à devenir ce qu'il n'est pas. Car, malgré le keepalive et les cookies, il reste fondamentalement un protocole déconnecté et sans états. Cela bien sûr se discute, mais il est quand même notable de constater qu'il aura fallu attendre cette année pour avoir une implémentation efficiente du keepalive dans le serveur web Apache (avec le mpm-event) ou encore que les cookies posent de vrais problèmes de vie privée (voir par exemple ce journal). De même, la gestion du cache côté navigateur, met en œuvre pas moins de quatre en-têtes tous optionnels (Pragma, Expires, Last-modified, Etag) ce qui rend l'implémentation quelque peu délicate et les effets de bord relativement nombreux. La compression, bien utile dans son ensemble, alourdit les traitements serveur comme client et somme toute les possibilités offertes par le format MIME sont relativement peu exploitées.
Du coup, avec l’avènement des smartphones, de la FullHD, du monde tout connecté toujours dans les nuages et des User-Agent à rallonge ("Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)" , "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19", …) certains ont senti qu'une évolution majeure du protocole était inévitable.
HTTPbis
Push toi de là
L'une des questions centrales dans l'évolution de HTTP est celle du push. Si elle a été abordée très tôt avec le type multipart/x-mixed-replace de Netscape (dès 1995), le défaut de consensus fait qu'à l'heure actuelle la situation n'est toujours pas figée. Le HTML5 avec les Server Sent Event (type text/event-stream) et l'API websocket devrait y remédier, mais le modèle même de HTTP rend difficile l'utilisation optimale d'une connexion persistante vers le serveur. Cette question est au centre de HTTP/2.0
Va donc chez…
Pour répondre à cette problématique, Google a introduit en 2009 le protocole expérimental SPDY. Il est actuellement implémenté dans Chromium, Firefox ainsi que dans Apache httpd via mod_spdy. Ce protocole se présente comme une couche de session, s'intercalant entre HTTP et SSL offrant :
- le multiplexage des flux (plusieurs flux au sein d'une seule connexion tcp)
- la priorité des requêtes
- la compression des en-têtes
Bien que l'amélioration des performances ne fasse aucun doute (le protocole a été par exemple adopté par twitter), SPDY est loin d'être idéal dans la mesure où il ne se défait pas des défauts de HTTP/1.1 et qu'il pose quelques nouveaux problèmes.
Dans un message sur la liste de haproxy, Willy Tarreau explique :
SPDY est sympa et apporte un gros gain de performances, mais au prix d’une infrastructure beaucoup plus complexe et d’une résistance moindre aux attaques DoS. Il est à peu près 100 fois plus facile de faire un déni de service sur un serveur SPDY que sur un serveur HTTP parce qu’avec la compression des en‐têtes vous pouvez forcer le serveur à analyser et traiter de très grandes requêtes avec très peu d’octets. La compression des en‐têtes signifie aussi que le double buffering devient obligatoire ce qui a un coût au niveau des mandataires.
Pour le moment avec SPDY, le HTTP/1.1 peut être optimisé autant que possible. Mais il y a des problèmes inhérents à HTTP/1.1 qui devront être réglés avec HTTP/2.0 (CRLF, en‐têtes longs, folding, etc.).
SPDY fait actuellement l'objet d'un « draft » dans le cadre du groupe de travail httpbis.
Ne pas confondre vitesse et précipitation
Suite à l’initiative de Google, Microsoft a proposé sa propre vision de l’évolution de HTTP appelée Speed+Mobility. Celui‐ci reprend l’essentiel de SPDY en essayant de tenir compte des appareils nomades, et en particulier d’optimiser les accès réseau pour accroître la durée de vie des batteries. Un rôle plus important est accordé aux websockets, mais pour l’essentiel l’approche est relativement similaire à celle de Google.
La revanche du proxy
Pour une approche différente, il faudra attendre une proposition émanant de Willy Tarreau (HAProxy), Poul‐Henning Kamp (Varnish), Adrien de Croy (WinGate) et Amos Jeffries (Squid) nommée httpbis Network Friendly. Elle s’articule autour de quatre améliorations à HTTP/1.1 :
- codage binaire des en‐têtes (cela évite les cycles de compression / décompression et favorise un traitement rapide) ;
- groupement des en-têtes communs. Si l’on multiplexe les requêtes au sein d’une même connexion, il est alors inutile de repasser à chaque fois certains paramètres (Host, User-Agent, version de HTTP…) ;
- multiplexage des requêtes et des réponses (elles sont envoyées en parallèle et sans ordre) ;
- un modèle en couche favorisant la mutualisation des informations (éviter les copies et le travail redondant).
Gageons que ce draft issue de l’expérience et du pragmatisme des développeurs trouvera sa place dans la mêlée. Il est certain (au vu des discussions sur la liste de httpbis) que ses auteurs le défendent avec vigueur.
Enfin
Comme on a pu le voir, HTTP/2.0 est sur les rails. Beaucoup d'acteurs du secteur semblent militer pour une finalisation rapide et une adoption massive. La démocratisation du web mobile y est sans doute pour beaucoup. Le groupe httpbis semble très actif et de nombreux documents sont produits.
On peut sans doute se féliciter de voir la communauté se saisir du problème. D'autant plus que les gens d'Apache, de Mozilla et quelques figures historiques comme Roy Fielding viendront sans doute y mettre leur grain de sel.
Questions à Willy Tarreau
Willy Tarreau est l’auteur du répartiteur de charge HAProxy. Il est aussi le dernier mainteneur des branches 2.4, 2.6.27 et 2.6.32 du noyau linux.
Comment est née l’initiative du draft httpbis-Network-Friendly ?
Willy Tarreau : Au début de l’année, Mark Nottingham a lancé un appel à propositions pour HTTP/2.0 sur le groupe. En fait il avait déjà prévenu un certain nombre de participants en privé de son intention de lancer le sujet, ce qui a permis aux gens de se préparer à mettre de l’ordre dans leurs idées. Les développeurs de SPDY ont rapidement proposé un document qui décrit très précisément le fonctionnement de leur protocole. Toutefois, à la lecture du document, un certain nombre de points ont causé une certaine discorde sur le groupe de travail : la compression des entêtes est obligatoire, puisque c’est l’un des piliers de la solution, et il n’est pas prévu de pouvoir réutiliser le port 80 ; au lieu de ça, une mise en œuvre sur TLS était suggérée (mais non mentionnée dans le document), ce qui rend TLS obligatoire partout où du HTTP est utilisé.
Les contraintes sur la compression et sur TLS sont des éléments bloquants pour un grand nombre de composants communément appelés les « intermédiaires », c’est‐à‐dire tous ceux qui subissent HTTP car étant placés entre un client et un serveur, ils doivent le comprendre et se rendre les plus compatibles possibles, à des niveaux de performance qui sont souvent d’au moins un ordre de grandeur au‐dessus de celui des serveurs habituels.
Pour des répartiteurs de charge qui traitent un million de requêtes par seconde, il n’est même pas concevable de devoir d’abord décompresser une requête pour commencer à l’interpréter, le coût est important et les DDoS deviennent grandement facilités. De la même manière, tout le monde n’est
pas d’accord pour chiffrer tout et n’importe quoi, que ce soit pour des raisons légales, d’inutilité (ex : communications entre serveurs) ou de difficultés à gérer correctement les certificats (ce qui est toujours pitoyable, chacun d’entre‐nous ayant pris l’habitude de cliquer aveuglément sur « j’accepte les risques » sur son navigateur en visitant plein de sites mal configurés).
Du coup, un certain nombre de participants travaillant sur des produits dits « intermédiaires » ont commencé à utiliser les mêmes arguments contre certaines des propositions. Amos Jeffries, le mainteneur de Squid, avait offert de participer à un draft si certains voulaient se lancer. Personne n’en avait vraiment le temps. Puis les discussions allant bon train, à un moment Roy Fielding, l’auteur d’Apache qui est un des auteurs des specificationss HTTP m’a répondu « écoute, ce n’est pas la peine de répéter sans cesse les mêmes choses, ici tout le monde a bien compris ton point de vue, donc maintenant tu fais un draft et ce sera mieux pour tout le monde ». Finalement, il a réussi à me convaincre de l’utilité de ce draft, mais je ne me sentais pas de me lancer là‐dedans tout seul, je ne connaissais rien au processus de publication, je suis nul en XML (le langage des documents) et je n’avais pas la vision complète des problèmes à couvrir. Finalement, j’ai commencé à pondre quelques lignes et j’ai décidé de recontacter Amos pour lui demander si sa proposition tenait toujours. Il était ravi de pouvoir se lancer aussi, donc on a travaillé à concevoir une ébauche de protocole plusieurs jours d’affilée sans s’interrompre, lui étant en Nouvelle Zélande, il n’y avait pas de temps morts. Puis, au fur et à mesure que nos avis convergeaient, j’ai commencé à rédiger. J’en ai fait part à Mark qui m’a proposé un créneau de présentation à la conférence qui se tenait à Paris la semaine suivante, ce que j’ai accepté avec la sensation d’un poids important qui commençait à peser sur mes épaules, parce qu’il fallait finir de produire le draft coûte que coûte. J’ai proposé à Adrien de Croy de WinGate de se joindre à nous, parce qu’il avait de bonnes idées, puis à Poul Henning Kamp de Varnish, vu qu’il avait une vision différente mais très complémentaire. Et, à raison de 6 heures de travail par nuit, le draft a vu le jour la veille de sa présentation.
Quel est son apport par rapport aux drafts existants ?
Willy Tarreau : En plus de l'optimisation des échanges entre le client et le serveur, il est focalisé sur deux points pas du tout couverts par SPDY, qui sont la préservation des ressources des intermédiaires, et la réutilisation des infrastructures existantes. Le premier point est primordial. Si le nouveau standard multiplie par 10 le travail des intermédiaires, on peut dire adieu au load-balancing et à pas mal d'accélérateurs. Au lieu de ça, on doit réduire encore les coûts en évitant de répéter des entêtes déjà transmis, afin que le 100 Gbps qui arrive puisse être une réalité. J'ai discuté de nos propositions avec les auteurs de SPDY qui y sont très favorables, ils ont reconnu ne pas avoir traité ce sujet et sont ouverts à remplacer leur algorithme de compression par un équivalent du nôtre qui aura une efficacité comparable mais à un coût beaucoup plus faible.
Le second point sur la réutilisation des infrastructures existantes me semble important également : pour qu'un protocole puisse être déployé, il faut qu'il ait des utilisateurs. Dans les écoles, les administrations et les grandes entreprises, si l'on n'a pas de produit pour analyser le contenu des échanges effectués sur ce nouveau protocole et pour le filtrer, on ne l'ouvre pas. Il faut aussi qu'il soit supporté par les caches, sinon le surcoût de trafic non cachable va engendrer son blocage de force à plein d'endroits. Où est la motivation alors pour les petits sites à implémenter un protocole qui n'est pas déployé partout ? Si c'est pour ouvrir systématiquement les deux (HTTP/1.1 et HTTP/2.0) et gérer la sécurité en doublon, on sait bien comment ça va finir, les gros qui ont des moyens supporteront les deux et les petits ne supporteront que l'ancien et on se retrouve avec un HTTP à deux vitesses.
Du coup nous avons proposé une méthode permettant de réutiliser ce qui existe avec le port 80, et qui permet à un client de formuler ses requêtes en HTTP/1.1 avec des extensions 2.0 et de continuer ensuite en 2.0 si toute la chaîne le supporte, et ceci sans ralentissement. L'avantage est que les administrateurs de réseaux pourront toujours gérer leur politique de filtrage à leur guise et maintenir ces sites ouverts avec un déploiement progressif au fur et à mesure que leurs composants sont mis à jour.
L’autre draft principal qui a été proposé consiste à réutiliser la couche WebSocket comme protocole de transport et de véhiculer des messages de type SPDY entrelacés dedans. C’est une façon de régler le problème du port 80 sans avoir à tout réinventer, car il y a quand même beaucoup de bonnes choses dans SPDY. Ce draft a été publié par Gabriel Montenegro qui est l’un des responsables du groupe de travail WebSocket et qui travaille aussi chez Microsoft. Il travaillait à côté de moi sur son draft pendant les conférences, et m’en a expliqué les principes. Il faut d’abord savoir que les drafts sont des travaux individuels, et que même si les individus partagent souvent des points de vue avec leur entreprise, leurs travaux sont personnels et n’engagent qu’eux. Mais, là, la suite était inévitable, je lui ai dit « tu vas voir que les journaux vont faire leur une en racontant partout que c’est Microsoft qui riposte à Google ». Et ça n’a pas raté vu que la presse ne publie que ce qui fait sensation :-). Nulle part il n’a été dit que l’un des pères de WebSocket pensait d’abord intervertir les rôles pour que WebSocket devienne le transport de HTTP !
As-tu le sentiment que les choses progressent dans le bon sens ? Que la discussion est ouverte ?
Willy Tarreau : En partie, oui. On sent déjà depuis plusieurs mois une préférence marquée pour SPDY parce que pas mal de librairies permettent de l'intégrer facilement à des nouveaux développements, et c'est séduisant. Les gains en vitesse de chargement qu'il procure en environnement mobile sont incontestables. Au-dessus de ça, il y a des tensions inévitables et compréhensibles. Des personnes qui ont travaillé longtemps et qui ont vraiment fait un travail de fourmi comme celui-ci n'aiment pas que leurs travaux soient critiqués par des gens qui n'ont rien à montrer en face. D'autre part, ces personnes fondent parfois des espoirs de futurs projets dont cette brique serait une première étape, et l'acceptation ou non de leur travail leur cause alors un certain stress légitime. Mais le fait d'avoir pu discuter avec les personnes en face à face aide beaucoup, ça permet de mieux comprendre les motivations des uns et des autres, de leur faire comprendre qu'on nage dans le même sens et qu'on n'est pas concurrents, et de mieux parvenir à des compromis sur certains points. Je pense qu'aujourd'hui les auteurs de SPDY sont prêts à revoir leur mécanisme de compression sur lequel ils ont pourtant fait un travail considérable. Ils ne sont a priori pas encore décidés à repasser sur le port 80, mais le succès espéré de WebSocket qui utilise déjà cette méthode pourrait faire changer les avis une fois que cela marchera bien. Il ne faut pas précipiter les choses sur HTTP, on risque d'en avoir pour 20 nouvelles années, et si on se plante, on restera encore en 1.1 comme les 10 années passées depuis la dernière tentative échouée de mise à jour.
Une dernière remarque ?
Willy Tarreau : Participer aux groupes de travail de l’IETF est très prenant et très utile, parce qu’en remontant des problèmes avant qu’ils ne deviennent des standards, on évite d’avoir à implémenter n’importe quoi plus tard dans ses propres produits. Et ça ne peut marcher que s’il y a beaucoup de participants, car personne ne détient le savoir. C’est ce qui a été difficile sur WebSocket, il y avait trop peu de participants et ça ressemblait à des guerres de bandes rivales, mais on a quand même abouti à quelque chose de bien. Pour participer aussi à quelques autres projets, j’ai remarqué une chose qui est très marquante au début : les jeunes se préoccupent du présent et les vieux du futur ! Je veux dire que les nouveaux n’ont pas l’expérience des protocoles qui vivent 20 ans et pensent d’abord aux apports immédiats, alors que les anciens savent que les apports ne se mesurent que dans la durée. Et je dois dire que l’exercice consistant à se projeter dans le futur pour estimer les impacts de telle ou telle décision relève un peu de la science fiction. On conçoit par exemple HTTP/2.0 avec en tête le fait que quand il sera omniprésent, les plus gros serveurs disposeront d’une connectivité en Terabit/s, qui sera aussi la taille de chacun des points d’accès des gros sites comme les réseaux sociaux. Et ça, je dois dire que c’est un exercice assez difficile mais nécessaire. J’ai entendu, par exemple, Roy Fielding dire « Si j’avais pu imaginer qu’un jour l’en‐tête If-Modified-Since serait responsable à lui seul de 20 % du trafic montant des smartphones, je l’aurais appelé autrement ». Il faut donc essayer de penser à tout et apprendre à ne pas rire des hypothèses farfelues émises par ses voisins. Et ça c’est un vrai défi !
Aller plus loin
- Page du groupe de travail httpbis à l'IETF (289 clics)
- SPDY: An experimental protocol for a faster web (124 clics)
- Proposition de Tim Berners-Lee à l'origine du web (104 clics)
- Fil sur SPDY sur la mailing list de haproxy (62 clics)
- L'annonce de HTTP Speed+Mobility sur le blog de msdn (54 clics)
- Site de l'IETF (37 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à -8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Compatibilité ascendante ?
Posté par Gabriel MAGNIEZ (site web personnel) . Évalué à 8.
Il faut bien lire tout l'article :-)
# La revanche du proxy
Posté par alpha_one_x86 (site web personnel) . Évalué à -4.
Je suis très fortement d'accords avec le paragraphe "La revanche du proxy".
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# SRV
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Et les enregistrements SRV, pour mettre HTTP au même niveau que des protocoles de conception plus modernes tels que SMTP (oui oui, SMTP est plus moderne que HTTP sur ce point-là), SIP, LDAP ou XMPP, et lui permettre de bénéficier de :
est-ce que c'est au programme ou est-ce qu'HTTP est vraiment trop fossilisé pour ça ?
[^] # Re: SRV
Posté par Moonz . Évalué à 9.
Tu peux leur proposer, si tu y tiens vraiment…
[^] # Re: SRV
Posté par barmic . Évalué à 2.
Je ne sais pas pourquoi il a était moinssé, les groupes de travail de l'IETF son de ce que j'en ai pu voir assez ouvert, il suffit de s'incrire à la liste de diffusion et de poster sa question (in english of course).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: SRV
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Je me demande dans quelle mesure, ça ne sort pas du scope. Historiquement http est un protocole indépendant du transport. Donc qui peut en théorie être très bien utilisé sur autre chose que de l'IP. Bon on voit bien que ça parle quand même beaucoup de "connexions tcp" donc c'est peut-être un peu illusoire. Mais sans doute l'une des raisons.
Une raison plus fondamentale est que cela demande de revoir le format des URL.
Il y a eu un draft en 2002 à ce sujet : http://tools.ietf.org/html/draft-andrews-http-srv-01
[^] # Re: SRV
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Pourquoi donc ?
[^] # Re: SRV
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Pour clarifier la question du port qui peut être spécifié et dans l'url et dans le srv.
[^] # Re: SRV
Posté par Donk . Évalué à 2.
Suffit de dire que le port spécifié dans l'url écrase celui du srv
[^] # Re: SRV
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
Oui par exemple. Il faut juste le standardiser :)
# Entêtes binaires???
Posté par Gui13 (site web personnel) . Évalué à 10.
Euhhh ok.
Des entêtes binaires, pourquoi pas, mais ils risquent de péter ce qui faisait de HTTP une belle machine: le fait que ce soit du full text.
Qu'est ce qui va se passer quand ils devront ajouter d'autres champs dans cette entête? Ils vont laisser des valeurs "réservées" que tout le monde va vouloir utiliser?
Je suis un peu dubitatif sur le coup…
[^] # Re: Entêtes binaires???
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
Les protocoles binaires peuvent aussi avoir des extensions, champs nouveau et autres… c'est juste qu'entre parser un nombre à taille fix, et un texte à taille innoconu (on doit parser/décompressé jusqu'as trouvé la fin, en reconstituant la trame tcp en boucle jusqu'as avoir tout les morceaux de l'entéte)…
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Entêtes binaires???
Posté par Jux (site web personnel) . Évalué à 7.
Pour un exemple de protocol binaire est extensible tout en restant backward-compatible, tu peux jetter un oeil à Google Protocol Buffers par exemple :
http://code.google.com/p/protobuf/
[^] # Re: Entêtes binaires???
Posté par bilboa . Évalué à 2.
Pour moi c'est surtout que le binaire c'est illisible passé quelque bytes.
On commence par les en têtes binaires. Ensuite tout le protocole et le HTML aussi. Ensuite il faut des clients speciaux pour interpreter la source. Bref, tout ce qui faisait que HTTP/HTML était super simple s'en va avec le binaire.
Alors oui c'est moins efficace. Oui on gzip (=binaire) mais ca reste très standard, pas besoin d'un "décodeur" spécialisé.
[^] # Re: Entêtes binaires???
Posté par Zenitram (site web personnel) . Évalué à 3.
Tu devrais pas : c'est très utilisé dans d'autre domaines, genre la où la bande passante est le point important. Et ça marche (dans mon domaine, MPEG-TS a 17 ans, et évolue en permanence pour de nouveau besoins, alors que c'est encodé au bit près, avec l'aide de bits "réservé" = pas touche c'est pour le futur officiel et de bits "privé" = fait ce que tu veux avec, mais remplit le champs "registration" officiel quand même qu'on sache de qui ça vient).
J'avoue n'avoir jamais compris comment on peut "dépenser" autant de place en utilisant des centaines d'octets identiques à chaque requête, juste pour le plaisir qu'un être humain utilise vi pour décoder les octets (les octets n'étant que des octets, pas un "GET") plutôt qu'un vi implémentant autre chose que le décodage ASCII ou UTF-8 (qui transforme 0x01 en "GET" pour te faire plaisir).
[^] # Re: Entêtes binaires???
Posté par claudex . Évalué à 8.
Tu ne compare pas vraiment la même chose, pas mal de trucs qui transitent par http sont lisible avec vi (html, js, xml, json…), donc tu peux imaginer debugger avec. Tandis que la vidéo est de toute façon illisible dans vi et nécessite un logiciel dédié.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Entêtes binaires???
Posté par Moonz . Évalué à 9. Dernière modification le 25 mai 2012 à 11:21.
Parce qu’avec "vi" (non, pas vraiment vi, mais c’est toi qui a commencé), je peux taper en HTTP, FTP, SMTP, IMAP, POP, et j’en passe.
Avec ta solution, il me faut un vi-http, un vi-ftp, un vi-smtp, un vi-imap, un vi-pop. Avec vi je peux éditer du Latex, du HTML, du Markdown, du JSON, du XML. Toi pour ton MPEG-TS tu es obligé d’écrire un outil spécifique ; moi c’est tous les jours que j’utilise des scripts qui communiquent avec des serveurs web/mail et qui n’utilisent rien d’autre que
nc, les outils unix standards et des pipes.Franchement, le nom des entêtes c’est négligeable devant :
- les entêtes répétées pour toutes les ressources d’une page (j’ai fait F5 sur une page sur linuxfr : 16 requêtes HTTP, avec toutes les entêtes identiques à chaque fois renvoyées)
- les gadgets de HTTP dont on pouvait se passer (content negociation particulièrement : accept, accept-language, accept-encoding)
- les cookies
Franchement, sur cette requête :
(vous inquiétez pas, c’est pas mon vrai cookie)
Qu’est-ce qui te semble le plus efficace pour gagner de l’espace :
- trouver un encodage binaire pour les entêtes
- rationaliser le système de cache pour éviter d’avoir plusieurs entêtes pour le contrôle du cache
- trouver un mécanisme pour que client et serveur se mettent d’accord pour se passer des entêtes qui servent à rien dans 90% des requêtes : Accept-* (presque toutes les pages ont une seule représentation linguistique/informatique), Connection (quand t’es en HTTP 1.1 à priori tu es sûr que tu feras du keep-alive)
- changer le scope de certaines entêtes (User-Agent, Cookie, Referer) pour qu’elles soient valides le temps de la connexion plutôt que le temps de la requête
[^] # Re: Entêtes binaires???
Posté par Larry Cow . Évalué à 3.
Sauf s'ils ont été malins et ont basé ça sur un truc commun (protocol buffers?), auquel cas il faut juste un 'vi-protocolbuf'.
[^] # Re: Entêtes binaires???
Posté par Zenitram (site web personnel) . Évalué à 1.
Ou dictionnaire (chaque octet a son mapping vers un mot "compréhensible" dans le dictionnaire, et on passe du binaire au ASCII vite fait).
Bref, pas vraiment une excuse contre pourrir le réseau avec des octets inutiles (et ce n'est pas parce qu'on ferait ça qu'il ne faut pas faire le reste).
Après, certes, c'est historique…
[^] # Re: Entêtes binaires???
Posté par Moonz . Évalué à 5. Dernière modification le 25 mai 2012 à 12:36.
Sauf que ton « translateur » est dépendant du protocole, puisqu’il doit savoir quels octets traduire (juste les noms des entêtes) et lesquels ne pas toucher.
Et encore une fois, c’est inutile si tu ne vois pas le mode texte comme une fonctionnalité. Moi c’est une fonctionnalité que j’utilise tous les jours. Encore une fois, « expliquez moi votre besoin, je vous dirai comment vous en passer » ?
Et de toute façon, une fois que ta requête tient dans un paquet TCP, ça sert à rien de t’échiner à la réduire, tu auras du padding de toute façon…
[^] # Re: Entêtes binaires???
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 25 mai 2012 à 13:09.
Dictionnaire! Le translateur ne dépend pas du protocole, il a un dictionnaire qui l'alimente.
Mais attends, qu'est-ce que vi fait… Ah oui, il la aussi un dictionnaire (ASCII table, qui va transformer un octet en une série de pixels compréhensibles par toi), sauf qu'il n'est pas optimisé pour la taille (peut mieux faire pour HTML).
Toi. Mais toi, tu ne représentes pas tout le monde.
Est-ce que sur ta machine tu as tous les paquets avec toutes les options de débugging au cas où un gus voudrait debugger? Non, tu as les paquets en mode "release", pour des question de place et performance. Ben la, HTTP et compagnie, on a mis le mode debug pour tout le monde, et les gens qui debuggent ne veulent pas qu'on leur retire leur mode debug. Mais je me demande juste pourquoi tu n'as pas toute ta machine en mode debug pour la même raison.
Oui et non :
- avec les data, ça peut dépasser. Et gagner un paquet ça peut être utile
- perfs : un client peut s'en foutre (et encore avec les mobiles), mais pour un serveur entre parser 1 octet ou 3 octets pour le "GET", ça change un peu en perfs.
Bref, ça dépend du besoin. Si le besoin est debug pour tout le monde, pourquoi pas, mais si le besoin est un gain en débit et perfs, ça se défend.
et encore une fois, ça n’empêche pas d'optimiser ailleurs.
Je ne changerai pas le monde, le monde a choisi HTTP, XML etc… (et s'amuse à optimiser ensuite, genre compression, qui n'est pas lisible par ton vi), je vivrai avec (et avec les logs Apache à ralonge car en mode texte aussi, avec une adresse IPv4 qui prend 15 octets à la place de 4), les protocoles "non texte" n'ont pas le vent en poupe en ce moment (qui sait, ça reviendra peut-être). Je trouve ça juste dommage que le mode debug je bouffe de la place soit actif pour tout le monde.
[^] # Re: Entêtes binaires???
Posté par Jux (site web personnel) . Évalué à 3.
Je me demande ceci dit à quel point l'attrait de HTTP vient de son mode texte. Le mode texte fait que pour un débutant, c'est facile à comprendre, on peut simplement lui montrer la requête.
Le mode texte fait que c'est aussi facile à implémenter dans la majorité des langages de prog (à coup de regexp ou de split, c'est super rapide à faire un parser HTTP). Si on compare ça à l'implémentation d'un parser pour Protobuf, ça fait une différence. Dès qu'on passe dans du binaire, on doit commencer à se poser des questions sur le décodage des entiers/float, etc… C'est pas la mort, mais on passe de "j'implémente un client en 30 minutes" à "je dois passer 2 jours à écrire mon parser".
Ceci dit, je suis un gros gros fan de Google Protobuf. J'utilise ça dans quasi tous mes projets à la place de JSON/XML, ça me permet d'avoir des messages typés avec un minimum de vérification et de cohérence.
Mais voilà, parfois, le texte c'est juste plus simple. Il faut aussi voir ce qu'on gagne en passant à du binaire. Si c'est pour garder la masse de headers inutiles, ça va pas changer grand chose.
[^] # Re: Entêtes binaires???
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 25 mai 2012 à 13:22.
Je ne doute pas que le mode texte est pour quelque chose dans le succès de ces protocoles. Les perfs (CPU et tailles) étant jugé mineurs par les développeurs qui débutent, à raison, et après ils continuent avec et la boucle est bouclée.
Juste que du coup, à déployer ça à grande échelle, les perfs deviennent gênantes, et on se retrouve avec 36 bidouilles derrière pour "corriger le tir".
Mais bon : ça marche. (surtout grâce au ratio coût être humain / coût des perfs)
On peut aussi prendre comme autre grand exemple (je vais me faire tirer dessus peut-être!) ATM vs IP, où ATM était techniquement meilleur (réservation de ressources etc) mais compliqué, IP avait l'avantage d'être simple, et donc ATM est… mort.
[^] # Re: Entêtes binaires???
Posté par reno . Évalué à 4.
Meilleur ATM? Avec une payload de 48 octets, meilleur pour la latence OK, mais pour le reste j'ai comme un doute..
[^] # Re: Entêtes binaires???
Posté par Zenitram (site web personnel) . Évalué à 2.
A un moment, ATM était utilisé pour un unique intérêt : son débit de 622 Mbps (et on balançait du IP au dessus). Alors, non, il n'y avait pas que la latence! La taille du bloc n'est pas un critère pour la conclusion.
Mais ensuite Ethernet et parti lui casser la gueule à coup de 1 Gbps moins cher et maintenant le 100 Gpbs qui peut tenir plusieurs dizaines de km.
[^] # Re: Entêtes binaires???
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
non, la latence n'était pas meilleur. Ceux qui sont passé à du 100mbits Ethernet à l'époque vs 155 mbits ATM, l'ont vite vu. Sur ATM il faut l'établissement d'un "circuit", qui coute cher sur les routeurs.
"La première sécurité est la liberté"
[^] # Re: Entêtes binaires???
Posté par Joris Dedieu (site web personnel) . Évalué à 9.
Je crois que plus trivialement la question qui se pose est d'éviter la compression et d'être efficace dans l'implémentation. Tes en-tête binaires, tu les colles dans une structure (qui au passage existe déja dans toutes les implémentations ou presque (ici httpd.h de chez apache)) :
Oh ! surprise, on traduit en binaire des en-têtes texte pour pouvoir appliquer des masques comme par exemple dans nginx (modules/ngx_http_static_module.c) :
Pour la surabondance et le foutoir, on peut toujours prier ou militer. Apparemment c'est mal barré (http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-19). Mais je crois qu'il ne faut surtout pas se tromper de débat. La question qui est posée est texte compressé vs binaire, pas texte rationnel vs binaire. On peut concevoir que ce ne soit pas le bon débat mais c'est ainsi qu'il se pose. C'est ce que j'ai essayé d'évoquer en filigrane dans l'article. HTTP/1.1 ayant la place qu'il a aujourd'hui, il va être remplacé par un protocole beaucoup plus agressif. C'est un fait. Cela signifie entre autre que le débat binaire / texte est déja tranché. Ce sera binaire, reste à savoir si ce sera du binaire intelligent que tu colles dans ta structure après t'être posé trois questions ou le charabia actuel comprimé qu'il faudra décomprimer avant de le parser pour finir par faire finalement une structure binaire (retour en 1) que tu va exploiter, puis refaire le chemin inverse.
Et il me semble qu'au niveau de l'efficacité d'une implémentation, il n'y a pas photo entre les deux propositions.
[^] # Re: Entêtes binaires???
Posté par Moonz . Évalué à 3.
S’il traduit tous les octets, il va te traduire aussi le contenu de la page et le contenu des entêtes, ce que tu ne veux pas. Donc il doit savoir quoi traduire et quoi ne pas traduire. Donc il doit avoir une connaissance parfaite de la grammaire HTTP. Donc il dépend du protocole.
Effectivement, c’est pour ça que quand j’ai parlé de la négociation de contenu, j’ai dit « trouver un mécanisme permettant de s’en passer », pas « supprimer la négociation de contenu ». Parce que des gens l’utilisent.
Toi, tu veux supprimer tout ce que tu n’utilises pas même si d’autres l’utilisent, pas moi.
Je vois pas le rapport entre un logiciel sur ma machine qui pourrait limite être compilé en -O9 sans que ça dérange personne d’autre que moi, et un protocole normalisé supposé être identique pour tous.
Accept-Encoding: identity[^] # Re: Entêtes binaires???
Posté par Moonz . Évalué à 4.
Ça change rien du tout. Ton GET il est passé par la pile TCP/IP de ton OS (et le driver de ta carte, et le driver de ton bus sur lequel est raccordé la carte), a été copié plusieurs fois en mémoire, été écrit sur le disque dur pour les logs (donc repassé par la couche I/O de ton OS). Le nom de fichier derrière a été analysé, réécrit, passé plusieurs fois par le VFS, éventuellement passé les filtres de sécurité de l’OS. C’est toutes les copies de mémoire, les allées et venues entre le mode kernel/user, les appels système etc… qui te coûtent du temps, pas le pauvre
strncmpqui est de toute façon optimisé par le pipelining des processeurs modernes…[^] # Re: Entêtes binaires???
Posté par benoar . Évalué à 6.
Traduction, dictionnaire, fourni avec… oui, tu viens bien de réinventer la compression style gzip ou autre. Sauf qu'en plus, les algorithmes de compression « standard » sont généralistes.
Après, je vais être gentil, j'ai découvert récemment que les mecs qui font vraiment attention au moindre bit, dans le domaine des microcontrôleurs, ont adapté du HTTP version très simple et « compressée », ça s'appelle CoAP (Constrained Application Protocol) http://tools.ietf.org/html/draft-ietf-core-coap-09
[^] # Re: Entêtes binaires???
Posté par ckyl . Évalué à 5.
Tu peux expliciter ?
Il n'y pas pas de padding ni dans IP ni dans TCP (en dehors des en-tête pour qu'ils soient alignés sur 32-bits). Le seul padding qui existe est au niveau Ethernet pour éviter les trames de moins de 46 octets de data. Si tu comptes que tu as mini 20+20 octets d'en-tête TCP/IP il te faut une payload TCP de moins de 6 octets pour que ton argument s'applique… Et encore c'est en prenant 20 octets pour un en-tête TCP alors que n'importe quelle stack moderne à les timestamp TCP d'activé ce qui rajoute 10 octets à l'en-tête TCP plus 2 de padding.
[^] # Re: Entêtes binaires???
Posté par Moonz . Évalué à 1.
Au temps pour moi, j’étais persuadé que la valeur minimale pour Ethernet était bien plus grande que ça.
[^] # Re: Entêtes binaires???
Posté par tarreau willy (site web personnel) . Évalué à 5.
En fait pour être un peu plus précis, en Gigabit et 10GE, la taille minimale des trames sur le fil est de 512 octets. Mais on peut concaténer plusieurs trames de moins de 512 octets dans un slot de 512 ou plus, donc le problème ne se pose que pour les réseaux où il n'y a pas assez de trafic pour remplir ces slots, ou bien avec les protocoles en ping-pong où on doit envoyer un paquet pour avoir une réponse avant d'en envoyer un autre (ex: ping flood).
Donc dans la pratique, vu des couches du dessus, tu peux considérer que la taille minimale reste à 64 octets.
[^] # Re: Entêtes binaires???
Posté par tarreau willy (site web personnel) . Évalué à 7.
Toutes les pistes que tu évoques sont nécessaires, on ne peut pas se contenter d'un petit peu. Autant j'adore les protocoles en clair, autant je suis bien placé pour savoir combien ils sont coûteux à traîter, à cause de l'extrème tolérance qu'ils demandent, justement pour permettre à des humains de les utiliser de manière un peu légère et parfois en croyant connaître. La grande majorité des développeurs web se croient capables d'écrire des requêtes HTTP valides et pourtant quand on voit ce qu'on trouve dans des traces réseau, on a la preuve du contraire. Et les équipements qui voient passer ces requêtes sont bien obligés de faire avec. C'est ainsi qu'on se retrouve à devoir accepter un LF seul au lieu d'un CRLF à la fin des lignes (à cause de telnet), des nombres d'espaces multiples partout (à cause des utilisateurs), des espaces autour du "=" dans les cookies (à cause des développeurs qui concatènent bêtement des chaînes), etc…
Le premier problème posé par la taille du texte est le volume montant sur les liens 3G. Rien que pour émettre les 100 requêtes que comportent la plupart des sites web aujourd'hui, il faut plusieurs allers-retours parce que les requêtes sont très volumineuses. Ces allers-retours se traduisent en secondes. Des vraies secondes! C'est là où SPDY excelle, en ramenant ces requêtes à un faible nombre d'octets, capables d'être émis en une fois sans attendre d'acquittements.
C'est désagréable de travailler avec des protocoles binaires quand on est développeur, mais on n'a vraiment pas le choix. Et personnellement, je préfère des protocoles bien formatés qu'on peut décoder visuellement quand on en a l'habitude (comme on lit aujourd'hui les entêtes IP et du TCP dans un dump hexa), plutôt qu'un blob inintelligible nécessitant d'abord un coup de inflate().
[^] # Re: Entêtes binaires???
Posté par _flo_ . Évalué à 1.
Oui, je penchais plutôt en faveur du texte clair, mais à lire le débat, c'est vrai que les arguments en faveur du binaire sont bien présents.
Pour l'avoir fait longtemps sur du protocole proprio binaire, il est vrai que c'est plus lourd d'exploiter les traces/débugger ce qui ne va pas. Mais une fois qu'on a les bons outils, décodeur wireshark ou peu importe la solution, ça devient "facile".
Et là, on parle de HTTP, pas d'un protocole obscur. Donc les outils seront vite là, de toutes façons.
[^] # Re: Entêtes binaires???
Posté par ~ lilliput (site web personnel) . Évalué à 0.
linuxfr.org_session=toto !!
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
# Filtrage
Posté par moules . Évalué à -1.
Est-ce qu'il s'agit réellement d'un risque suffisamment important de nuire à la popularisation de HTTP2 pour que des efforts soient à ce point déployés pour faciliter le filtrage du protocole ?
Sachant d'une part qu'un filtrage ça se contourne toujours, d'autre part que beaucoup de libristes sont opposés au filtrage par principe (mais on peut débattre de sa légitimité suivant les cas).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Filtrage
Posté par ecyrbe . Évalué à 5.
Il n'y a pas que le filtrage. Il y a aussi le load-balancing. S'il faut faire de la décompression, on peut dire adieu aux solutions de cheap load-balancing et il faudrait déployer des infrastructures très lourdes pour les moindres sites un peu surchargés.
[^] # Re: Filtrage
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
En fait, il y a plein de cas pour lesquels des reverse proxies sont nécessaires.
C'est un moyen couramment utilisé par exemple pour transmettre une requête à un serveur applicatif (tomcat, thin …). Décider si la requête est applicative ou non nécessite alors un cycle de décompression.
Ce n'est qu'un exemple. Dans toute les archi web un peu lourde, il est courent d'avoir des chaines de traitement des requêtes complexes mettant en oeuvre divers niveaux de proxies et de caches.
[^] # Re: Filtrage
Posté par Grunt . Évalué à 10.
De toute façon on est foutus. Il y a tellement d'enjeux contraires aux idéaux qui ont fait la construction d'Internet, qu'on est foutus.
Entre :
- ceux qui veulent faire de l'intégration verticale, c'est à dire à la fois produire du contenu, le vendre, louer les tuyaux pour le transporter, concevoir le terminal qui le reçoit et fournir le logiciel qui permet de l'acheter,
- ceux qui veulent tout contrôler tout filtrer au delà du raisonnable, au lieu de faire de l'éducation et d'avoir une approche coopérative, de confiance, éducative face aux problèmes,
- la tendance à l'infantilisation des utilisateurs adultes,
- les grosses entreprises qui ont tout intérêt à contrôler ce qui se passe sur le poste client afin de lui faire manger de la publicité, et pour lesquelles c'est très rentable de lui envoyer une soupe de javascript obfusqué à exécuter telle quelle (et pas différente, dans son principe, de "prends mon .exe et autorise le les yeux fermés), et pas rentable du tout de participer à l'élaboration propre de protocoles dédiés,
l'usage majoritaire d'Internet va devenir un Web moisi, sans réelle intéropérabilité. Une régression vers un usage du type Minitel : tout le code est côté serveur, le client se connecte à un service centralisé et ne décide pas de la façon dont ses données sont traitées. Ce n'est pas "une fois de plus le poncif du Minitel 2.0", c'est la réalité.
La solution pour les geeks, les libristes, c'est de faire du vrai Internet.
De préférer les accès neutres dans la mesure du possible, de gruger avec le caca sinon (tunnels SSH sur le port 443 et compagnie), de refuser de s'emmerder avec les plateformes trop coercitives, trop fermées du type Facebook©. De continuer à faire comme les pionniers d'Internet l'ont fait (ces gens qui utilisaient Internet avant que ça soit commercialement intéressant d'en vendre des accès) : utiliser les protocoles correctement, utiliser Internet avec intelligence. Avoir deux Internet, en fait : celui verrouillé proxyfié contrôlé du PEBKAC moyen, et l'Internet des origines qui finalement fonctionne toujours, celui sur lequel on fait de l'IRC, du XMPP, du SMTP, de l'IMAP en fonction du besoin.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Filtrage
Posté par FantastIX . Évalué à 4.
Je suis assez amusé et fondamentalement d'accord avec ton analyse. «Moi j'ai un rêve…»
Celui où les braves gens ont élaboré un réseau rien qu'à eux, avec leur smartphone, avec leur boîte à deux balle, qui avec une bête carte réseau, qui avec une carte wifi… un réseau où le DNS serait distribué et la charge répartie non plus sur des serveurs mais des installation clientes. Un réseau où la volatilité des connections personnelles ne serait pas un obstacle à la persistance des données. Un réseau où l'auto-découverte serait clé et où on ne se ferait plus emmerder par l'une ou l'autre injonction d'arrêt ou de mise hors service…
Finalement un réseau totalement volatile, basé sur la bonne volonté des citoyens et le partage, plus sur des éléments figés dans l'espace donc contrôlables par ceux qui ne le méritent pas… Ce réseau pourrait s'éteindre du jour au lendemain mais, comme un phénix renaître de ses cendres encore et encore.
La seule manière d'échapper au contrôle est de rendre distribués et volatiles dans l'espace et le temps les points d'accès (les serveurs) qui sont aujourd'hui contrôlables. Tu en pièges un, hop, un autre réapparaît avec les mêmes données. Tu distribues les données sur plusieurs dizaines ou centaines d'hôtes en ajoutant suffisamment de redondance (suffit de voir le prix d'un disque pour sa taille en octets), tu augmentes les possibilités des protocoles P2P et tu généralises leur usage en y encapsulant tous les autres…
C'est un doux rêve sans doute mais j'ai comme le sentiment qu'on n'en est plus très loin.
[^] # Re: Filtrage
Posté par Moonz . Évalué à 7.
Et on l’appellerait Freenet
[^] # Re: Filtrage
Posté par Grunt . Évalué à 1.
Freenet a un gros défaut : il n'a pas la versatilité de IP. Techniquement, c'est du Web simplifié, avec des protocoles en plus (forums et mails). Mais ajouter des protocoles par dessus (messagerie "instantanée" par exemple) nécessite de réinventer la roue. On a déjà IP, l'idéal serait un système basé sur Freenet qui recré-erait une couche IP, en allant piocher dans une plage IPv6 disponible par exemple. Ainsi les logiciels et protocoles n'auraient pas être adaptés pour s'en servir.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Filtrage
Posté par Aris Adamantiadis (site web personnel) . Évalué à 4.
Tu voulais probablement parler de polyvalence.
[^] # Re: Filtrage
Posté par geb . Évalué à 2.
http://www.cypherpunk.at/onioncat/ en gros ? :)
[^] # Re: Filtrage
Posté par tarreau willy (site web personnel) . Évalué à 3.
C'est incroyable de lire encore des trucs pareils en 2012 !
Quiconque touche un peu de près ou de loin à la sécurité sait que le filtrage est nécessaire pour protéger d'abord l'utilisateur. Quand tu auras des gamins et qu'ils iront à l'école, tu seras bien content que le proxy de l'école applique du filtrage de contenu pour éviter de leur délivrer des images choquantes ou qui ne sont pas de leur âge.
Idem pour la protection des postes de travail, puisque les sites web sont bourrés de malwares, il faut bien protéger un minimum les utilisateurs qui s'en foutent complètement et qui participent passivement aux botnets qui nous détruisent le net.
Quant à la pub… Aujourd'hui c'est elle qui finance 100% de l'internet. C'est facile de la critiquer, ça fait bien, ça fait révolutionnaire ou gars engagé, mais si tu ne veux pas de pub sur le net, on retourne à l'internet des années 80. Je pense qu'à cette époque tu n'y avais pas accès, donc au final tu peux juste te dispenser de ton accès pour ne plus voire cette pub qui te dérange et qui paie ton accès internet et la plupart des sites que tu visites.
Justement pour maintenir l'Internet comme on l'aime, il faut permettre tous les usages, ce qui passe par autoriser des blaireaux à raconter leur vie sur facebook et se goinfrer de pub, car la consommation de pub de ces gens-là te permet d'avoir un accès internet pas cher sur lequel tu peux faire du SSH et les autres protocoles que tu aimes bien. Ce qu'il ne faut pas faire, c'est décider pour les gens comment ils doivent l'utiliser, car on se retrouve à leur imposer des usages qui ne sont pas les leurs et qui nécessiteront d'abandonner cet internet pour en refaire un autre.
[^] # Re: Filtrage
Posté par Anonyme . Évalué à 5.
Alors, pour les images choquantes, on va faire une liste :
C’était partit d’une bonne intention pourtant…
Désolé si tes enfants utilisent Internet comme une télé 2.0 mais les miens auront un père qui leur apprendra à développer leur libre arbitre.
C’est sûr, responsabiliser les utilisateurs ça serait vraiment dangereux !
J’avais pas l’impression que ma connexion à Internet était gratuite.
[^] # Re: Filtrage
Posté par tarreau willy (site web personnel) . Évalué à 1.
Quand ils auront regardé sur un équivalent d'ogrish une seule video d'une scène de torture ou d'un journaliste qui se fait décapiter au canif avec un zoom sur la zone de "travail", faudra pas t'étonner qu'ils fassent des cauchemars pendant plusieurs mois et qu'ils aient du mal à t'en parler. Je suis pour le libre arbitre, mais il faut déjà que l'intéressé soit préparé à se faire sa propre opinion.
Non c'est indispensable, de même que les former. Mais tu ne dois pas exiger de chacun d'être expert dans tout ce qu'il utilise. Tant que des utilisateurs chevronnés se feront piéger, il n'y aura pas de moyen de considérer que tout est de la faute de l'utilisateur. C'est comme si on te disait que c'est de ta faute si ta voiture française neuve tombe toute seul en panne sur la route parce que le système d'injection électronique n'a pas été assez bien conçu. C'est vrai, après tout, tu pourrais aussi t'y connaître en système d'injection pour savoir qu'à un régime très précis et avec quelques conditions remplies simultanément, tu risques de casser ton moteur.
Essaie d'estimer tout ce que coûte l'infrastructure qui est entre toi et tes sites favoris, compte les gens qui la maintiennent, la font évoluer, assurent des astreintes etc… Divise ça par le nombre d'abonnés de ton ISP et demande-toi si tes 30 EUR/mois suffisent à payer tout ça. Je suis tout à fait certain que non. Ca paie grosso-modo l'entretien de la ligne cuivre entre chez toi et l'opérateur ainsi que les reversements dûs à la téléphonie sur laquelle on ne t'envoie pas de pub (un provider avait essayé mais ça n'avait pas pris).
D'ailleurs si ça suffisait, on aurait bien plus de fournisseurs d'accès qu'on n'en a, parce qu'il suffirait d'avoir 10 clients pour se lancer. Là, t'es obligé d'avoir plein de gros sous au départ pour acheter le matos, et c'est du matos que tu renouvelles très très souvent à la vitesse où les débits croissent.
Enfin, regarde de quoi vivent les plus gros générateurs de trafic du net : google, yahoo, facebook, youtube, … Y'a pas photo. Mais si tu veux t'abonner à leurs services de manière payante et éviter la pub, pour certains c'est possible. C'est juste une question de choix.
[^] # Re: Filtrage
Posté par Juke (site web personnel) . Évalué à 3.
Es tu déjà « tombé » sur ce genre de video ?
[^] # Re: Filtrage
Posté par barmic . Évalué à 2.
Pas forcément ce genre de vidéos, mais va sur google.fr partie image tape comme mot clef « copine » en retirant préalablement le « safesearch » (pas certain que mon lien soit valide pour quelqu'un d'autre que moi) :
https://www.google.fr/search?tbm=isch&hl=fr&source=hp&biw=1920&bih=911&q=copine&gbv=2&oq=copine&aq=f&aqi=g10&gs_l=img.3..0l10.3025.4063.0.4302.6.6.0.0.0.0.87.486.6.6.0...0.0._nRf_OasL_s
NSFW
C'est aussi ça le filtrage. Si tu n'en a pas tu peux facilement à partir de mot clef simple tomber sur du porno par exemple (ou grâce aux pub …).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Filtrage
Posté par Juke (site web personnel) . Évalué à 4.
oui mais c'est pas un filtrage au niveau du protocole.
Ce que tu decris pourrait arriver aussi si ton fils « tombe » sur un porno sur le service de VOD de ton FAI et qu'il precise bien qu'il veut acceder à la categorie adulte et chevre consentantes ou que ta fille « tombe » sur une chtouille verte parce qu'elle a menti sur son age à l'entrée d'une boite à partouse.
[^] # Re: Filtrage
Posté par Thomas Douillard . Évalué à 3.
Es tu déja tombé sur du goatse habilemenent camouflé par un ami (ou pas ?)
[^] # Re: Filtrage
Posté par Juke (site web personnel) . Évalué à 2.
Le mardi 29 mai 2012 à 10:41 +0200, Thomas Douillard a écrit :
> Es tu déja tombé sur du goatse habilemenent camouflé par un ami (ou
> pas ?)
Oui. Mais je ne pense pas que ces amis les camoufleraient à destination
des enfants.
[^] # Re: Filtrage
Posté par Thomas Douillard . Évalué à 2.
Les gosses entre eux sont parfois pas tendre. Un grand frère un peu con, ça peut arriver.
[^] # Re: Filtrage
Posté par Juke (site web personnel) . Évalué à 2.
ça c'est sûr, par contre le filtrage protocolaire est il pertinent dans
ce cas ?
[^] # Re: Filtrage
Posté par tarreau willy (site web personnel) . Évalué à 1.
Oui bien sûr. Tu sais, tu veux montrer à un consultant que sa solution de filtrage d'URL n'est pas très efficace, tu vas exprès sur ogrish.com à travers le proxy tout neuf qu'il t'a installé et tu cliques sur la première video que tu trouves. Bah franchement, moi qui étais totalement insensible à toute la collection rotten, ça m'a travaillé un moment.
Dans la même séance, on avait pu voir une vidéo d'une scène de torture où deux militaires à visage découvert coupaient avec un sécateur rouillé la partie du corps la plus sensible d'un gars qui manifestement n'avait pas envie de leur parler.
Je vois qu'ogrish a fermé depuis (il n'y avait absolument aucune censure dessus, j'étais impressionné que ce site arrive à rester en place), mais des sites comme ça il y en a de nouveaux qui naissent régulièrement pour satisfaire la curiosité de certains ou bien pour titiller un peu la faible sensibilité de ceux qui se prennent pour des durs.
Je me rappelle aussi d'un collègue qui, testant le même produit, avait découvert tout un filon de sites neo-nazis incitant au crime et tout… On n'en revenait pas, tous les liens passaient! Et là on a réalisé que lorsque ce sont des humains qui doivent qualifier des sites, il est compréhensible qu'ils passent beaucoup plus de temps sur des sites de boules que sur des sites de haine ou de "viande", il préfèrent quitter leur travail avec mal au poignet que mal au ventre.
Et donc oui, je prétends et je maintiens qu'il est absolument nécessaire de pouvoir effectuer du filtrage pour éviter que des internautes ne tombent là-dessus malgré eux et sans avoir été prévenus (en revanche je suis pour le fait qu'ils puissent forcer à passer malgré la mise en garde, et que leur demande soit journalisée pour qu'ils ne viennent pas se plaindre ensuite).
C'est bien beau de vouloir le monde libre et idéal pour tous, mais ce n'est déjà pas celui qui se trouve dehors alors c'est complètement utopique d'imaginer qu'il sera plus joli vu à travers des fibres optiques.
[^] # Re: Filtrage
Posté par Grunt . Évalué à 2.
Avec ma ligne FDN, je paie plus de 30€/mois, mais il n'y a aucune pub, aucun contrôle par le FAI, juste le minimum légal en termes de traces. Et ça ne coûte pas 100€/mois non plus.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Filtrage
Posté par FantastIX . Évalué à 3.
Je plussoie et ajoute que cette phrase résume assez bien le débat. J'allais ajouter qu'il ne faut pas mélanger le filtrage^W^Wl'éducation qu'un parent applique avec ses enfants (les enfants sont là pour apprendre de leurs parents et les parents pour apprendre à leurs enfants) et le filtrage qu'une instance quelconque applique à des tiers (généralement adultes donc ayant logiquement reçu le bagage nécessaire et suffisant au libre arbitre) prétendument pour leur bien, surtout si les intervenants ne connaissent ni les uns ni les autres.
Le filtrage dans le second cas ne résout rien, certainement pas le problème de base: l'éducation/instruction insuffisante pour arriver au libre arbitre. Si une personne [adulte] manque de bagage pour assurer son libre arbitre, alors il faut le lui enseigner. Lui masquer l'information ne fera que l'empêcher de se faire une opinion personnelle. Par contre, ça fera d'elle un excellent mouton… Mais ça c'est une autre histoire.
[^] # Re: Filtrage
Posté par Grunt . Évalué à 6. Dernière modification le 28 mai 2012 à 10:43.
Non. Elle finance surtout une partie des frais d'hébergement des contenus publiés sur le Web.
Heu.. je paie (cher) mon FAI pour qu'il me connecte à Internet. Et d'autres gens paient leur FAI pour qu'il les connecte aussi. Ça fait que je peux parler à ces gens.
La pub, je ne la vois pas : j'ai trois tonnes de filtres, d'une part parce que je n'aime pas exécuter du code javascript à la con sans vérifier un minimum d'où il vient, d'autre part parce que je n'ai aucune envie de dire à Facebook et compagnie quels sites je visite étant donné que je n'utilise pas leurs services, et enfin parce que je ne vois aucune raison de payer une fois de plus pour un service qui existe déjà. Je développe :
Tu sembles confondre l'évolution des technologies (qui font qu'on est passés du RTC 28kbs à l'ADSL et à la fibre optique, mais également la baisse de prix des ordinateurs), avec l'invasion, en parallèle, du Web par de la publicité. Ce sont deux évolutions différentes, ou plutôt c'est la démocratisation de l'accès à Internet qui a entraîné une invasion du Web par la pub. Pour reprendre la comparaison habituelle : la démocratisation de l'automobile a entraîné le développement des panneaux de publicité au bord des grandes routes.
Du coup, je ne suis pas d'accord avec le lien que tu fais entre démocratisation d'Internet (en terme de prix) et invasion du Web.
Enfin, la plupart des choses que je lis via Internet ont été écrites par des internautes qui ne sont pas payés pour l'écrire, et paient déjà une connexion à Internet. Si les FAI préfèrent fournir des accès NATés et des machinbox qui font absolument tout (afficher l'heure, VOD, stockage vidéo, jeux..) sauf héberger leurs trucs, s'pas ma faute s'ils sont obligés de recourir à des services payés par la pub (donc, payés par le lecteur qui fait ses courses avec le cerveau infiltré).
Edit : Ceci dit, ça me tente de plus en plus d'essayer, mettons, une semaine sans Web. Juste IRC, les protocoles de P2P, NNTP, XMPP.. pour voir s'il est encore possible d'utiliser Internet sans forcément causer HTTP. Après tout, des tas de gens utilisent Internet sans causer SSH, ça devrait pas être très différent.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Filtrage
Posté par tarreau willy (site web personnel) . Évalué à 3.
Mais avec quoi crois-tu q'on arrive à faire chauffer les tuyaux de l'AMS-IX à 1.5 Tbps et ceux du DE-CIX à 2 Tbps ? (Je ne sais même pas quel est le débit cumulé qui traverse l'atlantique mais je suis sûr que ça dépasse le Tbps également). La réponse est simple : c'est du cul. Et qu'est-ce qui paie le cul ? la pub. Oh y'a bien certainement des abonnements premium, mais je pense que la majorité des gens qui fréquentent ces sites préfèrent éviter de devoir justifier des lignes apparaissant sur un relevé de compte.
Donc avec des sites monstrueux pour remplir les tuyaux, on est en mesure de financer des infrastructures avec lesquelles on peut surfer occasionnellement sur le web et faire du SSH et autre, qui représentent un débit ridicule par rapport à tout ce qui passe. C'est pour ça que je dis qu'en bout de chaîne c'est la pub qui paie pratiquement tout. On n'est pas obligés de trouver ça bien, et on peut préférer revenir au début des années 90 où les abonnements coûtaient très cher pour quelques heures en modem RTC. Mais je pense qu'on est à peu près tous bien contents de pouvoir avoir un internet qui revient bien moins cher.
Note que je ne parle pas de l'évolution des technos, l'évolution est naturelle, on a toujours des moyens croissants pour un même coût. Là je parle bien de la baisse sensible des coûts d'accès par rapport à ce que c'était il y a 15-20 ans, à l'époque où Lycos et Altavista se partageaient les recherches du web et où la pub était rare et très mal vue et où les universités ne donnaient pas un accès complet au net aux étudiants parce que ça coûtait trop cher.
Bon en fait ceux qui paient vraiment, ce sont les clients des annonceurs de pub, parce qu'il faut bien que quelqu'un paie cette pub ! Moralité, si tu ne veux pas payer indirectement ton accès internet, il ne faut pas acheter les produits des entreprises qui font de la pub sur le net :-)
[^] # Re: Filtrage
Posté par Juke (site web personnel) . Évalué à 4.
Non la majorité de leur audience sont de gros consommateurs qui sortent facilement leur carte de credit (avec les lignes discretes sur leurs relevés de compte).
C'est d'ailleurs un des seul secteur ou les gens sont prets à payer.
[^] # Re: Filtrage
Posté par Grunt . Évalué à 2.
Bizarrement, il me semblait que c'était le P2P (donc, des trucs sans pub, certes pas mal de cul) qui occupait la majorité des tuyaux d'Internet.
Ton raisonnement est peut-être juste, mais il oublie un point important : le fait que plein de Claude Michu streament du pr0n (et ne le partagent pas en P2P, les vilains) a pour conséquence que, quand le réseau est congestionné, les FAI vont avoir tendance à prioriser HTTP et brider "le reste". "Le reste" étant mon pr0n en P2P (aussi légitime et important, d'un point de vue réseau, que le pr0n en streaming HTTP) ou bien ma session SSH. Et à tout prendre, je préfère payer plus cher un accès à Internet qui marche bien pour ce que j'en fais, plutôt qu'un accès pas cher qui marche mal ou ne marche pas. Le cas de la 3G est symptomatique : il n'existe aucune offre avec @IP publique sans aucun filtrage sur le marché. À cause de l'usage que veulent la quasi totalité des abonnés : n'utiliser que HTTP (directement ou via une "appli") et n'avoir que des accès clients.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Filtrage
Posté par barmic . Évalué à 2.
Il parle du financement de cette ligne pas de son utilisation.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Filtrage
Posté par Grunt . Évalué à 2.
Ben oui, elle est majoritairement financée par des gens qui prennent un lien ADSL parce que ça tipiak plus vite. C'est aussi ça la réalité économique, il ne faut pas oublier toute la pub que les FAI ont fait sur le débit de l'ADSL, sur le fait que ça permettait de télécharger vidéos et sons rapidement, à une époque où l'offre légale était pratiquement inexistante.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Filtrage
Posté par gnuzer (site web personnel) . Évalué à 3.
C'est assez tentant, j'avais pensé à un truc similaire (mais sûrement pas aussi sérieusement que toi :-) ) : passer un mois sans utiliser de navigateur lourdingue et complexe (pas de js, pas de CSS, d'image ou de cookies inutiles, juste un truc pour assurer le minimum vital, genre w3m, lynx, dillo ou weboob). Parce que me couper totalement du web ça m'obligerait à me couper de Wikipedia, et ça, c'est pas concevable.
Quoi que, Wikipedia est sous licence libre, ça donne le droit de le distribuer comme on veut… est-ce que les articles de Wikipedia sont disponibles sur d'autres réseaux que le Web ?
[^] # Re: Filtrage
Posté par Xavier Combelle (site web personnel) . Évalué à 1.
Les articles de wikipedia sont consultables en bittorent via kiwix
# deprecated != déprécié
Posté par Boa Treize (site web personnel) . Évalué à 10.
Comme souvent, « deprecated » a été traduit par « déprécié », qui est un faux ami. Une meilleure traduction est « obsolète ». Dans le cas présent, il serait plus correct d'écrire « rendant obsolète LINK et UNLINK au passage ».
[^] # Re: deprecated != déprécié
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# How standards proliferate... :)
Posté par karteum59 . Évalué à -5.
[^] # Re: How standards proliferate... :)
Posté par barmic . Évalué à 5.
Ouai sauf que ça ne s'applique pas vraiment (comme quoi il ne suffit pas de ballancer un xkcd vaguement en rapport pour faire bien). Actuellement il existe une norme HTTP (en plusieurs version, mais on s'en fout elles ne sont pas concurrentes entre elles). Elle pose un certain nombre de problèmes et Google, puis microsoft on proposé des solutions. Ces normes sont en cours d'étude et une troisième est présenté ici.
Bref il y a 3 protocoles sous forme de draft, mais aucune norme. Rien ne dis que les 3 seront normalisé. Il y a juste une concurrence sur l'étude. Pour moi c'est un peu comme les concours de fonction de hashage cryptographique (tu en met pleins en concurrence et tu prend le meilleur), là c'est un peu différent car les protocoles peuvent s'échanger des idées entre eux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: How standards proliferate... :)
Posté par Anonyme . Évalué à 6.
On pourrait pas améliorer Gopher et passer à un vrai protocole pour le Web ?
[^] # Re: How standards proliferate... :)
Posté par barmic . Évalué à 0.
Peut être je ne sais pas quel est l'avantage de gopher. J'en ai entendu parler ces derniers temps, mais je n'ai vu que le point de vu utilisateur (ajouter OverbiteFF à firefox et aller sur tel et tel site), mais rien sur les avantages et inconvénients de ce dernier face à HTTP. Est-il aussi flexible (comme les verbes HTTP) ? Qu'en est il des performances ?
Si j'ai bien compris Gopher(+) a un couplage fort entre le protocole et le format de données. Je ne pense pas qu'il soit possible de remettre en question HTML actuellement donc il faudrait retirer toute la partie sur la présentation des données et s'en servir conjointement avec HTTP.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: How standards proliferate... :)
Posté par Grunt . Évalué à 3.
Le gros avantage de Gopher est qu'il ne fait qu'une chose (publier des trucs) et le fait bien. En cliquant sur un lien Gopher tu es certain qu'on ne cherchera pas à te faire exécuter du code obfusqué, qu'on ne te demandera pas ta version de navigateur, qu'on ne cherchera pas à ta pister.. pour ceux qui veulent juste publier quelque chose (et pas embêter l'utilisateur), Gopher est idéal.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: How standards proliferate... :)
Posté par barmic . Évalué à 2.
J'aurais plutôt dis l'inverse : gopher c'est un remplaçant de HTTP et du HTML.
Il tiens ça de deux choses : il défini à la fois le transport et la présentation et il n'a pas ou peu évoluer ces 15 dernières années (il s'est fait bouffer par la balise du HTML à ce qu'il parait, mais aussi parce qu'il n'est pas connu et peu utilisé (c'est aussi ce qui explique le peu d'évolution.
J'en doute. Celui qui veut « juste publier » cherche à toucher un publique potentiellement large et ça ça n'existe pas avec gopher. Ne pas embêter l'utilisateur il peut tout à fait le faire en HTTP/HTML.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: How standards proliferate... :)
Posté par CrEv (site web personnel) . Évalué à 4.
Fait attention lorsque tu poste, il y a barmic qui a pris tes écris au sérieux…
[^] # Re: How standards proliferate... :)
Posté par barmic . Évalué à 0.
En effet mais comme je ne connais vraiment pas le gopher je ne connais pas ses qualités (mise part d'être « underground ») et ses inconvénients (à part de ne pas être connu) :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.