[HTTP2 In Action] 2. HTTP1.1 의 근복적인 성능 이슈와 우회 방법

 

인터넷이 발전함에 따하서 데이터를 주고받는 양이 증가하였다.

 

따라서 더 빠른 다운로드 속도에 대한 요구가 늘어나고 있다.

 

인터넷 가용성과 속도는 광대역과 광섬유망과 같은 기술로 인해 증가했고 증가하고 있지만

 

하지만 대기 시간은 기본적으로 광속에 의해 제한되어 있기에 

 

우회적으로 해결하기 위한 다양한 시도가 있었다.

 

오늘은 HTTP 1.1 의 근본적인 한계에 대해 정리해보려고 한다.

 

HTTP 1.1 의 한계

HTTP 1.1 은 텍스트 기반 요청 응답 프로토콜이다.

 

여러 리소스를 요청하게 되면 HOL 블로킹이 발생한다.

 

HOL 블로킹이란?

 

Head-Of-Line 블로킹이라고 하고 

 

HTTP 뿐만 아니라 다른 네트워크 프로토콜에도 흔하다고 한다.

 

향후 TCP HOL 블로킹 문제도 다룰 예정이다.

 

MDN HTTP 1.1 커넥션

 

해당 그림에서 보이듯 요청들이 순차적으로 처리되어야 해서

 

앞의 요청에 대한 응답이 느리게 온다면, 

 

다음 요청은 기다리게 된다. 

 

이것이 HOL 블로킹이다.

 

HTTP 1.1 에서 문제가 된 이유는 다음과 같다.

 

• HTTP/1.0: 각 요청마다 새로운 TCP 연결을 열어야 했다. 이는 비효율적이었지만, 다른 요청들의 HOL 블로킹은 없었다.
• HTTP/1.1: 지속 연결(keep-alive)을 도입하여 하나의 TCP 연결로 여러 요청을 처리할 수 있게 되었다. 그러나 여전히 한 연결에서는 요청들이 순차적으로 처리되어야 했기 때문에 HOL 블로킹 문제가 발생했다.

 

 

이에 따라 요청 간의 대기 시간이 증가한다.

 

이를 해결하기 위한 대안으로

 

1. 여러 HTTP 연결을 사용한다.

2. 적지만 잠재적으로 큰 HTTP 요청을 만든다.

 

위의 방법들로 우회적으로 성능 향상을 노렸다.

 

 

 

HTTP 1.1 의 우회적 성능 향상 방법

 

여러 HTTP 연결 사용

하나의 TCP 연결로 여러 요청을 처리하면 HOL 블로킹 문제가 생기니까

이 TCP 연결을 여러 개 쓰자!

 

 

우리가 쓰는 브라우저들은 도메인별로 6개의 연결 제한을 둔다.

 

(무한대로 많이 주면 좋겠지만 우리의 대역폭은 한정적이기 때문이다!)

 

따라서 도메인 샤딩 을 활용하여 정적 자산을 하위 도메인에서 제공해서 

 

웹 브라우저가 각각의 도메인에 대해 여섯 개의 연결을 더 열게 하는 것이다.

 

 

이에 따른 단점

세상 만사가 그렇듯. 어떤 문제의 해결책은 또 다른 문제를 가져온다.

 

1. 여러 개의 HTTP 연결이 사용되는 경우는 클라이언트와 서버에 추가적인 부담을 준다.

 

TCP 연결 시작에는 시간이 들고 연결을 유지하는데 메모리와 처리를 필요로 한다.

 

그니까

 

각 TCP 연결은 3-way 핸드셰이크(SYN, SYN-ACK, ACK)를 필요로 하고

또 https 라면 TLS 핸드셰이크(추가 왕복!!)도 필요하기에 비용이 많이 드는 것이다.

 

2. 여러 개의 독립된 연결은 대역폭 문제를 야기한다.

 

도메인 샤딩을 엄청나게 해서 모든 대역폭이 사용된다면 TCP 시간 초과와 다른 연결의 재전송이 될 수 있다.

 

그리고 이런 독립적인 연결에는 우선순위가 없기에 효율적으로 리소스를 가져올 수 없다.

 

 

브라우저가 왜 도메인별 연결을 6개로 제한했을지 생각해보자!

 

 

적지만 잠재적으로 큰 요청을 만든다.

적지만 이라는 것은 요청의 수를 줄인다는 것이다.

 

예를 들어 이미지 스프라이팅 이라는 기술이 있다.

 

이미지 스프라이팅 예시

 

어떤 미디어 아이콘 등 여러 이미지를 하나의 큰 이미지로 합쳐서

 

브라우저에서 잘라서 쓰는 것이다.

 

그리고 사이트에서 사용하는 css 와 자바스크립트를 최소화하고 인라인화하는 것이다.

 

최소화는 안에 불필요한 공백이나 주석을 줄이는 것이고

 

인라인화는 html 안에 script 나 style 태그로 넣어주는 것이다.

 

 

그니까

 

요청을 맺는 비용이 비싸니까 요청 수를 줄이고 한 번에 많이 받는 것이다!

 

 

이에 따른 단점

 

1. 복잡성

 

이미지 스프라이트를 생성하는데 노력이 든다는 것이다.

 

이미지 스프라이트를 생성한다고 하더라도 웹 사이트에 콘텐츠 관리 시스템(CMS)을 사용하면

 

CMS 가 자동으로 자바스크립트를 연결하거나 이미지를 스프라이트해주지 않을 수도 있다.

 

2. 낭비

 

이미지 스프라이팅을 하여 큰 이미지를 받더라도 그 안의 모든 이미지를 쓰지 않을 수도 있고

 

그 안에서 일부의 이미지에 대한 변경이 생기면 

 

그 이미지를 로드하기 위한 CSS 가 다시 작성되어야 하고

 

JS 나 CSS 를 통합해서 보내면

 

일부의 코드만 사용하는데도 너무 큰 파일을 가져와야 하는 낭비가 생긴다.

 

 

3. 캐싱

 

이미지 스프라이팅해서 보관하면 일부의 이미지의 변경이 생기면

 

해당 이미지에 대한 캐시는 쓸모없게 된다.

 

약간의 변화에도 브라우저는 캐시에 있는 이미지를 사용하지 못하고 다시 서버로 받아와야 하는 것이다.

 

인라인한 코드에 대해서도 동일한 캐시 문제가 발생한다.

 

 

 

요약

• HTTP 1.1 은 HOL 블로킹 등의 성능적 한계가 있고 이를 우회하기 위한 다양한 시도가 있었다.
• 여러 HTTP 연결을 사용해서 HOL 블로킹을 피할 수 있으나 너무 많은 연결을 쓰면 서버의 부하가 생기고 비효율이 발생한다.
• 적지만 잠재적으로 큰 요청을 만들어 요청을 줄일 수 있지만 복잡성이 증가하고 캐시가 무력화되어 비효율이 발생한다.