[컴네/CN] HTTP 버전

HTTP 발전

현재는 HTTP/1.1 이상의 버전만 사용한다.

 

HTTP/1.0

HTTP GET 메소드에 대해 1개의 TCP 연결을 사용한다.

즉, 객체 1개 전송할 때 1개의 TCP 연결을 사용한다는 의미이다.

따라서 객체 하나를 전송할 때에 새로운 TCP socket를 생성하고

새롭게 연결을 수행해야 하므로 생성과 연결에 지연 시간이 발생한다.

즉, 왕복지연시간문제(non-persistent HTTP)가 발생한다.

우리는 이러한 왕복지연시간문제를 해결하기 위하여 HTTP/1.1을 만들었다.

 

이때, 우리는 왜 왕복지연시간을 줄여야 할까?

아래 표는 지연 시간에 따른 사용자 체감을 나타낸 표이다.

밀리초(1/1000초)라는 아주 작은 시간 동안에도

사용자는 체감을 할 수 있다.

 

사용자가 이러한 지연 시간을 느끼지 않게 하려면

PTL(Page Load Time)을 줄이는 것이 중요한데,

아래는 bandwith와 지연시간에 따른 PTL의 변화를 나타낸 그래프이다.

bandwith가 늘어나면 3Mbps까지는 꾸준하게 줄어들다가

그 이후의 변화는 미미함을 확인할 수 있다.

즉, bandwith의 확장은 지연시간을 줄일 수 있지만,

일정 수준 이상이 된다면 지연시간이 더 이상 줄어들지 않는다.

하지만 지연시간이 줄어듦에 따라 PTL은 꾸준히 줄고 있으며

이는 bandwith보다 지연시간이 PTL을 줄이는 데에 유의미함을 알 수 있다.

 

HTTP/1.1

앞서 우리는 HTTP/1.0의 왕복지연시간을 줄이기 위해

HTTP/1.1이 등장했다고 언급했다. 어떻게 줄였을까?

바로 TCP 연결을 재사용하는 것이다.

즉, HTTP GET 메소드를 처리하는 데에 이전 TCP 연결을 재사용한다.

이전 TCP 연결을 재사용하는 것에 초점을 두었기 때문에

HTTP/1.0과 문법차이가 거의 나지 않는다.

 

위 그림은 HTTP/1.1 연결 흐름을 도식화한 것이다.

이때, 붉은 박스 안 화살표를 보면 2개가 한 번에 전송됨을 확인할 수 있다.

HTTP/1.1은 pipelining을 도입하여 요청을 순차적으로 전송하고 처리하지 않고

병렬적인 요청(GET HTML+CSS)과 응답(HTML+CSS response)이 가능하다.

 

HTTP/2

HTTP/1.1은 1개의 TCP 연결을 재사용하면서 객체를 순차적으로 전송한다.

이때 이미지나 영상같은 데이터의 크기가 큰 객체는 전송에 시간이 오래 걸린다.

이러한 경우 TCP 연결을 하나만 사용하기 때문에

앞에서 데이터 전송 시 지연된다면 뒤에 전송해야 할 데이터도 지연된다.

이러한 현상은 Head-of-Line(HoL) 병목 현상이라고 불린다.

HTTP/2는 HTTP/1.1의 웹 페이지 로딩 시간을 50% 단축을 목표로 한다.

 

binary frame

HTTP/2는 바이너리 프레임을 사용하여 ASCII(text)로 전송하던 데이터를

binary로 전송하여 더 간결하고 빠르게 전송이 가능하고,

메세지를 헤더와 데이터 프레임으로 분리하면서

이들을 재조립하여 데이터를 받을 수 있다.

또한 프레임에 우선 순위를 도입하여 흐름을 제어함으로써 빠른 성능을 낼 수 있다.

 

서버 푸시라는 기능을 도입하였는데,

서버 푸시는 서버에서 클라이언트가 요청하지 않는 데이터도 함께 전송하는 기능이다.

예를 들어, HTML파일을 전송할 때, css 또는 js 파일도 함께 전송한다.

 

스트림 전송

1개의 TCP 연결을 유지하되, 멀티플렉싱과 우선순위를 지원하여

객체를 순차적으로 전송하지 않고 순서를 섞어 전송할 수 있다.

 

네이버 메인화면에서 개발자도구를 통해 전송 중인 protocol을 확인하면

HTTP/2를 사용 중임을 알 수 있다.

 

여담으로 HTTP/2는 구글에서 개발하였으며,

Apache, Nginx, Node.js 등 많은 곳에서 사용하고 있다.

 

HTTP/3

2020년에 드래프트되었고, 2022년 HTTP/3 RFC9114 표준이 되었다.

HTTP/2는 TCP 연결을 사용하였는데,

TCP 계층에서 발생한 세그먼트의 손실을 HTTP에서 보이지 않았고,

이미 TCP가 보유하고 있는 기능이 충분히 많아

더 이상의 속도를 빠르게 할 수 있는 방법이 존재하지 않았다. (HoL 병목)

따라서, TCP의 부가 기능을 삭제하고, 데이터 전송 속도만 신경 써서

개발해낸 결과물이 바로 UDP이다.

 

왼쪽이 HTTP/2이고, 오른쪽이 HTTP/3의 구조이다.

HTTP/2에서는 TCP위에 TLS 1.2+를 통해 암호화를 진행한다.

하지만 HTTP/3에서는 기본적으로 제공되는 암호화 기능이

존재하지 않으므로 QUIC를 올려 개발자가 자유롭게 커스텀할 수 있다.

---

출처 및 참고

https://study-ihl.tistory.com/171