# SMPP vs. HTTP: welche Anbindung passt

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.

- 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.

## 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

|  | 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.

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

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

## 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

| 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](/de/resources/learn/what-is-smpp/) behandelt die Session, der [Leitfaden zur Anbindung](/de/resources/guides/smpp-http-connection/) 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.

### Check what you learned

**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.

## 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.

## Sources

- [smpp.org: SMPP-Sessions, PDU-Operationen und Zustellberichte](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: Technische Realisierung des Short Message Service](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19