Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

[MàJ] Le protocole HTTP/2 a désormais son document RFC

Direction le RFC Editor
Internet 2 min
[MàJ] Le protocole HTTP/2 a désormais son document RFC
Mise à jour :

HTTP/2 fait un pas de plus vers la standardisation avec la publication de la technologie sous forme de document RFC numéroté 7540. Il s'agit des spécifications définitives du protocole.

Le futur standard HTTP/2 est désormais finalisé. L’annonce vient d’en être faite ce matin par le président du HTTP Working Group au sein de l’IETF, Mark Nottingham. Prochaine étape désormais, la publication sous la forme d’un standard via un document RFC.

HTTP n’a pas bénéficié de révision majeure depuis 1999, quand la version 1.1 a été publiée. Au rythme où les technologies du web progressent, un successeur était très attendu et les problématiques très nombreuses. Comme on le sait, le futur HTTP/2 est bâti sur les fondations de la technologie SPDY, et en dépit de quelques critiques, le travail réalisé a fait consensus.

Depuis ce matin, on sait que le futur standard est finalisé, ce qui se traduit par une liste précise de caractéristiques. Dans sa forme actuelle, le protocole est donc largement basé sur SPDY, tout en gommant certains de ses défauts et en ajoutant d’autres capacités. HTTP/2 a pour objectif majeur d’accélérer le chargement des pages web et de sécuriser davantage les connexions, deux problématiques qui deviennent d’autant plus importantes que les ressources web sont très largement utilisées.

Du côté des performances, la caractéristique principale du protocole est le multiplexage des requêtes, autrement dit l’envoi par lots. Le serveur les reçoit donc toutes en même temps et peut procéder à l’envoi simultané des données, contrairement à la situation actuelle où de nombreux éléments doivent attendre que d’autres soient chargés. Les connexions « live » avec les serveurs pourront en outre être maintenues plus longtemps et le chiffrement sera une part importante des nouveautés.

Avec HTTP/2 viennent donc les promesses de connexions plus rapides et mieux sécurisées, mais il faudra encore attendre. Comme indiqué par Mark Nottingham de l'Internet Engineering Task Force ce matin, le protocole est maintenant en route vers le RFC Editor et ses différents documents devraient donc recevoir des numéros officiels d’attribution très prochainement.

Précisons que même si HTTP/2 n’est pas encore à proprement parler un standard, son inclusion est actuellement en travaux dans la plupart des navigateurs. C‘est le cas notamment chez Google avec Chrome 40, la firme ayant récemment annoncé que SPDY serait abandonné dans les prochaines semaines, son existence n’ayant plus lieu d’être.

53 commentaires
Avatar de jeffk_ INpactien
Avatar de jeffk_jeffk_- 18/02/15 à 10:04:53

Coté serveur ça se passe comment ?

Avatar de Etre_Libre Abonné
Avatar de Etre_LibreEtre_Libre- 18/02/15 à 10:06:37

Il faudra attendre que les serveurs web le supportent ;)

Avatar de Vekin Abonné
Avatar de VekinVekin- 18/02/15 à 10:16:09

Il y a d'ailleurs une extension sur Firefox qui permet de savoir si un site (ou des ressources externes de celui-ci) utilise SPDY ou HTTP/2.0.

Avatar de DDReaper INpactien
Avatar de DDReaperDDReaper- 18/02/15 à 10:16:23

Microsoft a officiellement annoncé son support aux Techdays (avec project spartan).

Avatar de John Shaft Abonné
Avatar de John ShaftJohn Shaft- 18/02/15 à 10:25:18

Tiens, ça sera l'occasion de rajouter des codes de réponses adaptés au chats dans un RFC du 1er avril :D

Avatar de 127.0.0.1 INpactien
Avatar de 127.0.0.1127.0.0.1- 18/02/15 à 10:38:54

C'est bien de corriger les problèmes. Dommage que ca se termine toujours par faire du "en plus" au lieu de "en mieux".

Davantage de complexité dans le protocole => Davantage de failles potentielle dans les implémentations.
Sans compter les problème d'interopérabilité au début (Chrome vs Apache, Firefox vs IIS, ...).

Enfin bon, il reste du temps avant la généralisation de HTTP/2 over IPv6. :D

Avatar de FRANCKYIV INpactien
Avatar de FRANCKYIVFRANCKYIV- 18/02/15 à 10:49:54

Très intéressante cette actu ... :chinois:

>contrairement à la situation actuelle où de nombreux
>éléments doivent attendre que d’autres soient chargés.

Ca me fait penser aux régies publicitaires qui lorsqu'elles ne sont pas accessibles font ramer toute la page web.

Heureusement, on a optimisé notre site web et nous n'avons plus le problème à présent !

Avatar de FRANCKYIV INpactien
Avatar de FRANCKYIVFRANCKYIV- 18/02/15 à 10:51:06

Vekin a écrit :

Il y a d'ailleurs une extension sur Firefox qui permet de savoir si un site (ou des ressources externes de celui-ci) utilise SPDY ou HTTP/2.0.

Marchi pour le lien :chinois:

Avatar de Gilbert_Gosseyn Abonné
Avatar de Gilbert_GosseynGilbert_Gosseyn- 18/02/15 à 10:56:59

FRANCKYIV a écrit :

Très intéressante cette actu ... :chinois:

>contrairement à la situation actuelle où de nombreux
>éléments doivent attendre que d’autres soient chargés.

Ca me fait penser aux régies publicitaires qui lorsqu'elles ne sont pas accessibles font ramer toute la page web.

Heureusement, on a optimisé notre site web et nous n'avons plus le problème à présent !

Je pensais à la même chose :chinois:. Une des raisons qui peuvent pousser à utiliser un bloquer de pubs ...

Avatar de 127.0.0.1 INpactien
Avatar de 127.0.0.1127.0.0.1- 18/02/15 à 11:11:01

FRANCKYIV a écrit :

Ca me fait penser aux régies publicitaires qui lorsqu'elles ne sont pas accessibles font ramer toute la page web.

Oui, mais non.

Si la page "rame" c'est que, d'une manière ou d'une autre, elle attend les données de la pub pour s'afficher. Et ca sera toujours le cas en HTTP/2.

Les pubs sont servies par un serveur différent, donc le client créera une connexion TCP/IP dédiee vers ce serveur et attendra la réponse (idem qu'en HTTP/1).

La différence c'est qu'en HTTP/2 le client crée une seule connexion par serveur (au lieu de une connexion par "objet" demandé). Donc si ta page rame a cause d'une limitation du nb de connexion gérée par le client, tu auras un gain. Mais tu peux déjà avoir ce gain en augmentant la limite de connexion de ton client web.

Édité par 127.0.0.1 le 18/02/2015 à 11:15
Il n'est plus possible de commenter cette actualité.
Page 1 / 6