Requête HTTP lente et TTFB dans PCAP : prouver si le délai est DNS, TCP, TLS ou l'heure du serveur

« Le site Web est lent » et « La requête API prend 10 secondes » ne sont pas des diagnostics. Une capture de paquets peut diviser le délai en phases: "recherche DNS, négociation TCP, négociation TLS, téléchargement de requêtes, traitement du serveur, téléchargement de réponse, retransmissions et comportement du client." Le temps jusqu’au premier octet est souvent l’expression recherchée par les utilisateurs. En termes de paquets, TTFB n'est pas un seul champ magique. C'est une chronologie.

Construire le calendrier de la demande

Pour une requête HTTP ou HTTPS, inspectez :

• Démarrage de la requête DNS
• Temps de réponse DNS
• SYNCHRONISATION TCP
• Achèvement de la négociation TCP
• Client TLSBonjour
• Serveur TLSBonjour et certificat
• Octets de requête HTTP envoyés
• premier octet de réponse
• achèvement de la réponse complète
• retransmissions ou réinitialisations

Si DNS prend cinq secondes, le serveur n'est pas encore lent. Si la négociation TCP est rapide mais que le premier octet de réponse est en retard, le traitement du serveur ou la dépendance en amont peuvent être à l'origine du problème. Si TLS se bloque avant HTTP, concentrez-vous sur le comportement du certificat, du chiffrement, du SNI ou du boîtier de médiation.

HTTP sur TLS nécessite des limites prudentes

Dans les captures HTTPS, la charge utile peut être chiffrée, mais le timing reste important. Vous pouvez souvent identifier :

• début de connexion
• durée de la poignée de main
• données d'application cryptées du client
• premières données d'application cryptées à partir du serveur
• perte ou retransmission de paquets
• connexion fermée ou réinitialisée

Même sans décrypter le contenu, la capture peut montrer si le retard s'est produit avant ou après l'envoi de la demande.

Surveillez les retransmissions

Un HTTP lent peut provenir d’une perte de paquets. Si des retransmissions TCP ou des ACK en double apparaissent lors du téléchargement de la demande ou de la livraison de la réponse, le serveur n'est peut-être pas le propriétaire principal. Une réponse importante avec perte sur le chemin serveur-client peut ressembler à une latence backend pour les utilisateurs.

Le rapport doit séparer :

• délai avant que la demande ne quitte le client
• le serveur de temps semble traiter
• temps passé à retransmettre la réponse
• comportement de la fenêtre de réception côté client

Cette distinction empêche les équipes back-end de résoudre les problèmes de réseau.

La place de la chirurgie PCAP

La chirurgie PCAP est utile lorsque la capture originale est trop grande ou trop sensible. Un transfert de latence HTTP ciblé doit préserver :

• Fenêtre DNS
• Prise de contact TCP
• Prise de contact TLS si présente
• délai de demande/réponse
• preuve de retransmission
• réinitialisations ou alertes
• horodatages originaux

Si l’anonymisation est nécessaire, préservez la synchronisation et la taille des paquets lorsque cela est important. Supprimer trop de contexte peut rendre l'analyse TTFB impossible.

Pour des recherches telles que « pcap de requête lente HTTP », « délai jusqu'à la capture du paquet du premier octet » ou « latence de l'API Wireshark », la réponse est une chronologie étape par phase, et non une seule étiquette de blâme.