HTTP/3

HTTP/3 est la dernière version du protocole web, et son changement déterminant est le transport sous-jacent : il fonctionne sur QUIC et UDP plutôt que sur TCP. Cela élimine le blocage en tête de ligne qui affectait HTTP/2, où un paquet perdu bloquait chaque flux sur la connexion ; avec QUIC, les flux sont indépendants. Il hérite également de la poignée de main plus rapide et cryptée de QUIC et de sa capacité à survivre à un changement de réseau, ce qui rend HTTP/3 plus rapide à démarrer et plus résilient, en particulier sur mobile.

Le passage à UDP a une conséquence pratique pour le proxying : parce que les proxies HTTP classiques et la méthode CONNECT ne transportent que TCP, HTTP/3 ne peut pas passer à travers eux. Il a besoin d'un chemin qui relaie UDP — un proxy SOCKS5 qui prend en charge UDP, ou un VPN à l'échelle de l'appareil qui tunnelise tout. Si un client tente d'utiliser HTTP/3 via un proxy uniquement TCP, il reviendra généralement à HTTP/2 sur TCP. Lorsque vous avez spécifiquement besoin de HTTP/3, faites-le passer par le VPN s4m ou le point de terminaison SOCKS5 compatible UDP plutôt que par le proxy HTTP.

Parce que HTTP/3 nécessite un chemin UDP, il ne peut pas traverser le tunnel TCP uniquement CONNECT d'un proxy HTTP classique ; un client reviendra généralement à HTTP/2 sur TCP. Lorsque vous avez spécifiquement besoin de HTTP/3, faites-le passer par un proxy SOCKS5 compatible UDP ou le s4m VPN à l'échelle de l'appareil. Pour la plupart des tâches, le retour en arrière est acceptable et invisible, donc n'optez pour un chemin compatible UDP que lorsqu'un outil nécessite réellement QUIC plutôt que d'accepter le retour en arrière TCP.