이동통신망 성능의 비밀
저자: 브라이스 하워드
1. 소개
지난 몇 년 간 셀 방식 이동통신망(mobile cellular network)의 성능이 크게 향상되었다. 그러나 증폭된 네트워크 잠복지연(latency) 때문에，그런 성능 향상의 이점을 최대한 취하지 못하는 모바일 응용 프로그램들이 많다.
예전부터 잠복지연은 모바일 네트워킹과 동의어였다. 최근 몇 년 동안 진척이 있긴 했지만，네트워크 잠복지연의 감소는 네트워크 속도의 증가와 발을 맞추지 못했다. 이러한 불일치의 한 결과로, 네트워크 트랜잭션의 성능을 제한하는 요인이 처리량이 아니라 바로 잠복지연인 경우가 많다.이번 장은 논리적으로 두 부분으로 나뉜다.
첫 부분에서는 잠복지연 문제에 영향을 미치는 셀 방식 이동통신망의 특이 사항들을 살펴보고,
둘째 부분에서는 높아진 네트워크 잠복지연이 성능에 미치는 영향을 최소화하기 위한 소프트웨어 기법들을 소개한다.
2 잠복지연의 근원들
잠복지연은 자료 패킷이 하나의 네트워크 또는 일련의 네트워크들을 거쳐서 전송되는 데 필요한 시간을 나타낸다. 이동통신망은 대부분의 인터넷 기반 통신에 이미 존재하는 잠복지연을 더욱 증폭시키는데, 여기에는 네트워크 종류(이를테면 HSPA+ 대 LTE，사업자(AT&T 대 Verizon)，주변 상황(정지 상태 대 운전 중, 지리，하루 중 시간 등) 등의 여러 요인이 관여한다. 모바일 네트워크 잠복지연의 정확한 수치를 언급하기는 어렵지만，수십 밀리초에서 수백 밀리초로 다양하다는 점은 확실하다.
왕복운행 시간(Round-trip time, RTT)은 하나의 자료 패킷이 그 원천에서 출발해서 목적지에 갔다가 다시 돌아오는 데 걸리는 잠복지연을 측정한 것이다. 왕복운행 시간은 여러 네트워크 프로토콜의 성능에 엄청난 영향을 미친다. 그 이유를 유서 깊은 스포츠인 탁구에 비유해서 설명해 보겠다.
보통의 탁구 시합에서 탁구공이 선수들 사이를 왕복하는 데 걸리는 시간은 인식하기 힘들 정도로 짧다. 그러나 선수들이 탁구대에서 멀어지면 아무 일도 하지 않고 공이 오길 기다리는 데 걸리는 시간도 길어진다. 선수들 사이의 거리가 보통일 때에는 5분 걸리는 시합이라도，선수들이 수백 미터 떨어져 있으면 몇 시간이 걸릴 수 있다(좀 황당한 가정이겠지만). 두 선수를 클라이언트와 서버로 대체하고 선수들 사이의 거리를 왕복운행 시간으로 대체한다면 잠복지연이 얼마나 큰 문제인지 알 수 있을 것이다.
대부분의 네트워크 프로토콜은 탁구 시합처럼 두 단위가 서로 메시지를 주고받으면서 작동한다. 논리적인 네트워크 세션을 확립하고 유지하려면(TCP 에서)，또는 서비스 요청을 수행하려면(HTTP에서) 그러한 메시지 왕복 교환이 필요하다. 그러한 메시지 교환 도중에 실질적인 자료는 거의 전송되지 않으며，따라서 네트워크 대역폭의 대부분이 쓰이지 않는다. 잠복지연은 이러한 과소활용의 규모를 더욱 키운다. 모든 메시지 교환은 적어도 네트워크의 왕복운행 시간만큼의 지연을 유발한다. 그러한 지연이 누적되면 성능에 커다란 영향이 미친다.
10KiB짜리 객체 하나를 내려 받기 위한 HTTP 요청에 4회의 메시지 교환이 필요하며, 왕복운행 시간은 100ms(이동통신망에서는 상당히 적당한 수준이다)라고 하자. 그러면 10KiB를 내려 받는 데 적어도 400ms가 걸린다. 즉，유효 산출량이 초당 25KiB인 것이다.
이 예에서 네트워크의 대역폭(bandwidth)은 전혀 무관함을 주목하기 바란다. 네트워크 자체가 아무리 빠르다고 해도 결과는 여전히 25KiB/s로 동일하다. 이런 부류의 연산의 성능을 개선하는 데 필요한 명확한 전략은 오직 “네트워크 클라이언트와 서버 사이의 왕복 메시지 교환을 피한다” 뿐이다.
3 셀 방식 이동통신망의 특성
다음은 잠복지연에 영향을 주는 셀 방식(센신너 이동통신망의 구성요소와 규약을 간략하게만 설명한 것이다.
셀 방식 이동통신망은 고도로 특화된 기능들을 가진 일련의 구성요소들이 연결된 형태이다. 그러한 구성요소들 각각은 어떤 방식으로든 네트워크 잠복지연에 기여하는데, 기여 수준은 다양하다. 셀 방식 통신망에는 무선 자원 관리 같은 고유한 규약들이 존재하는데，이들 역시 이동통신망의 잠복지연에 영향을 미친다.
기저대역 처리기
대부분의 이동기기에는 아주 정교한 컴퓨터 두 대가 들어 있다. 하나는 운영체제와 응용 프로그램들을 주재하는 응용 프로그램 처리기(AP)이다. 이는 데스크톱에 비유할 수 있다.
또 하나는 모든 무선 네트워크 기능을 담당하는 기저대역 처리기(baseband processor)로，컴퓨터 모뎀에 비유할 수 있다. 물론 기저대역 처리기는 전화선이 아니라 무선 전파를 사용한다는' 점이 다르다(실제로 여러 이동전화기들은 기저대역처리기를 AT 비슷한 명령 집합으로 관리한다.
http://www.3gpp.org/ftp/Specs/html-info/0707.htm을 보라
기저대역 처리기는 고정된 양의 잠복지연을 기여하는데，보통의 경우 그 잠복지연은 무시할 수 있다. 고속 무선망에서 일어나는 일은 엄청나게 복잡하다. 대부분의 네트워크 통신에서，고속 무선 통신에 필요한 정교한 신호 처리는 수 마이크로초에서 수 밀리초에 이르는 고정된 크기의 지연을 기여한다.
기지국
셀 사이트cell site나 셀 타워cell tower라고도 부르는 통신 기지국(tranaceiver base satation)은 이동통신망의 접속점(access) 역할을 한다.
각 기지국은 셀(cell)이라고 하는 단위 영역의 범위 안에서 네트워크 접근을 제공하는 임무를 담당한다.
기지국의 서비스를 받는 이동기기와 마찬가지로 기지국 자체에도 고속 무선망에 관련된 복잡한 처리가 요구되며, 그래서 기지국도 이동기기와 거의 비슷한 잠복지연을 기여한다. 그러한 잠복지연 자체는 무시할 수 있는 수준이긴 하지만，기지국이 동시에 수백에서 수천 개의 이동기기들에게 통신을 제공해야 한다는 점을 주목해야 한다. 이 때문에 구체적인 처리량과 잠복지연은 기지국 시스템에 걸린 부하에 따라 다를 수 있다. 예를 들어 공개 행사 때문에 사람이 많이 모인 지역에서는 기지국의 처리 능력이 한계에 달해서 네트워크가 느리고 불안정해지기도 한다.
최신 세대의 이동통신망에서는 기지국의 역할이 확장되어서，기지국이 이동기기들을 직접 관리하기까지 한다. 예전에는 무선망 제어기(radio network controller, RNC)가 했던 여러 기능들, 이를테면 네트워크 등록이나 전송 일정 조정 같은 것들을 이제는 기지국이 처리한다. 이후에 설명하겠지만，최신 세대의 셀 방식 이동통신망의 잠복 지연 감소에는 이러한 역할 변화가 큰 몫을 했다.
역송망
역송망(backhaul network, 백홀 망)은 기지국과 제어기，그리고 핵심망 사이의 전용 WAN 연결이다. 역송망은 오래 전부터 잠복지연의 커다란 근원으로 악명이 높다.
고전적인 역송망 잠복지연은 구식 이동통신망(GSM, EV-DO)에 쓰인 회로교환식 또는 프레임 기반 전송 프로토콜들에서 비롯된다. 그런 프로토콜들에서는 논리적인 연결들이 미리 배정된 짧은 시간 동안 자료를 받거나 보낼 수만 있는 하나의 채널로 표현된다. 이런 동기적인 성격 때문에 잠복지연이 생긴다. 반면 최신 세대의 이동통신망은 비동기 자료 전송을 지원하는 IP 기반 패킷 교환 역송망을 사용한다. 이러한 변화 덕분에 역송망의 잠복 지연이 크게 줄었다.
물리적 기반구조의 대역폭 한계는 예나 지금이나 병목이다. 역송망들 중에는 요즘의 고속 이동통신망이 감당할 수 있는 대량의 순간 통신량 부하를 처리할 수 있도록 설계되지 않은 것들이 많다. 그리고 그런 역송망들은 통신량이 많은 경우 잠복지연과 처리량이 크게 요동치는 현상을 보이는 경우가 많다. 통신망 사업자들이 그런 역송망들을 최대한 빨리 업그레이드하려고 노력하긴 하지만，다수의 네트워크 기반구조에서 이 구성요소는 여전히 약점으로 남아 있다.
무선망 제어기
관례적으로 무선망 제어기(RNC)는 근처의 기지국들과 그 기지국들에 접속하는 이동기기들을 관리한다.
무선망 제어기는 이동기기들의 활동을 신호 보내기(signaling)라고 부르는 메시지 기반 관리 방식을 이용해서 조정한다. 무선망 제어기에 관련된 위상 구조 때문에，이동기기들과 제어기 사이의 모든 메시지 소통이 반드시 하나의 잠복지연 높은 역송망을 통해서 이루어지게 된다. 그 자체도 그리 바람직하지 않지만, 여러 네트워크 등록，전송 일정 조정 같은 네트워크 연산들에 여러 번의 왕복 메시지 교환이 필요하다는 점 때문에 상황이 더욱 나빠진다. 이 때문에 전통적으로 무선망 제어기는 잠복지연의 주된 근원으로 작용했다，앞에서 언급했듯이 최신 세대의 이동통신망에서는 무선망 제어기가 담당하던 이동기기 관리 역할의 상당 부분을 기지국 자체가 처리한다. 이러한 설계싱의 결정 덕분에 여러 네트워크 기능들에서 역송신에 의한 잠복지연이 제거되었다
핵심망
핵심망(core network)은 통신망 사업자의 사설망과 공용 인터넷 사이의 관문(게이트웨이) 역할을 한다. 통신망 사업자가 인라인 네트워킹 장비를 이용해서 서비스 품질(QoS) 정책이나 대역폭 계량을 강제하는 지점이 바로 여기이다. 원칙적으로, 네트워크 소통에 뭔가가 끼어들 때마다 잠복지연이 증가된다. 현실적으로 이 지연은 대체로 무시할 수 있는 수준이지만, 어쨌든 그런 지연이 존재한다는 점은 인식할 필요가 있다.
이동기기의 절전 기능
이동통신망 잠복지연의 가장 중요한 원천 중 하나는 이동전화기 배터리의 제한된 용량과 직접 관련되어 있다. 고속 이동기기의 네트워크 무선 신호는 무선 통신 작동 시 약 3W의 전력을 소비할 수 있다. 이는 iPhone 5의 경우 한 시간을 조금 넘기면 배터리가 모두 소진되는 정도의 수치이다. 그래서 이동기기들은 기회만 되면 무선 회로에서 전력을 제거하거나 줄이려고 노력한다. 배터리 수명을 연장하는 데에는 이상적이겠지만，무선 회로에 전원이 다시 공급되고 나서 어느 정도 시간이 흐른 후에 실제로 자료를 보내거나 받을 수 있게 되는 시동지연(startup delay)이 발생하게 된다.
모든 셀 방식 이동통신망 표준은 전력 보존을 위한 무선 자원 관리(radio resource managemet, RRM) 방식을 공식화한다. 대부분의 RRM 관례들은 활성하(active)，유휴(idle), 단절(disconnected)이라는 세 가지 상태를 정의한다. 각각의 상태는 시동 잠복지연과 절전 사이의 서로 다른 절충을 나타낸다.
활성 상태
활성 상태는 최소한의 잠복지연으로 자료를 고속으로 보내거나 받을 수 있는 상태를 나타낸다.
이 상태는 자료를 보내거나 받지 않을 때에도 대량의 전력을 소비한다. 네트워크의 활동이 잠시(1초 미만인 경우도 많음) 멈추면 상태 전이가 발동해서 저전력의 유휴 상태가 된다. 이것이 성능에 미치는 영향에 주목할 필요가 있다. 네트워크 트랜잭션 도중에 일시 정지 기간이 충분히 길면 이동기기가 활성 상태와 유휴 상태를 오가게 되며，그러면 추가적인 지연이 발생할 수 있음을 조심해야 한다.
유휴상태
유휴 상태는 저전력과 적당한 시동 잠복지연 사이의 타협에 해당한다.
이 상태에서 이동기기는 여전히 네트워크에 연결되어 있지만 자료를 보내거나 받지는 못한다. 그러나 활성 상태에서 처리해야 할 네트워크 요청(유입 자료 등)을 받는 것은 가능하다. 유휴 상태에서 일정 기간 동안(보통은 1분 내외) 네트워크 활동이 없으면 기기는 단절 상태로 전이한다.
유휴 상태는 두 가지 방식으로 잠복지연에 기여한다.
첫째로, 무선 회로에 전원이 다시 공급되고 해당 아날로그 회로가 동기화되기까지에는 일정한 시간이 필요하다.
둘째로, 유휴 상태에서 전력을 더욱 아끼기 위해 이동기기는 간헐적으로만 무선 신호를 감지하므로 네트워크 통지에 대한 반응에 약간의 지연이 생긴다.
단절 상태
단절 상태는 전력 사용량이 가장 작고 시동 지연은 가장 크다.
이 상태에서 이동기기와 이동통신망의 연결은 완전히 끊어져 있으며，무선 기능도 비활성화되어 있다. 단，특별한 방송(broadcast) 채널을 통해 들어오는 네트워크 요청을 감지하기 위해 무선 기능이 가끔씩 활성화된다.
단절 상태에서는 유휴 상태에서와 동일한 잠복지연들 외에 네트워크 재연결에 의한 잠복지연도 존재한다. 이동통신망에 연결하는 것은 여러 번의 메시지 교환(‘신호 보내기’)이 관여하는 복잡한 공정이다. 연결을 복원하는 데 최소한 수백 밀리초가 소비되며, 몇 초 이상 걸리는 경우도 드물지 않다.
4 네트워크 프로토콜 성능
이제부터는 우리가 어느 정도 제어할 수 있는 것들을 살펴보자.
네트워크 트랜잭션의 성능은 증폭된 왕복운행 시간에 반비례한다. 이는 대부분의 네트워크 프로토콜의 연산들에서 필수적으로 수반되는 왕복 메시지 교환 때문이다. 이번 장의 나머지 부분에서는 이러한 메시지 교환이 일어나는 이유와 그 횟수를 줄이거나 심지어는 메시지 교환을 아예 제거하는 방법에 초점을 둔다
5 TCP(전송 제어 프로토콜)
TCP(Transport Control Protocol； 전송 제어 프로토콜)는 IP 네트워킹의 관례에 기초한 세션 지향적 네트워크 전송 프로토콜이다. TCP는 HTTP나 TLS 같은 다른 프로토콜들에 필수적인, 오류 없는 전이중 통신 채널에 영향을 미친다.
TCP는 우리가 줄이고자 노력하는 메시지 왕복 교환을 많이 사용한다. 그런 교환들 중에는 TFO 같은 프로토콜 확장을 이용해서 제거할 수 있는 것들도 있고 초기 밀집 구간 같은 시스템 매개변수를 조율해서 최소화할 수도 있는 것들도 있다. 이번 절에서는 그 두접근방식을 TCP의 기본적인 내부 작동 방식과 함께 살펴보겠다.
TFO 확장
TCP 연결을 새로 만들기 위해서는 삼중 제어 교환(three-way handshake)이라고 부르는 3단계 메시지 교환 과정이 필요하다. TFO(TCP Fast Open)는 그러한 제어 교환 과정에서 유발되는 왕복운행 지연을 제거하기 위한 TCP의 한 확장이다.
TCP의 삼중 제어 교환의 목적은 안정적인 이중 통신을 가능하게 하기 위해 클라이언트와 서버가 운영 매개변수들을 협상하는 것이다. 우선 클라이언트가 서버에게 SYN(synchronize) 메시지를 보낸다. 이 메시지는 서버에 대한 클라이언트의 연결 요청에 해당한다. 그 연결 요청을 수락한 서버는 SYN-ACK(synchronize ackhowledge) 메시지를 클라이언트에게 보낸다. 마지막으로 클라이언트는 그 메시지를 받았음을 확인해주기 위해 서버에게 ACK( 메시지를 보낸다. 여기까지 마치면 서버와 클라이언트 사이에 하나의 논리적 연결이 확립된 것이며，이제 클라이언트는 자료를 보낼 수 있다. 직접 계산해 보면 알겠지만, 이러한 삼중 제어 교환 과정에 의해 적어도 현재 네트워크의 왕복운행 1회에 해당하는 지연이 발생한다.
예전에는 연결 재활용 이외에는 이러한 TCP 삼중 제어 교환의 지연을 피할 방법이 없었다. 그러나 최근 IETF의 TFO 명세가 발표되면서 상황이 달라졌다. TFO를 이용하면 연결이 논리적으로 수립되기 전에 클라이언트가 자료를 보내기 시작할 수 있다. 결과적으로 삼중 제어 교환에 의한 모든 왕복운행 지연이 사실상 상쇄된다. 이러한 최적화의 효과가 누적되면 인상적인 결과가 생긴다. Google의 연구 결과에 따
르면 TFO가 페이지 적재 시간을 많게는 40%까지 줄여 준다고 한다. 아직 명세 초안 상태이긴 하지만，대0는 이미 주요 브라우저(Chrome 22+)와 플랫폼(Linux 3.6+)이 지원하고 있으며, 다른 제조사들도 조만간 이를 완전히 지원할 것이라고 약속하고 있다.
TFO는 SYN 메시지 안에 작은 자료 페이로드payload(이를테면 HTTP 요청)를 포함시킬 수 있도록 삼중 제어 과정을 수정한다. 이 페이로드는 연결 제어 교환이 이미 완료되었다는 가정 하에서 응용 프로그램 서버에 전달된다.
예전에도 TFO 같은 확장 제안들이 있었지만 보안상의 문제로 채택되지 못했다.
TFO는 보안 토큰 또는 쿠키를 이용해서 보안 문제를 해결한다. 전통적인 TCP 연결 제어 교환 도중에 클라이언트에 쿠키가 배정되며, 서버는 TFO에 최적화된 요청을 담은 SYN 메시지 안에 담긴 쿠키를 이용해서 클라이언트를 확인한다.
TFO 사용 시 주의해야 할 사소한 사항들이 몇 가지 있다. 가장 주목할 사항은 SYN 메시지와 함께 보낸 요청 자료에 대해 그 어떤 멱등성(idempotency)도 보장되지 않는다는 것이다. TCP는 중복된 패킷들(패킷 중복은 흔히 일어난다)이 수신자 쪽에서 무시됨을 보장하나，연결 제어 교환에서는 그러한 보장이 없다. 이에 대한 해결책을 명세 초안에 포함시키고자 하는 노력이 진행되고 있긴 하지만, 그렇지 않더라도 를 멱등 트랜잭션에 안전하게 사용할 수 있는 방법은 존재한다.
초기 밀집 구간
초기 밀집 구간(initial congestion window, initcwnd)은 변경 가능한 TCP 설정이다. 이를 잘 조율하면 작은 네트워크 트랜잭션들의 속도를 크게 높일 수 있다.
최근，공통의 초기 밀집 구간 설정을 구획(segment) 세 개(즉 패킷 세 개)에서 구획 10개로 증가하는 것을 장려하는 121？ 명세4가 나왔다. 이 제안은 그러한 설정을 통해서 성능을 평균 10% 증가할 수 있음을 보여주는, 구글이 수행한 상세한 연구 결과에 기초한 것이다. 이 설정의 목적과 잠재적 영향을 이해하려면 TCP의 밀집 구간(congestion window, cwnd) 설정이 무엇인지 알아야 한다.
TCP는 신뢰성이 없는 네트워크에서도 클라이언트와 서버에게 신뢰성을 보장한다. 이러한 신뢰성 보장은 한 쪽이 보낸 모든 자료가 반드시 다른 쪽에게 전달된다는(또는 적어도 그렇게 보인다는) 약속에 해당한다. 패킷 소실(packet loss)은 이러한 신뢰성 약속을 지키는데 있어 가장 큰 장애물이다. 따라서 피?는 반드시 패킷 소실을 검출하고，보정하고, 방지해야 한다.
패킷 소실을 검출하기 위해 TCP는 긍정 확인응답(positive acknowledge) 관례를 사용한다. 이 관례에서는 전송된 모든 패킷에 해당 수신자가 확인응답을 보내야 한다. 확인 응답이 오지 않았다면 TCP는 패킷이 전송 도중 사라진 것으로 간주한다. 확인응답을 기다리는 동안에는，전송된 패킷들을 밀집 구간이라고 부르는 특별한 버퍼에 보존해 둔다이 버퍼가 꽉 차는 사건을 일컬어 밀집 구간 소진(cwnd exhaustion)이라고 부른다. 밀집 구간 소진 사건이 발생하면 수신자의 확인응답이 도착해서 밀집 구간에 공간이 생길 때까지는 더 이상 패킷을 보내지 않는다. 이러한 사건들은 TCP의 성능에 커다란 영향을 미친다.
네트워크 대역폭 한계 외에, TCP 처리량은 궁극적으로 밀집 구간 소진 사건의 빈도에 의해 제한된다. 그리고 소진 사건이 발생할 확률은 밀집 구간의 크기와 관련이 있다. 순간 최대 TCP 성능을 달성하기 위해서는 밀집 구간의 크기가 네트워크의 현재 조건과 잘 맞아야 한다. 너무 크면 네트워크 밀집(네트워크가 너무 붐벼서 대역폭이 모자라는 현상) 때문에 패킷들이 더 많이 소실될 가능성이 있고, 너무 작으면 귀중한 대역폭을 제대로 써먹지 못하게 된다. 논리적으로, 네트워크 조건들을 잘 알수록 최적의 밀집 구간을 선택할 가능성이 커진다. 현실적으로，네트워크의 용량이나 잠복지연 같은 핵심 속성들은 측정하기 힘들고 끊임없이 변한다. 게다가 임의의 IP 기반 TCP 연결이 여러 개의 네트워크들에 걸쳐 있을 수 있다는 점 때문에 상황이 더욱 악화된다.
네트워크 용량을 정확히 측정할 수단이 없으면 TCP는 네트워크 밀집(network congestion)의 조건으로부터 네트워크 용량을 유추한다. TCP는 밀집 구간을 패킷 손실이 일어나기 시작하는 지점까지 확장해 본다. 패킷 손실이 일어난다면，연결 경로 어딘가에 현재의 전송 속도를 감당하지 못하는 네트워크가 존재한다는 뜻이다. 이러한 밀집 회피 방식을 사용하는 덕분에，언젠가는 TCP가 밀집 구간 소진 사건들을 할당된 연결 용량을 모두 소비하는 수준까지 최소화하게 된다. 이쯤 되면 TCP의 초기 밀집 구간 설정의 목적과 중요성을 이해할 수 있을 것이다.
네트워크 밀집은 패킷 소실의 징후가 없으면 검출할 수 없다. 새로 만들어졌거나 한동안 쓰이지 않은 연결에는 최적의 밀집 구간 크기를 결정하는 데 필요한 패킷 소실의 증거가 부족하다. TCP는 밀집이 발생할 가능성이 최소인 크기의 밀집 구간으로 시작하는 것이 낫다는 전략을 사용한다. 원래의 크기는 구획 1개(~1480바이트)였으며 한동안 그러한 설정이 권장되었다. 그러나 이후의 실험 결과들은 구획 4개까지 높여도 효과적일 수 있음을 보여준다. 실제로는 초기 밀집 구간이 구획 3개(~4KiB) 크기로 설정되어 있는 경우가 많다.
초기 밀집 구간은 작은 네트워크 트랜잭션들의 속도에 악영향을 미친다. 이는 간단한 예를 통해서 쉽게 이해할 수 있다. 표준적인 설정인 3 구획의 경우 패킷 세 개 또는 4KiB 만 전송해도 밀집 구간 소진이 발생할 것이다. 패킷들이 연달아 전송된다고 할 때, 해당 확인 응답들이 연결의 왕복운행 시간보다 더 일찍 도착할 수는 없다. RTT가 100ms라고 하면 유효 전송 속도는 초당 400바이트밖에 되지 않는다. 언젠가는 가용 용량을 완전히 소비할 수 있도록 TCP가 밀집 구간을 확장하겠지만，시동이 아주 느리다는 것이 문제다. 실제로 이런 현상을 흔히 느린 시동(slow start)이라고 부른다.
느린 시동이 작은 다운로드들의 성능에 미치는 영향을 알려면 초기 밀집 구간의 위험 대 보상' 비율을 재평가할 필요가 있다. 실제로 Google이 그런 실험을 수행했는데, 처리량이 최고가 되고 밀집 소진이 최소가 되는 초기 밀집 구간은 구획 10개 크기(~14KiB)라는 결과가 나왔다. 실세계의 결과들은 페이지 적재 시간이 전반적으로 10% 감소함을 보여준다. 왕복운행 잠복지연이 더 높은 연결들에서는 감소 비율이 더욱 클 것이다.
초기 밀집 구간 크기를 기본 설정 이외의 것으로 바꾸는 것이 간단하지는 않다. 대부분의 서버 운영체제에서 이 설정은 오직 특권을 가진 사용자만 바꿀 수 있는 시스템 전역 설정이다. 특권이 없는 응용 프로그램을 통해서 클라이언트가 이 설정을 바꿀 수 있는 경우는 드물다(아예 없을 수도 있다). 초기 밀집 구간을 크게 잡으면 서버에서는 다운로드 속도가 올라가고 클라이언트에서는 업로드 속도가 올라간다는 점이 중요하다. 클라이언트에서 이 설정을 변경하지 못한다는 점 때문에, 클라이언트의 요청 페이로드 크기를 최소화하는 데 특별한 노력을 기울일 필요가 있다.
6 HTTP(하이퍼텍스트 전송프로토콜)
이번 절에서는 높은 왕복운행 잠복지연이 HTTP(Hypertext Transfer Protocol)의 성능에 미치는 영향을 완화하는 기법들을 논의한다.
연결유지
연결 유지(keepalive)는 일련의 요청들에 동일한 TCP 연결을 사용할 수 있게 만드는 HTTP의 한 규약이다. 이를 이용하면 적어도 하나의 왕복운행(TCP의 삼중 제어 교환에 필요한)을 피할 수 있으므로 요청당 수십에서 수백 밀리초를 아낄 수 있다. 또한 연결 유지 기능에는 추가적인，그리고 종종 예상치 못한 성능상의 이점이 있다. 바로, 현재의 TCP 밀집 구간이 요청들 사이에서 보존되기 때문에 밀집 구간 소진 사건이 훨씬 덜 발생한다는 점이다.
밀집 구간을 고려하는 메시지 전달
HTTP를 메시지 전송 프로토콜로 사용할 때 종종 뜬금없고 영문 모를 지연이 발생하기도 한다. 이는TCP의 밀집 구간 소진 사건들 때문이다. 메시지와 메시지 사이에 유휴 시간이 어느 정도 있으면(보통은 1초 이상) TCP는 자신의 밀집 구간을 재설정한다.
메시지 페이로드 크기를 초기 밀집 구간 설정(보통은 구획 3개, 약 4KiB) 이하로 유지하면 그러한 밀집 구간 소진을 방지할 수 있다. 메시지 페이로드가 그러한 문턱값을 넘지 않도록 하는 기법 두 가지를 소개한다. 하나는 헤더 축소이고 또 하나는 차이 부호화이다.
헤더 축소
의외라고 생각하는 독자도 있을 것 같은데，사실 HTTP 요청들 중에는 반드시 헤더를 포함시키지 않아도 되는 것들이 많다. 이 점을 이용하면 공간을 상당히 줄일 수 있다. 대략적인 원칙은 먼저 헤더를 하나도 포함시키지 않는 것에서 시작해서 꼭 필요한 것만 추가해 나가는 것이다. HTTP 클라이언트나 서버가 자동으로 헤더들을 추가하는지도 살펴보아야 한다. 그런 행동을 방지하려면 설정을 변경해야 할 수도 있다.
차이 부호화
차이 부호화(delta encoding)는 연속된 메시지들 사이의 유사성을 활용하는 압축 기법이다.
차이 부호화로 압축된 메시지는 이전 메시지와 다른 부분으로만 구성된다. 일관된 서식을 따라 JSON 형태로 서식화된 메시지는 이 기법에 특히나 적합하다.
파이프라인화
파이프라인화pipelining는 여러 개의 연속된 요청들을 하나의 트랜잭션으로서 제출하는 HTTP의 한 규약이다. 이 기법은 HTTP 연결 유지와 동일한 성능상의 이점을 제공하며, 또한 보통의 경우 추가적인 HTTP 요청들에 필요한 왕복운행들을 제거한다는 이점도 있다.
파이프라인화는 네트워크 왕복운행 1회의 지연을 여러 HTTP 트랜잭션에 분산시키는 효과를 낸다. 예를 들어 HTTP 요청 다섯 개를 파이프라인화해서 RTT가 100ms인 연결을 통해 서버에 보낸다면，요청당 평균 RTT가 20ms로 줄어든다. 같은 조건에서 HTTP 요청 10개를 파이프라인화하면 평균 잠복지연이 10ms로 줄어든다.
그런데 HTTP 파이프라인화는 중요한 단점 때문에 그리 널리 쓰이지 못하고 있다. 단점이란，역사적으로 HTTP 프록시에 대한 지원이 좋지 않았다는 점과 서비스 거부(DoS) 공격에 취약하다는 점이다.
7 TLS(전송층 보안)
TLS(Transport Layer Security，전송층 보안) 프로토콜은 민감한 정보를 공공 네트워크를 통해서 안전하게 교환할 수 있는 세션 지향적 네트워크 프로토콜이다. TLS가 통신 보안에는 아주 효과적이지만, 잠복지연이 높은 네트워크에서 운용되는 경우에는 성능에 악영향을 미친다.
TLS에는 2회의 클라이언트-서버 메시지 교환올 수반하는 복잡한 제어 교환 과정이 필요하다. 이 때문에 TLS로 보안된 HTTP 트랜잭션이 눈에 띄게 느려 보일 수 있다. TLS가 느리다는 불평의 근본 원인은 이러한 제어 교환 절차에 의한 여러 회의 왕복운행에 의한 지연 때문인 경우가 많다.
좋은 소식은，트랜잭션들 사이에서 TCP 연결을 보존하는 모든 기법(HTTP의 연결 유지 규약 등)은 TLS 세션도 보존한다는 점이다. 그러나 현실적으호 보안 TCP 연결을 오랫동안 유지하는 것이 항상 가능하지는 않다. 다음은 TLS 제어 교환 절차 자체를 가속하는 방법 두 가지이다.
세션 재개
TLS의 세션 재개(session resumption) 기능은 TCP 연결들 사이에서 하나의 보안 세션을 보존 할 수 있게 만든다. 이를 이용하면 제어 교환 과정의 초반에서 공개키 암호화를 위한 메시지 교환(서버의 신원을 확인하고 대칭 암호화 키를 확립하는 데 필요한)이 제거된다. 계산 비용이 큰 공개키 암호화 연산들을 피하는 것도 성능에 도음이 되지만, 하나의 메시지 교환의 왕복운행 지연을 제거함으로써 절약되는 시간이 더 크다.
TLS의 이전 버전들(즉 SSL)에서는 서버가 세션 상태를 유지해야 했는데, 고도로 분산된 서버 구조에서는 그것이 아주 어려운 일이었다. TLS는 세션 티켓 session ticket을 이용한 더 간단한 해법을 제공한다. TLS의 한 확장인 세션 티켓에서는，제어 교환 과정에서 서버가 허락한다면 클라이언트가 암호화된 페이로드 형태로 세션 상태를 보존할 수 있다. 세션을 재개할 때에는 클라이언트가 제어 교환 과정의 처음에서 그 티켓을 제출해야 한다.
가짜시동
가짜 시동(false start)은 TLS내 제어 과정의 한 특징을 이용해서 프로토콜을 교묘한 방식으로 수정한 것이다. 기술적으로, 클라이언트가 자신의 최종 제어 교환 메시지를 서버에 보낸 직후에 암호화된 자료를 보내는 것이 허용된다. 이 점을 이용해서, 가짜 시동 기법은 보통의 경우 클라이언트가 서버의 최종 제어 교환 메시지를 기다리느라 소비되는 왕복운행을 제거한다.
가짜 시동은 세션 재개와 동일한 성능상의 이득을 제공하며, 게다가 상태가 없다는 장점도 제공한다. 클라이언트와 서버가 세션 상태를 관리하는 부담을 벗을 수 있는 것이다. 대다수의 웹 클라이언트는 조금만 수정하면 가짜 시동을 지원할 수 있다. 그리고 놀랍게도, 약 99%의 경우에서 서버는 전혀 수정할 필요가 없다. 따라서 이 최적화는 대부분의 기반구조에서 즉시 적용할 수 있다.
8 DNS(도메인 이름 시스템)
DNS(Domain Name System)는 대부분의 IP 기반 네트워크 트랜잭션에 필요한 이름-주소 환원 기능을 제공한다. 프로토콜로서의 DNS는 상당히 간단하다. 보통의 경우 신뢰성 있는 전송 프로토콜(TCP 등) 없이도 0^5가 작동한다. 그렇긴 하지만 DNS 질의에 걸리는 시간들이 길고 변동이 심한 경우가 많다(그 이유는 너무 다양하고 복잡해서 여기에서 일일이 설명하기 힘들다).
대체로 호스팅 플랫폼은 빈번한 DNS 질의를 피하기 위한 캐시 구현을 제공한다. DNS 캐싱의 의미론은 간단하다. 각 DNS 응답에는 그 응답이 캐시에 얼마나 오래 유지될 수 있는지를 뜻하는 유효 기간(time-to-live) 특성이 있다. TTL은 몇 초에서 며칠까지 다양하나, 일반적으로는 몇 분 정도이다. 아주 낮은(흔히 1분 이하) TTL은 부하 분산에，또는 서버 교체나 ISP 오류 복구시의 비가동 시간(downtime)을 최소화하는 데 쓰인다.
대부분의 플랫폼에 내장된 DNS 캐시 구현은 이동통신망의 더 높은 왕복운행 시간을 고려하지 않는다. 그러한 기본 캐시 구현을 보강하거나 대체하는 캐시 구현을 사용한다면 수많은 이동기기용 응용 프로그램에 도움이 될 것이다. 그럼 이동기기용 응용 프로그램들에 적용했을 때 불필요한 DNS 질의에 의한 무작위적이고 불필요한 지연을 제거할 수 있는 몇 가지 캐싱 전략을 살펴보자.
실패 시 갱신
가용성 높은 시스템들은 자신의 IP 주소 공간 안에 호스팅되어 있는 여분의 기반구조들에 의존하는 경우가 많다. TTL이 낮은 DNS 항목들은 고장 난 호스트의 주소를 지칭 할 수도 있는 네트워크 클라이언트의 시간을 줄여 준다는 장점이 있지만，대신 추가적인 DNS 질의가 많이 발생한다는 단점도 있다. TTL은 비가동 시간의 최소화와 클라이언트 성능의 최대화 사이의 절충 요인으로 작용한다.
일반적으로, 서버 고장이 일상적인 일이 아닌 예외적인 사건이라면 그런 사건을 위해 클라이언트의 성능을 낮추는 것은 비합리적이다. 이러한 딜레마에는 간단한 해답이 있다.
TTL을 엄격하게 따르는 대신, TCP나 HTTP 같은 더 높은 수준의 프로토콜이 복구 불가능한 오류를 검출한 경우에만 캐시의 DNS 항목을 갱신하면 된다. 대부분의 시나리오에서 이 기법은 TTL 준수 DNS 캐시의 행동을 갱신하면 된다. 대부분의 시나리오에서 이 기법은 TTL 준수 DNS 캐시의 행동을 흉내내면서도 DNS 기반 고가용성 솔루션에서 흔히 볼 수 있는 성능상의 피해를 거의 다 제거한다.
단, 이러한 캐싱 기법이 임의의 DNS 기반 부하 분산 방식과는 호환되지 않을 가능성이 있다는 점을 주의해야 한다.
비동기 갱신
비동기 갱신은 주어진 TTL들을 (대부분)따르면서도 잦은 DNS 질의에 의한 잠복지연을 대거 제거할 수 있는 접근방식이다. c-ares 같은 비동기 DNS 클라이언트 라이브러리는 그러한 기법을 구현해야 한다.
착상은 간단하다. 만료된 DNS 캐시 항목에 대한 요청이 들어오면 일단은 오래된 결과를 돌려주고，그와 함께 캐시를 갱신하기 위한 비차단(non-blocking) 질의를 배경에서 수행하도록 일정을 잡는 것일 뿐이다. 아주 오래된 항목에 대해서는 차단식(즉. 동기적인) 질의를 수행한다는 대안까지 구현한다면, 이 기법은 지연을 거의 다 제거하면서도 여러 DNS 기반 오류 복구，부하 분산 방식들과 호환된다.
9 결론
이동통신망의 증폭된 잠복지연이 미치는 영향을 완화하려면 잠복지연을 악화시키는 네트워크 왕복운행을 줄여야 한다. 그러한 벅찬 성능 문제를 극복하는 데에는 왕복운행 프로토콜 메시지 교환을 최소화하거나 제거하는 데 전적으로 초점을 둔 소프트웨어 최적화 기법들을 도입하는 것이 꼭 필요하다.
- 오픈소스 소프트웨어 성능 최적화 보고서, 네이비시 암스트롱 -
