# SMPP frente a HTTP: qué conexión encaja

SMPP mantiene una sesión persistente con una ventana de caudal por bind; HTTP autentica cada petición y recibe los eventos en un callback. Ambos transportan los mismos mensajes e informan los mismos estados de entrega. Elija por la forma del tráfico y por los fallos que su equipo sabe operar.

- SMPP mantiene una sesión abierta y lleva una ventana de peticiones en vuelo por bind.

- HTTP inicia una petición autenticada por cada envío y usa un callback para los acuses.

- Ambos modelos devuelven los mismos estados de entrega; el transporte cambia cómo llegan.

- Los fallos difieren: una ventana de bind llena en SMPP, un callback lento en HTTP.

## La decisión en un párrafo

Empiece con HTTP si el volumen es bajo, el tráfico va a ráfagas y el equipo ya opera endpoints web. Pase a SMPP cuando el tráfico sea un flujo constante, cuando la autenticación y el establecimiento de conexión por petición tengan un coste visible, o cuando los acuses deban llegar por la misma sesión transceptor que los envíos. Muchas plataformas usan ambos: SMPP para el flujo de envío y HTTP para los callbacks entrantes.
El protocolo no es el producto. La ruta, el registro del remitente y las pruebas en teléfonos deciden si un mensaje llega. SMPP y HTTP son dos formas de alcanzar el mismo centro de mensajes, y cualquiera de las dos se puede operar bien o mal.
La pregunta correcta no es qué protocolo es más nuevo. Es qué fallo puede ver y corregir su equipo a la velocidad que produce el tráfico. Un bind silencioso a las dos de la madrugada y un callback que falla a las dos de la madrugada son problemas operativos. Elija el que sus herramientas sepan diagnosticar.

### El mismo trabajo, dos formas

|  | SMPP | HTTP |
| --- | --- | --- |
| Sesión | Bind autenticado que se mantiene abierto | Clave enviada en cada petición |
| Ventana | Ventana fija de peticiones en vuelo por bind | Concurrencia fijada por el cliente y el pool |
| Acuse de entrega | PDU deliver_sm en un bind transceptor (o un receptor aparte) | Callback a su endpoint |
| Mensaje entrante | deliver_sm en un bind receptor o transceptor | Callback a su endpoint |
| Reintento | El cliente gestiona la ventana y el backoff | El cliente reintenta la petición; el proveedor reintenta el callback |

La tabla describe el transporte, no la implementación de un proveedor. Confirme los detalles en el onboarding.

## El caudal sigue a la forma

Un bind SMPP se aprovisiona con una tasa de caudal y una ventana. Con la sesión abierta, un envío cuesta una PDU y una respuesta, sin un nuevo handshake. Eso hace que SMPP sea eficiente para un flujo sostenido y predecible para planificar capacidad: cuente los binds, lea la asignación y mantenga las peticiones en vuelo por debajo de la ventana.
HTTP paga la autenticación y el establecimiento de conexión en cada petición, aunque la reutilización de conexiones reduce el coste. La capacidad viene de la concurrencia, no de una ventana de bind, así que el cliente puede hacer una ráfaga y luego chocar con un límite de tasa o una cola. Esa flexibilidad encaja con campañas y aplicaciones de bajo volumen; también hace que el pico sea más difícil de razonar si el cliente no limita la concurrencia. Un límite de tasa y una ventana son controles distintos: uno limita peticiones por segundo, el otro peticiones en vuelo. El coste por petición se nota a volumen alto, no con unos miles de mensajes al día.

Cambie la tasa y la ventana; el planificador se ejecuta en el navegador.

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

## Los acuses y el entrante deciden la integración

SMPP entrega los acuses y los mensajes entrantes por un bind receptor o transceptor. El cliente debe mantener viva la sesión para recibirlos, emparejar cada acuse con el message ID guardado y responder con deliver_sm_resp. No hay un endpoint de callback que asegurar, pero sí una sesión que vigilar: un bind abierto y silencioso es un modo de fallo.
HTTP entrega los acuses y los mensajes entrantes a una URL. El receptor verifica la firma, responde rápido y procesa el evento de forma asíncrona. Un callback lento es el fallo habitual: el proveedor agota el tiempo, reintenta y el mismo evento se procesa dos veces. Las claves de idempotencia y un acuse rápido forman parte de la integración, no son una optimización.
Sea cual sea el camino del acuse, guarde el payload original. La interpretación del proveedor puede cambiar, y un caso de soporte a menudo depende del estado o del código de error original. Guárdelo con el message ID, la ruta y la hora.

### Modos de fallo que hay que diseñar

| Fallo | Cómo se ve | Qué hacer |
| --- | --- | --- |
| Ventana de bind llena | Los timeouts y los reintentos suben juntos; la cola crece | Deje de reintentar, deje que la ventana se vacíe, añada un bind |
| Sesión silenciosa | El bind está abierto pero no llega respuesta | Envíe enquire_link, agote el tiempo, reconecte con backoff |
| Acuse mal emparejado | Los estados se asignan al mensaje equivocado | Empareje por message ID, no por orden de llegada |
| Callback lento | El proveedor reintenta; aparecen duplicados | Responda rápido, procese después, use una clave de idempotencia |
| Falta de idempotencia | Un reintento de red crea dos mensajes | Lleve una referencia de cliente y deduplique por ella |
| Desvío de codificación | Un mensaje largo llega en trozos o con caracteres erróneos | Fije GSM-7 o UCS-2 a propósito y pruebe el número de segmentos |

Las soluciones son operativas. Ningún transporte las elimina.

## Elegir e integrar

Elija SMPP cuando el flujo de envío sea sostenido, el proveedor asigne una ventana que usted pueda dimensionar y el equipo sepa operar una sesión: gestión de binds, keep-alive, reconexión y registros a nivel de PDU. Elija HTTP cuando el volumen sea moderado, el equipo ya opere endpoints web seguros y un callback encaje en la arquitectura. Elija ambos cuando el envío y el entrante tengan responsables distintos.
Elija lo que elija, pida la misma evidencia: una ruta de prueba, la asignación de caudal, el formato del acuse, la lista de códigos de error y la política de reintentos. La [explicación de SMPP](/es/resources/learn/what-is-smpp/) cubre la sesión, y la [guía de conexión](/es/resources/guides/smpp-http-connection/) cubre el camino a producción.
Escriba la elección con números: tasa de pico, ventana por bind, timeout del callback y presupuesto de reintentos. Una decisión sin esos números es una preferencia. Revísela cuando cambie el pico o el equipo.

### Check what you learned

**Una campaña va a 40 mensajes por segundo de forma constante y los acuses deben llegar por la misma sesión transceptor. ¿Qué transporte encaja?**

SMPP con un bind transceptor, binds suficientes y una ventana dimensionada para la tasa. HTTP puede llevar el volumen, pero los acuses llegan a un callback, no por la sesión SMPP.

**El endpoint de callback tarda ocho segundos en responder. ¿Qué sale mal?**

El proveedor agota el tiempo y reintenta, así que el mismo evento se entrega otra vez. Responda rápido y procese después de la respuesta.

**¿Por qué un bind silencioso es más difícil que un bind caído?**

Un bind caído falla de forma visible. Un bind silencioso parece abierto, así que el cliente sigue enviando hasta que un timeout lo descubre. El keep-alive lo encuentra antes.

## FAQ

**¿Podemos usar los dos?**

Sí. Muchas plataformas envían por SMPP y reciben callbacks por HTTP durante la migración.

**¿Cuál es más rápido de integrar?**

HTTP, normalmente en una tarde; SMPP compensa cuando el volumen justifica una sesión persistente.

**¿Cuál es más fiable?**

Ninguno lo es por sí solo. La fiabilidad viene de la ruta, la política de reintentos y las operaciones que los rodean.

**¿Puede HTTP con alto volumen?**

Sí, con concurrencia, pool de conexiones y callbacks asíncronos. SMPP suele ser más eficiente para un flujo sostenido, porque la sesión y el canal de acuses ya están abiertos.

**¿Necesitamos una IP fija?**

A menudo sí para SMPP, porque el proveedor permite la IP del cliente. Las integraciones HTTP suelen basarse en TLS y una clave. Confirme el requisito antes de construir.

## Sources

- [smpp.org: sesiones SMPP, operaciones PDU y acuses de entrega](https://smpp.org/) — Accessed: 2026-10-19
- [IETF RFC 9110: semántica de HTTP](https://datatracker.ietf.org/doc/html/rfc9110) — Accessed: 2026-10-19
- [3GPP TS 23.040: realización técnica del servicio de mensajes cortos](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19