SMPP ou HTTP : quelle connexion choisir

Une session SMPP persistante face à des appels HTTP par requête : débit, accusés, callbacks et les modes de défaillance qui décident du choix.

Unicom Americas – Mobile Business équipe

practitioner · 4 min de lecture

SMPP tient une session persistante avec une fenêtre de débit par bind ; HTTP authentifie chaque requête et reçoit les événements sur un callback. Les deux transportent les mêmes messages et signalent les mêmes états de remise. Choisissez selon la forme du trafic et les pannes que votre équipe sait exploiter.

Faits clés

SMPP garde une session ouverte et porte une fenêtre de requêtes en cours par bind.
HTTP lance une requête authentifiée à chaque envoi et utilise un callback pour les accusés.
Les deux modèles renvoient les mêmes états de remise ; le transport change leur mode d’arrivée.
Les pannes diffèrent : fenêtre de bind pleine côté SMPP, callback lent côté HTTP.

Sur cette page

La décision en un paragraphe

Commencez par HTTP si le volume est faible, le trafic arrive par rafales et l’équipe exploite déjà des endpoints web. Passez à SMPP quand le trafic est un flux régulier, quand l’authentification et l’établissement de connexion à chaque requête ont un coût visible, ou quand les accusés doivent arriver par la même session transceiver que les envois. Beaucoup de plateformes utilisent les deux : SMPP pour le flux d’envoi et HTTP pour les callbacks entrants.

Le protocole n’est pas le produit. La route, l’enregistrement de l’expéditeur et les tests sur téléphone décident si un message arrive. SMPP et HTTP sont deux façons d’atteindre le même centre de messagerie, et l’une comme l’autre peut être bien ou mal exploitée.

La bonne question n’est pas quel protocole est le plus récent. C’est quelle panne votre équipe peut voir et corriger à la cadence du trafic. Un bind silencieux à deux heures du matin et un callback en échec à deux heures du matin sont tous deux des problèmes d’exploitation. Choisissez celui que vos outils savent diagnostiquer.

Le même travail, deux formes

Les deux colonnes transportent les mêmes messages. Les lignes sont les éléments qui changent quand vous changez de transport.
Élément	SMPP	HTTP
Session	Bind authentifié maintenu ouvert	Clé envoyée à chaque requête
Fenêtre	Fenêtre fixe de requêtes en cours par bind	Concurrence fixée par le client et le pool
Accusé de remise	PDU deliver_sm sur un bind transceiver (ou un receiver séparé)	Callback vers votre endpoint
Message entrant	deliver_sm sur un bind receiver ou transceiver	Callback vers votre endpoint
Reprise	Le client gère la fenêtre et le backoff	Le client répète la requête ; le fournisseur répète le callback

Le tableau décrit le transport, pas l’implémentation d’un fournisseur. Confirmez les détails à l’onboarding.

Le débit suit la forme

Un bind SMPP est provisionné avec un débit et une fenêtre. Une fois la session ouverte, un envoi coûte une PDU et une réponse, sans nouvelle poignée de main. SMPP est donc efficace pour un flux soutenu et prévisible pour dimensionner la capacité : comptez les binds, lisez l’allocation et gardez les requêtes en cours sous la fenêtre.

HTTP paie l’authentification et l’établissement de connexion à chaque requête, même si la réutilisation des connexions réduit le coût. La capacité vient de la concurrence, pas d’une fenêtre de bind : le client peut lancer une rafale puis heurter une limite de débit ou une file. Cette souplesse convient aux campagnes et aux applications à faible volume ; elle rend aussi le pic plus difficile à raisonner si le client ne plafonne pas la concurrence. Une limite de débit et une fenêtre sont deux contrôles différents : l’un plafonne les requêtes par seconde, l’autre les requêtes en cours. Le coût par requête se voit à fort volume, pas avec quelques milliers de messages par jour.

Planificateur de débit et de campagnes SMS

Changez le débit et la fenêtre ; le planificateur s’exécute dans le navigateur.

Convertissez un volume de messages et une plage d’envoi en débit nécessaire, ou un débit en durée de campagne.

tps: 50
windowMin: 60

Ouvrir l’outil

Les accusés et l’entrant décident de l’intégration

SMPP remet les accusés et les messages entrants sur un bind receiver ou transceiver. Le client doit garder la session en vie pour les recevoir, rapprocher chaque accusé du message ID conservé et répondre avec deliver_sm_resp. Il n’y a pas d’endpoint de callback à sécuriser, mais une session à surveiller : un bind ouvert et silencieux est un mode de défaillance.

HTTP remet les accusés et les messages entrants à une URL. Le récepteur vérifie la signature, répond vite et traite l’événement de façon asynchrone. Un callback lent est la panne courante : le fournisseur expire le délai, réessaie, et le même événement est traité deux fois. Les clés d’idempotence et un accusé rapide font partie de l’intégration, ce ne sont pas des optimisations.

Quel que soit le chemin de l’accusé, conservez la charge utile d’origine. L’interprétation du fournisseur peut changer, et un dossier de support repose souvent sur l’état ou le code d’erreur d’origine. Conservez-les avec le message ID, la route et l’heure.

Modes de défaillance à concevoir

Chaque ligne est une panne qui apparaît en production, pas un cas théorique.
Panne	Ce que l’on voit	Que faire
Fenêtre de bind pleine	Les timeouts et les reprises montent ensemble ; la file grandit	Arrêtez de réessayer, laissez la fenêtre se vider, ajoutez un bind
Session silencieuse	Le bind est ouvert mais aucune réponse n’arrive	Envoyez enquire_link, expirez la session, reconnectez avec backoff
Accusé mal rapproché	Les états sont attachés au mauvais message	Rapprochez par message ID, pas par ordre d’arrivée
Callback lent	Le fournisseur réessaie ; des doublons apparaissent	Répondez vite, traitez ensuite, utilisez une clé d’idempotence
Idempotence absente	Une reprise réseau crée deux messages	Portez une référence client et dédupliquez dessus
Dérive de codage	Un message long arrive en morceaux ou avec de mauvais caractères	Fixez GSM-7 ou UCS-2 volontairement et testez le nombre de segments

Les corrections sont opérationnelles. Aucun transport ne les supprime.

Choisir et intégrer

Choisissez SMPP quand le flux d’envoi est soutenu, que le fournisseur alloue une fenêtre que vous pouvez dimensionner et que l’équipe sait exploiter une session : gestion des binds, keep-alive, reconnexion et journaux au niveau PDU. Choisissez HTTP quand le volume est modéré, que l’équipe exploite déjà des endpoints web sécurisés et qu’un callback s’intègre à l’architecture. Choisissez les deux quand l’envoi et l’entrant ont des responsables différents.

Quel que soit le choix, demandez les mêmes preuves : une route de test, l’allocation de débit, le format de l’accusé, la liste des codes d’erreur et la politique de reprise. L’explication de SMPP couvre la session, et le guide de connexion couvre le chemin vers la production.

Écrivez le choix avec des chiffres : débit de pointe, fenêtre par bind, timeout du callback et budget de reprises. Une décision sans ces chiffres est une préférence. Revoyez-la quand le pic ou l’équipe change.

Vérifiez vos acquis

Une campagne tourne à 40 messages par seconde de façon régulière et les accusés doivent arriver sur la même session transceiver. Quel transport convient ?

SMPP avec un bind transceiver, assez de binds et une fenêtre dimensionnée pour le débit. HTTP peut porter le volume, mais les accusés arrivent sur un callback, pas sur la session SMPP.
L’endpoint de callback met huit secondes à répondre. Que se passe-t-il ?

Le fournisseur expire le délai et réessaie, donc le même événement est livré à nouveau. Répondez vite et traitez après la réponse.
Pourquoi un bind silencieux est-il plus difficile qu’un bind tombé ?

Un bind tombé échoue de façon visible. Un bind silencieux paraît ouvert, donc le client continue d’envoyer jusqu’à ce qu’un timeout le révèle. Le keep-alive le trouve plus tôt.

Les réponses s’affichent sur demande. Rien n’est noté, stocké ni envoyé.

Questions fréquentes

Peut-on utiliser les deux ?

Oui. Beaucoup de plateformes envoient par SMPP et reçoivent des callbacks HTTP pendant la migration.

Lequel est plus rapide à intégrer ?

HTTP, souvent en une après-midi ; SMPP devient rentable quand le volume justifie une session persistante.

Lequel est plus fiable ?

Aucun ne l’est par lui-même. La fiabilité vient de la route, de la politique de reprise et de l’exploitation autour.

HTTP peut-il tenir un fort volume ?

Oui, avec de la concurrence, un pool de connexions et des callbacks asynchrones. SMPP est généralement plus efficace pour un flux soutenu, parce que la session et le canal des accusés sont déjà ouverts.

Faut-il une IP fixe ?

Souvent oui pour SMPP, car le fournisseur autorise l’IP du client. Les intégrations HTTP s’appuient plutôt sur TLS et une clé. Confirmez l’exigence avant de construire.

Sources

Termes rencontrés

Outils utilisés

Décodeur SMPP et DLR

Collez un command_status, les champs stat et err d’un accusé de réception ou une PDU hexadécimale pour savoir ce qu’ils signifient et quoi vérifier.