HTTP vs TCP vs Ping monitoring: quale protocollo usare?

Quando configuri l'uptime monitoring, una delle prime decisioni è quale protocollo usare per i check. HTTP, TCP e Ping (ICMP) testano strati diversi dell'infrastruttura e la scelta giusta determina quali problemi puoi intercettare.

Capire gli strati

Lo stack applicativo ha più livelli e ogni protocollo di monitoring testa una profondità diversa:

```
┌─────────────────────────┐
│ Application (HTTP) │ ← HTTP monitoring testa qui
├─────────────────────────┤
│ Service (TCP ports) │ ← TCP monitoring testa qui
├─────────────────────────┤
│ Network (ICMP) │ ← Ping monitoring testa qui
├─────────────────────────┤
│ Physical / Cloud │
└─────────────────────────┘
```

Uno strato può fallire mentre quelli sotto restano sani. Il server può rispondere al ping (rete ok) mentre il processo web è crashato (HTTP fallirebbe, TCP sulla porta 80 fallirebbe). Capirlo aiuta a scegliere il protocollo giusto per ogni servizio.

Monitoring HTTP / HTTPS

Come funziona

Un Monitor HTTP invia una richiesta HTTP completa (di solito GET) a un URL e valuta la risposta. Controlla:

• Connessione: riusciamo a stabilire TCP e completare il TLS handshake?
• Status code: il server ha restituito lo status atteso (200, 301, ecc.)?
• Response body: la risposta contiene (o non contiene) contenuto specifico?
• Response time: quanto ha impiegato l'intero ciclo richiesta/risposta?
• Certificato SSL: valido e non in scadenza imminente?

Quando usare HTTP monitoring

Siti e applicazioni web: qualsiasi URL raggiungibile dal browser. Scelta predefinita per la maggior parte dei casi.

REST API: monitora health check (/health, /api/status) per verificare che l'API risponda correttamente.

Webhooks: verifica che gli endpoint accettino richieste.

Verifica contenuto: quando serve verificare non solo il caricamento ma il contenuto giusto. Un server può restituire 200 OK con una pagina di errore — le keyword HTTP intercettano questo.

Vantaggi

• Testa lo stack applicativo completo, incluso il codice applicativo
• Può verificare il contenuto della risposta, non solo la connettività
• Monitora validità e scadenza del certificato SSL
• Misura response time percepito dagli utenti reali
• Supporta autenticazione (header, cookie)

Limitazioni

• Funziona solo con servizi HTTP/HTTPS
• Overhead per check maggiore di TCP o Ping
• Non può monitorare servizi non web (database, mail, game server)

Esempi

| Target | URL | Atteso |
|--------|-----|--------|
| Homepage | https://example.com | Status 200 |
| API health | https://api.example.com/health | Status 200, body contiene "ok" |
| Login | https://app.example.com/login | Status 200 |
| Webhook | https://hooks.example.com/ingest | Status 200 o 405 |

Monitoring TCP

Come funziona

Un Monitor TCP tenta di aprire una connessione a un indirizzo IP e a un numero di porta. Verifica:

• Porta aperta: si stabilisce una connessione TCP?
• Tempo di connessione: quanto velocemente la porta accetta?
• Risposta della porta: il servizio risponde entro il timeout?

Il monitoring TCP non invia dati a livello applicativo — testa solo se la porta è in ascolto e accetta connessioni.

Quando usare TCP monitoring

Database: PostgreSQL (5432), MySQL (3306), MongoDB (27017), Redis (6379) per verificare che accettino connessioni.

Server di posta: SMTP (25/587), IMAP (143/993), POP3 (110/995).

Servizi custom: qualsiasi servizio su porta TCP che non parla HTTP — game server, broker MQTT, FTP, SSH.

Load balancer: verifica che la porta del load balancer sia aperta e accetti connessioni.

Vantaggi

• Funziona con qualsiasi servizio TCP, non solo HTTP
• Overhead inferiore ai check HTTP
• Nessuna configurazione a livello applicativo
• Intercetta problemi a livello porta (servizio crashato, firewall sbagliato)

Limitazioni

• Testa solo che la porta sia aperta, non che l'applicazione funzioni correttamente
• Non può verificare il contenuto della risposta
• Non testa la logica applicativa (un database può accettare connessioni ma fallire tutte le query)

Esempi

| Target | Host:Porta | Scopo |
|--------|------------|-------|
| PostgreSQL | db.internal:5432 | Disponibilità database |
| Redis | cache.internal:6379 | Disponibilità cache |
| SSH | bastion.example.com:22 | Accesso jump server |
| SMTP | mail.example.com:587 | Invio email |
| Custom API | service.internal:8080 | Salute microservizio |

Monitoring Ping (ICMP)

Come funziona

Il Ping invia pacchetti ICMP Echo Request a un host e attende Echo Reply. Testa:

• Raggiungibilità dell'host: l'host risponde a livello di rete?
• Round-trip time: quanto impiega il pacchetto ad andare e tornare?
• Packet loss: qualche pacchetto viene perso?

Quando usare Ping monitoring

Infrastruttura di rete: router, switch, firewall e dispositivi senza servizi applicativi.

Disponibilità server: verifica rapida che un server sia acceso e connesso in rete, indipendentemente dai servizi.

Performance di rete: tempi di risposta del Ping e packet loss indicano la salute della rete tra la location di monitoring e il target.

Baseline: complemento ai check HTTP/TCP, il Ping aiuta a distinguere «server irraggiungibile» da «server raggiungibile ma applicazione rotta».

Vantaggi

• Overhead minimo tra i protocolli di monitoring
• Testa il livello più fondamentale di connettività
• Utile per dispositivi senza servizi applicativi
• Aiuta a capire se il problema è di rete o applicazione

Limitazioni

• Testa solo raggiungibilità di rete — non salute applicativa
• Alcuni host e firewall bloccano ICMP, rendendo il Ping inaffidabile
• Gli ambienti cloud spesso non supportano ICMP verso certe risorse
• Non verifica che un servizio specifico sia in esecuzione

Esempi

| Target | Host | Scopo |
|--------|------|-------|
| VPN gateway | vpn.example.com | Accesso di rete |
| Router | 10.0.0.1 | Infrastruttura di rete |
| Server | web-1.internal | Raggiungibilità base |
| ISP hop | isp-gateway.net | Salute del percorso di rete |

Scegliere il protocollo giusto

Schema decisionale:

È un sito, un'app web o una REST API?
→ Usa monitoring HTTP. Testa lo stack completo e dà i dati più utili.

È un servizio su porta TCP che non parla HTTP?
→ Usa monitoring TCP. Database, mail, game server, servizi custom.

È un dispositivo di rete o ti serve solo la raggiungibilità base?
→ Usa monitoring Ping. Router, switch, gateway VPN, salute base del server.

Non sei sicuro?
→ Inizia con HTTP per tutto ciò che ha un URL, TCP per tutto ciò che ha una porta, Ping per l'infrastruttura.

Combinare i protocolli per copertura completa

Le migliori strategie usano più protocolli per coprire diversi modi di fallimento. Per uno stack web tipico:

| Component | Protocol | Check |
|-----------|----------|-------|
| Website | HTTP | https://example.com → 200 |
| API | HTTP | https://api.example.com/health → 200 |
| Database | TCP | db.internal:5432 |
| Redis cache | TCP | cache.internal:6379 |
| Server | Ping | web-1.internal |

Quando il check HTTP fallisce ma TCP e Ping passano, sai che il server è su e la porta aperta — il problema è nel codice applicativo. Quando tutto fallisce, è un problema a livello server o rete. Questo approccio a strati accelera la diagnosi.

Conclusione

Non esiste un unico «miglior» protocollo di monitoring — ognuno testa uno strato diverso. HTTP è il più completo per i servizi web, TCP copre i servizi non HTTP, Ping dà visibilità di base a livello di rete.

Per la maggior parte dei team la risposta è «usa tutti e tre sui target giusti». Inizia con HTTP per i servizi user-facing, aggiungi TCP per l'infrastruttura e Ping per la salute di rete.

Monitora ogni strato dello stack. Inizia gratis — HTTP, TCP e Ping monitoring in ogni piano.