Jetty gets Speedy

Avec la sortie de Jetty 7.6.2, le protocole SPDY™ (NDT prononcé speedy) est maintenant supporté par le serveur éponyme. Précédemment développée pour la version 8.2, cette fonctionnalité a été reportée dans les versions 7.6.2 et 8.1.2, sera disponible dans les versions suivantes et avec le serveur d'application Hightide.

SPDY™ est une évolution de la couche de transport pour les connexions HTTP, disponible par défaut dans Google Chrome et avec un peu de configuration dans Firefox 11. Bien que non standard à ce jour, SPDY™ a été soumis à l'IETF en tant que draft pour le groupe de travail sur httpbis. Beaucoup des services de Google sont disponibles via SPDY, et d'autres sites publics (comme Webtide et Twitter) fournissent un support pour le protocole.

SPDY™ fonctionne avec TLS via une upgrade (NDT requête permettant le changement de protocole, comme le passage de HTTP à WebSocket) à l'aide de la proposition Next Protocol Negotiation pour la spécification de TLS. De ce fait, SPDY™ est un protocole implicitement sécurisé; de plus, les proxies HTTP qui autorisent actuellement le trafic sur le port 443 qui ne font pas d'inspection man-in-the-middle supporteront l'utilisation du protocole de façon transparente. Pour comprendre les bénéfices que SPDY™ apportera, InfoQ a interrogé Greg Wilkins et Simone Bordet du projet Jetty pour leur demander, d'où viennent les avantages de SPDY :

Greg Wilkins : Il y a plusieurs aspects dans SPDY qui améliorent les performances. Premièrement, l'utilisation d'une connexion multiplexée diminue la latence associée à l'ouverture de multiple connexions (parfois jusqu'à 6 par navigateur). De plus, en compressant les entêtes HTTP, on économise des centaines d'octets à chaque requête/réponse et comme beaucoup de pages nécessitent 10 à 20 requêtes pour leur rendu, cela représente une diminution significative en surcharge de données. De plus, en réduisant le nombre de connexions, on réduit les ressources nécessaires par client sur le serveur, ce qui libère de la mémoire et du CPU pour faire des choses utiles.

Notez que tout n'est pas positif. SPDY nécessite que le serveur utilise TLS et de la compression, on a besoin de CPU/mémoire pour cela. C'est cependant le genre de chose qui peut être facilement déplacé vers un intermédiaire dédié à SPDY si la consommation de CPU devient problématique.

Simone Bordet : Notez également que le multiplexage apporte d'autres avantages pour le chargement de ressources. Une page web contient typiquement 10 à 30 ressources secondaires à récupérer sur le serveur. Alors qu'un navigateur peut ouvrir seulement 6 requêtes concurrentes vers un même serveur, avec SPDY cette limite est supprimée et le navigateur est libre d'ouvrir autant de "flux" multiplexés que nécessaire, accélérant considérablement le chargement des pages, et supprimant le besoin de pipelining HTTP. En outre, les "flux" multiplexés peuvent être priorisés, en favorisant les ressources les plus importantes comme les CSS par rapport aux moins importantes comme les favicons. Ceci améliore en retour l'utilisation de la connexion TCP, donnant de meilleures performances TCP.

La possibilité de délivrer des "flux" multiplexés sans la limite des 6 connexions permet aux applications en temps-réel (celles basées sur l'approche Comet) de moins se soucier des détails d'implémentation. Tandis qu'une application web utilisant Comet doit s'assurer de ne pas épuiser les 4 à 6 connexions que le navigateur lui alloue, avec SPDY cette limite n'existe pas.

InfoQ : Avez vous un benchmark des différences de performances entre SPDY et HTTP ?

Greg Wilkins : Pas encore pour Jetty. Google a mesuré des améliorations de plus de 60% de la latence pour le chargement des pages, mais ils n'ont pas divulgué les changements dans l'utilisation de CPU/mémoire.

Pour Jetty, notre implémentation initiale doit faire avec une architecture qui n'avait pas été pensée pour du HTTP multiplexé, on s'attend donc à quelques défauts. Cependant, nous sommes déjà en train de travailler sur jetty-9, qui a été spécifiquement ré-architecturé pour des connexions de type SPDY. Nous espérons avoir rapidement des chiffres pour les performances, et qu'ils continueront de s'améliorer pendant que nous travaillons sur jetty-9.

InfoQ : Comment SPDY affecte-t-il les proxies de cache HTTP ? Des serveurs de cache SPDY sont-ils prévus à la place ?

Greg Wilkins : L'impact sera énorme! Les proxies HTTP existants ne seront pas capables de lire des flux SPDY, puisqu'ils sont chiffrés. Cependant SPDY inclue un très bon support de cache, il dispose d'un mécanisme de push ou de suggestion de contenu par anticipation des ressources dont le client aura probablement besoin. Mais n'importe quel proxy aurait besoin de comprendre SPDY et faire partie de la session SSL. De ce fait, des extensions TLS seront probablement nécessaires pour autoriser des intermédiaires actifs dans une connexion SPDY.

InfoQ : Doit-on changer du code ou de la configuration pour supporter SPDY dans une application web existante ? Y a-t-il une configuration particulière requise pour l'activation de SPDY sur le serveur, ou est-ce un réglage par défaut ?

Greg Wilkins : SPDY transporte des requêtes HTTP, donc l'application n'a pas besoin d'être changée et la sémantique des requêtes/réponses reste inchangée. Il finira peut-être par y avoir la possibilité d'accéder directement à la couche SPDY, mais pour le moment on peut le considérer comme un changement transparent pour l'application.

Simone Bordet : Non, les applications web Java existantes pourront être déployées dans Jetty comme avant, et bénéficieront de la plupart des fonctionnalités de SPDY – comme la compression des entêtes et les flux multiplexés – sans aucun changement. Seule la configuration du serveur doit être mise à jour, et les changements sont minimes : simplement remplacer le connecteur SSL par celui de SPDY ( org.eclipse.jetty.spdy.http.HTTPSPDYServerConnector).

InfoQ : Comment font les clients HTTP pour basculer (NDT requête upgrade) leurs connexion vers du SPDY ? Est-ce géré de façon transparente par le client HTTP déjà présent dans Jetty ?

Greg Wilkins : Une connexion SPDY est établie en ouvrant une connexion TLS sur le port 443 à l'aide des extensions Next Protocol (NPN). Si le serveur comprend l'extension NPN, il verra qu'une connexion SPDY est proposée et l'acceptera. Sinon la connexion se rabat sur de l'HTTPS classique.

L'extension NPN n'est pas encore un standard, et elle n'est pas supportée par les JVM. Simone a fait un travail très malin pour étendre les classes du JDK et supporter NPN. On espère que ça soit à terme supporté par toutes les JVM.

Simone Bordet : Nous n'avons pas encore intégré SPDY dans l'HttpClient de Jetty, mais nous offrons un client pur SPDY qui permet d'effectuer des appels SPDY vers des serveurs supportant SPDY (et de fait l'intégration d'HTTP est à faire manuellement, pour l'instant).

Une autre chose intéressante chez SPDY est qu'il peut pousser des ressources au client avant qu'il ne les demande. Donc, par exemple, lorsqu'on télécharge une page HTML statique, le serveur peut savoir que la page contient une feuille de style CSS, un script JS, et des images. Le serveur pourrait télécharger les premières lignes de la page, ensuite pousser le CSS, continuer à télécharger plus de lignes, pousser le script, télécharger d'autres lignes, pousser les images, et ainsi de suite. Cela permettra d'économiser beaucoup d'allers-retours et se traduira par des économies importantes dans le rendu des pages.

Une discussion est en cours pour savoir comment le serveur pourrait connaître ces ressources supplémentaires à pousser. Les solutions vont de fichiers de métadonnées (e.g. un fichier index.html.spdy qui contiendrait les ressources à pousser pour index.html), au profiling des requêtes par le serveur, remplissant un cache-par-ressource avec les ressources secondaires qui sont toujours demandées après la principale, etc. L'implémentation de ces fonctionnalités est à la discrétion du serveur, mais l'idée est que SPDY offre des possibilités d'optimisations côté serveur qui sont impossibles avec le protocole HTTP ordinaire.

Une dernière remarque pour les navigateurs, SPDY s'intègre complètement à tous les aspects HTTP du navigateur, non seulement lorsqu'on demande une page à partir de la barre d'adresse, mais aussi via XMLHttpRequest.

InfoQ : Les clients et serveurs peuvent-ils utiliser SPDY pour des requêtes supplémentaires, à la place d'HTTP, pour pousser des informations par exemple ?

Greg Wilkins : Oui. En fait pas via un navigateur pour le moment, mais sur un serveur il est possible d'accéder à SPDY directement. Reste à voir si les navigateurs exposeront directement les sémantiques SPDY ou s'ils continueront de le masquer derrière les couches applicatives comme pour HTTP et WebSocket.

InfoQ : Pour être omniprésent, SPDY aura besoin d'être standardisé par l'IETF, au lieu d'être un projet de Google. Existe-t-il une RFC qui explique le protocole dans son état actuel ? Si non, savez-vous quand cela devrait arriver ? N'est-ce pas un problème que Google possède la marque SPDY ?

Greg Wilkins : Premièrement, laissez-moi applaudir Google pour la manière dont ils ont géré ce projet. A bien des égards ce pourrait être considéré comme un abus de position dominante, vu qu'ils utilisent leur navigateur très populaire et leurs services sur le web pour pousser un nouveau protocole propriétaire sur le web, qu'on le veuille ou non. D'un autre côté, Google s'est montré très ouvert sur leurs intentions et à propos du développement du protocole. Le protocole est un projet en dev chez Google depuis plus de 2 ans, leurs développeurs se sont bien impliqués avec la communauté et ont tenu compte du feedback et des contributions pour la conception et l'implémentation.

Google a clairement affiché son intention de confier le protocole à l'IETF pour sa standardisation, et ils ont soumis un draft qui s'adresse au groupe de travail sur httpbis. Je ne suis pas au fait du timing exact de la standardisation, je pense cependant que l'approche retenue jusqu'ici correspond bien aux préférences de l'IETF plutôt favorable à un consensus et à du code qui fonctionne.

On peut en effet se poser la question d'un éventuel abus de position dominante mais je ne pense pas qu'il y ait matière à s'inquiéter si tant est que l'IETF le récupère dans un délai raisonnable. Ce qui est important, c'est qu'aucune "fonctionnalité" que Google offre ne soit liée à SPDY. Si vous ne l'aimez pas, vous êtes libre de le bloquer et vous aurez le même service en HTTP avec un peu plus de latence.

InfoQ : Pour finir, Jetty prend également en charge les WebSockets comme un mécanisme de communication générique, qui utilise HTTP pour le transport de ses trames. Peux-tu expliquer en quoi SPDY diffère de WebSocket, et si les deux pourront un jour se rencontrer ?

Greg Wilkins : WebSocket, comme HTTP peut être considéré en deux parties : la sémantique des échanges de communications et le tuyau qui transporte cette sémantique. WebSocket introduit des datagrammes bidirectionnels dans le navigateur et fournit un protocole pour les transporter du/vers le serveur. Tout comme SPDY a remplacé le tuyau pour HTTP, il peut être utilisé pour remplacer le tuyau de WebSocket. Il y a déjà une proposition et une implémentation en beta de WebSocket sur du SPDY.

SPDY™ est une marque déposée de Google, Inc.