Guide des protocoles
HTTP/3 et QUIC pour les sites web en production : architecture, déploiement, sécurité et validation
HTTP/3 est un déploiement de transport à l'edge, pas un bouton universel de performance. Conservez le repli TCP, mesurez les résultats côté client et rendez explicites les comportements UDP, proxy et données précoces.
Sur cette page
HTTP/3 conserve la sémantique HTTP, mais associe les échanges requête-réponse à des flux QUIC sur UDP plutôt que TCP. La perte sur un flux QUIC ne bloque pas les flux sans rapport à la couche de transport, mais elle affecte toujours le flux perdu et QPACK peut introduire ses propres dépendances de décodage. Ne résumez pas cela par « aucun blocage nulle part ».
Overview
Résultat attendu
Planifiez un déploiement canari HTTP/3 qui conserve le repli HTTP/2 et HTTP/1.1, mesure les résultats spécifiques au protocole et empêche 0-RTT de rejouer un travail non sûr.
Séparer le transport du spectateur du chemin vers l'origine
Un CDN ou proxy inverse peut terminer HTTP/3 pour les spectateurs et utiliser HTTP/2 ou HTTP/1.1 en amont. Activer HTTP/3 à l'edge n'exige pas intrinsèquement HTTP/3 à l'origine. QUIC est fiable et contrôlé pour la congestion malgré son utilisation d'UDP, mais l'accessibilité UDP, l'équilibrage de charge, la capacité DDoS et l'architecture d'inspection deviennent des dépendances de production.
- Spectateur
Découvre une alternative HTTP/3 par une annonce du fournisseur ou du protocole.
- Edge QUIC
Termine TLS 1.3 et route les identifiants de connexion en sécurité à travers l'edge.
- Contrôles de sécurité
Applique une inspection consciente de QUIC, des contrôles de débit et de la télémétrie.
- Origine
Reçoit le protocole amont choisi via un contrat de proxy explicite.
Le spectateur peut négocier `h3` sur QUIC tandis que HTTPS fondé sur TCP reste un chemin de premier rang lorsque UDP est indisponible ou inadapté.
Conserver le repli TCP et tester UDP délibérément
Les clients HTTP/3 doivent utiliser HTTP fondé sur TCP si QUIC ne peut pas être établi, notamment lorsque UDP est bloqué. Maintenez TCP/443 actif. Mesurez le protocole négocié, la réussite et la durée de handshake, l'accessibilité UDP, les codes de fermeture, les signaux de retransmission et de délai d'attente, les résultats de cache, les erreurs de requête, l'utilisation CPU et l'expérience utilisateur par ASN, zone géographique, navigateur et type de réseau.
| Risque | Contrôle | Validation |
|---|---|---|
| UDP bloqué | Garder HTTP/2 et HTTP/1.1 disponibles | Un blocage réseau contrôlé bascule dans le budget prévu |
| Routage instable | Utiliser un équilibrage de charge conscient de QUIC et la gestion des identifiants de connexion | Test de rebinding NAT et de changement de chemin mobile |
| Inspection HTTP perdue | Confirmer le chemin proxy/WAF conscient de QUIC | La politique de sécurité s'applique au trafic h3 et TCP |
| Rejeu 0-RTT | Commencer désactivé ; n'autoriser que les opérations sûres au rejeu | Les requêtes non sûres sont retenues, rejetées ou protégées |
Exiger HTTP/3 ; la commande échoue lorsque QUIC ou UDP est indisponible :
curl --http3-only -sS -D - -o /dev/null https://www.example.com/
Préférer HTTP/3 tout en autorisant le repli documenté de curl :
curl --http3 -sS -D - -o /dev/null https://www.example.com/
Inspecter l'annonce HTTP/3 depuis le chemin TCP :
curl --http2 -sSI https://www.example.com/ | grep -i '^alt-svc:'Traiter 0-RTT comme une décision de rejeu
QUIC utilise TLS 1.3. Les clients de retour peuvent envoyer des données précoces 0-RTT avant la fin du handshake, mais ces données sont rejouables. Activez-les uniquement pour les routes dont la sémantique tolère explicitement le rejeu et dont l'application est cohérente sur tous les proxies et origines. Une méthode HTTP nominalement sûre peut toujours provoquer un effet de bord propre à une ressource ; classez donc l'opération réelle. Les passerelles incapables de préserver le contrat de données précoces doivent les différer ou les rejeter, notamment avec 425 Too Early lorsque c'est approprié.
Classez l'opération réelle, pas seulement sa méthode HTTP. La connexion, le paiement et toute mutation non sûre restent hors des données précoces rejouables.
Déployer selon les preuves, pas par un commutateur global
Établissez une référence HTTP/2 et HTTP/1.1 avant d'activer HTTP/3. Confirmez les certificats, TLS 1.3, l'écouteur UDP et les règles de pare-feu, la capacité DDoS, la compatibilité proxy/WAF et la journalisation. Faites un canari par nom d'hôte, région ou cohorte de trafic. Testez les premières et nouvelles visites, les réseaux d'entreprise restrictifs, les passages mobiles du Wi-Fi au cellulaire, les API authentifiées, les redirections, le cache, le WAF et les chemins de données précoces sûrs ou non sûrs. Revenez en arrière en retirant l'annonce ou l'écouteur HTTP/3 tout en conservant HTTPS sur TCP.
Troubleshooting
Pièges du déploiement HTTP/3
- Déclarer HTTP/3 universellement plus rapide à partir d'un résultat de laboratoire ou d'une moyenne agrégée de chargement de page.
- Faire d'UDP le seul chemin public ou oublier les réseaux qui le bloquent.
- Supposer que le trafic QUIC chiffré reçoit automatiquement l'inspection de l'ère TCP.
- Activer 0-RTT pour la connexion, le paiement, une mutation ou toute opération sans analyse de rejeu.
Guides connexes
- Architecture edge mondiale
- Budgets de latence des systèmes distribués
- Déploiement de Cloudflare Workers
Références faisant autorité
- RFC 9114 : HTTP/3
- RFC 9000 : protocole de transport QUIC
- RFC 9001 : QUIC TLS
- RFC 8470 : utilisation des données précoces en HTTP
- curl : prise en charge HTTP/3
Validez HTTP/3 comme un changement de transport en production
Optimi peut vous aider à tester le déploiement du protocole edge, le repli, la visibilité de sécurité et une récupération sûre pour l'application sur l'ensemble du chemin de diffusion.
Examiner le déploiement HTTP/3