HTTP 1.1 VS HTTP 2.0

sunny·2021년 11월 7일

HTTP

목록 보기

2/5

HTTP 1.1 VS HTTP 2.0

HTTP 1.1

처음 release된 HTTP 1.0은 기본적으로 Connection 당 하나의 요청을 처리할 수 있었기 때문에 동시전송이 불가능하고 하나의 요청에 대한 응답이 온 후 다음 요청을 처리하게 된다. 이로 인해 수 많은 멀티미디어 리소스들이 있는 상황에서 이러한 특징은 Network Latency를 발생시킨다.

이를 위해 HTTP 1.1에서 HTTP Pipelining 이 도입되었습니다.

HTTP Pipelining

HTTP/1.1 에서 클라이언트는 각 요청에 대한 응답을 기다리지 않고, 여러개의 HTTP Request 를 하나의 TCP/IP Packet 으로 연속적으로 Packing 해서 요청을 보낸다.
👉 파이프라이닝이 적용되면, 하나의 Connection 으로 다수의 Request 와 Response 를 처리할 수 있게끔 Network Latency 를 줄일 수 있다.

하지만 이는 정확히 구현하기 힘들 뿐 아니라 HOL Blocking이 발생한다.

HOL Blocking

Head Of Line의 줄임말로 앞선 요청에 의해 뒤에 요청이 지연되는 것

또한,클라이언트와 서버 간에 수 많은 http 요청이 발생할 것이고 header의 정보는 대부분 동일하다.
하지만 HTTP 1.1에서는 이러한 헤더를 중복해서 계속 보낼 뿐 아니라 cookie 정보 역시 매 요청마다 헤더에 포함되어 전송된다.

👉 즉, 불필요한 데이터를 주고 받는데 네트워크 자원이 소비되는 문제가 발생합니다.

HTTP 1.1을 개선하기 위한 노력

Image Spriting

웹 페이지를 구성하는 다양한 아이콘 이미지 파일의 요청 횟수를 줄이기 위해,
아이콘을 하나의 큰 이미지로 만든 다음 CSS에서 해당 이미지의 좌표 값을 지정하여 표시한다.

Domain Sharding

요즘 브라우저들은 HTTP/1.1의 단점을 극복하기 위해 여러 개의 Connection을 생성해서 병렬로 요청을 보내기도 한다.
❗ 하지만 브라우저 별로 도메인당 Connection의 개수 제한이 존재하기 때문에 근본적인 해결책은 아니다.

Minified CSS/Javascript

HTTP를 통해 전송되는 데이터의 용량을 줄이기 위해서 CSS, Javascript를 축소하여 적용한다.
ex) name.min.js, name.min.css

Data URI Scheme

HTML 문서 내에 이미지 리소스를 Base64로 인코딩된 이미지 데이터로 직접 기술하는 방법으로 이를 이용하여 서버로의 요청을 줄이는 방식이다.

HTTP 2.0

HTTP2.0은 HTTP1.1을 프로토콜의 성능에 초점을 맞추어 수정한 버전이라 보면 된다. 특히 End-user가 느끼는 latency나 네트워크, 서버 리소스 사용량 등과 같은 성능 위주로 개선했다.

Multiplexed Streams

Connection 한 개로 동시에 여러 개의 메시지를 주고 받을 수 있으며 응답은 순서에 상관없이 Stream으로 주고 받는다.
HTTP1.1의 Connection Keep-Alive, Pipelining의 개선 버전이라 보면 된다.

Stream Prioritization

리소스 간의 의존관계에 따른 우선순위를 설정하여 리소스 로드 문제를 해결한다. 우선순위가 높을수록 응답을 빨리 합니다.

Server Push

서버는 클라이언트가 요청하지 않은 리소스를 사전에 푸쉬를 통해 전송할 수 있다.
이렇게 리소스 푸쉬가 가능해지면 클라이언트가 추후에 HTML 문서를 요청할 때 해당 문서 내의 리소스를 사전에 클라이언트에서 다운로드할 수 있도록 하여 클라이언트의 요청을 최소화할 수 있다.