SMPP vs API HTTP SMSC: quale deve parlare la Sua piattaforma?

Quando collega una piattaforma di messaggistica al mondo esterno, in realtà sta scegliendo come questa dialoga con gli operatori, e le risposte diffuse sono due. Una è SMPP, il protocollo binario delle telecomunicazioni che da decenni trasporta gli SMS applicativi (A2P). L’altra è un’API HTTP, la stessa logica di richiesta e risposta che alimenta il resto del web. Non sono tanto rivali quanto strumenti per compiti diversi, e la conclusione onesta, verso cui questa guida conduce, è che qualsiasi cosa Lei possa definire una piattaforma seria finisce per parlarli entrambi. Ecco cosa li distingue davvero, e perché.

Cos’è SMPP, e perché gli operatori lo usano ancora

SMPP, ovvero Short Message Peer-to-Peer, è un protocollo binario parlato su una connessione TCP di lunga durata, per convenzione sulla porta 2775. Invece di aprire una connessione nuova per ogni messaggio, come fa una richiesta web, un client SMPP stabilisce una sessione persistente chiamata bind, in una di tre modalità: transmitter (solo invio), receiver (solo ricezione) o transceiver (entrambi su una connessione). Una volta stabilito il bind, invia in flusso pacchetti binari compatti chiamati PDU: un submit_sm per inviare un messaggio, un deliver_sm per riceverne uno o una ricevuta di consegna, un enquire_link come battito di heartbeat per tenere viva la sessione.

Il motivo per cui operatori e grandi aggregatori si standardizzano ancora su SMPP si riduce all’efficienza sui grandi volumi. Un bind persistente elimina l’overhead di apertura connessione per ogni messaggio, e SMPP supporta il windowing: chi invia può mettere più messaggi in transito prima di attendere gli acknowledgement, così un singolo bind in salute può sostenere da centinaia a qualche migliaio di messaggi al secondo. È inoltre progettato apposta per il dominio, con campi nativi per sender ID, codifica dei dati, periodi di validità, invio programmato e flag di consegna registrata. Quando il Suo traffico si misura in milioni di messaggi al giorno, quella densità e quel controllo non sono un lusso: sono la differenza tra un server e dieci.

Il prezzo di tanta potenza è la complessità. SMPP mantiene lo stato, quindi Lei deve gestire i bind, riconnettersi in caso di caduta, rispondere agli heartbeat, rispettare la finestra e correlare le ricevute asincrone tramite l’ID del messaggio. Tende inoltre a richiedere un rapporto di IP stabile, ed è per questo che i bind con gli operatori stanno spesso dietro una allowlist di IP o una piccola VPN, anziché sull’internet aperto.

Dove si collocano le API HTTP SMSC

Un’API HTTP compie lo scambio opposto. Lei invia una richiesta per messaggio (o per piccolo lotto) a un URL, riceve indietro una risposta JSON o form, e non c’è alcuna sessione da mantenere. L’autenticazione è un token o una chiave in un header, le ricevute di consegna tornano come callback webhook verso un URL che Lei ospita, e il tutto attraversa firewall e load balancer ordinari senza gestioni particolari. Per uno sviluppatore, cablare un fornitore HTTP è un pomeriggio; cablare uno stack SMPP è un progetto.

È esattamente questa semplicità ad aver moltiplicato i fornitori HTTP. Moltissimi provider regionali, aggregatori WhatsApp e RCS ed entranti CPaaS più recenti espongono prima l’HTTP e l’SMPP solo su richiesta, o non lo espongono affatto. Per volumi bassi e medi, o per un Paese che Lei raggiunge tramite un unico fornitore specializzato, una rotta HTTP non è un compromesso: è la scelta sensata. L’overhead per messaggio è più alto e il tetto grezzo di throughput è più basso di un bind SMPP ben regolato, ma lo si scala nel modo noioso, in orizzontale, facendo più richieste concorrenti; e per gran parte dei rivenditori quel tetto è ben oltre il traffico reale.

Il limite onesto è controllo e coerenza. Ogni fornitore HTTP inventa i propri nomi dei campi, il proprio modo di esprimere Unicode e messaggi lunghi, e il proprio formato di callback DLR. Parli con cinque fornitori HTTP e avrà, di fatto, integrato cinque prodotti leggermente diversi.

Le differenze reali: throughput, DLR e codifica

Sono tre i dettagli tecnici a causare quasi tutto il dolore concreto, quindi vale la pena essere precisi.

Throughput e controllo di flusso. Il throughput SMPP è governato dalla dimensione della finestra e dalla latenza di andata e ritorno: con una finestra di, diciamo, 10 PDU non riscontrate e un collegamento veloce, un bind spinge molto traffico, e gli operatori impongono una frequenza contrattuale che Lei non deve superare, pena lo throttling. Il throughput HTTP è governato da quante richieste concorrenti Lei effettua e dal limite di frequenza (rate limit) del fornitore, di solito espresso in richieste al secondo. La conseguenza pratica: SMPP premia un piccolo numero di connessioni persistenti ben gestite, mentre HTTP premia un pool di worker che effettuano chiamate in parallelo. Il progetto della coda e dei worker della Sua piattaforma cambia di conseguenza.

Ricevute di consegna. È qui che le integrazioni ingenue si rompono. In SMPP, il DLR non è una risposta al Suo submit; arriva più tardi, non sollecitato, come deliver_sm sul Suo bind, e Lei deve ricondurlo al messaggio originale tramite l’ID assegnato dall’operatore al momento dell’invio. Se Lei non è in ascolto, o perde il bind, perde le ricevute. In HTTP, il DLR è un callback che il fornitore invia in POST al Suo webhook, il che significa che il Suo endpoint deve essere raggiungibile, idempotente (i fornitori riprovano) e in grado di correlare sul Suo riferimento. Stesso concetto, consegnato, fallito, scaduto, rifiutato, sconosciuto, ma due meccanismi del tutto diversi da catturare in modo affidabile.

Codifica dei caratteri. L’SMS è implacabile qui. L’alfabeto GSM 03.38 fa entrare 160 caratteri in un singolo messaggio a 7 bit; esca da lì (un’emoji, molti caratteri accentati o non latini) e il messaggio passa a UCS-2, che ne contiene solo 70 per parte. I testi più lunghi vengono spezzati in segmenti cuciti con uno user-data header (UDH), e ogni segmento viene tariffato. SMPP espone tutto ciò direttamente tramite il campo data_coding e si aspetta che Lei faccia le cose per bene. I fornitori HTTP di solito provano ad astrarlo, ma lo fanno in modo incoerente, e un fornitore che declassa in silenzio un messaggio Unicode o conta male i segmenti Le costerà denaro senza dirlo o Le storpierà il testo. Quale che sia il protocollo, la codifica è qualcosa che la Sua piattaforma deve gestire deliberatamente, non sperare che il fornitore azzecchi.

Perché una piattaforma seria li parla entrambi

Metta insieme quelle differenze e la conclusione si scrive da sé. La Sua rotta migliore verso un Paese potrebbe essere un bind SMPP con un operatore nazionale; l’unica rotta verso il successivo potrebbe essere uno specialista HTTP; il failover per entrambi potrebbe essere un terzo fornitore, sul protocollo che gli capita di offrire. Se la Sua piattaforma sa parlarne uno solo, le Sue scelte di instradamento si dimezzano e le Sue trattative coi fornitori restano ostaggio di un limite tecnico, anziché guidate da prezzo e qualità di consegna.

Ecco perché un gateway maturo fa girare uno stack SMPP e un client HTTP fianco a fianco, e in genere espone entrambi anche ai propri clienti: un server SMPP a cui i clienti tecnici si legano, e un’API HTTP per tutti gli altri. Il vero valore della piattaforma non è nessuno dei due protocolli: è il livello sopra di essi, il motore di instradamento, la fatturazione, la normalizzazione delle ricevute di consegna, che rende invisibile la scelta del protocollo a chi invia un messaggio. Una piattaforma self-hosted come Smppcube offre sia un server SMPP di livello carrier sia un’API HTTP proprio perché sia l’operatore, non il protocollo, a decidere come scorre il traffico. Se sta valutando se gestire quello stack in proprio, la guida al gateway self-hosted copre il lato operativo.

Un unico adattatore generico per i fornitori HTTP (come funziona davvero)

La trappola dei fornitori HTTP, che ognuno è sottilmente diverso, è risolvibile, e la soluzione è un pattern che vale la pena capire prima di comprare o costruire. Anziché scrivere codice su misura per ogni fornitore, sparso per la codebase, Lei definisce una sola interfaccia interna, un’unica forma normalizzata per invia un messaggio ed ecco una ricevuta di consegna, e poi scrive un adattatore sottile per fornitore che traduce tra le stranezze del fornitore e quella forma interna.

Ogni adattatore possiede esattamente le differenze: come questo fornitore si autentica, come chiama i campi di destinazione e testo, come vuole che l’Unicode sia segnalato, e come interpretare il suo particolare callback DLR nell’insieme comune di stati della piattaforma. Tutto ciò che sta a monte, la coda, il router, la fatturazione, i report, parla solo con l’interfaccia interna e non sa né gli importa quale fornitore ci sia dietro. Integrare un nuovo fornitore HTTP diventa allora una configurazione e un piccolo adattatore, non una riscrittura; e aggiungere in seguito fornitori voce-via-API segue esattamente lo stesso pattern. È così che una piattaforma resta aperta a decine di fornitori regionali senza collassare sotto le loro incoerenze, ed è il progetto che un gateway self-hosted dovrebbe già implementare, così che Lei non tocchi mai il codice di protocollo per aggiungere una rotta.

Quale dovrebbe scegliere?

Se è un rivenditore che sta cablando il primo fornitore e questo offre HTTP, cominci da lì: è più rapido da integrare, facile da testare, e sufficiente a dimostrare il Suo business. Aggiunga SMPP quando il volume, un rapporto con un operatore, o un cliente tecnico che vuole legarsi a Lei rendono utile la macchina in più. Se è un aggregatore o un operatore che tratta volumi seri e accordi diretti con i carrier, SMPP non è opzionale: è la lingua che parlano i Suoi fornitori.

Il contrappunto onesto a tutto questo: non scelga affatto un protocollo, se può evitarlo. Scelga una piattaforma che già li parla entrambi e ne nasconde la differenza, così che le Sue energie vadano alla qualità delle rotte e ai clienti, anziché a mantenere uno stack di protocollo binario. È l’intero senso del comprare un gateway invece di costruirne uno, e può vedere dove si colloca un’opzione self-hosted, di proprietà piena, sulla pagina dei prezzi. Il protocollo dovrebbe essere un dettaglio che Lei configura, mai un muro contro cui costruisce il Suo business.