표준소개 이동기 1. 머리말 2009 년 11월국내최초출시된아이폰과 2010 년그뒤를이은갤럭시 A와 S 출시로비로소국내에서도스마트폰을이용한무선인터넷접속이폭발적으로증가하기시작했다. 이와동시에스마트폰에서많이사용되는항시접속 (Always On) 유형의메신저앱범용화및그로인하여메신저앱과메신저앱서버상호간에작동상태확인을위해수시로전송되는킵어라이브 (keep-alive) 메시지가폭발적으로증가하였다. 2012 년 1월일본 NTT Docomo 의경우거의대부분의스마트폰에서전송되는시그널링메시지가쇄도하여무선인터넷서비스가중단되는사태까지이르게되었으며, 이외에도국내외많은이동통신사업자들이비슷한문제를경험하였다. 시그널링메시지는동영상등의트래픽과비교해매우적은양의트래픽을발생시키기때문에사용자들이잘인지하지는못하고있지만, 메시지가워낙빈번하게발생하기때문에이동통신망의신뢰성과안정성을약 하게하고, 사용자들의배터리를빨리소진시키는주범중하나이다. GSMA에따르면스마트폰이 Idle 상태에서시그널링메시지전송을위해사용하는 Cell Dedicated Channel 로천이할때마다 32 개의메시지가발생하며, Cell Dedicated Channel은 Idle 상태대비 100 배정도의배터리소모율을보인다고한다. 뿐만아니라, 최적화되지않은시그널링메시지는디도스 (DDoS) 공격과같은형태로이동통신망을무력화시키기도한다. 앱서버와연동하여킵어라이브메시지를주고받는스마트폰앱은이동통신망에장애가발생해도주기적으로메시지전송시도를할뿐만아니라, 무선망이장애후복구되어도복구와동시에무수히많은사용자들의앱에서보낸킵어라이브메시지로인해또다시장애를일으키기도한다. 본고는이런문제점을해소하여, 무선망자원을효율적으로사용하고스마트폰배터리지속시간을연장시켜사용자들의무선인터넷효용성을향상시키기위해최근표준화한 서비스 1부푸시서버와서비스제공자구간바이너리프로토콜규격을살펴보고자한다. 069
앱 푸시클라이언트 3 부 4 부 푸시서버 1, 2 부 1, 2 부 푸시서버 스마트폰 이동통신사업자 A 이동통신사업자 B 앱서버 [ 그림 1] 푸시서비스구조도 2. 서비스 1 부 2.1 서비스 1부규격범위 TTA PG703 산하푸시서비스실무반인 WG7036 은 2012 년 5월부터푸시서비스표준화를진행하고있다. TTA 는푸시서비스표준에킵어라이브메시지최소화및 Notification 메시지전달을위해스마트폰앱과앱서버사이에푸시서버와푸시클라이언트를도입하였다. [ 그림 1] 과같이푸시서버와푸시클라이언트도입후킵어라이브시그널링메시지를발생시키는앱은푸시클라이언트및푸시서버를통해서앱서버와연결된다. TTA 푸시서비스표준은이동통신사업자푸시서버간연동을고려하여개발되었으며, TTA 푸시서비스표준은다음과같이제1 부 ~ 제4 부로구성된다. 1부 : 앱서버- 푸시서버간바이너리프로토콜 2부 : 앱서버- 푸시서버간 HTTP 프로토콜 3부 : 앱- 푸시클라이언트간안드로이드인터페이스 4부 : 푸시클라이언트 -푸시서버간인터페이스 프로토콜인제2 부는제1 부와동일한내용을서로다른프로토콜을사용하여정의하였으며, TTA 에서 1부와 2 부를모두표준화한이유는앱개발사가자사앱의특성에맞는방식을취사선택할수있도록하기위함이다. 2.2 TLS 접속및인증앱서버는푸시서버와연결시 TCP 또는 TLS 를사용할수있으며, 보안이필요한경우에 TLS를그렇지않은경우에는 TCP를사용할수있다. 앱서버가푸시서버와 TLS 로연결시푸시서버에연결한후 TLS Handshake 과정을통해인증서를교환하며, 이때푸시서버는앱서버의인증서를인증하여암호화된채널을연결한다. 발급된인증서와개인키는하나의앱에대해서만유효하다. 앱서버는반드시푸시서버와정상적으로 TLS 채널을연결한이후푸시메시지를전송해야한다. 본절차는푸시서버간연동에도동일하게적용된다 [ 그림 2]. TLS Initiation Certificate 푸시서비스제1 부는 [ 그림 1] 에서보는바와같이앱서버와푸시서버또는푸시서버와푸시서버간바이너리프로토콜에대해서정의한다. 바이너리프로토콜은프로토콜전송및처리의고속화, 대용량화를위해파라메타가숫자화된값을사용한다. 한편, HTTP 방식의 Validate Certificate Certificate TLS Established [ 그림 2] 앱서버 TLS 접속및인증 Validate Certificate 070 09/10 2013
A B Request Simple Request Simple Request Request Request Request Multi Request [ 그림 3] Request 메시지전송 [ 그림 4] Multi Request 메시지전송 #1 #2 Request Response (App does not exist) Request Realtime Feedback [ 그림 5] 전송 [ 그림 6] Feedback 전송 2.3 Simple Request 푸시서버는앱서버로부터 Request 메시지를수신받으면푸시클라이언트로해당 Request 메시지를전달한다. 일반적인푸시메시지는 Token 과 Payload로구성되며, Payload는최대 256Bytes 까지지원한다. 앱서버는푸시메시지를보낼때사용자가가입된사업자푸시서버까지푸시메시지전달을위해사업자식별자를포함하여보낸다. 이는타메시지에도동일하게적용된다. 푸시서비스를이용하는앱이설치되면, 푸시클라이언트가푸시서버로 Token 발급을요청하며, Token 은푸시서버가푸시클라이언트로전달하는 30Byte 길이의 Binary Code 이다. 푸시클라이언트는전달받은 Token을앱서버와공유하며, 앱서버는 Token을통해해당단말기에설치된앱을식별한다. Payload는앱서버로부터단말앱까지전달되는푸시메시지이며앱서버와앱간제한된길이내에서정의하여사용한다 [ 그림 3]. 2.4 Multi Request Simple Request 와동일하게착신 Token을소유한푸시클라이언트로 Notification을전달하는데사용되며, 하나의메시지를 1,000 개의스마트폰에보낼수있다 [ 그림 4]. 2.5 앱서버는공지사항을 메시지에실어푸시서버로 1번만전송하면푸시서버는해당앱이설치되어있는모든단말에 Announcement Request 메시지를전달한다 [ 그림 5]. 2.6 Realtime Feedback 앱서버로부터수신한푸시메시지를푸시클라이언트로전송한후푸시클라이언트로부터앱미설치응답을수신하면, 푸시서버는푸시를수신한세션으로 Realtime Feedback 메시지를전송하여앱서버에게앱이삭제됐음을알린다. 또한, 앱서버로부터유효하지않은 Token 을수신한경우에도푸시서버는앱서버로 Realtime Feedback 메시지를전송한다. 071
Request Response (App does not exist) Request Realtime Feedback Fail Keep-Alive Request Keep-Alive Response(Expiration Timer) Feedback 저장 Feedback Request On-demand Feedback On-demand Feedback Keep-Alive Request Keep-Alive Response(Expiration Timer) Expiration Timer [ 그림 7] Feedback Request 전송 [ 그림 8] Keep-Alive 전송 Realtime Feedback 메시지를수신한앱서버는이후로해당 Token 에대한푸시메시지를보내지않아야한다 [ 그림 6]. 2.7 Feedback Request 푸시서버는앱서버로부터수신한푸시메시지를푸시클라이언트로전송한후클라이언트로부터앱미설치응답을수신하면, 푸시서버는푸시를수신한세션으로 Realtime Feedback 메시지를전송하여앱서버에게앱이삭제되었음을알린다. 푸시서버가 Realtime Feedback 메시지전송에실패했거나, 혹은 를수신한 TLS 세션이존재하지않으면해당 Token 을 Feedback List에저장한다. 앱서버는주기적으로 Feedback List 가있는지푸시서버에조회해야한다. 푸시서버는앱서버로부터 Feedback Request 메시지를수신하면, 저장되어있는 Feedback List 를 Ondemand Feedback 메시지에실어서앱서버로전송한다. On-demand Feedback 메시지를수신한앱서버는이후해당 Token 에대한푸시를보내지않아야한다 [ 그림 7]. 2.8 Keep-Alive 앱서버가푸시서버와 TLS 로연결시앱서버는푸시서버와암호화된채널을연결하고, 즉시 Keep-Alive 메시지를전송한후응답으로 Expiration Timer 값 을수신한다. 이후앱서버는푸시서버와 Transaction 이없을경우에도주기적으로 Keep-Alive 메시지를주 고받아야한다. 앱서버는푸시서버에 Keep-Alive Request 메시지를전송하고, 수신받은 Keep-Alive Response 메시지에포함된 Expiration Timer 값 에따라다음에전송할 Keep-Alive 메시지전송주 기를관리한다. 만약 Keep-Alive Expiration Timer 가 50 분이라면앱서버는 50 분이내에 Keep-Alive Request 메시지를푸시서버에전송해야한다. 앱서버 는 Keep-Alive Request 메시지를보낸시간을기준 으로 Expiration Timer 시간내에다음 Keep-Alive Request 메시지를전송한다 [ 그림 8]. 2.9 Application Verification Request 푸시서버 A 가푸시클라이언트로부터 Token Allocation 요청을받을경우, 앱이등록되어있는앱 마켓의해당이동통신사업자의푸시서버 B 에게해당 Client A Token Allocation Request Application Verification Request Application Verification Response Token 발급 Token Allocation Response Token 공유 B [ 그림 9] Application Verification Request 072 09/10 2013
앱등록여부혹은신뢰도를확인한다. 앱이푸시서버 B 가속한이동통신사업자에등록되어있을경우, 푸시 서버 A 는 Token 을할당한다 [ 그림 9]. 메일, 주소록동기화등의폴링주기를적절하게늘리는 것만으로도어느정도가능하다. 조직의약한고리를보호하는원리에의해사회는진 보하고조직은발전한다고한다. 앱개발사도이제는앱 3. 맺음말제한된자원인무선망을효율적으로활용하여이용자의품질만족도를높임과동시에네트워크품질악화를방지하기위해푸시서비스표준이제정되었다. 무 을개발할때항상전원이공급되고, 브로드밴드로항상접속되어있는 PC 환경이용자보다는대역폭, 전원등제한된자원을가지는모바일환경이용자를고려하고보호할때그린 ICT 는우리앞에한층더가까워질것이다. 선망대역폭은적게사용하지만발생빈도가매우높은 앱시그널링메시지로인해무선망이비효율적으로사용되는것을방지하기위해서푸시서비스 1부에서는앱상태관리및 Notification 메시지전송을대행하는푸시서버와푸시클라이언트를도입하였다. 효율적인무선망활용, 이용자의배터리지속시간연장및 [ 참고문헌 ] [1] 이동기, 무선네트워크환경을고려한트래픽최적화기술및표준화동향, TTA Journal, Vol 148, 2013. 7~8. [2] TTA, 푸시 () 서비스- 제1부푸시서버와서비스제공자구간바이너리프로토콜규격 (TTAK.KO-06.0327), 2013. 그린 ICT 실현등은푸시메시지최적화뿐만아니라이 정보통신용어해설 Korea Internet Self-governance Organization ion [ 관리운용 ] 인터넷자율규제를위하여포털업체들이설립한인터넷자율규제기구. KISO는인터넷사업자들이이용자들의표현의자유를신장하는동시에이용자들의책임감을높여인터넷이신뢰받는정보소통의장이될수있도록하고, 인터넷사업자들이이용자보호에최선의노력을기울이게하는등사회적책무를다하기위하여설립된기구이다. 073