# SMPP vs HTTP: quale connessione è adatta

SMPP mantiene una sessione persistente con una finestra di throughput per ogni bind; HTTP autentica ogni richiesta e riceve gli eventi su un callback. Entrambi trasportano gli stessi messaggi e riportano gli stessi stati di consegna. La scelta dipende dalla forma del traffico e dagli errori che il team è in grado di gestire.

- SMPP mantiene aperta una sola sessione e gestisce una finestra di richieste in transito per ogni bind.

- HTTP avvia una nuova richiesta autenticata per ogni invio e utilizza un callback per le ricevute.

- Entrambi i modelli restituiscono gli stessi stati di consegna; il trasporto cambia il modo in cui arrivano.

- Le modalità di errore sono diverse: una finestra di bind piena in SMPP, un callback lento in HTTP.

## La decisione in un paragrafo

Si parte da HTTP se il volume è ridotto, il traffico arriva a picchi e il team gestisce già endpoint web. Si passa a SMPP quando il traffico è un flusso costante, quando l’autenticazione per singola richiesta e l’apertura della connessione diventano un costo visibile, oppure quando le ricevute devono arrivare sulla stessa sessione transceiver degli invii. Molte piattaforme usano entrambi: SMPP per il flusso di invio e HTTP per i callback in entrata.
Il protocollo non è il prodotto. Sono la rotta, la registrazione del mittente e i controlli sul terminale a decidere se un messaggio arriva. SMPP e HTTP sono due modi per raggiungere lo stesso centro messaggi, ed entrambi possono essere gestiti bene o male.
La domanda giusta non è quale protocollo sia più recente, ma quale errore il team è in grado di vedere e correggere al ritmo prodotto dal traffico. Un bind silenzioso alle due di notte e un callback che fallisce alle due di notte sono entrambi problemi operativi. Scelga quello che i suoi strumenti sono in grado di diagnosticare.

### Lo stesso lavoro, due forme

|  | SMPP | HTTP |
| --- | --- | --- |
| Sessione | Bind autenticato mantenuto aperto | Chiave inviata con ogni richiesta |
| Finestra | Finestra fissa di richieste in transito per bind | Concorrenza impostata dal client e dal pool |
| Ricevuta di consegna | PDU deliver_sm su un bind transceiver (o receiver separato) | Callback verso il suo endpoint |
| Messaggio in entrata | deliver_sm su un bind receiver o transceiver | Callback verso il suo endpoint |
| Ritrasmissione | Il client gestisce la finestra e il backoff | Il client ritrasmette la richiesta; il fornitore ritrasmette il callback |

La tabella descrive il trasporto, non l’implementazione di un fornitore. Verifichi i dettagli in fase di onboarding.

## Il throughput segue la forma

Un bind SMPP viene configurato per un tasso di throughput e una finestra. Una volta aperta la sessione, un invio costa una PDU e una risposta, senza un nuovo handshake. Questo rende SMPP efficiente per un flusso continuo e prevedibile per la pianificazione della capacità: si contano i bind, si legge l’allocazione e si mantengono le richieste in transito al di sotto della finestra.
HTTP paga l’autenticazione e l’apertura della connessione a ogni richiesta, anche se il riutilizzo delle connessioni ne riduce il costo. La capacità deriva dalla concorrenza, non da una finestra di bind, quindi il client può generare rapidamente un picco e poi incontrare un limite di frequenza o una coda. Questa flessibilità si adatta alle campagne e alle applicazioni a basso volume; rende però il picco più difficile da valutare, a meno che il client non limiti la concorrenza. Un limite di frequenza e una finestra sono controlli diversi: il primo limita le richieste al secondo, la seconda limita le richieste in transito. Il costo per singola richiesta diventa visibile ad alto volume, non con poche migliaia di messaggi al giorno.

Modifichi il tasso e la finestra; il pianificatore funziona nel browser.

[Open the tool](/it/tools/tps-planner/?src=learn-smpp-vs-http&scenario=campaign-50tps&tps=50&windowMin=60)

## Ricevute e messaggi in entrata determinano l’integrazione

SMPP consegna ricevute e messaggi in entrata sulla sessione aperta. Per riceverli, il client deve mantenere attiva la sessione, associare ogni ricevuta all’ID del messaggio memorizzato e rispondere con deliver_sm_resp. Non c’è un endpoint di callback da proteggere, ma c’è una sessione da controllare: un bind aperto ma silenzioso è una modalità di errore.
HTTP consegna ricevute e messaggi in entrata a un URL. Il destinatario verifica la firma, risponde rapidamente ed elabora l’evento in modo asincrono. Un callback lento è l’errore più comune: il fornitore va in timeout, ritrasmette e lo stesso evento viene elaborato due volte. Le chiavi di idempotenza e una conferma rapida fanno parte dell’integrazione, non sono un’ottimizzazione.
Qualunque sia il percorso che trasporta la ricevuta, conservi il payload originale. L’interpretazione del fornitore può cambiare, e una richiesta di assistenza dipende spesso dallo stato o dal codice di errore originale. Lo memorizzi insieme all’ID del messaggio, alla rotta e all’orario.

### Modalità di errore da prevedere in fase di progettazione

| Errore | Come si presenta | Che cosa fare |
| --- | --- | --- |
| Finestra di bind piena | Timeout e ritrasmissioni aumentano insieme; la coda cresce | Interrompere le ritrasmissioni, lasciare svuotare la finestra, aggiungere un bind |
| Sessione silenziosa | Il bind è aperto ma non arriva alcuna risposta | Inviare enquire_link, chiudere la sessione per timeout, riconnettersi con backoff |
| Ricevuta non associata correttamente | Gli stati vengono attribuiti al messaggio sbagliato | Associare in base all’ID del messaggio, non all’ordine di arrivo |
| Callback lento | Il fornitore ritrasmette; compaiono duplicati | Confermare rapidamente, elaborare in modo asincrono, usare una chiave di idempotenza |
| Idempotenza assente | Una ritrasmissione di rete crea due messaggi | Includere un riferimento del client e deduplicare in base a esso |
| Deriva della codifica | Un messaggio lungo arriva a pezzi o con caratteri errati | Impostare GSM-7 o UCS-2 in modo esplicito e verificare il numero di segmenti |

Le correzioni sono operative. Nessun trasporto ne elimina la necessità.

## Scelta e integrazione

Scelga SMPP quando il flusso di invio è continuo, il fornitore assegna una finestra che è possibile dimensionare e il team è in grado di gestire una sessione: gestione dei bind, keep-alive, riconnessione e log a livello di PDU. Scelga HTTP quando il volume è contenuto, il team gestisce già endpoint web sicuri e un callback si adatta all’architettura. Scelga entrambi quando il percorso di invio e quello in entrata hanno responsabili diversi.
Qualunque sia la scelta, chieda le stesse evidenze: una rotta di test, l’allocazione di throughput, il formato delle ricevute, l’elenco dei codici di errore e la policy di ritrasmissione. La [guida introduttiva a SMPP](/it/resources/learn/what-is-smpp/) tratta la sessione, e la [guida alla connessione](/it/resources/guides/smpp-http-connection/) tratta il percorso verso la produzione.
Metta la scelta per iscritto con i numeri: tasso di picco, finestra per bind, timeout del callback e budget di ritrasmissione. Una decisione senza questi numeri è una preferenza. La riesamini quando cambiano il picco o il team.

### Check what you learned

**Una campagna viaggia a un ritmo costante di 40 messaggi al secondo e le ricevute devono arrivare sulla stessa sessione transceiver. Quale trasporto è adatto?**

SMPP con un bind transceiver, un numero sufficiente di bind e una finestra dimensionata per il tasso. HTTP può gestire il volume, ma le ricevute arrivano su un callback, non sulla sessione SMPP.

**L’endpoint di callback impiega otto secondi a rispondere. Che cosa va storto?**

Il fornitore va in timeout e ritrasmette, quindi lo stesso evento viene consegnato di nuovo. Risponda rapidamente ed elabori l’evento dopo la risposta.

**Perché un bind silenzioso è più difficile da gestire di un bind caduto?**

Un bind caduto fallisce in modo visibile. Un bind silenzioso sembra aperto, quindi il client continua a inviare finché un timeout non lo rivela. Il traffico di keep-alive lo individua prima.

## FAQ

**Possiamo usare entrambi?**

Sì. Molte piattaforme inviano tramite SMPP e ricevono i callback tramite HTTP durante la migrazione.

**Quale si integra più rapidamente?**

HTTP, di solito in un pomeriggio; SMPP ripaga quando il volume giustifica una sessione persistente.

**Quale è più affidabile?**

Nessuno dei due è affidabile di per sé. L’affidabilità deriva dalla rotta, dalla policy di ritrasmissione e dalla gestione operativa che li circonda.

**HTTP può gestire volumi elevati?**

Sì, con concorrenza, pool di connessioni e callback asincroni. SMPP è di solito più efficiente per un flusso continuo, perché la sessione e il canale delle ricevute sono già aperti.

**Serve un IP statico?**

Spesso sì per SMPP, perché il fornitore inserisce l’indirizzo del client in una allowlist. Le integrazioni HTTP di solito si basano invece su TLS e su una chiave. Verifichi il requisito prima di sviluppare.

## Sources

- [smpp.org: sessioni SMPP, operazioni PDU e ricevute di consegna](https://smpp.org/) — Accessed: 2026-10-19
- [IETF RFC 9110: HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) — Accessed: 2026-10-19
- [3GPP TS 23.040: realizzazione tecnica dello Short Message Service](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19