SMPP vs HTTP: quale connessione è adatta

Una sessione SMPP persistente a confronto con chiamate HTTP per singola richiesta: throughput, ricevute, callback e le modalità di errore che determinano la scelta.

Unicom Americas – Mobile Business team

practitioner · 4 min di lettura

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.

Dati essenziali

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.

In questa pagina

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

Entrambe le colonne trasportano gli stessi messaggi. Le righe sono gli elementi che cambiano quando si cambia trasporto.
Voce	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.

Pianificatore di throughput e campagne SMS

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

Converta un volume di messaggi e una finestra di invio nel throughput necessario, oppure un throughput nella durata della campagna.

tps: 50
windowMin: 60

Apra lo strumento

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

Ogni riga è un errore che si presenta in produzione, non un caso limite teorico.
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 tratta la sessione, e la guida alla connessione 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.

Verifichi ciò che ha imparato

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.

Le risposte vengono mostrate su richiesta. Nulla viene valutato, salvato o inviato.

Domande frequenti

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.

Fonti

Termini che incontrerà

Strumenti utilizzati

Decodificatore di codici SMPP e DLR

Incolli un command_status, i campi stat ed err di una notifica di consegna o una PDU esadecimale per capire cosa significano e cosa verificare dopo.