Shell by Me

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 8 décembre 2011

Le renouveau du web

On le voit en ce moment, le web est en pleine ébullition avec les nouveautés de html5 et css3 (entre autres). À ce propos, je vous recommande chaudement la lecture du livre HTML5 de Rodolphe Rimelé. Bien écrit, plein d'humour, vraiment complet, les 600 pages se lisent avec rapidité et plaisir.

Parenthèse terminée. Revenons à nos moutons. Bref, dans toute cette agitation, il en est un qui ne bouge pas d'un pouce, c'est le protocole qui est au dessus de tout ça : HTTP. La dernière version, la 1.1, date tout de même de 1999. Et les usages qui sont fait aujourd'hui ne collent plus trop avec cet âge avancé. Pour ma part, voici ce que j'aimerais trouver dans la version 2.0 de HTTP.

Tout d'abord, les protocoles assez récents n'utilisent plus des ports séparés pour les flux chiffrés et non chiffrés. Cela se fait la plupart du temps via une méthode appelée STARTTLS. Globalement, le client arrive avec une connexion non chiffrée puis demande à basculer sur un échange avec TLS. Cet ajout serait bien évidemment compatible avec l'implémentation actuelle (on pourrait garder deux ports le temps que la transition se fasse). En plus d'économiser des sockets réseaux sur les serveurs, ceci aurait un autre avantage plus visible, la gestion de multiples certificats par IP.

L'un des soucis actuel du HTTPS, c'est qu'il est assez difficile d'avoir plusieurs certificats sur une seule adresse IP. Avec la venue d'IPv6 (d'ici 2040), ça ne devrait plus poser problème mais en attendant, ça coince. Il y a deux solutions pour ça. La première est d'utiliser le champ altSubjectName. Seulement, quand on héberge des clients différents sur une seule machine, ça le fait moyen d'avoir tous les noms dans un certificat unique, d'autant qu'il faut le refaire à chaque nouveau client. La seconde option est de se baser sur SNI, sauf que problème, il n'est pas supporté par tous les navigateurs (avant IE7, point de salut et sous Windows XP même avec les versions plus récentes). Pour un site marchant, c'est se passer de pas mal de clients. En utilisant STARTTLS, le client pourrait demander le bon certificat ainsi :

 GET / HTTP/2.0
 Host: google.com
 STARTTLS

Et le serveur web saurait qu'il doit fournir le certificat pour google.com.

Une autre amélioration pourrait être la généralisation des champs SRV. Ces champs permettent d'indiquer non seulement l'ip destination mais aussi son port et une priorité (pratique pour du fail-over et de la répartition). En voici un exemple :

 _http._tcp      IN  SRV 5 0 80 google.com.

Plutôt que d'utiliser le port 80 (qui resterait le port par défaut), lors de l'interrogation DNS, le client saurait sur quel port se connecter. Deux avantages selon moi. Ça pourrait tout d'abord régler le problèmes des certificats vu plus haut. Une seule IP mais de multiples ports d'écoute (et d'une manière plus propre que d'ajouter :<port> à la fin du nom d'hôte). Ensuite, les serveurs web pourraient tourner sur des ports non privilégiés (> 1024). Apache par exemple (mais c'est valable pour les autres aussi) pourrait se lancer directement avec un simple utilisateur système (et non plus root pour s'attacher à la socket puis diminuer ses privilèges). Pour de l'hébergement mutualisé, ça serait top.

Dernière idée qui me vient en tête, la compression. Si en 1999, le bénéfice à compresser n'était pas forcément évident (ce qu'on gagnait en bande passante, on le perdait en cpu), ce n'est plus le cas aujourd'hui. HTTP 2.0 devrait compresser les pages de base, point.

Voilà pour mes idées, j'en ajouterais peut-être au fur et à mesure. En attendant, à vos RFCs.

mardi 21 avril 2009

Recherche agrégateur désespérement

Pour une fois, je vais mettre à contribution mes (rares) lecteurs.

J'utilise liferea comme lecteur de flux rss. Seulement voilà, il me pose actuellement deux soucis. Le premier est qu'il est devenu incroyablement lent. J'ai purgé complètement sa base de données mais rien y fait, ça rame! Ensuite, j'aimerais avoir une base synchronisée entre mes différents ordinateurs, pour pouvoir lire les news de chez moi (sur le fixe et le portable) et depuis le boulot (bouuhh mal!) tout en conservant ce qui a été lu ou non.

Bon, là, vous allez me dire qu'il me faut un agrégateur en ligne (style Google reader). Sauf que j'aimerais garder une application lourde pour ça (cherchez pas, c'est comme ça). En gros, un liferea mais qui stockerait sa base sur le web (via un web services par exemple).

D'où ma question : est-ce que ça existe ou bien vais-je devoir faire travailler mes petites mains et mes méninges et pondre quelque chose moi même?