Dépannage de la capture de paquets QUIC et HTTP/3 : ce que vous pouvez encore apprendre d'UDP

QUIC et HTTP/3 rendent l'analyse de capture de paquets plus difficile car le transport s'exécute via UDP et la plupart des données d'application sont cryptées. Les ingénieurs habitués aux numéros de séquence TCP peuvent ouvrir une capture QUIC et avoir l'impression que les preuves utiles ont disparu.

Cela n'a pas disparu. Les preuves ont changé.

Ce qu'une capture QUIC peut montrer

Même sans décrypter les données de l'application, un PCAP peut souvent afficher :

• paquets UDP client vers le port 443
• réponse UDP du serveur
• identifiants de connexion
• tailles de paquets
• timing de la poignée de main
• comportement de type retransmission au niveau du paquet UDP
• changements de chemin
• repli sur TCP/TLS
• Erreurs ICMP
• pare-feu ou suppressions NAT

Si le client envoie des paquets QUIC Initial et que le serveur ne répond jamais, le problème peut être dû au blocage UDP, à la stratégie du serveur, au routage ou au comportement du boîtier de médiation. Si QUIC échoue et que le client revient à TCP/TLS, cette solution de repli constitue une preuve importante.

UDP 443 est souvent bloqué différemment de TCP 443

De nombreux réseaux autorisent TCP 443 mais restreignent UDP 443. Un site peut fonctionner sur HTTP/2 mais échouer ou se dégrader sur HTTP/3. Du côté de l’utilisateur, cela peut ressembler à une lenteur aléatoire du navigateur ou à un échec de connexion.

Capturez les questions :

• le client a-t-il tenté l'UDP 443 ?
• le serveur a-t-il répondu ?
• ICMP a-t-il signalé qu'il était inaccessible ?
• le client a-t-il réessayé ?
• le client est-il revenu à TCP 443 ?
• combien de temps a été perdu avant le repli ?

C'est ainsi qu'une capture de paquet peut prouver que « HTTPS fonctionne » n'est pas la même chose que « HTTP/3 fonctionne ».

Le timing QUIC compte toujours

Étant donné que QUIC gère la fiabilité des paquets UDP chiffrés, les étiquettes d'analyse TCP classiques ne s'appliquent pas directement. Mais la synchronisation des paquets est toujours importante :

• paquets répétés de taille similaire
• écarts avant la réponse du serveur
• éclate après la perte
• changements dans la taille des paquets
• migration entre chemins
• long délai avant le repli

Ces modèles peuvent prendre en charge un diagnostic réseau même sans décrypter le flux.

La place de la chirurgie PCAP

PCAP Surgery devrait aider les ingénieurs à isoler le flux UDP pertinent, à préserver le timing et à préparer une capture partageable. Les cas QUIC nécessitent souvent un contexte autour de la solution de secours :

• Requête DNS
• Tentative UDP 443
• réponse ou absence du serveur
• TCP 443 de secours
• Prise de contact TLS après le repli
• impact sur le timing

Si une capture est nettoyée, les ID de connexion et la taille des paquets peuvent toujours être utiles. Supprimez-les uniquement si la politique de confidentialité l’exige et enregistrez ce qui a changé.

Pour des recherches telles que « Capture de paquets QUIC », « HTTP/3 UDP 443 bloqué » ou « Repli QUIC sur TCP », la réponse n'est pas d'abandonner car la charge utile est cryptée. Le calendrier de transport et le chemin de repli racontent toujours une histoire utile.