응용 레벨 모바일 트래픽 모니터링 및 분석을 위한 시스템 연구

응용레벨모바일트래픽모니터링및분석을위한시스템연구 (A Study on System Architecture for Application-Level Mobile Traffic Monitoring and Analysis) 최영락 *, 정재윤 **, 박병철 **, 홍원기 * 포항공과대학교정보전자융합공학부 *, 컴퓨터공학과 ** 분산처리및네트워크관리연구실 {dkby, dejavu94, fates, jwkhong}@postech.ac.kr 요 약 최근스마트폰과같은모바일단말사용이급증하면서, 인터넷접근을필요로하는다양한모바일어플리케이션이등장하였고, 이에따른트래픽양이급증하는추세에있다. 급증하는모바일트래픽에효율적으로대응하기위해서는어플리케이션수준에서의모바일트래픽정보를네트워크상에서모니터링하고분석하여이에따른대응책을수립해야한다. 본연구에서는응용레벨모바일트래픽모니터링및분석을위한정보를생성하기위해모바일 TMA (Traffic Measurement Agent) 를활용한모바일어플리케이션정보를수집하여모바일트래픽을모니터링하고분석하는시스템구조를제안한다. 제안하는시스템은모바일단말의성능제약으로인해모바일단말에서완전한트래픽정보를수집하지못하는문제를극복하기위해인터넷네트워크상에서손실없이수집한트래픽과매칭하는알고리즘을통해모바일어플리케이션을분류가능한정보를생성한다. 제안하는시스템을교내기숙사지역의모바일환경에적용하여모바일어플리케이션을분류가능한정보를생성하였고, 이를활용하여교내기숙사지역모바일트래픽의특성을어플리케이션별로분석하였다. Keywords: 모바일어플리케이션트래픽, 모바일트래픽모니터링및분석 1. 서론 1 어플리케이션트래픽모니터링및분석은네트워크의상태를이해하여고품질의네트워크서비스를제공하고, 악의적인공격을방어할뿐만아니라, 네트워크 Bandwidth 를점유하는어플리케이션트래픽을관리함에있어서매우중요하다. 다양한모바일장비및어플리케이션이급증하고있으며, 해당장비들이생성하는모바일어플리케이션트래픽이기존인터넷어플리케이션트래픽과다른패턴을보이고있어인터넷트래픽에서모바일어플리케이션을분류하는일이복잡해지고있다. 최근에는모바일어플리케이션개수및모바일트래픽양이점차급증하는추세를보이고있다. 현재스마트폰, 스마트타블렛과같은다양한종류의모바일장비들이등장하고있으며, 많은사람들은해당장비들을구입하여다양한모바일어플리케이션들을실행한다. 2011 년 3 월기준으로 200,000 개의안드로이드모바일어플리케이션및 300,000 개의아이폰모바일어플리케이션들이마켓에서다운로드가능할정도로 [1] 많은모바일어플리케이션들이계속해서등장하고있다. 인터넷트래픽상에서모바일어플리케이션트래픽을분류하기위해서는모바일어플리케이션을분류가능한정보를생성해야할필요가있다. 최근모바일트래픽을연구한논문결과를살펴보면, 모바일트래픽은 HTTP 트래픽비율이높고, 클라이언트 - 서버구조를따르는어플리케이션이많다는특성을나타내고있다 [3-5]. 이러한특성을나타내는모바일어플리케이션을분류하기위해서는기존트래픽분류에서와마찬가지로, 각모바일어플리케이션별로해당어플리케이션에대한트래픽을모아놓은 본연구는한국연구재단을통해교육과학기술부의세계수준의연구중심대학육성사업 (WCU) (R31-10100) 과방송통신위원회의 "HiMang (Highly Manageable Network and Service Architecture for New Generation) 원천연구 " 원천기술개발사업의연구결과로수행되었음 (KCA-2011-10921-05003). 10

Ground Truth 데이터를수집해야할필요성이있다. 기존인터넷트래픽모니터링및분석에서 Ground Truth 데이터를얻기위해서사용하던방법으로추가적인에이전트를데스크탑 PC 등에설치하여해당 PC 에서생성된어플리케이션및트래픽정보를추출하는방식이있다 [2]. 그러나, 모바일장비들은데스크탑 PC 에비해처리속도가매우느리고제한된메모리용량을가지고있어, 모바일장비에데스크탑에서동작하던기능과동일한에이전트프로그램을설치하여동작할경우, Ground Truth 데이터를얻어내기위한충분한처리속도를보장하지못하여해당방식을모바일환경에그대로적용하기어렵다는단점을가지고있다. 본연구에서는모바일단말에서 Ground Truth 데이터를추출하기위해모바일환경에서동작가능한에이전트프로그램을모바일 TMA (Traffic Measurement Agent) 라명명하고, 이를활용하여모바일어플리케이션정보를수집하고, 모바일트래픽을모니터링하고분석하는시스템구조를제안하고자한다. 모바일 TMA 는모바일어플리케이션정보를수집하지만, 모바일장비의낮은성능으로인하여 100% 완벽한트래픽정보를수집하지는못하기에, 인터넷 Junction 상에서손실없이모바일트래픽을동시에수집하여불완전한정보를보완하고자한다. 이때, 제안하는플로우매칭알고리즘을통해일반적으로사용되는 NAT (Network Address Translator) 환경에서도시스템에서수집한정보를활용해 Ground Truth 데이터를생성한다. 생성된 Ground Truth 데이터는모바일어플리케이션을구분하는정보를생성하는데사용가능한동시에, 인터넷 Junction 에서모바일어플리케이션을분류하였을때의정확도를검증하는데활용가능하다. 제안하는시스템및알고리즘을검증하기위해, 우리는안드로이드 OS 용모바일 TMA 및해당시스템을구현하여본교네트워크에적용하고모바일어플리케이션을분류가능한정보를생성하여교내기숙사모바일트래픽을모니터링하고분석하였다. 본논문의구성은다음과같다. 2 장에서는모바일트래픽분류및모바일트래픽측정과관련된연구에대해기술한다. 3 장에서는 TMA 를포함한모바일트래픽분류를위한정보생성및모바일트래픽분류시스템에대한구조를설명한다. 4 장에서는모바일 TMA 와인터넷 Junction 에서수집된정보를기반으로 Ground Truth 데이터를생성하는플로우매칭알고리즘에대해설명하고, 제안한알고리즘을검증한다. 5 장에서는제안한시스템을활용하여교내기숙사지역의모바일트래픽을분석한결과를기술하고, 마지막으로 6 장에서는요약및향후연구에대해기술한다. 2. 관련연구 많은기존연구들이모바일트래픽에대한측정및분석에관해다루었으며, 모바일네트워크의특성을기술하였다. [3] 에서는기숙사지역의광대역 DSL 회선에서 Handheld 모바일트래픽을수집하였는데, 11 개월동안 20,000 개이상의 DSL 회선으로부터트래픽을수집하여 HTTP user-agent 문자열과 IP TTL 값을수작업으로비교하여모바일트래픽을구별하였다. 해당연구에서는 iphone 및 ipod Touch 가모바일 HTTP 트래픽의 86-97% 를차지하였고, 장비별분포도에서는 71-87% 를나타내었으며 HTTP 프로토콜이 TCP 의 80-97% 를차지할만큼대다수를차지하였다. 가장많은비율에속하는모바일어플리케이션은 62% 를나타낸 Safari 모바일브라우저라는분석결과를보여주었다. [4] 는 Windows Mobile 및 Android 운영체제에서생성된스마트폰트래픽을단말상에서로그를수집하는방식으로플로우특성및프로토콜을분석하였다. 해당연구에서는 43 명의사용자단말에트래픽로그수집응용프로그램을설치하고포트사용및응용프로그램단위의트래픽발생분석, 플로우특성등을분석하였다. 응용레벨의트래픽분석을통해 HTTP 및 HTTPS 가포트분포도에서약 80% 의비율을보여주었으며, 프로세스별트래픽사용량은웹브라우징이 58.02% 로가장많은비율을나타내었다. 해당연구에서는 Transfer size, Retransmission rate, Round-trip-time, Radio power 와의상호작용등스마트폰트래픽의다양한측정결과를보여주었다. [5] 에서는학교 Wi-Fi 망에서 3 일동안총 32,278 개의장비에서발생한학교내캠퍼스트래픽을수집하였다. 연구결과에따르면, 어플리케이션프로토콜분석을통해 90% 이상의 Handheld 장비에서발생한트래픽이 HTTP 와 HTTPS 프토토콜이었으며, Handheld 장비들에서비디오트래픽이 Non-handheld 장비들보다 2 배이상많았다. 뿐만아니라, Handheld 웹트래픽의경우 HTTP 호스트가다양하지않아상위 10 개의호스트가 74% 의트래픽을차지하는반면, Non-handheld 장비에는상위 10 개의호스트가 42% 의트래픽만을차지하였다. 뿐만아니라, Handheld 웹트래픽에서는유사성이많이발견되었다. 그러나해당연구에서저자들이 Handheld 장비를파악한방법은장비의 MAC 주소의수집을필요로하며, 이는모든 Wi-Fi AP (Access Point) 들의접근이가능해야만얻을수있는정보라는단점이있다. 해당연구들에서공통적으로볼수있듯이, HTTP 및 HTTPS 어플리케이션프로토콜트래픽이모바일어플리케이션의대다수를차지하였다. 그러나, 모바일어플리케이션트래픽을수작업으로분류하는과정은상당한노력을필요로하며, 모바일어플리케이션과관련된보다정확하고상세한응용레벨정보를 11

보여주지못하였다. 정확한응용레벨의모바일어플리케이션분류를위해서는 Ground Truth 데이터수집이이루어져야하지만, 해당연구들에서는 Ground Truth 데이터를수집하지않고낮은정확도를보이는포트번호비교방식 [6] 을적용하였다. 따라서본연구에서는모바일장비의 Ground Truth 데이터를수집하는데초점을두어응용레벨의모바일어플리케이션을분류하기위한정보를생성하고이정보를활용하여모바일어플리케이션을구분하는시스템을제안하고, 해당시스템에서사용되는플로우매칭알고리즘을소개하고자한다. 그림 1. 모바일 TMA 를활용한모바일트래픽모니터링및분석시스템구조 3. 모바일트래픽모니터링및분석을위한시스템구조 3.1 제안시스템구조개요 그림 1 은제안하는모바일 TMA 를활용한모바일트래픽모니터링및분석시스템구조를나타낸다. 제안하는시스템구조에서는모바일 TMA 가모바일장치에설치되어해당장비에어떤모바일어플리케이션이실행되어인터넷 (Wi-Fi) 에접속하고트래픽을발생시키는지에대한응용레벨의트래픽정보를수집한다. 이를지원하기위해, 모바일데이터수집 (S1) 서브시스템이모바일어플리케이션프로세스명과패킷정보의일부분을수집하고, 플로우수집 (S2) 서브시스템에서패킷전체정보를수집한다. 이후, Ground Truth 생성및트래픽분류시스템 (S3) 은 S1 와 S2 의정보를이용하여모바일어플리케이션트래픽을모니터링하고분석하는데필요한 Ground Truth 데이터및모바일트래픽을분류가능한정보를생성하고, 트래픽분류시스템에바로적용가능하도록한다. Ground Truth 데이터는각어플리케이션으로구분한트래픽집합에해당하며, 트래픽분류에가능한정보를생성할때, 그리고트래픽분류알고리즘의정확도를확인하기위한용도로사용된다. 제안하는시스템구조가종래시스템또는기존에이전트를활용한 Ground Truth 생성과다른점은, 모바일 TMA 를통한데이터수집과플로우수집서브시스템에서수집된정보를모두활용하여 Ground Truth 를생성하는것에있다. 두서브시스템이필요한이유는 Ground Truth 생성을위해서는단말에서의프로세스정보가필요한데, 모바일장치의성능한계로인해모바일장치에서프로세스명과함께패킷을수집할때패킷손실이발생하기때문이다. 패킷손실을확인하기위해, 우리는모바일 TMA 를실행하는동시에중간 Router 에서패킷을수집하여수집된패킷수를비교해보았다. 패킷손실율은다음식에의해계산하였다. 패킷손실율 [ 모바일에서수집한패킷개수 ] [ 에서수집한패킷의총개수 ] 12

표 1 은모바일어플리케이션종류에따른패킷손실비율을나타낸다. 총패킷손실비율은 62.0% 의매우높은비율을보이며, 모바일어플리케이션종류에따른손실율을각각살펴보면멀티미디어재생관련모바일어플리케이션에서패킷손실율이가장높았다. 이는모바일단말에서비디오를재생시에많은자원을필요로하고모바일 TMA 는많은수의패킷을짧은시간에전부수집하지못하는것으로유추된다. 따라서, 제안하는시스템구조에서모바일 TMA 는페이로드전체를수집하지않도록하여모바일장치부하를줄이고, 플로우수집서브시스템에서페이로드전체를수집하여 Ground Truth 데이터를생성할때, 불완전한모바일 TMA 에서수집한정보를보완하여페이로드전체를포함하는플로우정보로변환하는과정을거친다. 표 1. 모바일응용프로그램별모바일 TMA 에서의패킷손실율 구분 모바일어플리케이션 패킷손실율 평균표준편차 1st 2nd 3rd 멀티미디어 YouTube 72.7% 73.4% 71.2% 72.4% 0.011 웹브라우저 인터넷 27.7% 20.5% 18.4% 22.2% 0.049 메신저카카오톡, & SNS Facebook 58.7% 5.1% 4.3% 22.7% 0.312 ( 총계 ) 61.2% 65.1% 59.6% 62.0% 0.028 3.2 모바일데이터수집 (S1) App 1 모바일장치 App 2... App n 모바일 TMA 클라이언트 패킷수집 네트워크인터페이스 응용프로그램트래픽 압축된패킷 & 응용프로그램정보 대학네트워크 모바일 TMA 서버 Listener 압축해제 플로우생성 그림 2. 모바일 TMA 와모바일 TMA 서버와의상호작용 본서브시스템은모바일 TMA (C1-1) 과모바일 TMA 서버 (C1-2) 로이루어져있다. 해당서브시스템은모바일 TMA 가설치된각모바일장비내에서발생한플로우와모바일어플리케이션프로세스명을수집하는역할을수행한다. 먼저, 모바일장치에서동작하는모바일 TMA 는모든패킷 ( 첫 20 byte 의페이로드만을포함하도록설정하여 ) 을 libpcap 라이브러리 [9] 를이용하여수집하고패킷정보와모바일어플리케이션프로세스정보를각각저장한다. 해당결과는모바일 TMA 서버에주기적으로전송된다. 모바일장비가제한된처리속도및메모리용량을가지고있어제안하는시스템에서는모바일장비내에서수집된패킷과어플리케이션정보를직접적으로매칭하지않는다. 그림 2 는모바일 TMA 와모바일 TMA 서버와의상호작용을나타낸다. 모바일 TMA 서버에서는모바일 TMA 에서수집된정보들을조합하는역할을수행한다. 해당컴포넌트에서는패킷정보와모바일어플리케이션프로세스명을매칭하는작업을수행한후, 프로세스명과패킷레벨의네트워크정보를플로우단위의정보로변환한다. 최종적으로, 모바일어플리케이션프로세스명과플로우단위의정보가데이터베이스에저장된다. 모바일 TMA 서버상의플로우정보는인터넷 Junction 에서수집된해당트래픽을찾는데이용된다. 어플리케이션프로세스명에대한정보는모바일어플리케이션을분류하는정보를생성하는데이용될뿐만아니라, 모바일어플리케이션분류결과의정확도를검증하는데이용된다. 그림 3 은안드로이드 OS 에동작가능한모바일 TMA 의내부구조를나타낸다. 안드로이드용모바일 TMA 프로그램은크게서비스프로세스와 C/C++ 프로세스로나뉘어진다. 서비스프로세스는실제모바일 TMA 의역할을하는 C/C++ 프로세스가올바르게실행되고있는지감시하고, C/C++ 프로세스가수집하여 13

저장한덤프파일들을관리하는역할을수행한다. 이때, 전송되는덤프파일은압축하여전송하여모바일네트워크의영향력을최소화하고자하였다. 실제로이와같이구현한모바일 TMA 를사용한결과덤프파일크기는초당약 250KBps 로전송되었을때, 27.68K 바이트로, 발생하는트래픽의약 0.01% 에해당하는상대적으로적은네트워크부하를주었다. C/C++ 프로세스는 Libpcap 라이브러리를사용하여모바일장비에서발생된트래픽을수집하는동시에, 패킷헤더정보를기반으로실제해당패킷을발생시킨모바일어플리케이션을찾는과정을수행한다. 이때, Libpcap 라이브러리는루팅된안드로이드장비에서만실행가능하기에, 모바일 TMA 는루팅된안드로이드장비에서만실행가능하다. 안드로이드에서패킷을수집하기위해안드로이드 NDK (Native Development Kit) 을활용하여 C/C++ 응용프로그램으로개발하였으며, 소켓정보를기반으로모바일어플리케이션명을찾아해당정보를덤프파일로기록하고, 모바일 TMA 서버에전송하도록구현하였다. 패킷 모바일 TMA 클라이언트 서비스프로세스 사용자인터페이스 서비스관리 덤프파일 JNI 서버 JNI 클라이언트 파일관리 패킷 패킷덤프생성 < 패킷, 응용프로그램명 > dump files 압축된덤프파일 모바일 TMA 서버 응용프로그램명 Libpcap <IP 주소, 포트번호 > 프로세스검색 그림 3. 안드로이드용모바일 TMA 의내부구조 모바일어플리케이션프로세스가모바일트래픽을발생시킬때, 모바일 TMA 는생성된네트워크패킷을수집하고네트워크패킷의 <source IP 주소, source 포트번호, destination IP 주소, destination 포트번호, 프로토콜종류 > 로이루어진튜플정보를이용해모바일 OS 상의내부소켓정보를활용하여해당패킷을발생시킨모바일어플리케이션프로세스정보를찾는다. TCP 프로토콜패킷에대해서는, TCP SYN 패킷에대해서만모바일어플리케이션프로세스정보를찾는과정을수행하여모바일장비의자원을지나치게사용하지않도록설계하였다. 3.3 플로우수집 (S2) C/C++ 프로세스 해당서브시스템의시스템구조는일반적인트래픽수집및분석시스템의구조를따라구성되었다. 패킷수집부분 (C2-1) 에서는모바일단말에서생성된트래픽을수집한다. 해당컴포넌트는트래픽을수집하는동안모든패킷의헤더와페이로드를저장할수있는충분한디스크공간이확보되어야한다. 플로우생성기 (C2-2) 는수집된패킷단위의트래픽을플로우단위의정보로변환한다. 플로우단위의트래픽정보는 <source IP 주소, source 포트번호, destination IP 주소, destination 포트번호, 프토토콜종류 > 에해당하는튜플과함께, 플로우시작시각, 플로우지속시간, 플로우를구성하는패킷의개수, 플로우크기에대한정보로이루어진다. 비록패킷수집부분 (C2-1) 에서전체페이로드를수집하지만, 플로우단위로변환할때에는처음 10 개의 inbound 및 outbound 패킷의전체페이로드만을저장하는데, 이만큼의 payload 만으로도충분히높은트래픽분류정확도를보증할수있기때문이다 [10]. 플로우의시작은 SYN 패킷이시작할때를, 플로우가끝나는부분은 FIN/RST 패킷또는플로우타임아웃이발견되었을때를기준으로정보를구성하였다 [11]. 또한, 플로우서버 (C2-3) 은플로우단위의트래픽을데이터베이스를통해관리한다. 각트래픽은하나또는여러개의데이터베이스테이블로구성되고인텍스를통해 Ground Truth 생성 (C3-1) 과같은타서브시스템에서빠른접근을가능하도록지원하였다. 3.4 Ground Truth 생성및테스트 (S3) Ground Truth 생성컴포넌트 (C3-1) 는각모바일어플리케이션에해당하는 Ground Truth 데이터를생성한다. 본컴포넌트의입력은모바일 TMA 서버 (C1-2) 및플로우서버 (C2-3) 에저장된데이터베이스 14

테이블에해당한다. 해당컴포넌트는먼저모바일 TMA 서버에존재하는응용레벨의정보와플로우서버에저장된페이로드전체정보를 4 장에서제안하는플로우매칭알고리즘을통해매칭하는과정을거친다. 해당과정을통해최종적으로각모바일어플리케이션별 Ground Truth 데이터가생성된다. 이후, 본컴포넌트에서는 Ground Truth 데이터를이용하여모바일어플리케이션분류에필요한정보를생성가능하며 (C3-2), 생성된정보는모바일트래픽을모니터링및분석하는데바로활용할수있다. 트래픽분류시스템 (C3-3) 은 C3-2 에서생성된정보를활용하여모바일어플리케이션을분류하는컴포넌트이다. 해당컴포넌트를통해모바일어플리케이션트래픽을분류할수있을뿐만아니라, 생성된 Ground Truth 데이터를이용한검증을수행할수있으며, 수집된트래픽에대한다양한모바일어플리케이션사용현황등에대한분석이가능하다. 4. 플로우매칭알고리즘을통한 Ground Truth 데이터생성 제안하는시스템에서는모바일 TMA 만을사용하여 100% 정확한트래픽정보를수집할수가없기때문에, 인터넷 Junction 에서트래픽을손실없이수집하고, 이를같이활용하여 Ground Truth 데이터를생성한다. Ground Truth 데이터에는모바일트래픽에대한플로우정보및모바일 TMA 를통해수집된모바일어플리케이션의프로세스정보가포함되어야한다. 그러나모바일 TMA 에서수집된플로우정보는모바일장비의낮은성능으로인해모든패킷을수집하지못하기때문에정확하지않다. 뿐만아니라, 일반적으로 Wi-Fi AP (Access Point) 들은 NAT (Network Address Translator) 기능 [7][8] 을지원하여 Wi-Fi AP 내부에서사용되는 source IP 주소및포트번호가 Wi-Fi AP 외부로해당패킷이 AP 의 IP 주소와임의의포트번호로변환되어전송된다. 이기능으로인해모바일 TMA 에서수집된플로우를인터넷 Junction 에서수집된트래픽과매칭하여트래픽정보를보완하는것이어렵다. 이러한문제점을극복하여 Ground Truth 데이터를생성하기위해, 본연구에서는플로우를휴리스틱하게매칭하여찾아내는플로우매칭알고리즘을이용하여모바일 TMA 에해당하는트래픽정보를인터넷 Junction 에서수집된트래픽으로부터찾아내고 Ground Truth 데이터를생성하였다. 4.1 플로우매칭알고리즘 모바일 TMA 를통해수집된트래픽은패킷손실이있어플로우에포함된패킷수, 플로우크기등의정보가실제트래픽정보와다르다. 이러한부정확한플로우정보는인터넷 Junction 에서손실없이수집된정확한트래픽정보와비교하여매칭하는작업을통해보완할수있다. 그러나모바일트래픽은대부분 NAT 기능이포함된 AP 를통해발생하며, 이때모바일 TMA 와인터넷 Junction 에서의 source IP 주소및 source 포트번호가같지않아 <source IP 주소, source 포트번호, destination IP 주소, destination 포트번호, 프로토콜종류 > 에해당하는 5- 튜플정보를이용해플로우매칭작업을수행할수없다. 본절에서는이를극복하기위해제안하는플로우매칭을수행하는휴리스틱알고리즘을소개하고자한다. 그림 4 는 Ground Truth 생성컴포넌트에서이루어지는플로우매칭의전반적인과정을나타낸다. 대부분의 Wi-Fi AP 에존재하는 NAT 기능으로인해, 모바일 TMA 서버데이터 (M subtuple ) 및플로우서버데이터 (T subtuple ) 중 destination IP 주소, destination 포트번호및프토토콜종류값만이의미있는값이라할수있다. 모바일 TMA 서버에는또한모바일어플리케이션프로세스명과함께첫 20 바이트에해당하는 payload 데이터를포함하고있다. 이일부 payload 데이터를이용하여인터넷 Junction 상에서수집한트래픽과의매칭을보완할수있다. 최종적으로, 인터넷 Junction 에서수집된트래픽에모바일 TMA 서버에저장되어있던모바일어플리케이션프로세스명을연결시켜, 장비상에서불완전한트래픽정보를수집하는것보다정확한트래픽정보를활용할수있도록한다. 알고리즘 1 은제안하는플로우매칭알고리즘을나타낸다. 알고리즘 1 에서모바일 TMA 에저장된각플로우는 M subtuple 집합으로표현되며, 플로우서버에저장된플로우인 T subtuple 와매칭작업을통해정확한트래픽정보를포함하는모바일어플리케이션에대한트래픽정보를가능한많이찾아내는것을목표로실행된다. 제안하는알고리즘은패킷손실이일어나지않는다고가정하고, 플로우에포함된패킷수및플로우크기와일치하는모바일트래픽을먼저찾아낸다. 그러나, 실제로모바일 TMA 는모바일장비에서수집할때에다량의패킷을손실한다. 따라서, 제안하는휴리스틱알고리즘은 (1) 플로우를구성하는패킷수및플로우크기가정확히일치하는경우 (3-5 행 ); (2) 플로우를구성하는패킷수만일치하는경우 (6-8 행 ); (3) 패킷수가많거나적은경우 (9-11 행 ); (4) 페이로드가일치하는경우 (12-17 행 ) 으로나누어플로우를매칭하였다. 15

(Retrieved from mtma) M <flow NAT, flow_info M, payload P, appname> (Retrieved from backbone) T <flow, flow_info, payload> M subtuple Π flow_dst,flow_infom,payloadp,appname (M) T subtuple Π flow_dst,flow_info,payload (T) [Flow Matching] R return σ protocol=tcp (Π appname,flow_dst,flow_info,payload (R join ) ) flow = <src_ip, src_port, dst_ip, dst_port, protocol> flow_info = <flow start time, number of packets, total bytes> flow NAT = <src_ip NAT, src_port NAT, dst_ip, dst_port, protocol> flow_dst = <dst_ip, dst_port, protocol> 그림 4. Ground Truth 데이터를생성하기위한플로우매칭과정 알고리즘 1. TCP 패킷에대한플로우매칭 00: 01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: procedure TCPFlow_Matching() for each item in M subtuple T subset of T subtuple that matches <dst_ip, dst_port, proto> for item within time period if # of T for exact matching <pktno, bytes> = 1 then Insert <appname, dst_ip, dst_port, flow_info, payload> into R end if else if # of T for exact matching <pktno> = 1 then Insert <appname, dst_ip, dst_port, flow_info, payload> into R end if else if # of T more or less <pktno> than item=1 then Insert <appname, dst_ip, dst_port, flow_info, payload> into R end if else Perform Match payload p and payload for item and T if # of matched results = 1 then Insert <appname, dst_ip, dst_port, flow_info, payload> into R end if end if end for return R end procedure M subtuple: 모바일 TMA 에서수집한트래픽집합, T subtuple: 인터넷 Junction 에서수집한트래픽집합 dst_ip: destination IP 주소, dst_port: destination 포트번호, proto: 프로토콜종류 pkt_no: 플로우를구성하는패킷수, bytes: 플로우크기, appname: 모바일어플리케이션프로세스명 flow_info: 기타플로우정보, payload: full payload, payload p: 모바일 TMA 에서수집한일부 payload R: 플로우매칭이이루어진결과집합 모바일 TMA 에서수집된모바일어플리케이션정보를포함한플로우정보중, 플로우의시작시각이거의일치하는인터넷 Junction 상에서수집한플로우를먼저찾아낸다. 제안하는알고리즘은모바일 TMA 에서패킷손실없이수집하였다고가정하고플로우를구성하는패킷수및플로우크기가일치하는트래픽을우선찾는다. 비록모바일 TMA 에서패킷손실이발생하지만, 플로우를구성하는패킷수및플로우크기가일치하는트래픽이발견된다는것은패킷손실이일어나지않았음을의미하기때문에, 우선모바일 TMA 에서수집된플로우를구성하는패킷수및플로우크기정보가신뢰할수있다고가정하고해당정보를인터넷 Junction 상에서수집한트래픽으로부터찾아낸다. 만약해당항목에대해매칭되는플로우를찾지못한경우에는패킷손실이일어났다고판단하고, 해당플로우를찾아내기위해다른방식을적용한다. Wi-Fi 와유선랜은서로다른 physical layer 프로토콜을사용하기때문에각패킷당서로다른추가적인트레일러 byte 가붙어전송될수가있다. 따라서, 제안하는알고리즘은 2 번째로플로우를구성하는패킷수를신뢰하고플로우크기를신뢰할수없다고가정하고, 매칭되는플로우정보를 16

찾아내는과정을거친다. 이과정을통해서매칭되는플로우를찾지못하였을경우에는두정보모두신뢰할수없다고가정하고 destination IP 주소, destination 포트번호, 프토토콜종류만을비교하여플로우매칭작업을수행한다. 만약여러개가매칭되는플로우후보로검색될경우, 모바일 TMA 에서수집한 20 byte 의 payload 데이터를비교하는과정을거쳐정확히매칭되는플로우정보를찾는다. 이과정을거친이후에도여러개의매칭되는결과가있을경우에는해당트래픽은같은정보를표현하고있거나비슷한트래픽으로유추할수있을것이다. 4.2 검증 제안한플로우매칭알고리즘을검증하기위해, 제안한시스템을교내네트워크에적용하고, 안드로이드폰에모바일 TMA 를실제로설치하고임의의모바일어플리케이션을실행하여교내 Wi-Fi 네트워크에연결하였다. 발생한모바일트래픽은교내인터넷 Junction 에서손실없이수집하였으며, 플로우매칭알고리즘을실행하여실제플로우매칭되는플로우개수가몇개인지확인해보았다. 표 2 는페이로드매칭여부에따른플로우매칭알고리즘의결과를나타낸다. 제안하는플로우매칭알고리즘이모바일장비에서발생한모든플로우개수를찾지는못하였지만, 80% 이상의플로우를찾았으며, 이는매칭된결과를가지고 Ground Truth 의데이터역할을할수있음을의미한다. 페이로드를매칭하는과정은수행하는데비용이드는동작과정에해당한다. 그러나, 페이로드매칭을함으로써플로우매칭비율을높일수있으며, 제안하는알고리즘이보다안정적으로동작하기에모바일 TMA 에해당하는실제플로우를찾기위해서는페이로드매칭을같이수행하는것이좋다. 표 2. 플로우매칭알고리즘결과매칭된플로우개수및비율 페이로드를매칭하지않았을때 페이로드를매칭하였을때 찾은플로우개수 ( 총 : 2,692) 2,257 2,396 비율 83.84% 89.00% 구분 표 3. 모바일어플리케이션별플로우매칭결과 생성된플로우 페이로드비매칭시 개수 비율 모바일어플리케이션명 플로우개수 페이로드매칭시플로우비율개수 Multimedia 62 60 96.77% 62 100.00% player 멀티미디어 YouTube 56 55 98.21% 55 98.21% JJangLive 30 30 100.00% 30 100.00% Web 브라우저 Browser 1357 1038 76.49% 1107 81.58% SearchBox 10 10 100.00% 10 100.00% 메시징 Facebook 345 329 95.36% 334 96.81% & SNS 카카오톡 155 111 71.61% 133 85.81% Android 마켓 Market 54 52 96.30% 52 96.30% T Store 30 28 93.33% 30 100.00% ( 기타 ) 293 274 93.52% 291 99.32% ( 총 ) 300 270 90.00% 292 97.33% 표 3 은각모바일어플리케이션별로플로우매칭알고리즘을실행하였을때매칭된플로우개수및비율을나타낸다. 표 3 의결과에따르면제안하는알고리즘은웹브라우저와카카오톡모바일어플리케이션에대해낮은플로우매칭비율을보임을알수있다. 실험결과를분석해보면, 많은사람들이모바일웹브라우저와카카오톡모바일어플리케이션을많이사용하고있으며대부분사용자들은비슷한모바일웹페이지를이용하기에, 플로우특징만으로는플로우매칭알고리즘을실행하였을때높은매칭비율을보이지않음을유추할수있다. 반면, 카카오톡모바일어플리케이션은 HTTPS 프토토콜기반의암호화된트래픽을사용한다. 이때, 암호화된플로우는비슷한플로우크기및패킷수를이루고있기에플로우매칭비율이낮음을유추할수있다. 이와같이유추한가정을확인하기위해, 플로우매칭알고리즘의각과정당매칭되는비율을분석해보았다. 표 4 는플로우매칭알고리즘의각과정당모바일어플리케이션플로우가매칭되는비율을나타낸다. 웹브라우저와카카오톡의경우, 패킷개수만으로플로우매칭이이루어졌을때낮은비율로매칭결과가있음을알수있다. 이는웹 17

브라우저의경우비슷한대상호스트에접속하며, 카카오톡의경우대다수의유저가메시지를주고받는패턴이비슷하기에표 4 와같은결과가나왔음을유추할수있다. 표 4. 플로우매칭알고리즘의각과정별모바일 TMA 트래픽매칭비율 구분 모바일어패킷개수만으로매칭시패킷개수및플로우플리케이 ( 동일한패킷개수-> 더크기로매칭시션명많을때-> 더적을때 ) 페이로드비교시 Multimedia 11.29% 25.81% 88.71% 0.00% player 멀티미디어 YouTube 0.00% 80.36% 98.21% 0.00% JJangLive 0.00% 96.67% 100% 3.33% Web 브라우저 Browser 6.48% 66.32% 71.55% 3.54% SearchBox 0.00% 100% 0.00% 메시징 Facebook 19.42% 73.62% 76.81% 0.58% & SNS 카카오톡 7.10% 33.55% 65.81% 12.90% Android 마켓 Market 9.26% 50.00% 90.48% 0.00% T Store 9.90% 66.21% 86.69% 2.73% ( 기타 ) 10.33% 78.33% 94.33% 2.67% 5. 교내기숙사지역모바일트래픽분석 본장에서는제안하는시스템및시스템에서사용된플로우매칭알고리즘을교내캠퍼스에적용하여적용가능성을검증하고, 해당시스템을활용하여생성한모바일어플리케이션분류정보및이를활용하여교내기숙사모바일트래픽을모니터링및분석한결과를소개하고자한다. 5.1 교내모바일네트워크환경적용결과 POSTECH 의기숙사지역에는대략 4,000 명의학생, 연구원및직원들이거주하고있으며, 모든기숙사지역의거주자들은교내전체에설치된총 1,000 개의 Wi-Fi AP 또는유선네트워크접속을통해인터넷에접근가능하다. Endace EAG 4.3 GE 카드 [12] 가장착된광탭을이용한모니터링장치를활용해패킷손실없이 500Mbps 에해당하는 Ethernet 링크의기숙사트래픽을수집하였다. Tcpdump 툴을이용하여기숙사지역에해당하는모든 Wi-Fi AP 들의 IP 주소를필터링룰로적용하여기숙사지역 AP 에서발생된모든트래픽을수집하도록설정한후, 기숙사지역에서모바일 TMA 를실행하고, Ground Truth 데이터를얻고자하는모바일어플리케이션을실행하는동시에제안한시스템을구동하였다. 표 5 는 Ground Truth 수집실험에사용된 Trace 정보를나타낸다. 표 6 은얻고자하는모바일어플리케이션에대한정보및수집한 Ground Truth 데이터에대한플로우개수및플로우크기를나타낸다. 해당 Ground Truth 데이터는안드로이드버전 2.3 에해당하는 Gingerbread 에서모바일프로세스명을기준으로추출하였다. 안드로이드 OS 는리눅스기반의 OS 로, 터미널모바일어플리케이션을실행하거나디버깅모드로안드로이드장비에접속하여 ps 명령을입력하면현재실행중인해당모바일프로세스명을확인할수있다. 모바일 TMA 는해당모바일프로세스명을패킷정보와같이수집하고, 이정보를기반으로플로우매칭알고리즘을실행하여표 6 의결과를얻을수있었다. 대표적인동영상재생을지원하는 YouTube [13], 웹브라우저, 메시징및 SNS 모바일어플리케이션에해당하는카카오톡 [15] 및 Facebook [16], 마켓어플리케이션에해당하는안드로이드마켓및 T Store 모바일어플리케이션을대상으로하여 Ground Truth 데이터를수집하였다. 표 5. Ground Truth 수집실험에사용된 Trace 정보수집일자수집시작수집종료총패킷수총트래픽양 Trace 2011. 6. 12. 21:03:37 22:02:32 66,578,145 54.78GB 18

모바일어플리케이션명 표 6. 수집한 Ground Truth 데이터 모바일프로세스명 Ground Truth 데이터 플로우개수 플로우총크기 (bytes) Media player /system/bin/mediaserver 62 378,228,999 YouTube com.google.android.youtube 55 5,953,064 웹브라우저 com.android.browser 1,107 16,313,238 SearchBox com.google.android.googlequicksearc hbox 10 17,015 Facebook com.facebook.katana 334 1,925,338 카카오톡 com.kakao.talk 133 6,370,146 Android Market #1 android.process.media 52 126,897,330 Android Market #2 com.android.vending 30 2,005,156 T Store com.skt.skaf.a000z00040 291 94,138,064 해당 Ground Truth 데이터를이용하여모바일어플리케이션트래픽분류에활용가능한정보를생성할수있으며, 해당정보를활용하여트래픽의시간대분포등모바일어플리케이션에대한응용레벨의상세한트래픽정보를얻을수있다. 표 7 은표 6 에서수집한 Ground Truth 데이터를이용해수작업을거쳐생성한트래픽분류에활용가능한정보를나타낸다. 해당모바일어플리케이션분류정보를활용하여, 응용레벨모바일트래픽분류가가능하며, 이를통한트래픽분석이가능해진다. 그림 5 는표 7 의모바일어플리케이션분류정보를이용해 2011 년 4 월 16 일하루동안교내기숙사지역에서페이로드전체를수집한 236.3GB 트래픽을분석한결과를나타낸다. 교내기숙사지역모바일트래픽을특정일자에대해분석결과, 모바일웹브라우저를가장많이사용함을알수있었고, 멀티미디어재생과관련된트래픽이저녁및심야에급증하는것으로나타났다. 웹브라우저트래픽은전반적으로계속사용되는것으로나타났다. 또한, 사용자들은주로점심시간또는심야에안드로이드마켓또는 T Store 에접속하여모바일어플리케이션을검색하거나설치하는등의응용레벨기반의모바일트래픽사용현황을알수있었다. 표 7. Ground Truth 데이터를활용하여생성한모바일어플리케이션분류정보 모바일어플리케이션명 모바일프로세스명분류관찰항목비교내용 /system/bin/mediaserver stagefright/1.1, Media player HTTP User-Agent Android YouTube com.google.android.youtube HTTP User-Agent Android-YouTube/2 인터넷 ( 웹브라우저 ) com.android.browser HTTP User-Agent Mozilla/5.0, Android Facebook com.facebook.katana HTTP Host facebook.com or fbcdn.net 카카오톡 com.kakao.talk 110.76.140.0/24, 서브넷 203.246.172.0/24 Android Market #1 android.process.media HTTP User-Agent AndroidDownloadMan ager Android Market #2 com.android.vending HTTP User-Agent Android-Market/2 T Store com.skt.skaf.a000z00040 444, 8205, 9104, 9200, 포트번호 9401 19

그림 5. 응용레벨트래픽비율변화분석 (2011 년 4 월 16 일, POSTECH 기숙사지역 ) 6. 결론 본연구에서는모바일 TMA 를이용하여응용레벨에서모바일트래픽을모니터링및분석하기위해필요한정보를생성하기위한시스템구조를제안하였다. 모바일장비는처리속도가느리고, 메모리공간에한계가있어모바일장비에에이전트프로그램을설치하여모바일어플리케이션및트래픽정보를정확하게수집하는데한계가있다. 이를극복하기위해, 제안하는시스템에서는인터넷 Junction 상에서패킷손실없이트래픽을수집하고제안하는플로우매칭알고리즘을적용하여모바일 TMA 에서수집한불완전한정보를기반으로 Ground Truth 데이터를생성하였다. 생성한 Ground Truth 데이터를통해응용레벨의모바일어플리케이션분류에필요한정보를생성할수있었으며, 이를교내기숙사네트워크에적용하여교내기숙사지역의모바일어플리케이션트래픽모니터링및분석을수행하였다. 추후연구로써, 우선해당 Ground Truth 를활용해모바일트래픽에적합한트래픽분류방법을고안하고, Wi-Fi 및 3G 모바일트래픽을모니터링및분석가능한시스템및 iphone OS, Windows Mobile 등의다른모바일 OS 에대한모바일 TMA 를구현하여다양한모바일네트워크및여러플랫폼의모바일트래픽모니터링및분석을수행하고자한다. 일부모바일응용프로그램은 Wi-Fi 와 3G 에서다른프로토콜을사용하기도하는만큼, 이에대한고려가이루어져야할것이다. 그리고, 모바일어플리케이션분류에필요한정보를수작업으로생성하는대신, 기존인터넷트래픽분류에사용가능하였던분류방법들을적용하여모바일어플리케이션트래픽에적합한트래픽분류방법을찾고자한다. 뿐만아니라교내모든링크에대해트래픽모니터링이가능한시스템을구축하여학내전체트래픽에대한수집및분석을수행하고, 모바일트래픽과비모바일트래픽을응용레벨에서모니터링및분석하여모바일트래픽과비모바일트래픽의특성차이및그원인을정확하게분석할계획이다. 참고문헌 [1] A. A. Gokhale,"Introduction to Telecommunications", 2E p22~23, 2004. Distimo, The battle for the most content and the emerging tablet market, April, 2011, http://www.distimo.com/blog/2011_04_the-battle-for-the-most-content-andthe-emerging-tablet-market/. [2] B. Park, Y. J. Won, M. S. Kim, and J. W. Hong, Towards Automated Application Signature Genration for Traffic Identification, Proc. Of the IEEE/IFIP Network Operations and Management Symposium (NOMS 2008), April 2008, pp.160-167. [3] G. Maier, F. Schneider, and A. Feldmann, A First Look at Mobile Hand-held Device Traffic, Passive and Active Measurement, Zurich, Switzerland, Apr. 7-9, 2010, pp.161-170. [4] H. Falaki, D. Lymberopoulos, R. Mahajan, S. Kandula, and D. Estrin, "A First Look at Traffic on Smartphones", Internet Measurement Conference (IMC), 2010, pp 281-287. [5] A. Gember, A. Anand, and A. Akella, A Comparative Study of Handheld and Non-Handheld Traffic in Campus Wi-Fi Networks, Passive and Active Measurement, Atlanta, USA, Mar. 20-22, 2011, pp.173-183. [6] IANA, IANA port number list, http://www.iana.org/assignments/port-numbers. [7] P. Srisuresh and M. Holdrege, IP Network Address Translator (NAT) Terminology and Considerations, RFC 2663, August 1999. [8] M. Cotton and L. Vegoda, Special Use IPv4 Addresses, RFC 5735, January 2010. 20

[9] Tcpdump & libpcap, http://www.tcpdump.org/. [10] G. Aceto, A. Dainotti, W. de Donato, A. Pescape, "PortLoad: taking the best of two worlds in traffic classification," IEEE INFOCOM, 2010, pp. 1-5. [11] K.C. Claffy, H.-W. Braun, and G.C. Polyzos, A Parameterizable Methodology for Internet Traffic Flow Profiling, IEEE Journal on Selected Areas in Communications, vol.13, no.8, Oct. 1995, pp. 1481-1494. [12] Endace, DAG 4.3GE, http://www.endace.com/dag4_3ge.htm. [13] Google, Youtube, http://www.youtube.com/. [14] SK Telecom, T store, http://www.tstore.co.kr/. [15] Kakao, KakaoTalk, http://www.kakao.com/talk/en. [16] Facebook, Facebook for Android, http://www.facebook.com/android. 최영락 2009 포항공과대학교, 컴퓨터공학과학사 2009 ~ 2011 포항공과대학교, 정보전자융합공학부석사과정 2011 ~ 현재포항공과대학교, 정보전자융합공학부박사과정 < 관심분야 > 네트워크트래픽모니터링및분석, 클라우드컴퓨팅, Autonomic 네트워크관리 정재윤 2009 포항공과대학교, 컴퓨터공학과학사 2009 ~ 현재포항공과대학교, 컴퓨터공학과석박사통합과정 < 관심분야 > 네트워크트래픽분석, 네트워크관리, 스마트그리드 박병철 2006 포항공과대학교, 컴퓨터공학과학사 2006 ~ 현재포항공과대학교, 컴퓨터공학과석박사통합과정 < 관심분야 > 인터넷트래픽모니터링및분석, 응용트래픽분류, 네트워크관리및관리시스템 홍원기 1983 Univ. of Western Ontario, BSc in Computer Science 1985 Univ. of Western Ontario, MS in Computer Science 1985 ~ 1986 Univ. of Western Ontario, Lecturer 1986 ~ 1991 Univ. of Waterloo, PhD in Computer Science 1991 ~ 1992 Univ. of Waterloo, Post-Doc Fellow 1992 ~ 1995 Univ. of Western Ontario, 연구교수 1995 ~ 현재포항공과대학교컴퓨터공학과교수 2007 ~ 2010 포항공과대학교정보통신연구소장 2007 ~ 2011 포항공과대학교정보통신대학원장 2008 ~ 2009 포항공과대학교컴퓨터공학과주임교수 2008 ~ 현재포항공과대학교정보전자융합공학부장 < 관심분야 > 네트워크트래픽모니터링, 네트워크및시스템관리. 21