SMPP vs. HTTP: welche Anbindung passt

Eine dauerhafte SMPP-Session gegenüber HTTP-Aufrufen pro Anfrage: Durchsatz, Zustellberichte, Callbacks und die Fehlerbilder, die die Wahl entscheiden.

Unicom Americas – Mobile Business Team

practitioner · 4 Min. Lesezeit

SMPP hält eine dauerhafte Session mit einem Durchsatzfenster pro Bind; HTTP authentifiziert jede Anfrage und empfängt Ereignisse über einen Callback. Beide transportieren dieselben Nachrichten und melden dieselben Zustellstatus. Entscheiden Sie nach der Form Ihres Verkehrs und nach den Fehlern, die Ihr Team im Betrieb beherrscht.

Eckdaten

SMPP hält eine Session offen und führt pro Bind ein Fenster laufender Anfragen.
HTTP startet für jeden Versand eine neue authentifizierte Anfrage und nutzt einen Callback für Zustellberichte.
Beide Modelle liefern dieselben Zustellstatus; der Transport ändert nur, wie sie ankommen.
Die Fehlerbilder unterscheiden sich: ein volles Bind-Fenster bei SMPP, ein langsamer Callback bei HTTP.

Auf dieser Seite

Die Entscheidung in einem Absatz

Beginnen Sie mit HTTP, wenn das Volumen gering ist, der Verkehr in Spitzen kommt und das Team bereits Web-Endpunkte betreibt. Wechseln Sie zu SMPP, wenn der Verkehr ein gleichmäßiger Strom ist, wenn Authentifizierung und Verbindungsaufbau pro Anfrage zu sichtbaren Kosten werden oder wenn Zustellberichte in derselben Transceiver-Session ankommen müssen wie die Sendungen. Viele Plattformen betreiben beides: SMPP für den Sendestrom und HTTP für eingehende Callbacks.

Das Protokoll ist nicht das Produkt. Die Route, die Registrierung des Absenders und die Prüfungen auf dem Endgerät entscheiden, ob eine Nachricht ankommt. SMPP und HTTP sind zwei Wege zum selben Nachrichtenzentrum, und beide lassen sich gut oder schlecht betreiben.

Die richtige Frage ist nicht, welches Protokoll neuer ist. Sie lautet, welchen Fehler Ihr Team in dem Tempo erkennen und beheben kann, in dem der Verkehr ihn erzeugt. Ein stummer Bind um zwei Uhr nachts und ein fehlschlagender Callback um zwei Uhr nachts sind beides Betriebsprobleme. Wählen Sie das, was Ihre Werkzeuge diagnostizieren können.

Dieselbe Aufgabe, zwei Formen

Beide Spalten transportieren dieselben Nachrichten. Die Zeilen zeigen, was sich beim Wechsel des Transports ändert.
Element	SMPP	HTTP
Session	Authentifizierter Bind, der offen gehalten wird	Schlüssel wird mit jeder Anfrage gesendet
Fenster	Festes Fenster laufender Anfragen pro Bind	Parallelität wird von Client und Pool festgelegt
Zustellbericht	deliver_sm-PDU über einen Transceiver-Bind (oder einen separaten Receiver-Bind)	Callback an Ihren Endpunkt
Eingehende Nachricht	deliver_sm über einen Receiver- oder Transceiver-Bind	Callback an Ihren Endpunkt
Wiederholung	Der Client steuert Fenster und Backoff	Der Client wiederholt die Anfrage; der Anbieter wiederholt den Callback

Die Tabelle beschreibt den Transport, nicht die Umsetzung eines bestimmten Anbieters. Klären Sie die Details im Onboarding.

Der Durchsatz folgt der Form

Ein SMPP-Bind wird für eine Durchsatzrate und ein Fenster eingerichtet. Ist die Session offen, kostet ein Submit eine PDU und eine Antwort, ohne neuen Handshake. Dadurch ist SMPP für einen anhaltenden Strom effizient und für die Kapazitätsplanung berechenbar: Binds zählen, die Zuteilung ablesen und die laufenden Anfragen unter dem Fenster halten.

HTTP zahlt bei jeder Anfrage für Authentifizierung und Verbindungsaufbau, auch wenn die Wiederverwendung von Verbindungen die Kosten senkt. Die Kapazität ergibt sich aus der Parallelität, nicht aus einem Bind-Fenster. Der Client kann daher schnell in Spitzen senden und dann auf ein Ratenlimit oder eine Warteschlange stoßen. Diese Flexibilität passt zu Kampagnen und Anwendungen mit geringem Volumen; sie macht die Spitzenlast aber schwerer kalkulierbar, solange der Client die Parallelität nicht begrenzt. Ein Ratenlimit und ein Fenster sind unterschiedliche Steuergrößen: Das eine begrenzt die Anfragen pro Sekunde, das andere die gleichzeitig laufenden Anfragen. Die Kosten pro Anfrage werden bei hohem Volumen sichtbar, nicht bei einigen tausend Nachrichten pro Tag.

Planer für SMS-Durchsatz und Kampagnen

Ändern Sie Rate und Fenster; der Planer läuft im Browser.

Rechnen Sie ein Nachrichtenvolumen und ein Versandfenster in den benötigten Durchsatz um, oder einen Durchsatz in die Kampagnendauer.

tps: 50
windowMin: 60

Tool öffnen

Zustellberichte und eingehende Nachrichten bestimmen die Integration

SMPP liefert Zustellberichte und eingehende Nachrichten über die offene Session. Der Client muss die Session aufrechterhalten, um sie zu empfangen, jeden Zustellbericht der gespeicherten Message-ID zuordnen und mit deliver_sm_resp antworten. Es gibt keinen Callback-Endpunkt, den man absichern muss, aber eine Session, die Sie im Blick behalten müssen: Ein Bind, der offen, aber stumm ist, ist ein Fehlerbild.

HTTP liefert Zustellberichte und eingehende Nachrichten an eine URL. Der Empfänger prüft die Signatur, antwortet schnell und verarbeitet das Ereignis asynchron. Ein langsamer Callback ist der häufigste Fehler: Der Anbieter läuft in ein Timeout, wiederholt den Aufruf, und dasselbe Ereignis wird zweimal verarbeitet. Idempotenzschlüssel und eine schnelle Bestätigung gehören zur Integration und sind keine Optimierung.

Gleich auf welchem Weg der Zustellbericht kommt: Bewahren Sie die Rohdaten auf. Die Interpretation des Anbieters kann sich ändern, und ein Supportfall hängt oft am ursprünglichen Status oder Fehlercode. Speichern Sie sie mit der Message-ID, der Route und dem Zeitpunkt.

Fehlerbilder, die Sie einplanen sollten

Jede Zeile ist ein Fehler, der im Produktivbetrieb auftritt, kein theoretischer Grenzfall.
Fehler	Woran man ihn erkennt	Was zu tun ist
Volles Bind-Fenster	Timeouts und Wiederholungen steigen gemeinsam; die Warteschlange wächst	Wiederholungen stoppen, das Fenster leerlaufen lassen, einen Bind hinzufügen
Stumme Session	Der Bind ist offen, aber keine Antwort kommt an	enquire_link senden, die Session per Timeout beenden, mit Backoff neu verbinden
Falsch zugeordneter Zustellbericht	Status werden der falschen Nachricht zugeordnet	Nach Message-ID zuordnen, nicht nach Eingangsreihenfolge
Langsamer Callback	Der Anbieter wiederholt; Duplikate entstehen	Schnell bestätigen, asynchron verarbeiten, einen Idempotenzschlüssel verwenden
Fehlende Idempotenz	Eine Wiederholung im Netz erzeugt zwei Nachrichten	Eine Client-Referenz mitführen und darüber deduplizieren
Abweichende Kodierung	Eine lange Nachricht kommt in Teilen oder mit falschen Zeichen an	GSM-7 oder UCS-2 bewusst festlegen und die Segmentanzahl testen

Die Abhilfen sind betrieblich. Kein Transport macht sie überflüssig.

Auswahl und Integration

Wählen Sie SMPP, wenn der Sendestrom anhaltend ist, der Anbieter ein Fenster zuteilt, das Sie dimensionieren können, und das Team eine Session betreiben kann: Bind-Verwaltung, Keep-alive, Wiederverbindung und Logs auf PDU-Ebene. Wählen Sie HTTP, wenn das Volumen moderat ist, das Team bereits sichere Web-Endpunkte betreibt und ein Callback zur Architektur passt. Wählen Sie beides, wenn Sendepfad und Eingangspfad unterschiedliche Verantwortliche haben.

Gleich wofür Sie sich entscheiden, verlangen Sie dieselben Nachweise: eine Testroute, die Durchsatzzuteilung, das Format der Zustellberichte, die Liste der Fehlercodes und die Wiederholungsrichtlinie. Die SMPP-Erklärung behandelt die Session, der Leitfaden zur Anbindung den Weg in den Produktivbetrieb.

Halten Sie die Entscheidung mit den Zahlen fest: Spitzenrate, Fenster pro Bind, Callback-Timeout und Wiederholungsbudget. Eine Entscheidung ohne diese Zahlen ist eine Vorliebe. Überprüfen Sie sie, wenn sich die Spitzenlast oder das Team ändert.

Prüfen Sie Ihr Wissen

Eine Kampagne läuft gleichmäßig mit 40 Nachrichten pro Sekunde, und die Zustellberichte müssen in derselben Transceiver-Session ankommen. Welcher Transport passt?

SMPP mit einem Transceiver-Bind, genügend Binds und einem auf die Rate dimensionierten Fenster. HTTP kann das Volumen tragen, aber die Zustellberichte kommen über einen Callback an, nicht in der SMPP-Session.
Der Callback-Endpunkt braucht acht Sekunden für die Antwort. Was geht schief?

Der Anbieter läuft in ein Timeout und wiederholt den Aufruf, sodass dasselbe Ereignis erneut zugestellt wird. Antworten Sie schnell und verarbeiten Sie das Ereignis nach der Antwort.
Warum ist ein stummer Bind schwieriger als ein abgebrochener Bind?

Ein abgebrochener Bind fällt sichtbar aus. Ein stummer Bind wirkt offen, daher sendet der Client weiter, bis ein Timeout ihn aufdeckt. Keep-alive-Verkehr findet ihn früher.

Antworten werden auf Wunsch angezeigt. Nichts wird bewertet, gespeichert oder gesendet.

FAQ

Können wir beides betreiben?

Ja. Viele Plattformen senden während einer Migration über SMPP und empfangen Callbacks über HTTP.

Was lässt sich schneller integrieren?

HTTP, meist an einem Nachmittag; SMPP lohnt sich, sobald das Volumen eine dauerhafte Session rechtfertigt.

Was ist zuverlässiger?

Keines von beiden ist für sich allein zuverlässig. Zuverlässigkeit entsteht durch die Route, die Wiederholungsrichtlinie und den Betrieb drumherum.

Kann HTTP hohes Volumen bewältigen?

Ja, mit Parallelität, Connection-Pooling und asynchronen Callbacks. SMPP ist für einen anhaltenden Strom meist effizienter, weil die Session und der Kanal für Zustellberichte bereits offen sind.

Brauchen wir eine statische IP-Adresse?

Bei SMPP oft ja, weil der Anbieter die Client-Adresse auf eine Allowlist setzt. HTTP-Integrationen setzen stattdessen meist auf TLS und einen Schlüssel. Klären Sie die Anforderung, bevor Sie mit der Umsetzung beginnen.

Quellen

Begriffe, die Ihnen begegnen

Verwendete Tools

Decoder für SMPP- und DLR-Codes

Fügen Sie einen command_status, die Felder stat und err eines Zustellberichts oder eine Hex-PDU ein, um zu sehen, was sie bedeuten und was als Nächstes zu prüfen ist.