SMPP란? SMS 세션 프로토콜

전문 용어 없이 설명하는 SMPP: 바인드, 윈도우, PDU, 수신 확인 경로, 그리고 대량 발송에서 세션 구조가 중요한 이유.

Unicom Americas – Mobile Business 팀

practitioner · 3 분 분량 · 레슨 2 / 8

SMPP는 플랫폼이 지속 세션을 통해 메시지 센터와 단문 메시지를 주고받는 프로토콜입니다. 바인드가 방향을 선언하고, 세션은 처리량 윈도우를 가지며, 수신 확인은 PDU로 돌아옵니다. 요청-응답 방식의 API가 아닙니다.

주요 정보

SMPP는 바인드 방향이 선언된 지속 세션입니다.
바인드는 처리량 할당량과 응답 대기 요청의 윈도우를 가집니다.
PDU는 16바이트 헤더와 명령별 본문으로 구성됩니다.
수신 확인은 세션을 통해 비동기로 도착하며, 메시지 ID로 대조합니다.

이 페이지의 목차

호출이 아니라 세션

SMPP는 플랫폼과 메시지 센터 사이의 연결을 열어 둡니다. 플랫폼은 한 번 인증하고 무엇을 할지 선언한 다음, 같은 세션에서 메시지를 제출하고 이벤트를 받습니다. 메시지 센터는 수신 확인이나 수신 메시지를 보내기 위해 새 요청을 기다리지 않습니다. 보고할 내용이 생기면 PDU를 푸시합니다.

이 구조는 꾸준한 트래픽 흐름에 적합합니다. 세션 상태가 이미 수립되어 있어 메시지당 오버헤드가 작고, 수신 확인 채널도 이미 열려 있습니다. 동시에 HTTP 클라이언트에는 없는 상태를 클라이언트가 직접 관리해야 한다는 뜻이기도 합니다. 바인드 상태, 진행 중 윈도우, keep-alive 타이밍, 재연결 동작이 그것입니다.

바인드는 방향을 선언합니다

바인드는 인증된 세션에 방향을 더한 것입니다. 트랜스미터 바인드는 메시지를 제출합니다. 리시버 바인드는 단말 발신(MO) 메시지와 수신 확인을 받습니다. 트랜시버 바인드는 하나의 세션에서 둘 다 처리합니다. 제공업체는 바인드마다 자격 증명을 발급하며, 열 수 있는 바인드 수를 제한할 수 있습니다.

바인드 하나를 할당량 이상으로 밀어붙이지 말고, 바인드를 추가해 확장하십시오. 바인드 하나는 처리량 할당량 하나와 응답 대기 요청 윈도우 하나를 가집니다. 피크 트래픽이 그보다 많다면 바인드를 추가로 요청하고 트래픽을 분산하십시오. 윈도우를 넘겨 구동되는 단일 바인드는 스로틀링, 타임아웃, 재시도를 일으킵니다. 이는 네트워크 장애처럼 보이지만 원인은 클라이언트에 있습니다.

바인드, 제출, 수신 확인

애플리케이션(ESME)
bind_transceiver 세션 열기
SMSC
submit_sm_resp 전달 접수됨
전달 확인

세션은 한 번 열립니다. 각 제출에는 메시지 ID가 담긴 응답이 돌아오고, 수신 확인은 나중에 같은 세션으로 도착합니다. 출처: smpp.org: SMPP 세션과 PDU 동작

텍스트 설명

애플리케이션이 바인드를 열면 메시지 센터가 응답합니다. 애플리케이션은 submit_sm으로 단문 메시지를 제출하고, 메시지 ID가 담긴 submit_sm_resp를 받습니다. 이후 메시지 센터는 수신 확인을 담은 deliver_sm PDU를 보냅니다. 애플리케이션은 deliver_sm_resp로 이를 확인 응답합니다. 작업이 끝나면 unbind로 세션을 닫습니다.

윈도우가 곧 계약입니다

윈도우는 클라이언트가 응답을 기다리기 전에 미처리 상태로 둘 수 있는 요청 수입니다. 권장 사항이 아니라 지켜야 하는 한도입니다. 윈도우가 허용하는 것보다 많이 제출하면 메시지 센터가 스로틀링을 걸고, 같은 속도로 계속 재시도하면 대기열이 늘어납니다. 제출마다 응답 코드를 읽고, 스로틀링이 걸리면 속도를 낮추고, 다음 버스트 전에 윈도우가 비워지도록 하십시오.

keep-alive 트래픽이 세션을 열린 상태로 유지합니다. enquire_link를 전혀 보내지 않는 클라이언트는 첫 제출이 실패할 때까지 끊어진 연결에 머물러 있을 수 있습니다. 연결이 끊길 때마다 즉시 재연결하는 클라이언트는 제공업체에 과부하를 줄 수 있습니다. 백오프를 사용하고, 재연결 빈도에 상한을 두고, 바인드가 트래픽이 견딜 수 있는 시간보다 오래 끊겨 있으면 알림을 보내십시오.

PDU 하나를 필드별로

command_length: 53
command_id: 0x00000004
command_status: 0x00000000
sequence_number: 1
service_type
source_addr_ton: 1
source_addr_npi: 1
source_addr: 12345
dest_addr_ton: 1
dest_addr_npi: 1
destination_addr: 15551234567
esm_class: 0x00
protocol_id: 0x00
priority_flag: 0
schedule_delivery_time
validity_period
registered_delivery: 0x01
replace_if_present_flag: 0x00
data_coding: 0x00
sm_default_msg_id: 0x00
sm_length: 4
short_message: 54657374
텍스트: Test

헤더는 고정되어 있고 본문은 명령에 따라 달라집니다. submit_sm은 주소, 코딩, 수신 확인 플래그를 담습니다. 출처: SMPP v3.4 규격, PDU 헤더 및 submit_sm

텍스트 설명

모든 PDU는 명령 길이, 명령 ID, 명령 상태, 시퀀스 번호로 시작하며, 각 필드는 네 바이트입니다. 그 뒤에 본문이 옵니다. submit_sm의 본문에는 발신 및 수신 주소, 단문 메시지, 데이터 코딩, registered-delivery 플래그가 담깁니다. 선택적 파라미터는 TLV(tag-length-value) 필드로 전달됩니다.

메시지 하나의 여정

클라이언트는 트랜시버 바인드를 열고 바인드 응답을 읽습니다. 메시지를 제출하고 응답에서 메시지 ID를 저장합니다. 메시지 센터는 메시지를 대상 네트워크로 라우팅합니다. 몇 분 뒤 수신 확인을 담은 deliver_sm PDU가 도착합니다. 여기에는 원래 메시지 ID, 상태, 그리고 흔히 네트워크 코드가 담겨 있습니다. 클라이언트는 수신 확인에 응답하고, 그 상태를 자체 기록과 대조합니다.

단계마다 실패 유형이 있습니다. 바인드는 잘못된 자격 증명이나 맞지 않는 인터페이스 버전 때문에 거부될 수 있습니다. 제출은 스로틀링되거나 거부될 수 있고, 수락된 뒤 수신 확인 단계에서 실패할 수도 있습니다. 수신 확인이 코드가 만료된 뒤에 도착할 수도 있습니다. 클라이언트가 메시지 ID를 저장하고, 늦게 도착한 수신 확인도 받아들이며, 사용자가 무엇을 했는지는 애플리케이션 자체 상태를 기준으로 삼도록 설계하십시오.

SMPP 및 DLR 코드 디코더

디코더는 브라우저에서 실행되며, 붙여 넣은 수신 확인은 브라우저 안에만 머뭅니다.

command_status, 전송 결과 보고서의 stat 및 err 필드 또는 16진수 PDU를 붙여 넣으면 그 의미와 다음에 확인할 사항을 알려 줍니다.

sample: id:0123456789 sub:001 dlvrd:001 submit date:2610181200 done date:2610181201 stat:DELIVRD err:000 text:Your code is 123456

도구 열기

경로를 디버깅하기 전에 수신 확인부터 디코딩하십시오

수신 확인을 SMPP 및 DLR 디코더에 붙여 넣고 필드를 읽으십시오. 메시지 ID, 상태, done date, 오류 코드를 확인합니다. 상태가 DELIVRD가 아니면, 제공업체의 코드표와 대조해 읽은 오류 코드로 번호, 단말, 네트워크 중 어디에서 메시지를 거부했는지 가늠할 수 있습니다. 제공업체에 경로 변경을 요청하기 전에 이 작업부터 하십시오.

수신 확인과 디버깅

수신 확인은 비동기로 처리됩니다. 세션에서 deliver_sm PDU로 도착하며, 형식은 메시지 센터에 따라 다릅니다. 최신 구현은 상태를 message_state TLV 필드에 담습니다. 이전 구현은 short message 필드에 텍스트 형식의 수신 확인을 넣고, id, stat, err 같은 키-값 쌍을 사용합니다. 한쪽을 가정하지 말고 두 형식을 모두 파싱하십시오.

도착 순서가 아니라 메시지 ID로 대조하십시오. 거의 동시에 제출한 두 메시지가 반대 순서로 돌아올 수 있고, 재시도로 중복이 생길 수 있습니다. 제출 시 ID를 저장하고, 수신 확인이 도착하면 기록을 갱신하며, 같은 ID에 대한 두 번째 수신 확인은 상태가 더 최신이 아니면 무시하십시오. 연결 가이드는 이를 운영 절차로 정리합니다.

학습 내용 확인

재시도 속도를 높이는 것보다 바인드를 하나 더 두는 것이 왜 더 도움이 됩니까?

바인드 하나는 윈도우 하나를 가집니다. 바인드를 추가하면 용량이 늘지만, 가득 찬 윈도우에 재시도하면 대기열과 지연만 늘어납니다.
메시지 ID는 어디에서 옵니까?

메시지 센터가 submit_sm_resp로 반환합니다. 이를 저장하고, 나중에 오는 수신 확인을 그 ID로 대조하십시오.
전달 완료 수신 확인은 무엇을 증명합니까?

네트워크가 메시지를 수락하고 단말 경로까지 전달했다는 것입니다. 사람이 메시지를 읽었다는 것을 증명하지는 않습니다.

답은 요청 시 공개됩니다. 채점, 저장, 전송은 하지 않습니다.

자주 묻는 질문

시작할 때 SMPP가 필요합니까?

아닙니다. HTTP는 한나절이면 연동할 수 있고, SMPP는 꾸준한 물량이 세션을 둘 만큼 커졌을 때 효과를 냅니다.

바인드란 무엇입니까?

트랜스미터, 리시버, 트랜시버 중 하나의 방향이 선언된 지속 세션입니다. 처리량 할당량을 가지며, keep-alive 교환으로 열린 상태를 유지합니다.

PDU란 무엇입니까?

Protocol Data Unit, 즉 SMPP가 주고받는 바이너리 메시지입니다. 모든 PDU는 16바이트 헤더와 명령별 본문으로 구성됩니다.

공용 인터넷에서 SMPP를 사용할 수 있습니까?

TLS와 IP 허용 목록을 적용하면 가능한 경우가 많지만, 제공업체에 문의하십시오. 일부 구축 환경에서는 대신 전용 연결을 사용합니다.

긴 메시지는 어떻게 처리됩니까?

사용자 데이터 헤더를 붙인 연결 세그먼트로 보내거나, 네트워크가 분할하는 message payload TLV로 보냅니다. 결과는 단말에서 테스트하십시오.

출처

나오는 용어

사용 도구

SMS 처리량 및 캠페인 플래너

메시지 양과 발송 시간대로 필요한 처리량을, 또는 처리량으로 캠페인 기간을 계산합니다.