{"id":81847,"date":"2020-05-17T01:42:34","date_gmt":"2020-05-16T23:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic"},"modified":"2020-05-17T01:42:34","modified_gmt":"2020-05-16T23:42:34","slug":"http-po-udp-ispolzuem-s-polzoj-protokol-quic","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic","title":{"rendered":"HTTP sur UDP - optimisons l'utilisation du protocole QUIC","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Quick UDP Internet Connections) est un protocole bas\u00e9 sur UDP qui prend en charge toutes les fonctionnalit\u00e9s de TCP, TLS et HTTP\/2, tout en r\u00e9solvant la plupart de leurs probl\u00e8mes. Il est souvent qualifi\u00e9 de nouveau protocole ou de \u00ab protocole exp\u00e9rimental \u00bb, mais il a depuis longtemps d\u00e9pass\u00e9 la phase d'exp\u00e9rimentation : son d\u00e9veloppement dure depuis plus de 7 ans. Au cours de cette p\u00e9riode, le protocole n'est pas devenu un standard, mais il a tout de m\u00eame gagn\u00e9 en popularit\u00e9. Par exemple, QUIC est utilis\u00e9 pour acc\u00e9l\u00e9rer le trafic et r\u00e9duire la latence dans les r\u00e9seaux mobiles par des g\u00e9ants comme Google et Facebook, et l'IETF a d\u00e9clar\u00e9 son fork comme base pour le standard HTTP\/3 (alors que HTTP\/2 utilise seulement 44,8%<\/a><\/noindex> des sites).<\/a><\/noindex><\/p>\n

Concept<\/h2>\n

\nQUIC a \u00e9t\u00e9 d\u00e9velopp\u00e9 pour remplacer le TCP obsol\u00e8te, qui \u00e9tait initialement con\u00e7u pour des r\u00e9seaux filaires avec un faible pourcentage de perte. TCP livre les paquets dans un ordre d\u00e9termin\u00e9, donc lorsqu'un paquet est perdu, toute la file d'attente se bloque (head-of-line blocking<\/a><\/noindex>), ce qui impacte n\u00e9gativement la qualit\u00e9 et la stabilit\u00e9 de la connexion. Pour \u00e9viter des pertes massives, les r\u00e9seaux mobiles utilisent de grands tampons, ce qui entra\u00eene des surcharges et une r\u00e9action faussement n\u00e9gative du protocole (bufferbloat<\/a><\/noindex>). De plus, le TCP prend beaucoup de temps pour \u00e9tablir une connexion : les requ\u00eates SYN\/ACK et TLS sont effectu\u00e9es s\u00e9par\u00e9ment, n\u00e9cessitant trois allers-retours au lieu d'un, comme le fait QUIC.<\/p>\n

\"HTTP
\n
\nPuisque QUIC combine un remplacement du TCP et la mise en \u0153uvre de TLS 1.3, toutes les connexions sont toujours chiffr\u00e9es, et il n'est pas plus facile de d\u00e9chiffrer ce trafic que s'il circulait via HTTPS. En outre, QUIC est mis en \u0153uvre au niveau applicatif, car une substitution compl\u00e8te de la pile TCP prendrait une \u00e9ternit\u00e9.<\/i>.<\/p>\n

Bien qu'il prenne en charge le multiplexage dans HTTP\/2, le probl\u00e8me de head-of-line blocking subsiste \u00e0 cause de la n\u00e9cessit\u00e9 de livrer les paquets dans l'ordre. QUIC est mis en \u0153uvre au-dessus de l'UDP, ce qui le rend exempt de blocages, et pour \u00e9viter que les paquets ne soient irr\u00e9m\u00e9diablement perdus, ils sont num\u00e9rot\u00e9s et peuvent contenir des parties de \u00ab voisins \u00bb, assurant ainsi une redondance. De plus, QUIC divise la file d'attente monolithique en plusieurs flux pour diff\u00e9rents types de requ\u00eates au sein d'une seule connexion. Ainsi, en cas de perte d'un paquet, les probl\u00e8mes ne peuvent survenir que dans une seule file d'attente (par exemple, lors de la transmission d'un fichier sp\u00e9cifique) :<\/p>\n

\"HTTP
\n<\/p>\n

Utilisation <\/h2>\n

\nQUIC a \u00e9t\u00e9 initialement d\u00e9velopp\u00e9 \u00e0 l'int\u00e9rieur de Google et \u00e9tait en grande partie con\u00e7u pour un usage interne. En 2013, il a \u00e9t\u00e9 transf\u00e9r\u00e9 \u00e0 l'IETF pour normalisation (ce qui est toujours en cours), et maintenant tout le monde peut participer au d\u00e9veloppement du protocole en proposant ce qui lui manque. Le groupe de travail de l'IETF organise chaque ann\u00e9e des r\u00e9unions au cours desquelles un nouveau standard est approuv\u00e9 et o\u00f9 des innovations sont discut\u00e9es. Cette impl\u00e9mentation de QUIC est consid\u00e9r\u00e9e comme la principale et c'est sur cette base que la norme HTTP\/3 est certifi\u00e9e.<\/p>\n

Actuellement, il n'est pas question d'inclure HTTP\/3 comme protocole principal, car il n'est pas encore termin\u00e9 et n'est presque pas pris en charge :<\/p>\n

\"HTTP
\n
\nMais QUIC peut \u00eatre mis en \u0153uvre comme un transport entre l'application et le serveur, ce qui a \u00e9t\u00e9 r\u00e9alis\u00e9 avec succ\u00e8s chez Uber :<\/p>\n

\n

Commentaire d'Uber sur l'impl\u00e9mentation de QUIC<\/i><\/h3>\n

\nPour int\u00e9grer QUIC avec succ\u00e8s et am\u00e9liorer les performances de l'application dans des conditions de mauvaise connexion, nous avons remplac\u00e9 l'ancienne pile (HTTP\/2 sur TLS\/TCP) par le protocole QUIC. Nous avons utilis\u00e9 la biblioth\u00e8que r\u00e9seau Cronet<\/a><\/noindex> de Chromium Projects<\/a><\/noindex>, qui contient la version originale de Google du protocole \u2013 gQUIC. Cette impl\u00e9mentation est \u00e9galement constamment am\u00e9lior\u00e9e pour suivre les derni\u00e8res sp\u00e9cifications de l'IETF.<\/p>\n

Nous avons d'abord int\u00e9gr\u00e9 Cronet dans nos applications Android pour ajouter le support de QUIC. L'int\u00e9gration a \u00e9t\u00e9 effectu\u00e9e de mani\u00e8re \u00e0 minimiser au maximum les co\u00fbts de migration. Au lieu de remplacer compl\u00e8tement l'ancienne pile r\u00e9seau qui utilisait la biblioth\u00e8que OkHttp<\/a><\/noindex>, nous avons int\u00e9gr\u00e9 Cronet SOUS le cadre de l'API OkHttp. En proc\u00e9dant ainsi, nous avons \u00e9vit\u00e9 des modifications dans nos appels r\u00e9seau (qui utilisent Retrofit<\/a><\/noindex>) au niveau de l'API.<\/p>\n

Tout comme pour les appareils Android, nous avons int\u00e9gr\u00e9 Cronet dans les applications Uber sous iOS, en interceptant le trafic HTTP des API<\/a><\/noindex>, en utilisant NSURLProtocol<\/a><\/noindex>. Cette abstraction, fournie par iOS Foundation, g\u00e8re les donn\u00e9es URL sp\u00e9cifiques au protocole et garantit que nous pouvons int\u00e9grer Cronet dans nos applications iOS sans co\u00fbts de migration significatifs.<\/p><\/blockquote>\n

extrait de cette traduction<\/a><\/noindex> article d'Uber<\/i><\/p>\n

Sur le backend, ils capturent les connexions QUIC via Google Cloud lb, qui prend en charge le protocole<\/a><\/noindex> depuis le milieu de 2018.<\/p>\n

Il n'est pas surprenant que Google Cloud fonctionne parfaitement avec le protocole d\u00e9velopp\u00e9 par Google, mais quelles sont les alternatives ?<\/p>\n

Nginx<\/h3>\n

\nR\u00e9cemment, CloudFlare a essay\u00e9 de croiser<\/a><\/noindex> nginx (qui par d\u00e9faut ne supporte pas HTTP\/3) avec son outil Quiche. L\u2019impl\u00e9mentation est disponible sous la forme d\u2019un unique fichier .patch, accompagn\u00e9 d\u2019un tutoriel d\u2019installation :<\/p>\n

curl -O https:\/\/nginx.org\/download\/nginx-1.16.1.tar.gz\ntar xvzf nginx-1.16.1.tar.gz\ngit clone --recursive https:\/\/github.com\/cloudflare\/quiche\ncd nginx-1.16.1\npatch -p01 < ..\/quiche\/extras\/nginx\/nginx-1.16.patch<\/code><\/pre>\n
\nIci, vous pouvez connecter vos propres modules si n\u00e9cessaire<\/p>\n
.\/configure                          \t\n   \t--prefix=$PWD                       \t\n   \t--with-http_ssl_module              \t\n   \t--with-http_v2_module               \t\n   \t--with-http_v3_module               \t\n   \t--with-openssl=..\/quiche\/deps\/boringssl \n   \t--with-quiche=..\/quiche\n make<\/code><\/pre>\n
\nIl ne reste plus qu'\u00e0 activer le support de HTTP\/3<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # Activer QUIC et HTTP\/3.\n        listen 443 quic reuseport;\n\n        # Activer HTTP\/2 (optionnel).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Activer toutes les versions TLS (TLSv1.3 est requis pour QUIC).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # Le buffering des requ\u00eates n\u2019est actuellement pas support\u00e9 pour HTTP\/3.\n        proxy_request_buffering off;\n\n        # Ajouter un en-t\u00eate Alt-Svc pour n\u00e9gocier HTTP\/3.\n        add_header alt-svc 'h3-27=":443"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nDans les navigateurs classiques, il n'est pas encore possible de se connecter via HTTP\/3, mais vous pouvez le prendre Chrome Canary<\/a><\/noindex> et le lancer avec le drapeau --enable-quic<\/code>, acc\u00e9der \u00e0 votre serveur ou, par exemple, au site quic.rocks et v\u00e9rifier le type de connexion dans les Outils de d\u00e9veloppement :
\n\"HTTP
\nAu lieu de HTTP\/3, cela affiche http2+quic\/99<\/code>, mais c'est en r\u00e9alit\u00e9 la m\u00eame chose.<\/p>\n
D'autres technologies<\/h3>\n
<\/p>\n