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.

• lien n°1 : Page du groupe de travail httpbis à l’IETF
• lien n°2 : SPDY : An experimental protocol for a faster web
• lien n°3 : Proposition de Tim Berners-Lee à l’origine du web
• lien n°4 : Fil sur SPDY sur la mailing list de haproxy
• lien n°5 : L’annonce de HTTP Speed+Mobility sur le blog de msdn
• lien n°6 : Site de l’IETF

Sommaire

• Un brin d’histoire
  • GET /
  • HEAD / HTTP/1.0
  • TRACE / HTTP/1.1
  • PATCH / HTTP/1.1
  • Oui mais
• HTTPbis
  • Push toi de là
  • Va donc chez…
  • Ne pas confondre vitesse et précipitation
  • La revanche du proxy
  • Enfin
• Questions à Willy Tarreau

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  !

Lire les commentaires

Cet article est repris du site http://linuxfr.org/news/en-route-po...