{"id":52181,"date":"2019-11-02T00:00:00","date_gmt":"2019-11-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/http-3-razrushenie-osnov-i-divnyj-novyj-mir"},"modified":"2020-02-18T13:59:51","modified_gmt":"2020-02-18T10:59:51","slug":"http-3-razrushenie-osnov-i-divnyj-novyj-mir","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3 : destruction des fondements et un monde nouveau merveilleux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Cela fait plus de 20 ans que nous consultons des pages Web via le protocole HTTP. La plupart des utilisateurs ne se rendent m\u00eame pas compte de ce que c'est et comment cela fonctionne. D'autres savent qu'il y a quelque part sous HTTP du TLS, puis TCP, puis IP, et ainsi de suite. Et enfin, certains h\u00e9r\u00e9tiques estiment que TCP est d\u00e9pass\u00e9 et d\u00e9sirent quelque chose de plus rapide, plus fiable et plus s\u00e9curis\u00e9. Cependant, dans leurs tentatives d'inventer un nouveau protocole id\u00e9al, ils reviennent \u00e0 des technologies des ann\u00e9es 80 pour essayer de construire leur nouveau monde merveilleux.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3 : destruction des fondements et un monde nouveau merveilleux\" src=\"\/wp-content\/uploads\/2019\/11\/869bd86cc0b47c6c42f315cf20640018.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Un peu d'histoire : HTTP\/1.1<\/h2>\n<p>\nEn 1997, le protocole d'\u00e9change d'informations textuelles HTTP version 1.1 a obtenu son RFC. \u00c0 l'\u00e9poque, le protocole \u00e9tait d\u00e9j\u00e0 utilis\u00e9 par les navigateurs depuis plusieurs ann\u00e9es, et la nouvelle norme a dur\u00e9 encore quinze ans. Ce protocole fonctionnait uniquement sur le principe de la demande-r\u00e9ponse et \u00e9tait principalement destin\u00e9 \u00e0 la transmission d'informations textuelles.<\/p>\n<p>HTTP a \u00e9t\u00e9 con\u00e7u pour fonctionner au-dessus du protocole TCP, garantissant la livraison fiable des paquets au destinataire. Le fonctionnement de TCP repose sur l'\u00e9tablissement et le maintien d'une connexion fiable entre les points finaux et le d\u00e9coupage du trafic en segments. Les segments ont un num\u00e9ro de s\u00e9quence et un code de contr\u00f4le. Si un des segments ne parvient pas ou arrive avec un code de contr\u00f4le incorrect, la transmission s'arr\u00eate jusqu'\u00e0 ce que le segment perdu soit restitu\u00e9.<\/p>\n<p>Dans HTTP\/1.0, la connexion TCP se fermait apr\u00e8s chaque demande. C'\u00e9tait extr\u00eamement gaspilleur, car l'\u00e9tablissement d'une connexion TCP (3-Way-Handshake) n'est pas un processus rapide. Dans HTTP\/1.1, un m\u00e9canisme keep-alive a \u00e9t\u00e9 introduit, permettant de r\u00e9utiliser une seule connexion pour plusieurs demandes. Toutefois, comme cela peut facilement devenir un goulot d'\u00e9tranglement, diff\u00e9rentes impl\u00e9mentations de HTTP\/1.1 autorisent l'ouverture de plusieurs connexions TCP vers un m\u00eame h\u00f4te. Par exemple, dans Chrome et dans les versions r\u00e9centes de Firefox, jusqu'\u00e0 six connexions sont autoris\u00e9es.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3 : destruction des fondements et un monde nouveau merveilleux\" src=\"\/wp-content\/uploads\/2019\/11\/b1c131da8e62ace741f3064f2fb96c60.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLe chiffrement devait \u00e9galement \u00eatre confi\u00e9 \u00e0 d'autres protocoles, et pour cela, le protocole TLS a \u00e9t\u00e9 utilis\u00e9 au-dessus de TCP, prot\u00e9geant les donn\u00e9es de mani\u00e8re assez fiable, mais augmentant encore davantage le temps n\u00e9cessaire \u00e0 l'\u00e9tablissement de la connexion. Au final, le processus de poign\u00e9e de main ressemblait \u00e0 ceci :<br \/>\n <img decoding=\"async\" alt=\"HTTP\/3 : destruction des fondements et un monde nouveau merveilleux\" src=\"\/wp-content\/uploads\/2019\/11\/2fdccf56e0ed29444557836fdc65351b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustration Cloudflare<\/i><\/p>\n<p>Ainsi, HTTP\/1.1 avait un certain nombre de probl\u00e8mes :<\/p>\n<ul>\n<li>Installation de connexion lente.<\/li>\n<li>Les donn\u00e9es sont transmises sous forme de texte, ce qui signifie que la transmission d'images, de vid\u00e9os et d'autres informations non textuelles est inefficace.<\/li>\n<li>Une connexion TCP est utilis\u00e9e pour une seule requ\u00eate, ce qui signifie que les autres requ\u00eates doivent soit trouver une autre connexion, soit attendre que la requ\u00eate en cours se lib\u00e8re.<\/li>\n<li>Seul le mod\u00e8le pull est pris en charge. La norme ne parle pas du server-push.<\/li>\n<li>Les en-t\u00eates sont transmis en texte.<\/li>\n<\/ul>\n<p>\nSi le server-push est plus ou moins r\u00e9alis\u00e9 par le protocole WebSocket, d'autres probl\u00e8mes doivent \u00eatre abord\u00e9s de mani\u00e8re plus radicale.<\/p>\n<h2>Un peu de modernit\u00e9 : HTTP\/2<\/h2>\n<p>\nEn 2012, Google a commenc\u00e9 \u00e0 travailler sur le protocole SPDY (prononc\u00e9 \u00ab speedy \u00bb). Ce protocole visait \u00e0 r\u00e9soudre les principaux probl\u00e8mes de HTTP\/1.1 tout en maintenant la r\u00e9trocompatibilit\u00e9. En 2015, le groupe de travail IETF a pr\u00e9sent\u00e9 la sp\u00e9cification HTTP\/2, bas\u00e9e sur le protocole SPDY. Voici les diff\u00e9rences dans HTTP\/2 :<\/p>\n<ul>\n<li>S\u00e9rialisation binaire.<\/li>\n<li>Multiplexage de plusieurs requ\u00eates HTTP dans une seule connexion TCP.<\/li>\n<li>Server-push int\u00e9gr\u00e9 (sans WebSocket).<\/li>\n<\/ul>\n<p>\nLe protocole a constitu\u00e9 un grand pas en avant. Il am\u00e9liore consid\u00e9rablement <noindex><a rel=\"nofollow\" href=\"https:\/\/http2.akamai.com\/demo\">la vitesse par rapport \u00e0 la premi\u00e8re version<\/a><\/noindex> et ne n\u00e9cessite pas de cr\u00e9er plusieurs connexions TCP : toutes les requ\u00eates vers un m\u00eame h\u00f4te sont multiplex\u00e9es en une seule. Cela signifie qu'il y a plusieurs flux dits, chacun ayant son propre ID. En prime, on a le server-push int\u00e9gr\u00e9.<\/p>\n<p>Cependant, le multiplexage entra\u00eene un autre probl\u00e8me fondamental. Imaginez que nous effectuons de mani\u00e8re asynchrone 5 requ\u00eates vers un m\u00eame serveur. Avec HTTP\/2, toutes ces requ\u00eates seront ex\u00e9cut\u00e9es dans le cadre d'une connexion TCP unique, donc si un segment de l'une des requ\u00eates est perdu ou mal re\u00e7u, la transmission de toutes les requ\u00eates et r\u00e9ponses sera arr\u00eat\u00e9e jusqu'\u00e0 ce que le segment perdu soit r\u00e9cup\u00e9r\u00e9. \u00c9videmment, plus la qualit\u00e9 de la connexion est mauvaise, plus HTTP\/2 fonctionne lentement. <noindex><a rel=\"nofollow\" href=\"https:\/\/http3-explained.haxx.se\/en\/why-tcphol.html\">Selon Daniel Steinberg<\/a><\/noindex>, dans des conditions o\u00f9 les paquets perdus repr\u00e9sentent 2 % du total, HTTP\/1.1 se comporte mieux dans le navigateur que HTTP\/2 car il ouvre 6 connexions au lieu d'une.<\/p>\n<p>Ce probl\u00e8me est appel\u00e9 \u00ab head-of-line blocking \u00bb et, malheureusement, il semble impossible de le r\u00e9soudre en utilisant TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3 : destruction des fondements et un monde nouveau merveilleux\" src=\"\/wp-content\/uploads\/2019\/11\/234a6dc218a9acf8d2212fbdf28f2188.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustration Daniel Steinberg<\/i><\/p>\n<p>En fin de compte, les d\u00e9veloppeurs de la norme HTTP\/2 ont r\u00e9alis\u00e9 un travail \u00e9norme et ont fait pratiquement tout ce qui pouvait \u00eatre fait au niveau applicatif du mod\u00e8le OSI. Il est temps de descendre au niveau de transport et d'inventer un nouveau protocole de transport.<\/p>\n<h2>Nous avons besoin d'un nouveau protocole : UDP vs TCP<\/h2>\n<p>\nIl est rapidement devenu clair que l'impl\u00e9mentation d'un tout nouveau protocole de transport est une t\u00e2che irr\u00e9alisable dans les conditions actuelles. En effet, ce sont les \u00e9quipements mat\u00e9riels ou les middle-boxes (routeurs, pare-feu, serveurs NAT\u2026) qui connaissent le niveau de transport, et les former \u00e0 quelque chose de nouveau est une t\u00e2che extr\u00eamement difficile. De plus, le support des protocoles de transport est int\u00e9gr\u00e9 dans le noyau des syst\u00e8mes d'exploitation, et ces noyaux ne changent pas facilement non plus.<\/p>\n<p>On pourrait alors baisser les bras et dire \u00ab Bien s\u00fbr, nous allons inventer un nouveau HTTP\/3 avec des atouts et des courtisanes, mais son adoption prendra 10-15 ans (environ le temps qu'il faudra pour que la plupart des \u00e9quipements soient remplac\u00e9s) \u00bb, mais il existe une autre option, pas si \u00e9vidente : utiliser le protocole UDP. Oui, ce m\u00eame protocole avec lequel nous \u00e9changeons des fichiers sur le r\u00e9seau local \u00e0 la fin des ann\u00e9es 90 et au d\u00e9but des ann\u00e9es 2000. Pratiquement tous les \u00e9quipements d'aujourd'hui savent comment travailler avec cela.<\/p>\n<p>Quels sont les avantages d'UDP par rapport \u00e0 TCP ? Tout d'abord, il n'y a pas de session de niveau de transport, connue des \u00e9quipements. Cela nous permet de d\u00e9finir nous-m\u00eames la session aux points finaux et de g\u00e9rer les conflits qui pourraient survenir. Cela signifie que nous ne sommes pas limit\u00e9s \u00e0 une ou plusieurs sessions (comme dans TCP), mais pouvons en cr\u00e9er autant que nous le souhaitons. Deuxi\u00e8mement, la transmission des donn\u00e9es via UDP est plus rapide que via TCP. Ainsi, en th\u00e9orie, nous pourrions percer le plafond de vitesse actuel atteint avec HTTP\/2. <\/p>\n<p>Cependant, UDP ne garantit pas la fiabilit\u00e9 de la transmission des donn\u00e9es. En fait, nous envoyons simplement des paquets, esp\u00e9rant qu'ils seront re\u00e7us \u00e0 l'autre bout. Pas re\u00e7u ? Eh bien, tant pis\u2026 Cela \u00e9tait suffisant pour transmettre des vid\u00e9os pour adultes, mais pour des choses plus s\u00e9rieuses, la fiabilit\u00e9 est n\u00e9cessaire, ce qui signifie qu'il faudra ajouter quelque chose au-dessus de l'UDP.<\/p>\n<p>Tout comme dans le cas de HTTP\/2, le travail sur la cr\u00e9ation d'un nouveau protocole a commenc\u00e9 chez Google en 2012, c'est-\u00e0-dire \u00e0 peu pr\u00e8s au m\u00eame moment que le d\u00e9but du travail sur SPDY. En 2013, Jim Roskind a pr\u00e9sent\u00e9 au grand public <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/document\/d\/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34\/edit\">le protocole QUIC (Quick UDP Internet Connections)<\/a><\/noindex>, en 2015, un Internet Draft a \u00e9t\u00e9 soumis pour standardisation \u00e0 l'IETF. \u00c0 ce moment-l\u00e0, le protocole d\u00e9velopp\u00e9 par Roskind chez Google \u00e9tait d\u00e9j\u00e0 tr\u00e8s diff\u00e9rent de la version propos\u00e9e pour le standard, c'est pourquoi la version de Google a \u00e9t\u00e9 surnomm\u00e9e gQUIC.<\/p>\n<h4>Qu'est-ce que QUIC<\/h4>\n<p>\nTout d'abord, comme d\u00e9j\u00e0 mentionn\u00e9, c'est un wrapper au-dessus de l'UDP. Au-dessus de l'UDP, une connexion QUIC est \u00e9tablie, o\u00f9 plusieurs flux peuvent exister, comme avec HTTP\/2. Ces flux existent uniquement aux points finaux et sont g\u00e9r\u00e9s de mani\u00e8re ind\u00e9pendante. Si un paquet est perdu dans un flux, les autres ne sont pas affect\u00e9s.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3 : destruction des fondements et un monde nouveau merveilleux\" src=\"\/wp-content\/uploads\/2019\/11\/0a64aa26d9b8216db56d389fa48578a5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Illustration Daniel Steinberg<\/i><\/p>\n<p>Deuxi\u00e8mement, le chiffrement est d\u00e9sormais int\u00e9gr\u00e9 dans le protocole plut\u00f4t que sous forme d'un niveau s\u00e9par\u00e9. Cela permet d'\u00e9tablir une connexion et d'\u00e9changer des cl\u00e9s publiques en un seul \u00e9change, et d'utiliser un astucieux m\u00e9canisme de handshake 0-RTT pour \u00e9viter les d\u00e9lais lors de l'\u00e9tablissement de la connexion. De plus, il est maintenant possible de chiffrer des paquets de donn\u00e9es individuels. Cela permet de d\u00e9chiffrer les paquets re\u00e7us ind\u00e9pendamment, sans attendre la fin de la r\u00e9ception des donn\u00e9es du flux. Ce mode de fonctionnement \u00e9tait impossible avec TCP, car TLS et TCP fonctionnaient ind\u00e9pendamment l'un de l'autre, et TLS ne pouvait pas savoir comment les donn\u00e9es seraient fragment\u00e9es par TCP. Par cons\u00e9quent, il ne pouvait pas pr\u00e9parer ses segments pour qu'ils s'adaptent segment par segment avec ceux de TCP et puissent \u00eatre d\u00e9chiffr\u00e9s de mani\u00e8re ind\u00e9pendante. Toutes ces am\u00e9liorations permettent \u00e0 QUIC de r\u00e9duire la latence par rapport \u00e0 TCP.<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3 : destruction des fondements et un monde nouveau merveilleux\" src=\"\/wp-content\/uploads\/2019\/11\/cb3c522636f7a052a0f5988fe7ea3a65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nTroisi\u00e8mement, le concept de flux l\u00e9gers permet de dissocier la connexion de l'adresse IP du client. Cela est important, par exemple, lorsque le client passe d'un point d'acc\u00e8s Wi-Fi \u00e0 un autre, changeant ainsi son IP. Dans ce cas, avec TCP, un long processus se d\u00e9roule, au cours duquel les connexions TCP existantes expirent et de nouvelles connexions sont \u00e9tablies avec la nouvelle IP. Avec QUIC, le client continue simplement \u00e0 envoyer des paquets au serveur \u00e0 partir de la nouvelle IP avec l'ancien ID de flux. \u00c9tant donn\u00e9 que l'ID de flux est d\u00e9sormais unique et non r\u00e9utilis\u00e9, le serveur comprend que le client a chang\u00e9 d'IP, renvoie les paquets perdus et poursuit la communication \u00e0 la nouvelle adresse.<\/p>\n<p>Quatri\u00e8mement, QUIC est impl\u00e9ment\u00e9 au niveau de l'application et non au niveau du syst\u00e8me d'exploitation. D'une part, cela permet de modifier le protocole plus rapidement, car pour obtenir une mise \u00e0 jour, il suffit de mettre \u00e0 jour la biblioth\u00e8que, au lieu d'attendre une nouvelle version de l'OS. D'autre part, cela entra\u00eene une forte augmentation de la consommation du processeur.<\/p>\n<p>Enfin, parlons des en-t\u00eates. La compression des en-t\u00eates est justement l'un des aspects qui diff\u00e8rent entre QUIC et gQUIC. Je ne vois pas l'int\u00e9r\u00eat d'y consacrer beaucoup de temps, je dirai simplement que dans la version soumise \u00e0 la normalisation, la compression des en-t\u00eates a \u00e9t\u00e9 rendue aussi similaire que possible \u00e0 celle du HTTP\/2. Vous pouvez en lire plus. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">ici<\/a><\/noindex>.<\/p>\n<h4>\u00c0 quel point est-ce plus rapide ?<\/h4>\n<p>\nC'est une question complexe. Le fait est qu'en l'absence de norme, il n'y a pas grand-chose \u00e0 mesurer. Peut-\u00eatre que les seules donn\u00e9es statistiques dont nous disposons sont celles de Google, qui utilise gQUIC depuis 2013 et en 2016 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ietf.org\/proceedings\/96\/slides\/slides-96-quic-3.pdf\">a rendu compte devant l'IETF<\/a><\/noindex>, que pr\u00e8s de 90 % du trafic vers leurs serveurs en provenance du navigateur Chrome utilise d\u00e9sormais QUIC. Dans cette m\u00eame pr\u00e9sentation, ils annoncent que via gQUIC, les pages se chargent environ 5 % plus rapidement, et qu'il y a 30 % de moins de \u00ab freezes \u00bb pour la vid\u00e9o en streaming par rapport \u00e0 TCP. <\/p>\n<p>En 2017, un groupe de chercheurs dirig\u00e9 par Arash Molavi Kakhki a publi\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">un grand travail<\/a><\/noindex> une \u00e9tude sur la performance de gQUIC par rapport \u00e0 TCP. <br \/>\nL'\u00e9tude a mis en \u00e9vidence plusieurs faiblesses de gQUIC, telles que sa sensibilit\u00e9 au m\u00e9lange des paquets r\u00e9seau, son avidit\u00e9 (unfairness) en mati\u00e8re de bande passante, et la transmission plus lente des petits objets (jusqu'\u00e0 10 Ko). Cette derni\u00e8re, en revanche, peut \u00eatre compens\u00e9e par l'utilisation du 0-RTT. Dans tous les autres cas \u00e9tudi\u00e9s, gQUIC a montr\u00e9 une augmentation de la vitesse par rapport \u00e0 TCP. Il est difficile de parler de chiffres ici. Mieux vaut lire <noindex><a rel=\"nofollow\" href=\"https:\/\/conferences.sigcomm.org\/imc\/2017\/papers\/imc17-final39.pdf\">l'\u00e9tude elle-m\u00eame<\/a><\/noindex> ou <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.apnic.net\/2018\/01\/29\/measuring-quic-vs-tcp-mobile-desktop\/\">une courte publication<\/a><\/noindex>.<\/p>\n<p>Il convient de noter que ces donn\u00e9es concernent pr\u00e9cis\u00e9ment gQUIC, et elles ne sont pas pertinentes pour la norme en cours d'\u00e9laboration. Ce que sera QUIC : c'est encore un myst\u00e8re, mais on esp\u00e8re que les faiblesses identifi\u00e9es dans gQUIC seront prises en compte et corrig\u00e9es.<\/p>\n<h2>Un peu d'avenir : qu'en est-il de HTTP\/3 ?<\/h2>\n<p>\nIci, tout est clair : l'API ne changera pas. Tout restera exactement comme c'\u00e9tait dans HTTP\/2. Et si l'API reste la m\u00eame, le passage \u00e0 HTTP\/3 devra \u00eatre r\u00e9solu en utilisant une version r\u00e9cente de la biblioth\u00e8que c\u00f4t\u00e9 serveur, prenant en charge le transport via QUIC. Cependant, il faudra encore un bon moment pour maintenir une r\u00e9trocompatibilit\u00e9 avec les anciennes versions d'HTTP, car Internet n'est pas encore pr\u00eat pour une transition compl\u00e8te vers UDP.<\/p>\n<h4>Qui supporte d\u00e9j\u00e0<\/h4>\n<p>\nVoici <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/quicwg\/base-drafts\/wiki\/Implementations\">des<\/a><\/noindex> les impl\u00e9mentations existantes de QUIC. Malgr\u00e9 le manque de norme, la liste est plut\u00f4t bonne. <\/p>\n<p>Aucun navigateur ne prend actuellement en charge QUIC en version stable. R\u00e9cemment, des informations ont \u00e9t\u00e9 publi\u00e9es sur le fait que Chrome a activ\u00e9 la prise en charge de HTTP\/3, mais seulement dans la version Canary. <\/p>\n<p>Parmi les serveurs, seul <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/caddyserver\/caddy\">Caddy<\/a><\/noindex> et <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/http3-the-past-present-and-future\/\">Cloudflare<\/a><\/noindex>le support de HTTP\/3 est disponible, mais seulement de mani\u00e8re exp\u00e9rimentale. NGINX a commenc\u00e9 \u00e0 travailler sur la prise en charge de HTTP\/3 \u00e0 la fin du printemps 2019. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.nginx.com\/blog\/nginx-1-16-1-17-released\/\">ont annonc\u00e9<\/a><\/noindex>, but has not yet finished.<\/p>\n<h4>Quels sont les probl\u00e8mes<\/h4>\n<p>\nNous vivons dans un monde r\u00e9el o\u00f9 aucune grande technologie ne peut se r\u00e9pandre sans rencontrer de r\u00e9sistances, et QUIC n'est pas une exception.<\/p>\n<p>Le plus important est qu'il faut expliquer au navigateur que \"https:\/\/\" ne m\u00e8ne peut-\u00eatre pas au port TCP 443. Il se peut qu'il n'y ait m\u00eame pas de TCP. Pour cela, on utilise l'en-t\u00eate Alt-Svc. Il permet de signaler au navigateur que ce site web est \u00e9galement accessible sur un autre protocole \u00e0 une certaine adresse. En th\u00e9orie, \u00e7a devrait fonctionner parfaitement, mais en pratique, nous serons confront\u00e9s au fait que UDP peut \u00eatre interdit par le pare-feu pour \u00e9viter les attaques DDoS.<\/p>\n<p>Mais m\u00eame si UDP n'est pas bloqu\u00e9, le client peut se trouver derri\u00e8re un routeur NAT configur\u00e9 pour maintenir la session TCP par adresse IP, et comme nous utilisons UDP, qui n'a pas de session de mat\u00e9riel, le NAT ne maintiendra pas la connexion, et la session QUIC <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.cloudflare.com\/the-road-to-quic\/\">sera constamment interrompue.<\/a><\/noindex>. <\/p>\n<p>Tous ces probl\u00e8mes sont li\u00e9s au fait que UDP n'a pas \u00e9t\u00e9 utilis\u00e9 auparavant pour le transfert de contenu Internet, et les fabricants de mat\u00e9riel n'avaient pas pr\u00e9vu que cela arriverait un jour. De m\u00eame, les administrateurs ne comprennent pas tr\u00e8s bien comment configurer correctement leurs r\u00e9seaux pour le fonctionnement de QUIC. Cette situation commencera lentement \u00e0 changer, et de toute fa\u00e7on, ces changements prendront moins de temps que l'impl\u00e9mentation d'un nouveau protocole de transport. <\/p>\n<p>De plus, comme indiqu\u00e9 pr\u00e9c\u00e9demment, QUIC augmente consid\u00e9rablement l'utilisation du processeur. Daniel Stenberg <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=idViw4anA6E\">a \u00e9valu\u00e9<\/a><\/noindex> une augmentation du processeur allant jusqu'\u00e0 trois fois.<\/p>\n<h4>Quand HTTP\/3 arrivera<\/h4>\n<p>\nStandard <noindex><a rel=\"nofollow\" href=\"https:\/\/datatracker.ietf.org\/wg\/quic\/about\/\">veulent l'adopter.<\/a><\/noindex> \u00c0 la mi-mai 2020, et compte tenu du fait que les documents pr\u00e9vus pour juillet 2019 ne sont toujours pas finalis\u00e9s, on peut dire que la date sera probablement repouss\u00e9e.<\/p>\n<p>En effet, Google utilise sa propre impl\u00e9mentation de gQUIC depuis 2013. Si l'on examine la requ\u00eate HTTP envoy\u00e9e au moteur de recherche Google, on peut y voir ceci :<br \/>\n<img decoding=\"async\" alt=\"HTTP\/3 : destruction des fondements et un monde nouveau merveilleux\" src=\"\/wp-content\/uploads\/2019\/11\/af422268eb85b488c7be1b70c6d33fad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusions<\/h2>\n<p>\nQUIC semble actuellement \u00eatre une technologie encore en d\u00e9veloppement, mais avec un potentiel tr\u00e8s prometteur. \u00c9tant donn\u00e9 que, ces 20 derni\u00e8res ann\u00e9es, toutes les optimisations des protocoles de transport se sont principalement concentr\u00e9es sur TCP, QUIC, qui surpasse souvent en performance, appara\u00eet d\u00e9j\u00e0 tr\u00e8s favorable. <\/p>\n<p>Cependant, il existe encore des probl\u00e8mes non r\u00e9solus qu'il faudra aborder dans les ann\u00e9es \u00e0 venir. Le processus pourrait prendre du temps \u00e0 cause de l'\u00e9quipement, que personne n'aime mettre \u00e0 jour, mais toutes les questions semblent n\u00e9anmoins assez solutionnables, et t\u00f4t ou tard, nous aurons tous HTTP\/3. <\/p>\n<p>L'avenir est \u00e0 port\u00e9e de main !<br \/>\n<br \/>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/473930\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442. \u0414\u0440\u0443\u0433\u0438\u0435 \u0437\u043d\u0430\u044e\u0442, \u0447\u0442\u043e \u0433\u0434\u0435-\u0442\u043e \u043f\u043e\u0434 HTTP \u0435\u0441\u0442\u044c TLS, \u0430 \u043f\u043e\u0434 \u043d\u0438\u043c TCP, \u043f\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u044b\u043c IP \u0438 \u0442\u0430\u043a \u0434\u0430\u043b\u0435\u0435. \u0410 \u0442\u0440\u0435\u0442\u044c\u0438 \u2013 \u0435\u0440\u0435\u0442\u0438\u043a\u0438 \u2013 \u0441\u0447\u0438\u0442\u0430\u044e\u0442, \u0447\u0442\u043e TCP \u2013 \u044d\u0442\u043e \u043f\u0440\u043e\u0448\u043b\u044b\u0439 \u0432\u0435\u043a, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52181","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HTTP\/3: \u0440\u0430\u0437\u0440\u0443\u0448\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432 \u0438 \u0434\u0438\u0432\u043d\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u043c\u0438\u0440 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-01T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T10:59:51+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HTTP\/3 : destruction des fondations et un nouveau monde merveilleux | ProHoster","description":"Cela fait plus de 20 ans que nous surfons sur des pages web via le protocole HTTP. La plupart des utilisateurs ne se rendent m\u00eame pas compte de ce que c'est et comment cela fonctionne.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HTTP\/3: \u0440\u0430\u0437\u0440\u0443\u0448\u0435\u043d\u0438\u0435 \u043e\u0441\u043d\u043e\u0432 \u0438 \u0434\u0438\u0432\u043d\u044b\u0439 \u043d\u043e\u0432\u044b\u0439 \u043c\u0438\u0440 | ProHoster","og:description":"\u0412\u043e\u0442 \u0443\u0436\u0435 \u0431\u043e\u043b\u044c\u0448\u0435 20 \u043b\u0435\u0442 \u043c\u044b \u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0432\u0435\u0431-\u0441\u0442\u0440\u0430\u043d\u0438\u0447\u043a\u0438 \u043f\u043e \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0443 HTTP. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0435 \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u0438 \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-01T21:00:00+00:00","article:modified_time":"2020-02-18T10:59:51+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52181","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 02:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:48:31","updated":"2026-01-24 02:46:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/52181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=52181"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/52181\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=52181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=52181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=52181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}