Analyse HTTP/2 GOAWAY et RST_STREAM PCAP : débogage des flux de réinitialisation, limites du proxy et échecs de gRPC

Les échecs HTTP/2 peuvent être difficiles à diagnostiquer car une connexion TCP peut transporter plusieurs flux. Une seule requête peut échouer avec « RST_STREAM », la connexion entière peut recevoir « GOAWAY », ou un client gRPC peut signaler « NON DISPONIBLE », « INTERNE », « ANNULÉ » ou « réinitialisation du flux ». Les utilisateurs recherchent « HTTP2 GOAWAY pcap », « RST_STREAM Analysis », « gRPC stream reset packet capture », « HTTP/2 proxy reset » et « ALPN HTTP2 troubleshooting » lorsque les journaux n'expliquent pas si le client, le proxy, l'équilibreur de charge ou le serveur ont mis fin au flux.

La chirurgie PCAP est utile car la preuve HTTP/2 doit préserver TLS, ALPN, le timing de connexion, les réinitialisations de flux et le comportement de fermeture TCP. Si TLS est chiffré et que les clés ne sont pas disponibles, les captures de paquets affichent toujours la synchronisation, les réinitialisations TCP, la réutilisation des connexions et parfois le HTTP/2 déchiffré uniquement dans des environnements contrôlés.

Connexion HTTP/2 vs flux

HTTP/2 multiplexe plusieurs flux sur une seule connexion. Une réinitialisation de flux n'est pas la même chose qu'une réinitialisation de connexion TCP.

• RST_STREAM : un flux est annulé ou a échoué.
• « GOAWAY » : le point de terminaison ferme ou draine la connexion HTTP/2.
• TCP FIN/RST : la connexion sous-jacente se ferme ou s'interrompt.

Les applications les regroupent souvent en une seule erreur. Les preuves de paquets et les journaux doivent les séparer.

Négociation ALPN

HTTP/2 sur TLS dépend généralement d'ALPN. La prise de contact TLS négocie « h2 » ou un autre protocole. Si ALPN ne négocie pas HTTP/2, le client et le serveur peuvent échouer ou échouer.

Préserver:

• ClientBonjour Extension ALPN.
• ALPN sélectionné par le serveur là où il est visible.
• Alertes TLS.
• TCP se réinitialise pendant la négociation.

Si HTTP/2 n'a jamais été négocié, ne déboguez pas encore RST_STREAM.

GOAWAY

« GOAWAY » indique à l'homologue qu'aucun nouveau flux ne doit être créé sur cette connexion. Cela peut être normal lors d'un drainage progressif, de déploiements, du vieillissement de la connexion proxy ou du comportement de l'équilibreur de charge. Cela devient un problème lorsque les clients réutilisent incorrectement les connexions drainantes ou lorsque GOAWAY apparaît lors de requêtes actives.

Questions importantes :

• Qui a envoyé GOAWAY ?
• Quel était le dernier identifiant de flux ?
• Les flux actifs ont-ils échoué ?
• Le client a-t-il réessayé avec une nouvelle connexion ?
• GOAWAY se produit-il à un âge de connexion fixe ?

RST_STREAM

RST_STREAM termine un flux HTTP/2. Les causes incluent :

• Annulation du client.
• Le serveur rejette une demande.
• Délai d'expiration du proxy.
• Problème de contrôle de flux.
• Limite maximale de flux.
• Délai gRPC dépassé.
• Réinitialisation du backend traduite par proxy.

L’ID du flux et le timing sont importants. Sans eux, l’histoire du paquet est incomplète.

La couche TCP compte toujours

HTTP/2 repose sur TCP. Si la connexion sous-jacente présente des retransmissions, une fenêtre nulle, une réinitialisation, des problèmes de MTU ou un délai d'inactivité, les erreurs HTTP/2 peuvent être secondaires.

Corrélatif:

• Heure de réinitialisation du flux.
• Retransmissions TCP avant réinitialisation.
• Expéditeur FIN/RST.
• Intervalle d'inactivité.
• TLS close_notify si visible.

Checklist

Utilisez ce flux de travail :

1. Préservez la négociation DNS, TCP et TLS.
2. Confirmez qu’ALPN a négocié HTTP/2.
3. Identifiez si l’échec est au niveau du flux ou au niveau de la connexion.
4. Recherchez le timing et l’expéditeur GOAWAY.
5. Recherchez la synchronisation RST_STREAM et l'ID de flux dans les traces ou les journaux déchiffrés.
6. Faites une corrélation avec les journaux du proxy/de l'équilibreur de charge.
7. Vérifiez la retransmission TCP, la fenêtre zéro, FIN et RST.
8. Vérifiez si le client réessaye correctement.
9. Préservez la synchronisation des paquets lors du découpage.
10. Combinez les preuves pcap avec les journaux de débogage HTTP/2 une fois chiffrés.

Diagnostic final

Les erreurs HTTP/2 GOAWAY et RST_STREAM ne sont pas des pannes réseau génériques. Il s'agit de signaux de contrôle de flux et de connexion qui doivent être corrélés avec ALPN, le comportement du proxy, les délais gRPC, l'état TCP et la réutilisation des connexions.

PCAP Surgery aide à préserver la chronologie afin que les échecs HTTP/2 et gRPC puissent être réduits à la bonne couche : négociation TLS, réinitialisation de flux, fuite de connexion, délai d'expiration du proxy ou échec du transport TCP.