{"id":104306,"date":"2022-06-07T09:36:47","date_gmt":"2022-06-07T07:36:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta"},"modified":"2022-06-07T09:36:47","modified_gmt":"2022-06-07T07:36:48","slug":"protokol-http-3-0-poluchil-status-predlozhennogo-standarta","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/protokol-http-3-0-poluchil-status-predlozhennogo-standarta","title":{"rendered":"Le protocole HTTP\/3.0 a obtenu le statut de norme propos\u00e9e","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Le comit\u00e9 IETF (Internet Engineering Task Force), responsable du d\u00e9veloppement des protocoles et de l'architecture d'Internet, a finalis\u00e9 la RFC pour le protocole HTTP\/3.0 et a publi\u00e9 les sp\u00e9cifications associ\u00e9es sous les identifiants RFC 9114 (protocole) et RFC 9204 (technologie de compression des en-t\u00eates QPACK pour HTTP\/3). La sp\u00e9cification HTTP\/3.0 a re\u00e7u le statut de \u00ab Standard Propos\u00e9 \u00bb, apr\u00e8s quoi les travaux commenceront pour lui conf\u00e9rer le statut de Standard de Projet (Draft Standard), signifiant en fait la stabilisation compl\u00e8te du protocole et la prise en compte de tous les commentaires formul\u00e9s. Simultan\u00e9ment, des versions mises \u00e0 jour des sp\u00e9cifications pour les protocoles HTTP\/1.1 (RFC 9112) et HTTP\/2.0 (RFC 9113) ont \u00e9t\u00e9 publi\u00e9es, ainsi que des documents d\u00e9finissant la s\u00e9mantique des requ\u00eates HTTP (RFC 9110) et des en-t\u00eates HTTP pour la gestion du cache (RFC 9111). <\/p>\n
Le protocole HTTP\/3 d\u00e9finit l'utilisation du protocole QUIC (Quick UDP Internet Connections) comme transport pour HTTP\/2. QUIC repr\u00e9sente une surcouche au protocole UDP, prenant en charge le multiplexage de plusieurs connexions et fournissant des m\u00e9thodes de chiffrement \u00e9quivalentes \u00e0 TLS\/SSL. Le protocole a \u00e9t\u00e9 cr\u00e9\u00e9 en 2013 par Google comme alternative \u00e0 la combinaison TCP+TLS pour le web, r\u00e9solvant les probl\u00e8mes de temps d'\u00e9tablissement et de n\u00e9gociation des connexions dans TCP et \u00e9liminant les retards caus\u00e9s par la perte de paquets lors de la transmission de donn\u00e9es.
<\/center> <\/p>\n
Actuellement, le support de QUIC et HTTP\/3.0 est d\u00e9j\u00e0 impl\u00e9ment\u00e9 dans tous les navigateurs web populaires (dans Chrome, Firefox et Edge, le support de HTTP\/3 est activ\u00e9 par d\u00e9faut, tandis que dans Safari, il n\u00e9cessite l'activation de l'option \u00ab Advanced > Experimental Features > HTTP\/3 \u00bb). Du c\u00f4t\u00e9 serveur, les impl\u00e9mentations de HTTP\/3 sont disponibles pour nginx (dans une branche s\u00e9par\u00e9e et sous la forme d'un module distinct), Caddy, IIS et LiteSpeed. Le r\u00e9seau de diffusion de contenu Cloudflare prend \u00e9galement en charge HTTP\/3. <\/p>\n
Fonctionnalit\u00e9s principales de QUIC : <\/p>\n
\n
Haute s\u00e9curit\u00e9, similaire \u00e0 TLS (en substance, QUIC permet d'utiliser TLS sur UDP) ; <\/li>\n
Contr\u00f4le de l'int\u00e9grit\u00e9 du flux, emp\u00eachant la perte de paquets ; <\/li>\n
Capacit\u00e9 \u00e0 \u00e9tablir instantan\u00e9ment une connexion (0-RTT, dans environ 75% des cas, les donn\u00e9es peuvent \u00eatre transmises imm\u00e9diatement apr\u00e8s l'envoi du paquet d'\u00e9tablissement de connexion) et \u00e0 garantir des d\u00e9lais minimaux entre l'envoi de la requ\u00eate et la r\u00e9ception de la r\u00e9ponse (RTT, Round Trip Time);
<\/center> <\/li>\n
L'utilisation d'un num\u00e9ro de s\u00e9quence diff\u00e9rent lors de la retransmission d'un paquet, ce qui permet d'\u00e9viter les ambigu\u00eft\u00e9s lors de l'identification des paquets re\u00e7us et d'\u00e9liminer les d\u00e9lais d'attente ; <\/li>\n
La perte d'un paquet n'affecte que la livraison du flux qui lui est associ\u00e9 et ne bloque pas la livraison des donn\u00e9es dans les flux simultan\u00e9ment transmis via la connexion actuelle ; <\/li>\n
Les m\u00e9canismes de correction d'erreurs r\u00e9duisent les d\u00e9lais dus \u00e0 la retransmission des paquets perdus. L'utilisation de codes sp\u00e9cifiques de correction d'erreurs au niveau du paquet permet de r\u00e9duire les situations n\u00e9cessitant la retransmission des donn\u00e9es d'un paquet perdu. <\/li>\n
Les limites des blocs cryptographiques sont align\u00e9es sur les limites des paquets QUIC, ce qui r\u00e9duit l'impact des pertes de paquets sur le d\u00e9codage du contenu des paquets suivants ; <\/li>\n
Absence de probl\u00e8mes de blocage de la queue TCP. <\/li>\n
Support de l'identifiant de connexion, permettant de r\u00e9duire le temps d'\u00e9tablissement d'une reconnexion pour les clients mobiles. <\/li>\n
Capacit\u00e9 \u00e0 se connecter \u00e0 des m\u00e9canismes avanc\u00e9s de contr\u00f4le de congestion. <\/li>\n
Utilisation de techniques de pr\u00e9vision de bande passante dans chaque direction pour garantir une intensit\u00e9 d'envoi optimale des paquets, emp\u00eachant un glissement vers un \u00e9tat de congestion, o\u00f9 des pertes de paquets sont observ\u00e9es. <\/li>\n
Un gain significatif de performance et de bande passante par rapport \u00e0 TCP. Pour les services vid\u00e9o tels que YouTube, l'utilisation de QUIC a montr\u00e9 une r\u00e9duction de 30 % des op\u00e9rations de rebuffering lors de la visionnage de vid\u00e9os. <\/ul>\n
Parmi les changements dans la sp\u00e9cification HTTP\/1.1, on peut noter l'interdiction de l'utilisation isol\u00e9e du symbole de retour chariot (CR) en dehors du corps de contenu, c'est-\u00e0-dire que dans les \u00e9l\u00e9ments du protocole, le symbole CR peut \u00eatre utilis\u00e9 uniquement avec le symbole de saut de ligne (CRLF). L'algorithme de composition des requ\u00eates chunked a \u00e9t\u00e9 am\u00e9lior\u00e9 pour simplifier la s\u00e9paration des champs joints et de la section des en-t\u00eates. Des recommandations pour le traitement de contenus ambigus ont \u00e9t\u00e9 ajout\u00e9es afin de bloquer les attaques de type \u00ab HTTP Request Smuggling \u00bb, permettant de s'ins\u00e9rer dans le contenu des requ\u00eates d'autres utilisateurs dans le flux entre le frontend et le backend. <\/p>\n
La mise \u00e0 jour de la sp\u00e9cification HTTP\/2.0 d\u00e9finit clairement le support de TLS 1.3. Le sch\u00e9ma de d\u00e9finition des priorit\u00e9s et les champs associ\u00e9s dans les en-t\u00eates ont \u00e9t\u00e9 rel\u00e9gu\u00e9s dans la cat\u00e9gorie obsol\u00e8te. Le m\u00e9canisme de mise \u00e0 jour des connexions de HTTP\/1.1, qui n'a pas \u00e9t\u00e9 largement adopt\u00e9, a \u00e9t\u00e9 d\u00e9clar\u00e9 obsol\u00e8te. Les exigences relatives \u00e0 la v\u00e9rification des noms de champs et des valeurs ont \u00e9t\u00e9 r\u00e9duites. Certains types de trames et param\u00e8tres auparavant r\u00e9serv\u00e9s sont propos\u00e9s pour une utilisation. Les champs d'en-t\u00eate interdits li\u00e9s \u00e0 la connexion ont \u00e9t\u00e9 d\u00e9finis plus pr\u00e9cis\u00e9ment. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Le](\"\/wp-content\/uploads\/2022\/06\/0821fd634337ac1f1cc0924abb4f55dc.jpg\")
<\/center> <\/p>\n![\"Le](\"\/wp-content\/uploads\/2022\/06\/d416668e500fd2b79304fa0b13f793e3.jpg\")
<\/center> <\/li>\n