27 Fév 2016

HTTP/2 is coming… to Java !

On a eu enfin la chance d’avoir David Delabassee (@delabassee) au Ch’ti JUG cette semaine. Depuis le temps qu’on en discute, nos emplois du temps se sont alignés, tels des planètes, il était temps !

Mais HTTP/2 pourquoi faire ?

Là c’est simple à comprendre, il y a de plus en plus de données partout et tout le temps et ça ne va pas s’arrêter demain. Les besoins du web ont bien évolués depuis sa création et particulièrement ces 10 dernières années. On utilise HTTP/1.1 depuis 1999 (nonante-neuf), soit un protocole de 17 ans d’age. 17 ans, dans le domaine du web c’est une éternité, c’est un peu comme si aujourd’hui vous deviez tourner une manivelle pour démarrer votre véhicule.

Un site internet se compose de différentes ressources : des fichiers HTML, du CSS, du JS, des images… qu’il faut transférer au moins une fois du serveur vers l’ordinateur en charge de l’affichage.

Par exemple le site du Figaro, c’est :

  • 140 requêtes HTTP
  • 3 Mo
  • 130 images
  • 6 JS
  • 2 CSS

Ça en fait du monde à transférer, et pour plus il y a de ressources, plus il y aura de connections à ouvrir entre le serveur et le client. Et justement, ouvrir des connexions TCP, ça coûte très cher ! C’est un problème.

Et la tendance veut que le poids des ressources à transférer augmente dans le temps. Encore un problème!

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/

Vous connaissez l’adage, le temps (de chargement), c’est de l’argent et si Amazon se chargeait en 1 seconde de plus que aujourd’hui, la perte de chiffre serait de 1,6 milliards de dollar par an. Les internautes ne sont plus patients: “Ça rame ? Je me casse !” Là autant dire que ce n’est plus un problème, c’est une catastrophe.

Avec HTTP/1.1, le chargement d’un page suit un processus des plus ennuyeux, on demande le HTML, on le récupère, on demande les ressources nécessaires (JS, CSS, images), on les récupère chacune leur tour et on les affiche. Alors que bon, depuis le début, le serveur sait exactement qu’il va avoir besoin de transférer tout ça, et il pourrait tout envoyer directement, mais non… depuis 17 ans c’est comme ça… quel temps et quelle énergie perdue ^^

Du coup, les hackers se sont empressés de contourner les problèmes de diverses façons:

  • avec de la concaténation de fichiers (appelée aussi des sprites)
  • en multipliant le nombre des sous domaines utilisés pour héberger les ressources (car les navigateurs limitent le nombre de connexions simultanées par domaine)
  • en mettant des ressources directement dans le HTML (inlining)

Cela complexifie le processus créatif et freine les évolutions du web.

HTTP/2 à la rescousse

Depuis 2015, HTTP/2 débarque dans nos navigateurs en mode activé par défaut et il est bien supporté.

http://caniuse.com/#feat=http2

Grossomodo, HTTP/2 c’est quoi ?

  1. Du streaming binaire bidirectionnel au sein d’une connexion TCP
  2. une sémantique similaire avec HTTP/1.1 (ouf)
  3. des fonctionnalités gadget (c’est bon je plaisante, mais on va faire simple hein)

C’est simple, on ouvre un lien entre un serveur et un client puis on utilise ce lien pour faire passer toutes les informations nécessaires. Plus besoin d’ouvrir tout plein de connexions TCP, tout passe dans la même. Un problème de résolu!

En plus, dans la même connexion, on aura plusieurs streams en même tant qui se mélangeront et qui pourront aller dans les 2 sens. C’est le multiplexage. Classe.

Forcément, si vous regardez ce qu’il s’échange comme données sur le réseau, vous allez voir que ça change pas mal de choses. En tant qu’internaute et même en tant que développeur, ça devrait bien se passer. Cela va améliorer l’expérience de navigation.

Il ne faut pas s’inquiéter les outils comme curl, chrome dev tools etc sont déjà compatibles.

Dans les fonctionnalités supplémentaires, on trouve un système de priorisation des streams, la possibilité de contrôler l’échange de flux, le server push qui permet d’envoyer directement toutes les ressources nécessaires au navigateur sans attendre de lire le fichier HTML, tout est envoyé d’un coup pour gagner du temps (cool) ou encore la compression des entêtes.

Autant dire que HTTP/2 est très attendu pour améliorer le web.

Et Java dans tout ça ?

Dans Java SE 9, on aura ce qu’il faut pour consommer du HTTP/2 et du HTTP/1.1 avec le même code.

Dans Java EE, on pourra tout utiliser, notamment avec les Servlet 4 qui permettront de faire le fameux server push.

THE (Stream) END

En résumé, HTTP/2 comble les manques de HTTP/1.1 tout en restant compatible avec (tant mieux tout le monde ne va pas migrer en HTTP/2 à la même fraction de seconde).

On peut s’attendre à de nombreuses implémentations chez les fournisseurs de serveurs et de librairies dans les mois à venir. En attendant, vous pouvez utiliser jetty entre autre. Cela va prendre des années avant que HTTP/2 soit partout et c’est normal.

Plus d’infos:

Une petite démo pour la route ? HTTP/2 concrétement ca donne quoi?

http://http2.golang.org/gophertiles

Les slides: http://www.slideshare.net/delabassee/http2-comes-to-java-58750957 

Thx a lot to Hubert SABLONNIÈRE for reviewing this (oui remercier en anglais c’est plus classe)

Share