HTTP/1.1 vs HTTP/2

요즘은 대부분 HTTP/2(h2)를 사용하시지만, 왜 HTTP/2가 HTTP/1.1보다 효율적인지는 한번쯤 생각해보면 좋을 것 같습니다.

해당 글의 목적은 아래 글을 읽고 HTTP/1.1의 한계와 HTTP/2의 장점을 간단하게 학습하는 것 입니다.

Deep Dive영역은 추후 작성하겠습니다.

이제 본론으로 들어가보시죠.

개발자 도구(F12) > Network Tab에서 리소스 예약(Queue에 넣는중)의 시간이 길어진다면 무엇때무일까요?

🤷‍♂️ 왜 늦어졌을까? Why🤔 라는 질문을 자신에게 질문을 던져본다면, 아래와 같이 여러 시나리오를 생각해 볼 수 있을 것 같습니다.

Network 지연(Proxy, Gateway, etc..)?
특정 요청만 응답 지연은 아닐까?
앞선 Request에 대한 dependency 로 지연? 등..

정답은 HTTP/1.1의 요청이었기 때문입니다. HTTP/1.1과 큐에 넣는 시간이 길어지는 것과 무슨 연관이 있지? 라는 생각이 들 수 있을 텐데요.

결론부터 정리하자면 HTTP/1.1에서 동시 처리는 Host(=Domain)기준으로 6개만 가능하기 때문입니다.
(예전에 CS 공부하실 때 “HTTP에서 TCP Connection은 동시 최대 6개”라는 생각이 얼핏 떠오르실 수 있는데요. 같은 내용입니다. 😊)

출처) Network issues guide - Microsoft Edge Developer documentation | Microsoft Learn

왜 6개만 가능할까? 라는 생각이 들 수 있는데요. 사실 처음에 고안했을 때는 2개만 RFC문서에 2개만 가능하도록 제한했었습니다. RFC 2616(RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 (ietf.org))에서는 클라이언트가 단일 서버나 프록시에 대해 동시에 유지할 수 있는 연결 수를 2개로 제한함을 알 수 있습니다.

이후 Web Application의 성능 최적화와 사용자 경험 향상을 위해 Chromium Browser는 6개로 변경했습니다

참고) Configurable connections-per-host [40580943] - Chromium

Really? 진짜 6개의 Connection만 허용될까? 테스트해보고 싶어서 테스트 코드를 만들어서 테스트해봤습니다.

(버튼을 클릭하면 50번의 API를 호출하도록 만들었습니다.)

버튼 클릭 후 과정을 네트워크 모니터로 확인해보면 다음과 같이 Waterfall이 6개씩 끊기는 것을 확인할 수 있습니다.

사실 HTTP/1.1은 동시 전송에 대한 문제가 있습니다.

(well-known)왜냐하면 HTTP/1.1은 하나의 Connection 당(per Connection) 한 개의 요청(Request)와 응답(Response)를 처리하기 때문에 HOL(Head Of Line) Blocking / RTT(Round Trip Time) 증가 / 무거운 Header 구조 등 여러 단점이 발생합니다.

HTTP/1.x의 문제점을 아래에서 잘 설명해줍니다.

참고) 해석이 어색할 수 있어서 영문서로 보는 것이 이해가 더 쉬울 수 있습니다.

- ko: https://developer.mozilla.org/ko/docs/Web/HTTP/Connection_management_in_HTTP_1.x

- en: https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x

이런 단점을 위해 Domain Sharding, Load Faster, Image Spriting등 여러 대안이 있습니다.

하지만 HTTP/1.1의 단점을 보완하기보다는 HTTP/2를 사용하는 것이 더 합리적인 선택입니다.

왜냐하면 HTTP/2는 하나의 Connection 당(per Connection) 여러 개의 요청과 응답을 동시에 처리합니다.

HTTP/2의 동작과정도 확인하기 위해 샘플코드를 작성하고 테스트 해보았습니다.