Monitoring HTTP vs TCP vs Ping : quel protocole choisir ?

En configurant l’uptime monitoring, l’une des premières décisions concerne le protocole de vos checks. HTTP, TCP et Ping (ICMP) testent des couches différentes de votre infrastructure, et le bon choix détermine les problèmes que vous pouvez détecter.

Comprendre les couches

Votre pile applicative comporte plusieurs couches, et chaque protocole de monitoring teste une profondeur différente :

```
┌─────────────────────────┐
│ Application (HTTP) │ ← Le monitoring HTTP teste ici
├─────────────────────────┤
│ Service (ports TCP) │ ← Le monitoring TCP teste ici
├─────────────────────────┤
│ Réseau (ICMP) │ ← Le monitoring Ping teste ici
├─────────────────────────┤
│ Physique / Cloud │
└─────────────────────────┘
```

Une couche peut tomber pendant que les couches inférieures restent saines. Votre serveur peut répondre au ping (le réseau va bien) alors que le processus web a planté (HTTP échouerait, le TCP sur le port 80 aussi). Comprendre cela aide à choisir le bon protocole pour chaque service.

Monitoring HTTP / HTTPS

Fonctionnement

Un Monitor HTTP envoie une requête HTTP complète (généralement GET) vers une URL et évalue la réponse. Il vérifie :

• Connexion : peut-on établir le TCP et terminer la poignée de main TLS ?
• Code de statut : le serveur a-t-il renvoyé le statut attendu (200, 301, etc.) ?
• Corps de réponse : le corps contient-il (ou n’contient-il pas) le contenu attendu ?
• Temps de réponse : combien de temps a pris tout le cycle requête/réponse ?
• Certificat SSL : le certificat est-il valide et non proche de l’expiration ?

Quand utiliser le monitoring HTTP

Sites et applications web : toute URL accessible dans un navigateur. C’est le choix par défaut pour la plupart des besoins.

APIs REST : surveillez des endpoints de santé (/health, /api/status) pour vérifier que votre API répond correctement.

Webhooks : vérifiez que les endpoints acceptent les requêtes.

Vérification de contenu : quand vous devez vérifier non seulement qu’une page charge, mais qu’elle contient le bon contenu. Un serveur peut renvoyer 200 OK avec une page d’erreur — le monitoring par mots-clés le détecte.

Avantages

• Teste toute la pile applicative, y compris le code
• Peut vérifier le contenu de la réponse, pas seulement la connectivité
• Surveille la validité et l’expiration du certificat SSL
• Mesure des temps de réponse proches de l’expérience utilisateur
• Prend en charge l’authentification (en-têtes, cookies)

Limites

• Ne fonctionne qu’avec les services HTTP/HTTPS
• Coût par check plus élevé que TCP ou Ping
• Ne surveille pas les services non web (bases de données, messagerie, jeux)

Exemples d’usage

| Cible | URL | Attendu |
|-------|-----|---------|
| Page d’accueil | https://example.com | Statut 200 |
| Santé API | https://api.example.com/health | Statut 200, corps contient « ok » |
| Page de connexion | https://app.example.com/login | Statut 200 |
| Webhook | https://hooks.example.com/ingest | Statut 200 ou 405 |

Monitoring TCP

Fonctionnement

Un Monitor TCP tente d’ouvrir une connexion vers une adresse IP et un numéro de port. Il vérifie :

• Port ouvert : une connexion TCP peut-elle s’établir ?
• Temps de connexion : à quelle vitesse le port accepte-t-il la connexion ?
• Réponse du port : le service répond-il dans le délai imparti ?

Le monitoring TCP n’envoie pas de données applicatives — il teste seulement si le port écoute et accepte les connexions.

Quand utiliser le monitoring TCP

Bases de données : PostgreSQL (5432), MySQL (3306), MongoDB (27017), Redis (6379) pour vérifier qu’elles acceptent les connexions.

Serveurs de messagerie : SMTP (25/587), IMAP (143/993), POP3 (110/995).

Services personnalisés : tout service qui écoute sur un port TCP mais ne parle pas HTTP — jeux, brokers MQTT, FTP, SSH.

Load balancers : vérifier que le port du load balancer est ouvert et accepte les connexions.

Avantages

• Fonctionne avec tout service TCP, pas seulement HTTP
• Surcharge inférieure aux checks HTTP
• Pas de configuration applicative nécessaire
• Détecte les problèmes de port (service crashé, pare-feu mal configuré)

Limites

• Ne teste que l’ouverture du port, pas le bon fonctionnement applicatif
• Ne peut pas vérifier le contenu de la réponse
• Ne teste pas la logique applicative (une base peut accepter les connexions mais échouer toutes les requêtes)

Exemples d’usage

| Cible | Hôte:Port | Objectif |
|-------|-----------|----------|
| PostgreSQL | db.internal:5432 | Disponibilité base de données |
| Redis | cache.internal:6379 | Disponibilité cache |
| SSH | bastion.example.com:22 | Accès bastion |
| SMTP | mail.example.com:587 | Livraison email |
| API custom | service.internal:8080 | Santé microservice |

Monitoring Ping (ICMP)

Fonctionnement

Ping envoie des paquets ICMP Echo Request et attend des Echo Reply. Il teste :

• Atteignabilité de l’hôte : l’hôte répond-il au niveau réseau ?
• Aller-retour : combien de temps met le paquet ?
• Perte de paquets : des paquets sont-ils perdus ?

Quand utiliser le monitoring Ping

Infrastructure réseau : routeurs, commutateurs, pare-feu et équipements qui n’exécutent pas de services applicatifs.

Disponibilité serveur : vérification rapide qu’un serveur est allumé et connecté au réseau, quel que soit ce qu’il exécute.

Performance réseau : temps de ping et taux de perte indiquent la santé du chemin entre votre emplacement de monitoring et la cible.

Monitoring de référence : en complément des checks HTTP/TCP, le ping aide à distinguer « le serveur est totalement injoignable » de « le serveur répond mais l’application est cassée ».

Avantages

• Surcharge la plus faible de tous les protocoles
• Teste le niveau le plus fondamental de connectivité
• Utile pour les équipements sans services applicatifs
• Aide à diagnostiquer si le problème est réseau ou application

Limites

• Ne teste que l’atteignabilité réseau — pas la santé applicative
• Certains hôtes et pare-feux bloquent ICMP : ping peu fiable
• Les environnements cloud n’ont souvent pas d’ICMP vers certaines ressources
• Ne vérifie pas qu’un service spécifique tourne

Exemples d’usage

| Cible | Hôte | Objectif |
|-------|------|----------|
| Passerelle VPN | vpn.example.com | Accès réseau |
| Routeur | 10.0.0.1 | Infrastructure réseau |
| Serveur | web-1.internal | Atteignabilité de base |
| Saut FAI | isp-gateway.net | Santé du chemin réseau |

Choisir le bon protocole

Voici un cadre de décision :

Site web, application web ou API REST ?
→ Utilisez le monitoring HTTP. Il teste toute la pile et fournit les données les plus utiles.

Service qui écoute sur TCP mais ne parle pas HTTP ?
→ Utilisez le monitoring TCP. Bases de données, messagerie, jeux, services personnalisés.

Équipement réseau, ou besoin de vérifier une atteignabilité de base ?
→ Utilisez le monitoring Ping. Routeurs, commutateurs, passerelles VPN, santé serveur de base.

Pas sûr ?
→ Commencez par HTTP pour tout ce qui a une URL, TCP pour tout ce qui a un port, et Ping pour l’infrastructure.

Combiner les protocoles pour une couverture complète

Les meilleures stratégies utilisent plusieurs protocoles pour couvrir différents modes de défaillance. Pour une pile web typique :

| Composant | Protocole | Check |
|-----------|-----------|-------|
| Site web | HTTP | https://example.com → 200 |
| API | HTTP | https://api.example.com/health → 200 |
| Base de données | TCP | db.internal:5432 |
| Cache Redis | TCP | cache.internal:6379 |
| Serveur | Ping | web-1.internal |

Quand le check HTTP échoue mais que TCP et Ping passent, vous savez que le serveur est up et le port ouvert — le problème est dans le code applicatif. Quand tout échoue, c’est un problème serveur ou réseau. Cette approche par couches accélère fortement le diagnostic.

Conclusion

Il n’y a pas de « meilleur » protocole de monitoring unique — chacun teste une couche différente de votre stack. Le monitoring HTTP est le plus complet pour les services web, le TCP couvre les services non HTTP, et le Ping apporte une visibilité réseau de base.

Pour la plupart des équipes, la réponse est « utilisez les trois, sur les bonnes cibles ». Commencez par le HTTP pour les services orientés utilisateur, ajoutez le TCP pour l’infrastructure et le Ping pour la santé réseau.

Surveillez chaque couche de votre stack. Commencer gratuitement — monitoring HTTP, TCP et Ping sur tous les plans.