널리

안녕하세요. 최인숙입니다. 

지난번에는 우리가 현재 도입하고 있는 성능최적화의 방법들이 왜 생겨난 것인지 그 이유가 되는 HTTP 1.1의 communication 구조에 대해서 잠시 알아봤었습니다. 좀 슬픈 사실은 아직 국내에서는 현재의 성능 최적화 방안마저도 적용인 안되어 있는 사이트들을 어렵지 않게 찾아 볼 수 있는데요 인터넷 기술에서 단연 선두자인 Google에서는 현재 사이트에 적용될 수 있는 방법을 다각적으로 분석해서 사용함은 물론 오래 전부터 HTTP 1.1의 한계를 근본적으로 개선하고자 새로운 방식의 Protocol 연구에 힘 써 왔습니다. 그것이 바로.. SPDY입니다. 

무엇의 약자는 아니구요, 그냥 SPEEDY라는 단어를 줄여서 쓴듯 한데 단순하고 명확한 목적을 잘 드러내 주고 있는것 같네요... 읽을 때는 스피디라고 읽습니다. 

SPDY 개발의 주요 목적은 말 그대로 빠른 페이지 로딩타임(PLT)과 좀 더 강력한 보안에 있습니다. 이번 글에서는 성능강화 문제에서 큰 변화를 가져오게 될 것이라고 주장하는 SPDY가 지금의 프로토콜과 다른 점은 무엇이 있는지 또 그러한 변화로 기대할 수 있는 점은 어떤 것인지 알아보고 또 MicroSoft에서 만들어진 Speed+Mobility라는 새로운 프로토콜에 대해서도 잠시 살펴 보겠습니다. 

SPDY

1. Multiplexing 

웹 성능문제에 있어서 가장 문제가 되었던 부분이라고 하면 아마도 리소스 하나하나 마다 새로운 Request를 보내야 한다는 구조의 제한이었을 것입니다. Sprite 이미지, domain sharding, 스크립트 화일 합치기 등의 방안들이 나온 이유라고도 앞글에서 설명을 드렸었죠? 

Multiplexing이란 여러가지의 리소스를 한번의 Request로 받을수 있어 client마다 하나의 TCP connection이면 충분하다는 새로운 방법입니다. 

그러니 SPDY가 널리 보급이 된다면 현재 사용하고 있는 최적화의 상당부분이 필요없는 노력이 되겠지요???  (no stupid css positioning or file concatenating)

아래 그림이 기존의 방식과 multiplexing의 차이를 보여주고 있습니다. (참고로 그림판으로 이해를 돕고자 그린 그림이므로 비웃지는 말아 주셈) 

그림에서 보듯이 현재의 protocol로는 각각의 리소스마다 다른 TCP연결이 필요하므로 각각 다른 도메인을 사용하는 경우 병렬 다운이 가능하지만 DNS lookup, 3-way TCP handshake등 페이지 로딩타임을 지연하는 요소들이 그만큼 늘어나게 됩니다. Multiplexing에서는 sub-resource들을 하나의 TCP연결로 한꺼번에 다운받을 수가 있으므로 그만큼의 시간을 절약할 수가 있겠죠. 1개의 TCP connection으로 1,073,741,824개의 스트림을 수용할 수 있다네요. 

SPDY는 기본적으로 지속적인 연결 (persistent connection)을 이용하고 있는데요, HTTP 1.1에서는 열린 커넥션으로 개인정보가 유출되는 보안의 문제나 너무 많은 커넥션이 열려있어 memory와 서버쪽의 CPU낭비라는 문제점을 가지고 있었습니다. 그런데 SPDY는 기본적으로 TLS (Transport Layer Security)위에서 작동이 되므로 보안에 있어서도 안정성이 있고 또 GOAWAY라고 하는 메세지를 통해 서버나 클라이언트 어느쪽에서도 스트림을 닫을 수 있는 메카니즘을 제공하고 있습니다. 이때 마지막 packet이 client 쪽에서 보내짐과 동시에 서버쪽에서 스트림을 닫는 경우와 같은 race condition을 우려를 하시는 분들이 있을텐데요 이를 방지하기 위해 GOAWAY메세지와 last-stream-id를 함께 사용하여 마지막 packet이 처리되었는지 확인 할 수 가 있습니다.   

2. 헤더 압축(header compression) 

두번째로는 header compression을 볼 수 있습니다. 

지금의 header는 사람이 읽을 수 있는 텍스트로 되어 있어 Byte 사이즈가 적지 않을 뿐더러 이를 반복적으로 보내게 되면 header의 사이즈만도 network packet에 상당부분을 차지하게 됩니다. 

SPDY는 header를 압축하여 데이터의 양을 줄이고 또 User Agent와 같이 매번의 request마다 동일하게 보내어지는 정보를 제거함으로 최초의 요청에서 소요되는 시간은 물론 Request가 반복되는 구조에서는 더욱 더 많은 데이터가 제거되게 됨으로 확연한 성능의 변화를 느낄 수 있게 해 줍니다. 또한 인간이 읽을 수 있는 텍스트로 전송이 되는것이 아니라 binary frame의 형태로서 parsing하는데 있어서 더 빠르기도 하고 에러의 발생이 최소화 되기도 합니다. 

Google의 발표에 따르면 header compression을 통해 최고 88%의 request header 사이즈가 줄고 response header 사이즈는 최고 ~85%까지 감소한다고 합니다. 

3. Request 우선순위(Request prioritization)

이 기능은 client쪽에서 request들을 보낼때 각각의 요청에 우선순위를 부여해 보냄으로써 우선순위가 높은 request (예를들어 dependency 상위에 있는 javascript)를 먼저 처리함으로서 더 원할하고 빠른 페이지 로딩을 가능하게 합니다. 이는 Pipelining과 같은 FIFO (First in First out)의 구조에서 보여졌던 head of line blocking의 문제를 해결하고 network상의 막힘현상을 제거해 주게 됩니다. 아래 이미지에서 어떤 형태로 사용되는지 살짝 엿볼 수 있습니다. 

4. Advanced Features

기본 사양에 속하지는 않지만  SPDY는 추가적으로 클라이언트쪽의 요청없이 서버쪽에서 스트림을 시작하여 contents를 전달하는 기능을 제공하고 있습니다. 

물론 이 기능은 기존의 Client와 Server같의  Request - Response라는 HTTP 기본구조에 어긋나는 기능이라고는 하지만 Request의 양을 줄이고 좀 더 스마트하게 content를 제공함으로 웹 성능 향상을 꾀하고자 하는데 촛점을 맞추고 있습니다. 

이 사양은 개발자에 의해 configure될 수 있으며 그 종류는 다음과 같습니다. 

*  Server Push: 

X-Associated-Content Header를 통해서 client에 데이타를 추가적으로 보내는 방법입니다. 이 header에는 클라이언트에게 필요한 리소스를 보내고 있다는 정보를 포함하고 있으며 처음으로 페이지가 다운되는 경우, 예를 들어 사용자가 처음으로 사이트를 방문하는 cold-cache상황 (cache정보가 전혀 없는 경우)에서 사용자 만족도를 크게 향상시킬 수 있게 될 것입니다. 

아래 server push의 한 예를 보면 처음 request와 관계되는 resource들이 별도의 다른 request없이 보내졌다는 정보를 포함합니다. 또한 특정 리소스에 대해서는 우선순위(priority)를 줄 수 있어 더 중요한 리소스를 빨리 처리하게도 할 수 있습니다. 이때 우선순위가 정해져 있지 않을 경우에는 자동적으로 우선순위 맨 아래도 떨어지게 됩니다. 우선순위는 0부터 주어지며 숫자가 낮을수록 우선순위가 높게 측정이 됩니다. 

* Server Hint: 

이 옵션은 서버쪽에서 일방적으로 content를 보내기보다는 X-Subresources Header를 통해 서버쪽에서 클라이언트쪽에 필요한 리소스를 이미 알고 있는 경우 클라이언트쪽에 특정한 리소스를 미리 요청하라고 "제안 (suggest)" 하는 기능이며 이는 이니셜 페이지가 로딩 된 후, 그 다음페이지들에 적용하기에 적합한 기능이라고 볼 수 있습니다. 

5. 보안

앞서 잠시 말씀드렸듯이 SPDY는 항상 TLS 위에서 작동합니다. 그러므로 당연히 HTTPS가 enable 되어야 SPDY를 사용할 수 있습니다.  

구조를 잠시 살펴 보면 아래와 같습니다. SPDY는 HTTP의 semantic은 지키면서 기존의 프로토콜을 다시 써서 성능 강화를 위한 기능을 추가하고 항상 TLS를 거쳐 packet이을 주고 받으므로 보안상 안정적이라고 볼 수 있습니다. 보안문제 하나만으로도 하나의 주제가 될 듯하니 그건 또 다음 기회에 글을 또 올려 보도록 하겠습니다.  

. 

6. 서버와 브라우저의 지원

그러면 현재 SPDY의 사용이 어느정도 가능할까요? 

일단 현재 SPDY를 지원하고 있는 브라우저와 서버환경들을 한번 열거 해 보겠습니다. 

* Server:  

Apache(2.2.4 이상): mod_spdy 

erlang-spdy

node-spdy

Netty 3.3.1 (Jboss)

Jetty 70602

Ngnix 1.3

Tomcat 8.0.0-dev

* Browser:

Chrome: version 11 이상, Ice Cream Sandwich

Amazon Silk (Kindle Fire)

Firefox version 13 이상

Opera version 12.1 이상

서버나 브라우저의 지원이 순차적으로 이루어짐에 따라 사용자가 많은 서비스업계에서의 SPDY 도입이 잇따라 발표되고 있습니다. 현재 우리나라의 사용자수도 많이 보유하고 있는 twitter에서는 2012년 3월 서버에 SPDY를 도입하였고 또 facebook에서도 2012년 7월에 도입계획을 발표했었습니다. 

여기서 보이지 않는것이 있지요???  우리의 친구 Microsoft IE와 IIS .... IE사용자가 절대적인 대한민국에서 SPDY의 상용화가 가능할지 걱정되는 부분이네요.. 

Speed+Mobility

Microsoft에서도 현재의 프로토콜의 문제에 대해 아무런 대응이 없는건 아닙니다. Speed+Mobility라는 프로토콜을 개발 준비중이라고 하는데요, 기본적이 network protocol은 SPDY의 communication protocol을 받아들이고 여기에 mobile에서의 성능강화부분을 더해 브라이저 이외에 스마트 폰이나 tablet pc등 다양한 mobile기기에서 접속하는 사용자들의 만족도까지도 상승시키고자 하는 목적을 가지고 있습니다. 

1990년대 후반 처음 HTTP 1.1이 발표되었을 때 웹서비스를 이용할 수 있는 방법은 브라우저를 통한 방법밖에는 없었습니다. 이후 스마트 폰을 시작으로한 각종 mobile 기기들의 개발로 웹서비스를 이용하는 방법이 다양해져 왔지만 프로토콜의 변화 없이 현존하는 구조에 대응할 수 있는 최적화 방안으로 성능을 향상시켜 온 것이 사실입니다.  

현재의 프로토콜에 대응하는 최적화의 방법들로 성능면에서 많은 발전이 이루어 진것은 사실이나, 앞으로 사용량이 더욱 높아질 모바일 기기에서의 성능 향상에 중점을 두어 현실성있는 대안을 모색하고자 하는것이 Microsoft가 Speed+Mobility("S"+"M")를 발표하게된 주요 배경이 되었습니다. 

2012년 5월 IETF에 발표한 specification을 보면 "S"+"M"에서는 SPDY에서 사용되고 있는 Muliplexing을 통해 하나의 TCP 연결로 여러개의 리소스를 다운받는 것을 기본으로 하고있지만 브라우저와 기기의 종류가 수십가지가 넘는 현재 상황에서 앞으로의 network protocol이 사용자의 접속환경등을 고려해서 환경에 적합한 기능들을 선택할 수 있는 옵션을 제공해야 한다고 주장하고 있습니다. 

예를 들어 Server push와 같은 기능은 자주 방문하는 페이지의 contents 업데이트가 자주 일어나지 않는 환경이나 client환경의 bandwidth와 processing power가 충분할 경우에는 성능의 향상을 가져올 수 있지만 contents를 다운 받을때 비용이 발생할 수 있는 mobile환경에서는 부적합 할 수 있다는 의견입니다. Header Compression 기능도 "S"+"M"에서는 배제하고 있는 기능인데요 이것은 compression해서 발생하는 사이즈의 변화보다 mobile기기에서 CPU의 활동을 최소화하여 배터리 수명을 연장하고자 하는데 촛점을 두었다고 볼 수 있습니다. 

이와 같이 Mocrosoft는 웹서비스의 접속에 있어서 mobile환경과 일반적인 pc환경에서의 차이점이 분명한데 일반적인 프로토콜을 만들어 일률적으로 사용하게 한다는것이 부합리하다는 주장인데요, 이것이 현재 개발단계인 http 2.0에 어떠한 영향을 미칠 것인가 주목해 보는 것도 재미있을 것 같습니다.  

HTTP 2.0: 현재로는 SPDY와 같다  

지난 2012년 11월 http 2.0의 첫번째 draft가 발표 되었었습니다. 1999년 http 1.1이 발표되고 난 이래 첫 변화입니다. 웹서비스 컨텐츠의 양도 사용하는 기기의 다양성도 기하급수적으로 늘어난 데에 비하면 상당히 오랫동안 변화 없이 사용되고 있었죠. 

2.0는 2014년 11월 기본화되는것을 목표로 현재 활발한 개발단계에 있는데요, 현재 발표된 바로는 SPDY의 프로토콜을 그대로 적용한 수준입니다. 여기서 더 확장이 되어서 기능을 추가하게 될지 아니면 다시 새롭게 재개발 될지는 밝혀지지 않았지만 그래도 http 1.1과의 호환성을 기본으로 하고 있기때문에 기존의 웹 서비스 제공 환경을 다시 고쳐야 하는 일이 일어나지는 않을 듯 합니다.    

2014년이라고 하면 아직 시간이 많이 남아 있는듯 하지만 눈깜짝하면 계절이 바뀌고 자고 일어나면 해가 바뀌는 듯한 요즘, 특히나 새로운 기술들의 개발이 하루가 멀다하고 발표되고 상용화되는 시대이기에 2014년이 되면 그때가서 닥치면 생각해봐야지 하는 맘을 가지고 있다면 막상 다들 발빠르게 새로운 환경에 대처할 때에 이미 한발 늦어 있는 사태가 발생하게 될 것입니다. 

현재 http 2.0를 사용할 수는 없는 일이지만, 새로운 프로토콜의 이해와 현재의 서비스 환경과 사용자들의 접속환경이 SPDY같은 프로토콜을 사용할 수 있는 환경이 되는지 또 현재 진행중인 최적화 방안에서 새로운 프로토콜과 충돌되는 문제는 없는지 (예를 들어 domain sharding) 고민하는 시간을 좀 가져 보는것도 좋을 듯 합니다. 

너무 세부내용이 많은 주제라서 짧은 글로 심도있는 설명을 드리기에 역부족했지만 큰 그림을 파악하는데 조금이라도 도움이 되었으면 합니다. 

감사합니다.