널리

요즘의 웹사이트는 컨텐츠의 양과, 서버와의 끊임없는 접속 그리고 front-end의 복잡한 기능들이 늘어남에 따라 스피드를 향상하고 성능을 최적화하여 사이트를 찾는 방문자들에게 좋은 경험을 주는 것이 더 없이 중요시 되고 있습니다. 

특히나 e-Commerce 사이트의 경우 속도의 차이는 매출의 차이를 의미한다는 분석결과가 뚜렷하기 때문에 업체들의 성능강화에 대한 노력은 끊이지 않고 있습니다

그렇기 때문에 성능최적화를 위한 테크닉들이 많이 발표가 되었고 또 그러한 방법들을 이용해서 확연하게 속도의 차이가 생기고 또 매출과 방문자의 수가 늘어나는 등 고무적인 일들을 실제로나 혹은 분석자료를 통해 많이 접해왔습니다. 일반적으로 화일의 사이즈를 줄이면 다운로드의 속도가 빨라진다는 것은 어떤 환경에서도 틀리지 않는 원초적인 이론입니다. 그런데 현재 성능 최적화의 많은 부분을 살펴보면 화일들을 한곳으로 합치거나 여러개의 도메인을 이용하는등의 trick들이 사용되고 있습니다.   

이러한 성능 최적화를 위한 방안들은 왜 착안이 되었는지 그 배경이 되는 HTTP1.1의 구조를 살펴보고 어떠한 문제와 제한요소가 있는지 알아보도록 하겠습니다. 

평균적으로 웹페이지는 50-80번의 Request들과 1Mb 내외의 컨텐츠들로 구성이 되어있다고 합니다. 페이지 로딩에 필요한 컨텐츠들을 다운받는데에 쓰이는 커뮤니케이션은 어떤 구조로 되어 있으며 Request부터 Response까지 발생하는 커뮤니케이션 Life Cycle을 살펴 보도록 하겠습니다. 

다음의 이미지는 한번의 HTTP Request가 있을때 발생하는 일들은 그래프로 나타내고 각 부분별 어떤 최적화 방안들을 생각할 수 있는지 간단하게 표시해둔 표 입니다. 

좀 더 풀어서 단계를 설명하면 다음과 같이 나타낼 수 있습니다. 

1. Unload DOM

2. DNS 레졸루션(resolution)

3. Connection & TCP (3way) 핸드쉐이크

4. Request보내고, Response 기다리기

5. Response 파싱

6. 서브 리소스 Request  (go to step 1)

7. 스크립트 실행, CSS 적용  

앞서 말했듯이 평균적으로 한페이지가 50-80번의 Request들로 구성이 되어있다고 할때 위와같은 과정을 50-80회 거친다는 것입니다. (wow) 

다음 이미지는 아마존 사이트의 HTTP Waterfall의 단면을 보여주는 것입니다.

이미지에서 쉽게 보여지듯이 하나의 커넥션에 하나의 Request, 그리고 하나의 Response를 받고 있는 것을 볼 수 있습니다. 아무리 작은 이미지 하나라고 해도 각각의 Request를 통해 다운 받아지고 다른 도메인을 이용할 경우 별도의 Domain 검색도 필요합니다. 결국에 우리가 사용하는 최적화 방안들은 이 waterfall의 면적을 줄이고자 하는 것입니다. 수직으로 줄인다는것은 요청개수를 줄이는 것이고 수평으로 줄인다는 것은 화일의 사이즈들을 줄인다는 뜻입니다. 

아래 이미지는 하나의 TCP 커넥션을 통해 여러개의 Request와 Reponse가 순차적으로 이루어 지는 모습을 나타낸 것입니다. 두번째의 Request는 첫번째 Response가 도착하기 전에는 보내질 수 없으며 세번째.. 그 다음의 것도 마찬가지 입니다. 이어달리기에서 전 주자가 도착하기 않으면 다음주자가 나갈수 없는 것을 생각하시면 이해가 빠를 것 같습니다.    

위와 같은 방법에서 좀 더 현명한 방법으로 고안된것이 pipelining인데 이 방법은 Request들을 Response가 도착하기 전에 연속으로 하나씩 여러개를 보내는 방법인데 아래의 왼쪽 그림이 pipelining을 설명하는 그림입니다. 이때 Response들은 request queue로부터 보내어진 순서대로 처리, 도착하여야 합니다. (First In First Out).  

그런데 이 방법에서의 문제는 제일 먼저 보내진 Request에 대한 처리과정이 길어서 Response 생성이 느려질 경우에 나타납니다. 이미지 오른쪽에 있는 것이 이 문제를 설명하는 것인데요, 처음의 Response에 대한 처리가 오래걸려 결과적으로 모든 Response가 늦게 도착하는 현상입니다. 고장난 차를 길 한복판에서 수리하고 있어서 뒤에 차들이 가지 못하는 경우를 생각하면 되겠습니다. 

그래서 많은 경우에 pipelining이 성능면에서 그렇게 뛰어난 최적화 방안이 되지 않기도 합니다. 

현재 사용되고 있는 여러가지 최적화 방안들은이렇게 multiplexing이 지원되지 않는 HTTP 1.1의 구조적인 문제에서 착안이 된 것인데요 그런 방안들에는 다음과 같은 것들이 있습니다. 

화일들을 합치기 

Javascript와 CSS화일들을 소수의 화일로 합치기

모듈은 줄이고, bundle을 늘리기 

Spriting images

 이 방법은 작은 이미지를 한데 모아서 하나의 이미지 화일로 만들어 다운받은 후에 뷰포인트에 작은 창을 만들어서 CSS position 값으로 해당이미지를 보이게 하는 혁신(?)적인 방법으로 현재 보편적으로 많이 쓰이고 있습니다.. 위의 구조에서는 탁월한 성능의 향상을 가져오지만 개발자들이게는 효율적이지 못한 방법이지요...(What a pain!!!)

Resource inlining

TCP connection에 소모되는 시간이 많으므로 round trip을 줄이고자 작은 이미지들을 HTML안에서 inline시키는 것입니다.

Domain sharding

병렬다운을 위한 방법으로 여러개의 통로를 열어 많은 리소스를 동시에 받기위해 고안된 방법인데 너무 많은 도메인을 이용할 경우 DNS검색과 TCP handshake에서 발생하는 시간때문에 오히려 역효과를 발생할 수도 있습니다.

그러면 이러한 문제점들의 근본적인 해결책으로 제시되고 있는 SPDY(by Google)나 Speed+Mobiliy(by Microsoft) 그리고 다음 세대의 프로토톨이라고 알려진 HTTP 2.0 (2012년 11월에 초안 발표)에서 제시하는 기술적인 방향은 어떤것이고 또 그러한 프로토콜을 사용함으로서 웹 성능 향상 면에서 어떤것들을 기대할 수 있을지는 다음번에 또 자세하게 살펴 보도록 하겠습니다. 

감사합니다.