Analyser les requêtes HTTP directement dans le terminal avec httptap
Lorsqu'un service externe ou un microservice interne commence soudainement à ralentir, vos mains se tournent naturellement vers le bon vieux curl. Mais curl standard ne fait qu'afficher le corps de la réponse, et pour extraire les timings des phases de connexion, vous devez construire un modèle monstrueux avec une douzaine de variables via le flag -w. Ou vous ouvrez un navigateur, allez dans l'onglet Réseau des outils de développement, et admirez le beau graphique en cascade. Sur la console d'un serveur distant, vous ne pouvez pas ouvrir de navigateur, et fouiller dans une sortie brute est pénible.
Je suis récemment tombé sur httptap. C'est un outil Python élégant qui décompose toute requête HTTP en phases composantes : DNS, poignée de main TCP, négociation TLS, temps jusqu'au premier octet (TTFB), et transfert du corps de la réponse. Tout cela s'affiche sous forme de graphique en cascade clair directement dans la console.
Ce qui se cache sous le capot et pourquoi vous en avez besoin
L'outil est construit en Python en utilisant httpx, httpcore, dnspython et la bibliothèque Rich pour le rendu de l'interface. Il ne se contente pas de mesurer le temps de réponse total — il s'intègre au traçage de la pile réseau et montre exactement à quelle étape une requête s'est bloquée.
Si vous avez déjà utilisé le projet httpstat, l'idée vous semblera familière. Mais httptap présente plusieurs différences clés :
- Il peut suivre les chaînes de redirections et mesurer le timing de chaque étape séparément, en affichant un tableau récapitulatif.
- Supporte les vérifications de budget de latence (SLO) avec des codes de sortie lisibles.
- Inspecte les certificats TLS : signale le nom d'hôte (CN), l'algorithme de chiffrement, la version du protocole et les jours avant expiration.
- Exporte du JSON structuré détaillé avec toutes les métriques pour l'automatisation.
- Comprend les flags curl (
-X,-L,-H,-k,-x), donc vous n'avez pas à réapprendre vos réflexes.
Comment installer et exécuter
Le moyen le plus rapide d'installer sur macOS ou Linux est via Homebrew :
brew install httptap
Si vous préférez les outils Python, pip ou uv fonctionneront :
uv pip install httptap
# или
pip install httptap
Il y a aussi une image Docker prête à l'emploi dans le registre GitHub Packages :
docker run --rm ghcr.io/ozeranskii/httptap:latest https://example.com
L'utilisation de base est simple :
httptap https://httpbin.io/get
L'outil effectuera la requête et affichera un tableau net avec les timings pour chaque étape, le code de statut et les informations réseau (y compris la version du protocole HTTP/2 et la famille d'adresses IPv4/IPv6).
Ce que l'outil peut faire en pratique
Travailler avec n'importe quelles méthodes HTTP et corps de requêtes
L'outil envoie du JSON ou XML sans problème. Si vous passez le flag --data sans spécifier explicitement une méthode, l'outil basculera vers POST de lui-même, imitant le comportement de curl :
httptap https://httpbin.io/post --data '{"status": "testing", "source": "httptap"}'
Si les données sont dans un fichier, vous pouvez passer le chemin via la syntaxe @ :
httptap https://httpbin.io/post --data @payload.json
Pour les autres méthodes, il y a le flag familier --method (ou -X) :
httptap https://httpbin.io/put --method PUT --data '{"key": "value"}'
Suivre les chaînes de redirections
Peu d'outils peuvent correctement afficher le temps que prennent une série de réponses 301 et 302. Ici, vous avez juste besoin d'ajouter le flag --follow (ou -L) :
httptap --follow https://httpbin.io/redirect/2
La sortie inclura une ventilation détaillée pour chaque hôte intermédiaire et une ligne finale avec le temps total.
Vérifier les budgets de latence dans la CI
L'une des fonctionnalités les plus utiles du projet est le flag --slo. Il transforme l'outil en instrument de test de fumée et de gate pour les pipelines de build :
httptap --slo total=500,ttfb=200 https://api.example.com/health
Si le service cible répond avec un statut 200 mais que le TTFB dépasse 200 millisecondes ou que le temps total dépasse 500 millisecondes, l'outil retournera le code de sortie 4. Si une erreur réseau se produit, il retourne le code 75 (EX_TEMPFAIL selon la norme BSD sysexits).
Grâce à la séparation du code, vous pouvez configurer un script de déploiement pour distinguer les échecs réseau de la dégradation de performance :
httptap --slo total=1500,tls=200 https://staging.example.com/
case $? in
0) echo "Сервис уложился в нормативы" ;;
4) echo "Нарушен SLO по времени ответа"; exit 1 ;;
75) echo "Временный сетевой сбой, повторяем проверку" ;;
esac
Scripting et sortie compacte
Pour l'automatisation et les tâches cron, la sortie graphique de Rich peut être excessive. Deux modes sont disponibles pour ces scénarios :
-
Mode ligne compact
--compactpour les logs :httptap --compact https://httpbin.io/get -
Flux texte des métriques
--metrics-only:httptap --metrics-only https://httpbin.io/getVous recevrez une seule ligne de ce type :
Step 1: dns=30.1 connect=97.3 tls=199.0 ttfb=472.2 total=476.0 status=200 bytes=389 ip=44.211.11.205 family=IPv4 tls_version=TLSv1.2 proxy=direct -
Export JSON via
--json out/report.json, où les timings, les en-têtes, les paramètres TLS et les adresses IP sont sauvegardés.
Résolveurs personnalisés et extensibilité
Si vous écrivez des utilitaires Python internes, httptap peut être utilisé comme une bibliothèque. L'architecture est construite sur des protocoles (typing.Protocol), donc les composants sont faciles à échanger. Par exemple, vous pouvez écraser le résolveur DNS pour tester la réponse d'une IP spécifique sans modifier /etc/hosts :
from httptap import HTTPTapAnalyzer, SystemDNSResolver
class StaticDNS(SystemDNSResolver):
def resolve(self, host, port, timeout):
return "93.184.216.34", "IPv4", 0.05
analyzer = HTTPTapAnalyzer(dns_resolver=StaticDNS())
steps = analyzer.analyze_url("https://example.com")
for step in steps:
print(f"TTFB: {step.timing.ttfb_ms:.2f} ms")
L'outil s'est avéré compact, rapide et concentré sur une tâche spécifique. Il comble joliment le fossé entre curl brut et les profileurs graphiques lourds.
L'utilitaire sera utile pour les ingénieurs opérations pour le diagnostic rapide des endpoints lents sur les serveurs, les développeurs backend pour mesurer les latences des API externes, et les équipes QA pour vérifier les SLO directement dans les pipelines. Essayez de l'installer localement et de remplacer votre curl -I habituel pendant quelques jours. La différence en termes de clarté est immédiatement perceptible.
Projets similaires