# Fenstergröße SMPP: Warum Ihre Bindung langsamer ist als der bezahlte Tarif

> Ein Betreiber vereinbart 100 Nachrichten pro Sekunde, die Bind-Verbindung liefert zwölf, und alle geben dem Netzwerk die Schuld. In neun von zehn Fällen liegt die Ursache in einem Fenster mit Standardeinstellung. Hier erfahren Sie, was die Fensterung in einer SMPP-Sitzung tatsächlich bewirkt und wie Sie ihre Größe anpassen.

- Kanonische URL: https://www.broadnet.me/de/blog/smpp-window-size-throughput-tuning-2026
- Sprache: de
- Zuletzt aktualisiert: 2026-10-20
- Herausgeber: BroadNet (https://www.broadnet.me)

- Veröffentlicht: 2026-09-10
- Autor: BroadNet Engineering

Ein immer wiederkehrendes Muster: Ein Unternehmen bestellt 100 SMS pro Sekunde, richtet seine Anwendung auf die maximale Bandbreite aus und misst zwölf. Die Bandbreite ist ausreichend. Die Verbindung funktioniert einwandfrei. Niemand wurde gedrosselt. Der Datenverkehr kriecht einfach nur dahin, und der erste Gedanke ist immer, die Route zu bemängeln. Doch fast nie liegt es an der Route. Es ist das Zeitfenster.

SMPP ist ein asynchrones Protokoll, das bei den meisten Integrationen versehentlich synchron ausgeführt wird. Zu verstehen, warum, ist der Unterschied zwischen bezahltem Durchsatz und tatsächlichem Durchsatz.

## Was das Fenster tatsächlich ist

Das Zeitfenster gibt die Anzahl der PDUs an, die Sie zu einem beliebigen Zeitpunkt innerhalb einer einzigen Verbindung gesendet, aber noch nicht bestätigt bekommen haben. Senden Sie beispielsweise eine submit_sm-Nachricht, antwortet die SMSC-Nachricht mit submit_sm_resp – die SMPP-Nachricht erforderte jedoch nie, dass Sie auf diese Antwort warten, bevor Sie die nächste Nachricht senden konnten. Das Zeitfenster definiert, wie weit im Voraus Sie planen dürfen.

Bei einem Fenster von 1 senden Sie die Nachricht, warten, empfangen sie und senden sie erneut. Ihr Durchsatz ist nun durch die Round-Trip-Zeit begrenzt, nicht mehr durch vertraglich vereinbarte Bedingungen. Bei 40 ms Round-Trip-Zeit sind das 25 Nachrichten pro Sekunde – unabhängig von Ihrem Vertrag. Mit einem Fenster von 10 befinden sich zehn Nachrichten gleichzeitig in der Übertragung, und dieselbe Verbindung überträgt etwa das Zehnfache des Datenverkehrs.

> Die Fenstergröße ist der wichtigste Faktor für den Durchsatz einer Bindung und wird in Bibliotheken am häufigsten auf dem Standardwert belassen, was die Integration stillschweigend weit unter die vereinbarte Rate begrenzt.

## Warum verwenden so viele Bibliotheken standardmäßig einen einzigen Wert?

Ein Zeitfenster von 1 ist der sichere Standardwert für Bibliotheksautoren. Es benötigt keinen Korrelationsstatus, keine Timeout-Verwaltung und keine Neusortierung: Jede Anfrage hat genau eine ausstehende Antwort, sodass ein unerfahrener Client SMPP als Anfrage/Antwort behandeln kann und den Unterschied nicht bemerkt. Es funktioniert, ist leicht nachvollziehbar und langsam. Viele SMPP-Clientbibliotheken werden auf diese Weise ausgeliefert, und der Wert wird nie überprüft, da scheinbar nichts kaputt geht – die Nachrichten kommen an, nur nicht schnell.

## Sequenznummern sind es, die ein Fenster möglich machen

Jede SMPP-PDU enthält eine sequence_number-Nummer in ihrem 16-Byte-Header. Wenn mehrere Anfragen gleichzeitig gesendet werden, ist diese Nummer die einzige Verbindung zwischen jeder submit_sm_resp-Anfrage und der submit_sm-Anfrage, die sie ausgelöst hat. Da die Antworten nicht garantiert in der Reihenfolge des Sendens der Anfragen eintreffen, muss ein Client mit einem Fenster größer als 1 eine Liste der ausstehenden Sequenznummern führen und diese beim Eintreffen abgleichen.

Zwei Regeln sind wichtig. Verwenden Sie niemals eine Sequenznummer wieder, solange sie noch aktiv ist – eine verspätete Antwort auf eine wiederverwendete Nummer wird der falschen Nachricht zugeordnet. Und lassen Sie Einträge immer zeitlich begrenzt laufen: Wenn keine Antwort eintrifft, muss der Slot freigegeben werden, da das effektive Zeitfenster sonst im Laufe der Sitzung auf null schrumpft. Dies führt zu dem frustrierenden Problem einer Bindung, die zwar schnell beginnt, sich aber über Stunden immer weiter verschlechtert.

Sie können dies Feld für Feld in unserem [SMPP-Sitzungssimulator](https://www.broadnet.me/tools/smpp-simulator) verfolgen – es zeigt das sequence_number im Header jeder PDU an und welche Antwort auf welche Anfrage verweist.

## Fenstergröße und TPS sind unterschiedliche Grenzwerte.

Diese beiden Werte werden häufig verwechselt. TPS ist eine vom Betreiber festgelegte Ratenbegrenzung: Übermittlungen pro Sekunde, gemessen über einen bestimmten Zeitraum. Das Zeitfenster SMPP ist eine von Ihnen konfigurierte Begrenzung der gleichzeitigen Nutzung: Anzahl der aktuell ausstehenden PDUs. Sie beeinflussen sich gegenseitig, ihre Anzahl ist jedoch nicht identisch.

Die Beziehung ist grob gesagt: Erreichbare Transaktionen pro Sekunde (TPS) ≈ Fenstergröße ÷ Roundtrip-Zeit. Ein Fenster von 10 mit einer Roundtrip-Zeit von 50 ms ergibt etwa 200 TPS. Wenn der Anbieter die Anzahl auf 100 begrenzt, erreichen Sie diese Grenze und erhalten für den Überschuss ESME_RTHROTTLED. Wenn der Anbieter 500 zulässt und Ihr Fenster 10 beträgt, erreichen Sie niemals 500 TPS, egal wie viel Traffic Sie anbieten – Ihre Kapazität ist durch die Anzahl gleichzeitiger Transaktionen begrenzt, nicht durch die Datenrate.

| Fenster | Rundfahrt | Decke | Symptom |
|---|---|---|---|
| 1 | 40 ms | ~25 TPS | Der vereinbarte Preis wurde nie erreicht; die Verbindung scheint inaktiv zu sein. |
| 10 | 40 ms | ~250 TPS | Für die meisten Unternehmensabsender gesund |
| 50 | 40 ms | ~1.250 TPS | Nur wenn der Netzbetreiber zugestimmt hat; andernfalls ist mit Drosselung zu rechnen. |
| 10 | 250 ms | ~40 TPS | Latenzbedingt – Fenster vergrößern oder näher herangehen |

## ESME_RTHROTTLED korrekt lesen

ESME_RTHROTTLED (0x00000058) bedeutet, dass die vereinbarte Übermittlungsrate überschritten wurde. Es handelt sich weder um eine Ablehnung der Nachricht noch um einen Routingfehler. Die korrekte Vorgehensweise ist, einen Schritt zurückzutreten und die Nachricht erneut zu senden. Wird dies als endgültig behandelt, verwirft es den Datenverkehr stillschweigend, der vom Betreiber kurz darauf akzeptiert worden wäre.

Es signalisiert außerdem, dass Ihr Zeitfenster für die von Ihnen angestrebte Datenrate zu groß ist. Falls eine Vergrößerung des Zeitfensters zu einer Drosselung statt zu einer Steigerung des Durchsatzes geführt hat, hat sich die Einschränkung von der Parallelverarbeitung auf die Vertragsgestaltung verlagert, und die nächste Diskussion wird kommerzieller statt technischer Natur sein.

## enquire_link: Der andere Grund bindet den Tod

Eine Bindung, die keine Daten sendet, sieht genauso aus wie eine Bindung, deren TCP-Verbindung stillschweigend abgebrochen wurde – NAT-Timeouts und zustandsbehaftete Firewalls trennen inaktive Verbindungen, ohne die beiden Seiten zu benachrichtigen. enquire_link alle 30 bis 60 Sekunden beweist, dass der Socket in beide Richtungen noch nutzbar ist. Verpasst man das vom Operator erwartete Zeitfenster, wird die Verbindung durch SMSC getrennt, meist im ungünstigsten Moment.

Senden Sie enquire_link über dieselbe Verbindung, über die Sie die Anfrage gesendet haben, antworten Sie umgehend auf die Antwort enquire_link des Clients SMSC und behandeln Sie eine ausbleibende Antwort als abgebrochene Sitzung: unbind, stellen Sie die Verbindung wieder her und setzen Sie die Sitzung fort. Ein Client, der wiederholt Anfragen an eine halb geöffnete Verbindung sendet, verursacht den klassischen Vorfall, bei dem alles in Ordnung zu sein scheint, aber keine Daten übertragen werden.

## Wie man in der Praxis ein Fenster dimensioniert

1. Messen Sie die Laufzeit des Hin- und Rückwegs auf dem von Ihnen tatsächlich verwendeten Bind-Gerät, nicht auf Ihrem Laptop. Senden Sie eine einzelne Nachricht mit einem Zeitfenster von 1 Sekunde und dem Zeitraum submit_sm bis submit_sm_resp.
2. Teilen Sie Ihre vertraglich vereinbarte Transaktionsrate (TPS) durch die Anzahl der Nachrichten pro Sekunde, die ein Roundtrip ermöglicht. Dieser Quotient ist Ihr minimales Zeitfenster.
3. Planen Sie einen Spielraum ein – runden Sie auf und addieren Sie dann etwa 50 % –, da die Round-Trip-Zeit nicht konstant ist und ein Fenster, das genau auf den Mittelwert zugeschnitten ist, beim Median schlechter abschneidet.
4. Erhöhen Sie die Drehzahl schrittweise, nicht sprunghaft, und achten Sie auf ESME_RTHROTTLED. Die erste anhaltende Drosselung zeigt Ihnen, wo die tatsächliche Leistungsgrenze des Bedieners liegt.
5. Bitten Sie den Operator, den Wert zu bestätigen. Einige SMSC-Systeme erzwingen ein maximales Zeitfenster pro Bindung und führen bei Überschreitung dieses Fensters stillschweigend zu einer Warteschlangen- oder Verwerfungsvorgängen.
6. Erst dann sollte man eine zweite Bindung in Betracht ziehen. Mehrere Bindungen erhöhen zwar die Parallelität, aber auch die Anzahl der möglichen Fehlerquellen für eine Sitzung.

## Wenn mehr Bindungen ein größeres Fenster schlagen

Die Übertragungskapazität einer TCP-Verbindung ist begrenzt. Ab einigen hundert ausstehenden PDUs werden die Fehlerursachen gravierend: Ein einzelnes Socket-Problem führt zum Ausfall des gesamten Datenverkehrs, Head-of-Line-Blocking wird sichtbar, und die Wiederherstellung nach einem Verbindungsabbruch erfordert das erneute Abspielen eines großen, bereits übertragenen PDU-Satzes. Die meisten Betreiber bevorzugen mehrere moderate Bindungen gegenüber einer einzigen, extrem hohen, und die meisten werden Ihnen auf Nachfrage ihre bevorzugte Verbindungsstruktur nennen.

Die Aufteilung erfolgt nach Verkehrsklassen statt willkürlich. Durch die separate Speicherung zeitkritischer Einmalpasswörter und Massenmarketing-Daten wird verhindert, dass ein Marketing-Ansturm die Übermittlung eines Anmeldecodes verzögert – eine Entscheidung, die den Durchsatz und letztendlich das Produkt selbst betrifft.

## Eine Checkliste, bevor Sie die Route beschuldigen

- Welches Fenster ist konfiguriert, und wurde es von jemandem absichtlich so eingestellt?
- Sind die ausstehenden Sequenznummern abgelaufen und freigegeben worden?
- Läuft enquire_link in dem vom Betreiber erwarteten Intervall?
- Werden ESME_RTHROTTLED-Antworten mit Backoff wiederholt oder als Fehler gewertet?
- Entspricht die gemessene Umlaufzeit Ihren Annahmen bei der Dimensionierung des Fensters?
- Werden die Belege (deliver_sm) umgehend bestätigt – kann ein nicht bestätigter Belegstrom die Sitzung ebenfalls unterbrechen?

## Häufig gestellte Fragen

### Welche Fenstergröße (SMPP) ist empfehlenswert?

Es gibt keine allgemeingültige Zahl, da der optimale Wert von Ihrer Round-Trip-Time und Ihrem Vertragspreis abhängt. Ein praktischer Ausgangspunkt für Unternehmensdatenverkehr ist 10. Erhöhen Sie den Wert dann, bis Sie entweder Ihren vertraglich vereinbarten Transaktionswert pro Sekunde (TPS) erreichen oder Werte um ESME_RTHROTTLED erreichen. Die Berechnung nach der Formel „Vertrags-TPS × Round-Trip-Time“ plus ca. 50 % Puffer führt bei den meisten Integrationen bereits beim ersten Versuch zu einer guten Lösung.

### Erhöht ein größeres Fenster meinen Durchsatz unbegrenzt?

Nein. Sobald das Zeitfenster so groß ist, dass die Ratenbegrenzung des Betreibers erreicht ist, führen weitere Erhöhungen zu ESME_RTHROTTLED anstatt zu mehr Nachrichten. Das Zeitfenster beseitigt einen Engpass bei der gleichzeitigen Verarbeitung; es kann keine kommerzielle Obergrenze anheben.

### Warum verschlechtert sich mein Durchsatz erst über Stunden und nicht sofort?

Dies ist ein typisches Symptom für ausstehende Sequenznummern, deren Zeitlimit nie erreicht wird. Jede fehlende Antwort belegt dauerhaft einen Zeitfensterplatz, sodass das effektive Zeitfenster im Laufe der Sitzung immer kleiner wird, bis sich die Bindung so verhält, als ob das Zeitfenster 1 wäre. Das Freigeben von Zeitfensterplätzen bei einem Timeout behebt das Problem.

### Handelt es sich bei ESME_RTHROTTLED um einen endgültigen Ausfall?

Nein, und behandeln Sie es so, als ob Sie Traffic verlieren würden. Es bedeutet, dass Sie die vereinbarte Rate in diesem Moment überschritten haben. Reduzieren Sie die Geschwindigkeit, senden Sie dieselbe Nachricht erneut, und wenn die Drosselung anhält, verringern Sie das Zeitfenster oder verhandeln Sie die Rate neu.

### Wie oft soll ich enquire_link senden?

Ein Intervall von 30 bis 60 Sekunden ist üblich, und der genaue Wert sollte den Erwartungen des Betreibers entsprechen. Ziel ist es, sicherzustellen, dass eine möglicherweise inaktive TCP-Sitzung in beide Richtungen noch aktiv ist, bevor sie von einem NAT-Router oder einer Firewall stillschweigend getrennt wird.

### Soll ich eine große Bindung oder mehrere kleinere verwenden?

Mehrere moderate Verbindungen sind in der Regel besser als eine sehr große, da ein Socket-Fehler dann nur einen Bruchteil der Kapazität anstatt der gesamten Kapazität kostet. Die Aufteilung nach Verkehrsklassen – zeitkritische Passwörter getrennt von Massendaten – verhindert, dass ein Marketing-Ansturm die Übermittlung eines Anmeldecodes verzögert.

### Hat das Zeitfenster auch Auswirkungen auf Zustellberichte?

Ja, in umgekehrter Richtung. Der SMSC sendet Ihnen deliver_sm-Empfangsbestätigungen. Wenn Ihre Anwendung deliver_sm_resp nur langsam zurückgibt, staut sich der Empfangsbestätigungsstrom. Bei einer Transceiver-Bindung kann diese Überlastung die gesamte Sitzung beeinträchtigen. Bestätigen Sie daher Empfangsbestätigungen umgehend, auch wenn Sie diese asynchron verarbeiten.

### Wo kann ich dieses Verhalten beobachten, ohne eine Verbindung zu einem realen SMSC herzustellen?

Unser [SMPP-Sitzungssimulator](https://www.broadnet.me/tools/smpp-simulator) durchläuft eine vollständige SMPP 3.4-Sitzung im Browser – Bind, Submit, die asynchrone Zustellbestätigung, enquire_link und unbind – und zeigt die Felder jeder PDU den tatsächlichen Oktetten auf der Leitung zu. Es wird keine Verbindung hergestellt und es werden keine Daten gesendet.

## Die Kurzfassung

Wenn eine Bindung nicht die erwartete Leistung erbringt, überprüfen Sie das Zeitfenster, bevor Sie das Netzwerk prüfen. SMPP ist von Natur aus asynchron, wird aber in den meisten Integrationen versehentlich synchron ausgeführt. Bestimmen Sie die Größe des Zeitfensters anhand der gemessenen Roundtrip-Zeit und der vereinbarten Datenrate, setzen Sie die Sequenznummern auf ein Timeout, stellen Sie sicher, dass enquire_link korrekt ist, und versuchen Sie ESME_RTHROTTLED mit Backoff erneut. Diese Vorgehensweise behebt die meisten Durchsatzprobleme, ohne dass die Route geändert werden muss.