3G 모바일 네트워크의 이해

NHN 성능엔지니어링랩 장재완, 김일환

모바일 환경에서 모바일 네트워크는 쌀이나 공기와 같습니다. 언제 어디서나 인터넷에 연결될 수 있기 위해서는 3G나 LTE 같은 모바일 네트워크가 필요하기 때문입니다. 3G나 LTE는 자주 듣는 용어라 잘 알고 있다고 생각할 수 있지만, 정확히 이해하고 있는 사람은 많지 않을 것입니다. 이 글에서는 모바일 서비스 개발자에게 매우 유용한 정보인 모바일 네트워크 정보를 다루려고 합니다.

여기서 다루는 모바일 네트워크는 3G입니다. 국내의 모든 이동통신망 사업자는 전국적으로 LTE 망을 구축하였고, 이를 읍, 면 단위까지 확대하려 하고 있습니다. 하지만 2012년 5월 말 기준으로 LTE 사용자의 비율은 13% 정도에 불과할 정도로 3G 네트워크 사용자가 훨씬 많습니다(참고: 방송통신위원회 제공 통계 자료). 그리고 LTE가 3G를 완전히 대체하기까지는 오랜 시간이 걸릴 것으로 예상되므로 우선은 3G 네트워크에 대한 기본 지식을 갖추는 게 중요합니다.

3G 네트워크 소개

3G 네트워크란 3GPP(3rd Generation Partnership Project)라는 표준화 기구에서 제정한 UMTS(Universal Mobile Telecommunication System) 표준안을 따르는 네트워크를 의미한다. 여기서 G는 세대(generation)를 지칭하고, 숫자는 모바일 네트워크의 발전 단계를 나타낸다. 모바일 네트워크는 1G → 2G → 2.5G → 3G 단계로 발전해 왔고, 4G를 향해 나아가고 있다. 그리고 현재 보급하고 있는 LTE는 3.9G에 해당한다(4G에 해당하는 LTE는 LTE-Advanced라고 한다). 전반적인 모바일 네트워크 발전 과정은 음성 중심에서 데이터 중심으로, 저대역폭에서 고대역폭의 데이터 네트워크로 발전하고 있다고 할 수 있다.

한 세대에는 하나의 표준안만 있는 것은 아니다. 2G에는 GSM(Global System for Mobile Communications), CDMA(코드분할 다중접속, Code Division Multiple Access), TDMA(시분할 다중접속, Time Division Multiple Access) 방식 등이 있고, 3G에는 비동기식인 W-CDMA(광대역 부호분할 다중접속, Wideband Code Division Multiple Access), 동기식인 IMT-2000(International Mobile Telecommunication-2000)이, 4G에는 WiBro(Wireless Broadband), LTE-Advanced 방식이 있다.

그림 1은 3G 네트워크의 일반적인 구조를 보여준다.

그림 1 대표적인 3G망인 UMTS/GSM 구조

그림 1에 표시된 주요 시스템에 대한 설명은 다음과 같다.

• GSM RAN(Radio Access Network), GSM Core 2G 음성 통화를 처리하는 네트워크다.
• UTRAN(UMTS Terrestrial Radio Access Network) 단말기와 기지국이 무선 전파 신호를 통해 교신하는 무선망 구간이다.
• GPRS(General Packet Radio Service) Core 흔히 '코어 망'이라고 부른다. KT와 SKT가 소유한 유선 네트워크 구간이다.
• nodeB 흔히 말하는 '기지국 안테나'를 의미한다.
• Radio network controller(줄여서 'RNC'라고도 함) 안테나를 원격 조정하는 서버다. '기지국'의 두뇌에 해당한다.
• GGSN(Gateway GPRS Support Node) 각 통신망 사업자의 사설 네트워크와 망을 중계하는 (IPv4) 공용 인터넷 관문 처리 장치다.

이와 같은 3G 네트워크의 하부 구조는 모바일 애플리케이션에서 접근하지 못하도록 계층 구조로 매우 복잡하게 추상화되어 있다.

애플리케이션에서 접근할 수 있는 TCP/IP 스택은 단말기 운영체제와 GGSN 사이에 있는 PPP(Point-to-Point Protocol) 터널까지다. PPP 바깥에 있는 GTP(GPRS Tunnelling Protocol)와 AAL(ATM Adaption Layer)은 TCP/IP가 아닌 다른 네트워크다.

그림 2를 보면 알 수 있듯이, TCP/IP를 사용하려면 매우 복잡한, 추가적인 네트워크 구성이 필요하다. 네트워크 애플리케이션 관점에서 가상망을 구축하여 만든 3G 네트워크가 유선 네트워크와 다른 점은 여러 가지가 있다.

그림 2 3G 네트워크 프로토콜 스택

이제부터는 가상 네트워크 스택을 사용하는 3G 네트워크가 유선 네트워크와 어떻게 다른지 설명하고, 이를 바탕으로 애플리케이션을 개발할 때 어떤 점을 주의해야 하는지 알아보도록 하겠다.

단말기=사설 IP 기기, GGSN=거대한 공유기

단말기(스마트폰 또는 3G 피처폰)에 할당되는 IP 주소는 GGSN 내의 해당 통신사 네트워크에서만 유효한 사설 IP다. 그리고 공유기 역할을 하는 GGSN에는 단말기에 부여된 사설 IP와 공용 네트워크에서 사용할 공인 IP를 매칭하는 주소 변환 테이블이 있고, 여기서 사설 IP는 GGSN에서 공인 IP로 변환된다. GGSN을 단순화하여 3G 네트워크 사용자가 공유하는 PPP 서버+NAT 공유기라고 할 수 있다. 이런 이유로 공인 IP(GGSN IP) 하나에 수많은 단말기의 사설 IP가 1:N으로 매핑된다.

이런 환경에서 생기는 여러 문제점 중의 하나는 바로 단말기가 서버에 접속하기 전에는 서버가 단말기로 접근할 수 없다는 점이다. 단말기에서 비록 서버 소켓을 열고 접속이 들어오기를 기다리더라도 외부에서는 단말기의 리스닝 포트(listening port)에 SYN 패킷을 보낼 수 없다. 대신 단말기가 먼저 외부 소켓에 접속한 다음에야 외부에서 단말기로 원하는 데이터를 보낼 수 있다. 이런 이유로 푸시 시스템의 경우 단말기에서 서버에 대한 TCP 세션을 만들어 두고, 이 세션을 사용하여 푸시 데이터가 전송되도록 하고 있다. 그런데 이 방식에는 단말기와 서버 간의 세션이 끊기면 서버에서 단말기로 메시지를 보낼 방법이 없다는 문제가 있다. 그렇기 때문에 단말기에서는 어떻게 해서든 서버와의 연결을 유지해야 한다.

애플리케이션에서는 연결 상태를 알 수 없다

유선 네트워크와 달리 모바일 네트워크상에서는 단말기에서 소켓 API를 호출하는 방법으로 정상적인 연결 여부를 확인할 수 없다. 정상적인 연결 상태라는 결과가 나와도 실제로 통신이 불가능한 상태에 있을 수 있기 때문이다. 3G 네트워크에서는 단말기 이동으로 인해 네트워크 연결 정보가 변경되더라도, 단말기에 부여된 IP 주소나 열려 있는 TCP/UDP 소켓을 초기화하지 않고 계속 유지하려 한다. 덕분에 애플리케이션 개발자는 IP 이동성을 전혀 고려하지 않고 유선 네트워크와 동일한 방식으로 애플리케이션을 개발할 수 있다. 하지만 단말기의 이동이나 무선 전파 자원 사정에 따라 PPP/GTP-U(GPRS Core Network-U) 터널이나 AAL 가상 서킷의 상태가 시시각각 변경되고, 이로 인해 발생한 문제가 PPP 레이어까지 전달되지 않는 경우가 많다. 네트워크 연결은 운영체제가 관장하고 있기 때문에 연결을 맺은 후에 PPP에서 오류를 전달하지 않는다면 운영체제와 애플리케이션은 정상적인 소켓 연결 상태라고 판단할 수 밖에 없다.

이런 상태에서는 당연히 데이터를 전송할 수 없게 되니 단말기 운영체제는 ACK를 받지 못하고 TCP/IP 규약에 따라 지속적으로 재전송을 시도한다. 이렇게 재전송을 시도하는 중에 하위 계층 터널이 복구되면 그제야 패킷이 애플리케이션 서버까지 전달되는 것이다. 심한 경우, 단말기 애플리케이션에서 전송한 패킷이 30초가 지나서야 서버에 도달하기도 한다. 일정 시간 이상 PPP 터널을 복구하지 못하여 PPP 연결이 초기화되거나, 재전송에 실패하여 TCP 연결을 초기화할 시점이 되면 단말기 운영체제에서 애플리케이션으로 소켓 오류를 전달한다.

단말기 화면에서 볼 수 있는 안테나 아이콘은 기지국과의 무선 채널 연결 상태를 나타낸다. 기지국과의 무선 채널 연결 상태와 모바일 네트워크 스택 이상 발생 유무는 별개의 문제이기 때문에, 사용자는 '안테나 신호 강도는 충분한데 왜 연결이 안 되는 거야?'라고 생각할 수 있다. 따라서 3G 네트워크에서 애플리케이션을 설계할 때 소켓 API를 통한 확인이나 native API를 이용한 신호 강도 확인 결과와는 무관하게 언제든지 수십 초 이상 서버 불통이 발생할 수 있다는 점을 고려해야 한다.

3G 네트워크의 속도

일반 사용자나 애플리케이션 개발자 입장에서 가장 궁금한 사항은 아마 '3G 네트워크의 속도'일 것이다. 인터넷 속도 측정 앱 등으로 속도를 측정해 본다 해도 장소와 시간에 따라 차이가 많이 나기 때문에 기준을 잡기 어렵다.

일반적으로 네트워크의 속도는 크게 '대역폭(bandwidth)'과 '지연시간(latency)'을 기준으로 접근할 수 있는데, 대역폭은 용량이 큰 데이터를 내려받는 시간에 영향을 미친다. 3G 네트워크는 기본적으로 업로드와 다운로드 대역폭이 다른 비대칭 네트워크다. 2012년 5월 21일 기준으로 BenchBee(스마트폰 속도 측정 애플리케이션)로 측정한 10주 간의 통계 자료를 보면, 다운로드 속도는 1.9~2.0Mbps 정도이고, 업로드 속도는 0.8~0.9Mbps 정도다.

하지만 용량이 작은 데이터를 내려받는 경우에는 대역폭보다는 지연시간이 체감 속도에 더 큰 영향을 준다. 이는 TCP 세션이 회선 대역폭을 한계까지 활용하지 못하고 세션이 끝나 버리기 때문이다. 이로 인해 웹 서비스나 메신저, VoIP 같은 서비스의 품질은 대역폭보다 지연시간에 더 많은 영향을 받게 된다. 따라서 3G 네트워크상에서 구동하는 애플리케이션의 속도를 향상시키려면, 대역폭보다 지연시간에 더 많은 관심을 가져야 한다.

3G 네트워크의 지연시간

그림 3 TCP 핸드세이크를 통한 RTT 추정

모바일 네트워크는 네트워크 품질에 영향을 미치는 요소를 통제하기 어렵기 때문에 동일한 지점에서 같은 단말기를 이용하여 반복하여 품질을 측정한다 해도 대표적인 품질 지표를 얻어내기 어렵다. 따라서 충분히 많은 샘플을 획득하여 통계 분포를 살펴보는 작업이 필요하다.

다행히 네이버 서비스에는 수많은 사용자가 24시간 방문하고 있어 무선망 상태를 전체적으로 관측하기 유리한 면이 있다. 따라서 NHN의 서버에서 패킷을 수집하여 분석하면 네트워크 상태에 대해 많은 정보를 얻을 수 있다.

그림 3은 TCP 핸드세이크(handshake)를 포함하는 HTTP 시퀀스 다이어그램이다. 단말기에서 서버로 TCP 접속을 요청하면 SYN, SYN+ACK, ACK 패킷이 순서대로 단말기와 서버 사이를 이동한다. 이때 서버에서 SYN 패킷을 받는 시각과 단말기로부터 ACK 패킷을 받는 시각의 차이(A)를 계산하면, 해당 시점에 대한 단말기와 서버 사이에서 패킷이 왕복하는데 걸린 시간(RTT=round-trip time)을 알 수 있다. 단말기와 서버의 TCP 스택에서 발생하는 약간의 오버헤드와 오차를 무시하면 서버에서 단말기로 ping을 실행해서 얻는 RTT에 근사한 결과를 얻을 수 있다.

그림 4 3G 네트워크의 지연시간 누적 분포

이렇게 측정한 3G 네트워크의 RTT 누적분포는 그림 4와 같다. 통신망 사업자에 따라 차이가 있긴 하지만, 3G 네트워크의 전형적인 RTT는 100~200ms 정도로 파악된다. 참고로 동일한 방식으로 계측한 국내 유선망의 RTT는 20ms 이하로, 3G 네트워크의 전송 지연시간은 국내 유선 네트워크보다 10배 정도 더 느리다고 볼 수 있다. 유선 네트워크로 한국에서 미국, 유럽, 동남아에 있는 서버에 연결할 때의 RTT가 100~200ms라면, 3G 네트워크를 사용한다는 것은 유선 네트워크를 이용하여 이들 국가의 서버에 연결하는 것과 비슷하다고 볼 수 있을 것이다. 만약 3G 네트워크 이용자가 미국에 있는 서버로 접속한다면, 패킷 왕복 한 번에 대략 0.5초 정도가 걸리게 되는 것이다(모바일 네트워크 RTT+유선 네트워크 RTT).

패킷 왕복 시간과 HTTP 응답 성능의 관계

그림 5 HTTP GET 시퀀스 다이어그램

3G 네트워크의 RTT가 100~200ms라는 의미는 서버와 메시지를 한 번 주고받는 데 0.2초가 걸릴 수 있다는 것이다. 브라우저가 A.naver.com이라는 서버에서 100바이트 이미지를 하나 가져온다고 가정하자. 브라우저는 먼저 DNS 서버에게 A 서버의 IP를 묻는다. 그리고 A.naver.com 서버의 IP로 TCP 연결을 맺고, 이미지를 가져오기 위해 HTTP GET 요청을 보낸다. 그림 5는 이 과정을 나타낸 것이다. 이 경우 적어도 3번의 패킷 왕복이 필요하다. 다시 말해, 작은 패킷 하나에 불과한 이미지 하나를 가져오는 데 대략 0.6초에 가까운 시간이 필요하다.

그림 6 HTTP 리다이렉트를 사용할 때 웹 페이지를 방문하는 과정

HTTP 리다이렉트는 사용자 클릭 로그를 수집하기 위한 목적으로 대부분의 모바일 웹 링크에서 사용하고 있다(그림 6 참조). 사용자의 클릭 로그를 수집하기 위해 어쩔 수 없이 사용하고 있지만, 사용자가 하나의 웹 페이지에 방문을 하기까지 최대 6번의 패킷 왕복이 필요하고, 이는 3G 환경의 RTT인 100~200ms를 가정한다면, 대략 0.6초~1초에 가까운 시간이다. 그렇기 때문에 HTTP 리다이렉트가 꼭 필요한 경우가 아니라면 3G 네트워크에서는 가급적 사용하지 않는 것이 좋다.

RTT 값이 작은 유선 네트워크에서는 DNS 조회나 TCP 핸드세이크가 웹 성능에 큰 영향을 주지 않지만, RTT 값이 큰 3G 네트워크에서는 상대적으로 영향력이 크다. 그래서 웹 페이지 개발할 때 HTTP 요청 횟수를 줄이기 위해 CSS Sprite나 DataURI 같은 기법을 쓰기도 한다. 

3G 네트워크의 통신모드 전환지연

통신모드 전환지연(wake-up delay)이란 일정 시간 동안 인터넷과 연결되지 않은 상태로 있다가 인터넷에 연결했을 때 발생하는 2~3초 정도의 대기시간을 말하는데, 3G 네트워크상에서 인터넷에 연결할 때 발생할 수 있다.

그림 7 단순화한 3G 네트워크 구조

통신모드 전환지연이 발생하는 원인은 3G 네트워크 구조다. 그림 1의 3G 네트워크의 구조를 단순화하면 그림 7과 같다. 3G 네트워크에서는 여러 단말기가 무선 주파수를 공유하기 때문에 주파수 자원을 최대한 아껴 쓰도록 프로토콜이 동작한다. 그래서 단말기가 데이터를 전송하지 않는 동안에는 가급적 네트워크에 연결하지 않도록 설계되어 있다. 또한 단말기에서 기지국과 무선으로 통신하려면 많은 전력이 소모되기 때문에 필요할 때만 무선 통신 칩을 가동하고 그 외에는 잠자기 모드(sleep mode)를 유지하도록 설계되었다.

무선통신 채널이 해제된 유휴(idle) 상태에서 데이터 통신이 필요한 상황이 되면, 단말기는 통신사의 RNC와 시그널 메시지를 주고받아 통신사 내부 네트워크에 연결을 시도한다. 이런 시그널 메시지는 (통신사와 단말기의 설정에 따라 다르지만), 약 30여 개가 오고 가는데, 이 과정에서 약 2~3초의 지연이 생긴다.

통신모드 전환지연은 단말기가 유휴 상태에 있다가 깨어나 데이터 통신을 재개할 때만 발생한다. 실제로 m.naver.com(네이버 모바일)의 패킷을 분석해 본 결과, 통신모드 전환지연의 발생 빈도는 전체 PV(page view)의 10% 미만임을 알 수 있었다. 이는 대부분의 사용자는 일단 네트워크를 쓰기 시작하면 (유휴 상태로 전환되지 않을 정도로) 계속해서 사용한다는 것을 의미한다.

따라서 스마트폰 앱을 개발할 때 통신모드 전환지연을 고려하여 read() 타임아웃 값을 설정할 필요가 있다. 초기 통신의 타임아웃은 3초 이상으로 약간 길게 잡는 것이 좋다. 정상적으로 연결을 맺은 다음에는 (통신모드 전환 이후에는) 모바일 네트워크상에서 발생할 수 있는 패킷 유실을 감지하기 위하여 초기 설정한 read() 타임아웃 값을 초기 설정 값보다 작게 수정하면 좋다.

통신모드 전환지연과 사용자 경험

스마트폰 앱을 개발할 때는 통신모드 전환지연으로 인해 사용자가 앱의 수행 성능이 느리다고 오해할 수 있다는 점을 유념하자. 사용자가 3G 네트워크 특성을 이해한다 해도 장기간 떠 있는 스플래시 화면은 좋지 않은 사용자 경험을 만들 소지가 있다. 지연시간이 짧은 Wi-Fi 환경에서는 크게 문제가 되지 않지만, 3G 네트워크 환경에서는 통신모드 전환지연과 더불어 DNS 조회와 100~200ms에 이르는 RTT로 인해 최악의 경우 서버로부터 응답을 받기까지 4초 정도의 시간이 걸릴 수 있다. 이 문제를 방지하기 위해 이전 실행에서 얻은 데이터를 최대한 활용하여 사용자에게 의미 있는 화면을 먼저 보여주고, 네트워크에 연결된 후에는 서버로부터 받은 데이터를 보여주는 방식을 채택할 것을 권장한다.

TCP 세그멘테이션 및 혼잡 윈도우와의 관계

전송 지연시간이 긴 3G 네트워크의 단점을 극복할 수 있는 근본적인 방법은 데이터 전송 시의 패킷 왕복 횟수를 최대한 줄이는 것이다. 실제 물리적인 패킷의 왕복 횟수는 TCP의 동작에 영향을 받는다. TCP 프로토콜에서는 데이터를 여러 개의 여러 개의 패킷으로 나눠 송출한다. 이렇게 데이터를 나누는 단위를 MSS(maximum segment size)라고 하는데, 보통 이더넷 네트워크에서는 MSS가 1,460바이트다. 예를 들어, 애플리케이션에서 4,000바이트 데이터를 전송한다면, TCP에서는 1,460바이트 패킷 두 개와 80바이트 패킷 한 개로 나눠 전송된다.

3G 네트워크의 MSS는 이더넷보다 작다. 3G 네트워크 스택은 PPP 등의 VPN(virtual private network)으로 구성되어 있기 때문에 VPN을 운용하기 위한 패킷 헤더 정보가 추가되기 때문이다. 그림 8은 모바일 통합검색 서비스의 패킷을 2시간 정도 수집하여 3G 네트워크의 MSS 크기를 분석한 결과다.

그림 8 3G 네트워크의 MSS 분포

SKT는 1,380바이트의 MSS를, KT는 1,410바이트의 MSS를 주로 사용한다는 것을 알 수 있지만, 1,360바이트의 MSS도 상당수 있는 것으로 파악되었다. 보수적으로 접근하여 3G 네트워크의 MSS는 1,360바이트로 볼 필요가 있다. 즉, 데이터는 1,360바이트 단위로 나눠 전송된다고 예상해야 한다. 그러므로 패킷 왕복 횟수를 줄이려면 가급적 전송 데이터를 잘 패킹하거나 압축해서 1,360바이트의 배수 이내로 줄이는 것이 효과적이다.

하지만 10킬로바이트 이상의 큰 데이터를 전송할 때에는 TCP 혼잡 제어(congestion control) 메커니즘이 작용하므로 반드시 패킷 개수만큼 시간이 소요되는 것은 아니다. TCP는 혼잡 윈도우(congestion window)라는 방법으로 한번에 여러 개의 패킷을 전송할 수 있도록 고안되었다. 최초로 TCP 연결이 발생하면 먼저 패킷을 2개 보낸다. 그리고 상대로부터 ACK 패킷을 받으면 패킷 4개를 보내는데, 이와 같이 패킷 전송량을 2배씩 늘려간다.

그림 9는 서버가 TCP를 통해 단말기로 데이터를 전송할 때 시간에 따라 패킷의 개수가 어떻게 증가하는지 도식화한 것이다. 정확히 2배씩 증가하지는 않지만, 2개 송출 -> ACK 대기(약 0.15초) -> 3개 송출 -> ACK 대기 -> 3개 송출 -> ACK 대기 -> 5개 송출 -> ACK 대기 -> 10개 송출하는 식으로 패킷의 양이 증가하는 양상을 볼 수 있다.

그림 9 TCP 패킷 전송

이와 같이 TCP의 혼잡 윈도우는 작은 값으로 시작해서, 별다른 문제 없이 제때 ACK를 수신하면 2배씩 증가하는 방식으로 동작한다. 그러다가 회선 대역폭을 꽉 채우면 RTO(Retransmission TimeOut)이 발생하고 일시적으로 혼잡 윈도우가 늘었다 줄었다 하면서 최대 대역폭에 가까운 성능을 유지하게 되는 것이다.

최초에 TCP 연결이 맺어진 시점의 혼잡 윈도우의 값인 initial congestion window(initcwnd)는 성능 제어에 있어 매우 중요한 파라미터다. 이 값이 너무 크면 처음부터 과다하게 패킷 손실과 재전송이 발생하여 성능 저하와 망 부하를 초래한다. initcwnd 값은 TCP 표준안에서는 2로 되어 있지만, 최근에 나오는 Linux 배포판인 Centos 6.x의 initcwnd 값은 Google이나 Amazon의 실험에 따라 10으로 조정되어 있는 상황이다.

전력 소비량을 줄일 수 있는 방법은?

스마트폰 배터리 전력의 대부분은 디스플레이와 3G 네트워크 사용에 소모된다고 한다. 이 중에서도 디스플레이보다는 3G 네트워크 사용에 더 많은 전력을 소비한다고 알려져 있다. 그래서 실제로 얼마나 많은 전력을 사용하는지 SKT용 갤럭시 S2를 이용한 간단한 실험으로 전력 소모량을 측정해 보았다. Wi-Fi를 대조군으로 3G 네트워크를 실험군으로 삼고, 약 400초 동안 쉬지 않고 벌크 데이터를 보내는 경우와, 주기적으로 일정량의 데이터를 보내는 Android 앱을 만들어 배터리 소모량을 측정했다. 데이터(payload) 크기는 64바이트와 1,300바이트의 두 가지 경우로 나누어 측정했고, 3G 네트워크 사용 이외의 다른 조건의 영향력을 최소화하기 위해 화면 밝기는 최소로 설정했다.

그림 10 네트워크를 사용할 때 소모되는 전력량

Wi-Fi의 경우 많은 양의 데이터를 지속적으로 전송할 때 전력이 가장 많이 소모되는 것으로 측정됐는데, 이는 Wi-Fi 환경에서의 전송 속도가 3G 환경보다 빨라 더 많은 데이터를 전송하기 때문에 발생하는 현상이다. 실제로 Wi-Fi 환경에서 패킷 하나를 전송하는 데 필요한 전력은 3G 환경에서 필요한 전력의 10~20% 정도에 불과하다.

그림 10을 통해 3G 환경에서는 데이터 전송 주기나 데이터 크기가 Wi-Fi 환경에 비해 전력 소모에 거의 영향을 미치지 않는 것을 알 수 있다. 이런 특성은 3G 네트워크의 구조와 RNC(그림 7 참조)에서 운용하는 RRC(무선 자원 관리, Radio Resource Controller) 프로토콜의 특성에서 기인한다. 3G 네트워크에서는 한정된 무선 자원을 여러 단말기가 공유해서 쓰기 때문에 가급적이면 꼭 필요한 경우에만 자원을 사용하도록 만들어 졌다. 그리고 단말기에서도 3G 네트워크를 사용하면 전력량이 증가하기 때문에 가능하면 데이터 전송이 필요할 때만 3G 네트워크에 접속하고 그 외의 경우에는 무선 채널을 해제하는 것이 유리하고, 이런 결정은 RNC에서 한다. RRC 프로토콜은 다음과 같이 크게 3가지 통신 모드를 지원한다.

• IDLE: 무선 채널을 해제하고 통신을 하지 않는 상태. 잠자기 모드(sleep mode)라 볼 수 있다.
• CELL_FACH: 무선 채널을 점유하고 있지만, 낮은 속도로 통신할 수 있는 상태. 전력 소모가 적다.
• CELL_DCH: 일반적인 데이터 전송이 진행되는 상태. 전력 소모가 크다.

실제로 3G 표준에서 지원하는 통신 모드는 이보다 많지만, 국내 3G 네트워크 분석 결과 대부분 IDLE과 CELL_DCH 상태만 사용하는 것을 알 수 있었다.

그림 11 단말기의 통신 모드 전환

IDLE 상태에 있는 단말기에서 데이터가 전송되면 단말기 상태는 CELL_DCH로 전환된다(그림 11 참조). 이때 상태가 전환되는데 걸리는 시간을 앞서 설명한 통신모드 전환지연(wake-up delay)이라고 한다. 데이터 전송이 완료되면 cool-down timer가 동작하여 CELL_DCH에서 IDLE 상태로 전환된다. 즉, 데이터 전송 완료 후에 바로 IDLE 상태로 전환되지 않고 일정 시간 동안 CELL_DCH 상태에 머문다. 갤럭시 S2의 경우 이 시간은 약 20초다. 이 20초 동안 아무런 데이터 전송이 발생하지 않아도 CELL_DCH에 머무르면서 많은 전력이 소모된다. 문제는 패킷 하나를 보내더라도 이와 같이 CELL_DCH로 상태가 변하고 cool-down timer에 의해 IDLE 상태로 변하기까지 20초 동안은 아무 의미 있는 일을 하지 않은 채로 전력을 고스란히 소모한다는 점이다. 참고로 몇몇 단말기에서는 서비스 모드 또는 필드 테스트 모드로 들어가면 현재 통신 모드를 확인할 수도 있다.

그림 12 64바이트 패킷을 1초 간격으로 ping할 때 소모되는 전력량(갤럭시 S2, SKT)

그림 12는 SKT용 갤럭시 S2로 64바이트의 패킷을 1초 간격으로 ping할 때 발생하는 소비전력을 보여준다. 통신을 시작하자 CELL_DCH로 상태가 바뀌면서 소비전력이 증가한다. 하지만 CELL_DCH 상태를 유지하는 데 전력이 많이 소모될 뿐 실제로 데이터가 전송되는 순간에 소모되는 전력량은 그다지 많지 않다는 것을 알 수 있다. 이런 이유로 3G 네트워크 환경에서는, 데이터를 주기적으로 보내든, 지속적으로 보내든, 사용하는 전력량에는 큰 차이가 나지 않는 것이다(그림 10 참조).

3G 네트워크 환경에서 데이터 통신에 필요한 전력 사용량을 줄이는 방법은 데이터 통신을 한번에 몰아서 사용한 후 빨리 IDLE 상태로 전환되도록 하는 것이다 가능한 주기적인 데이터 전송은 피하고, 주기적인 데이터 전송이 필요하다면 단말기의 cool-down timer를 고려한다.

cool-down timer의 설정은 단말기와 통신사에 따라 다르기 때문에 구체적인 모범 사례를 제시하기 어렵다. SKT용 갤럭시 S와 갤럭시 S2의 경우 약 20초고, KT용 iPhone 4의 경우 약 2.5초다. iPhone 4의 cool-down timer 시간이 짧은 이유는 iPhone 4와 KT가 3G 표준의 확장 기능인 fast dormancy를 구현했기 때문인 것으로 보인다.

주의할 사항은 주기적인 통신이 필요할 때 주기를 cool-down timer에 정확히 맞추면 패킷 손실률이 50% 가까이 올라간다는 점이다. 예를 들어, SKT용 갤럭시 S2에서 20초 주기로 데이터를 내려받아 콘텐츠를 업데이트하면, 업데이트 요청 패킷이 손실될 확률이 50% 가깝게 올라간다. 정확한 내부 동작은 알 수 없지만, CELL_DCH 상태와 IDLE 상태를 오가는 도중에 데이터 통신이 불안정해지면서 발생하는 문제가 아닐까 추측하고 있다.

음영지역과 TCP

그림 13 음영지역에서 TCP의 상황 인식

기본적으로 TCP에서는 보낸 패킷에 대한 ACK 패킷 도착 여부로 네트워크 상태를 파악한다. ACK 패킷이 도착하지 않으면, 보낸 패킷이 유실되었거나 네트워크가 아주 느리다고 판단한다. 그러면 고속 패킷 전송을 포기하고, 네트워크가 정상으로 돌아올 때까지 패킷을 천천히 조금씩 재전송하기 시작한다. 그러나 3G 네트워크 환경은 모바일 네트워크이기 때문에 과거 TCP가 만들어지던 시절의 유선 네트워크 상황과는 매우 다르다. 모바일 네트워크에서는 음영지역과 같은 변수를 고려할 필요가 있기 때문이다.

그림 13에서 볼 수 있듯이 음영지역에서는 네트워크의 상황이 급변한다. 고속으로 데이터를 전송하다가도 음영지역으로 이동하니 갑자기 통신 속도가 떨어진다. 하지만 음영지역을 벗어나니 다시 고속 통신이 가능한 환경이 구성된다. 그런데 TCP 계층에서는 이런 하부 네트워크 계층의 상태를 알 수가 없다. 오직 ACK 패킷의 도착 여부로만 통신 상태를 파악한다. 음영지역에 들어가는 것도 바로 파악하지 못하고, 음영지역에서 빠져 나와도 여전히 통신 상태가 열악한 곳에 있다고 착각한다.

그림 14 TCP의 패킷 재전송 방식

다음에서는 모바일 웹 브라우저를 이용할 때 유실되는 패킷을 처리하는 방법을 설명한다. 그림 14와 같이 TCP에서는 유실된 패킷이 SYN 패킷이냐 여부에 따라 재전송하는 방식이 다르다. SYN 패킷이 유실된 경우에는 initRTO(재전송 타임아웃)의 영향을 받고, 그 외의 패킷이 유실된 경우에는 RTO(재전송 타임아웃)의 영향을 받는다. 각 경우 타임아웃 설정 값은 운영체제에 따라 다르다.

SYN 패킷이 유실될 때 브라우저와 TCP의 동작

그림 15 SYN 패킷 유실 - Android 브라우저

그림 15는 브라우저에서 SYN 패킷이 유실됐을 때의 동작 과정을 보여준다. Android의 initRTO는 3초(RFC2988에 정의된 값 그대로 사용)이며, 패킷이 유실될 때마다 2배씩 재전송 시간을 연장하며 SYN 패킷 전송을 재시도한다. 하지만 3번째 시도 전에 SYN 패킷이 도착하지 않으면, 커널은 연결 실패를 반환한다. 그러면 애플리케이션인 브라우저는 새 소켓을 생성하여 접속을 시도한다. 그래도 접속이 성공하지 않으면 접속 오류를 표시하고 더 이상 연결을 시도하지 않는다. 이것으로 봤을 때 Android 브라우저는 2번의 연결을 시도하는 것을 알 수 있다.

그림 16 SYN 패킷 유실 - iOS Safari 브라우저

그림 16은 iOS의 Safari 브라우저에서 SYN 패킷이 유실됐을 때의 동작 과정을 보여준다. Android에서보다 더 공격적으로 TCP 접속을 시도하고 있을 것을 알 수 있다. 1초 간격으로 SYN 패킷을 5번 보내고, 그 후에는 시간 간격을 2배씩 늘여가며 접속을 시도한다. 그러다가 60초 동안 접속이 성공하지 않으면 접속 오류를 표시하고 종료한다. 이것으로 Safari의 연결 타임아웃(connect timeout)은 약 60초일 것으로 추정된다.

TCP 세션 도중에 일반 패킷이 유실되는 경우

SYN 패킷이 아닌 그 외의 패킷이 유실됐을 때는 단말기와 서버 사이의 RTT에 비례하는 시간으로 RTO가 결정된다. 지정된 시간이 지나도 전송한 패킷에 대한 ACK 패킷이 도착하지 않으면 재전송이 시도되고, RTO는 2배로 늘어난다. 이와 같이 재전송 타이머가 2배씩 늘어나는 방식을 바이너리 백오프(binary backoff)라 한다.

그림 17 패킷 유실 - Android 브라우저

Android 브라우저에서 GET 요청 패킷이 유실되면 그림 17과 같이 패킷을 재전송한다. 약 30초 동안 TCP는 바이너리 백오프를 하면서 패킷을 재전송한다. 그래도 패킷이 제대로 전송되지 않으면 기존 소켓을 닫고 새로운 소켓을 열어 해당 GET 요청을 다시 시도한다. 이런 방식으로 측정한 결과 Android 브라우저의 TCP 소켓에 대한 read() 타임아웃 값은 30초, GET 요청에 대한 전체적인 타임아웃 값은 50초 정도로 예상된다.

그림 18 패킷 유실 - iOS 사파리 브라우저

iOS도 Android와 비슷하게 동작한다. 다만 새로운 소켓을 만들지 않고, 기존 소켓으로 60초 동안 시도한 후에도 ACK가 오지 않으면 접속 오류를 표시한다. 이로 보아 TCP 소켓에 대한 read() 타임아웃 값을 60초로 설정한 것으로 알 수 있다.

서버와 통신을 빨리 복구하고 싶을 때

그림 19 TCP 재전송으로 인한 반응성 저하

TCP 재전송 타이머는 음영지역과 같은 모바일 네트워크 특성을 고려하지 않았기 때문에, 몇 번의 재전송이 진행된 이후에는 재전송 타임아웃 값이 커지면서 반응성이 크게 떨어지는 일이 생길 수 있다. 그림 19에서 볼 수 있는 것처럼 RTO가 10초가 넘어가는 시점에 음영지역에서 벗어나면 하위 계층의 연결이 정상화됐음에도 불구하고 8~20초를 기다려야 서버와의 통신이 재개된다. 이를 고려한다면, 무작정 TCP의 재전송 타이어만 의지하기 보다는 애플리케이션 레벨에서 5~10초 정도의 timeout을 설정하고 재전송을 시도하는 것이 효율적일 것이다.

TCP/UDP 연결 유지를 위한 heartbeat 주기

앞서 설명한 바와 같이 3G 네트워크는 거대한 NAT(Network Address Translation)에 비유할 수 있다. 다시 말하면, NAT에서 발생하는 여러 제약 사항이 3G 네트워크에서 발생한다는 것이다. 이 중 하나가 NAT 세션 유지 시간이다.

3G 네트워크에서 NAT 서버 역할은 GGSN이 담당한다(그림 7 참조). 새로운 단말기가 TCP 접속을 요청하면, 해당 TCP 요청을 GGSN이 가지고 있는 공인 IP 주소로 바꾸어서 공용 네트워크에 있는 서버와 TCP 연결을 맺는다. 이 과정에서 접속한 단말기의 <사설IP:포트>를 <공인IP:포트>로 매핑한 세션 정보를 GGSN 내부에 유지한다. 이 정보가 유지되는 한 단말기와 서버는 정상적으로 패킷을 주고받을 수 있다. 본래 UDP(User Datagram Protocol)에는 연결이라는 개념이 없지만, NAT 장비는 UDP 트래픽에 대해서도 암묵적인 세션이 생성된 것으로 간주하여 일정 시간 동안 <사설IP:포트>와 <공인IP:포트> 간의 매핑 테이블을 유지한다.

표 1 NAT 세션 유지 시간

	KT	SKT
UDP	60초	90초
TCP	1시간	1시간

하지만 이 정보를 영원히 유지할 수는 없기 때문에, 일정 시간 동안 이 세션을 통해 주고받은 패킷이 없으면 해당 정보를 삭제하고 TCP 연결을 강제로 종료한다. 그리고 강제로 종료된 경우 해당 단말기와 서버는 더 이상 같은 소켓 연결로 통신할 수 없게 된다. 표 1은 통신사별로 TCP와 UDP에 대해 설정한 NAT 세션 유지 시간을 실험을 통해 알아낸 것이다. 이 정보를 통해 항상 TCP 연결을 유지해야 한다면, NAT 세션이 삭제되기 전에 Keep-Alive 메시지를 보내야 한다는 점을 알 수 있다.

마치며

3G 네트워크는 그 자체도 굉장히 복잡해서 이해하기 어렵고, 단말기와 네트워크 사업자별로 특성이 다르기도 해서, 언제 어디서나 네트워크를 효율적으로 사용할 수 있게 하는 단일 개발 방법이 존재하지 않는다. 이 때문에 애플리케이션이 요구하는 데이터 통신 패턴과 특성에 따라 적절한 튜닝이 필요하다. 그렇기에 3G 네트워크의 특성을 이해하고 애플리케이션 개발에 임한다면 더 나은 사용자 경험을 제공할 수 있을 것이다.

출처: http://helloworld.naver.com/helloworld/textyle/111111