[네트워크] HTTP/2의 등장 배경과 특징

1. HTTP/2의 등장 배경

1) 기존의 HTTP/1.1

지속연결을 제공하는 HTTP/1.1은 웹페이지당 하나의 TCP연결을 이용할 수 있게 하였고, 서버에서의 소켓수를 줄이고 공정한 네트워크 대역폭을 가질 수 있도록 하였습니다. 하지만 하나의 TCP상에서 웹 페이지의 모든 객체를 보내면 문제가 발생할 수 있습니다.

예시를 들어보겠습니다. 

웹 페이지의 상단에 비디오 클립이 있다고 가정해봅시다. 다른 작은 객체들이 앞에 있는 비디오 객체가 링크를 통과할때까지 기다려야 합니다. TCP는 순서 보장 프로토콜이기 때문에 패킷이 순서대로 도착하지 않으면 뒤의 패킷들도 재조립을 기다리며 전달되지 않습니다. 이에 여러 요청을 하나의 TCP연결에 얹으면 패킷 손실이 생길 때  모든 요청이 함꼐 지연될 수 있습니다. 이러한 문제를 HOL 블로킹 문제라고 합니다.

HOL(Head Of Line) 블로킹: 큐의 맨 앞(Head)에 있는 요청이 지연되면, 뒤의 요청들이 모두 대기하게 되는 현상

HTTP/1.1에서는 이 문제를 피하기 위해 브라우저가 여러 개의 TCP연결을 병렬적으로 열었습니다. 하지만 TCP연결을 여러 개 열면서 생긴 오버헤드 (핸드셰이크, 혼잡 제어), 네트워크 효율 저하 등의 단점이 있었습니다.

 

2) HTTP/2의 주요 목표

HTTP/2의 주요 목표는 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간을 줄이는 데 있으며, 요청 우선순위화, 서버 푸시, HTTP 헤더 필드의 효율적인 압축 기능을 제공하는 것 입니다. HTTP/2는 상태코드, URL, 헤더필드 등 HTTP 메서드 자체는 변경하지 않았습니다. 대신에 클라이언트와 서버 간의 데이터 포맷 방법과 전송방법을 변경했습니다.

멀티플렉싱(multiplexing): 하나의 TCP Connection이 여러 파일을 동시에 전송하는 방식

2. HTTP/2의 특징

1) HTTP/2 프레이밍

HTTP/2의 프레이밍은 HTTP 메시지를 독립된 프레임들로 나눠서 전송하고 반대편 사이트에서 재조립하는 방식입니다.

여러 요청의 데이터 프레임을 한 TCP 연결 안에서 번갈아가며 섞어 전송하는 방식입니다.

HTTP/2는 하나의 TCP 연결안에서 여러 개의 스트림을 관리하고 각 스트립은 여러 개의 프레임으로 구성됩니다.

모든 프레임은 공통된 헤더(9byte)를 갖고 있습니다.

 

이러한 헤더들은 프레임 하나가 어떤 스트림의 어떤 데이터인지를 구분해주는 역할을 합니다.

프레이밍: 데이터를 프레임 단위로 쪼개서 전송하는 규칙

 

2) 메시지 우선순위화 

메시지 우선순위화를 통해 요청들의 상대적 우선순위를 조정하여 애플리케이션의 성능을 최적화할 수 있습니다. 즉 중요한거 먼저 보내고 안중요한걸 나중에 보낼 수 있다는 뜻입니다.

각 스트림은 다음 두 정보를 가질 수 있습니다.

• Wegith(가중치): 1~256사이의 값으로 중요도 표현
• Dependency(의존 관계): 다른 스트림에 의존 가능, ex) "A가 끝나야 B전송 가능"

클라이언트가 하나의 특정 서버로 동시에 여러 개의 요청을 할 떄, 각 메시지에 1에서 256사이의 가중치를 부여함으로써 요청에 우선순위를 매깁니다. 높은 수치일 수록 높은 우선순위입니다.

예시를 들어보겠습니다.

Stream 1 (HTML) ← root
 ├── Stream 3 (CSS) [weight=200]
 └── Stream 5 (JS) [weight=100]
      └── Stream 7 (image) [weight=50]

 

이러면 서버는 HTML -> CSS -> JS -> 이미지 순으로 전송 비율을 다르게 하거나 순서를 조정할 수 있습니다.

이러한 방식은 다음과 같은 장점을 가집니다.

• 초기 렌더링 속도 향상
• 병렬 효율 극대화
• 클라이언트 주도 제어

 

3) 서버 푸시

기존 HTTP/1.1에서는 클라이언트가 요청해야만 서버가 응답을 했습니다. 하지만 HTTP/2에서는 서버가 클라이언트가 요청하지 않은 리소스도 먼저 보낼 수 있습니다. 이를 서버 푸시라고 합니다.

서버는 HTML을 분석하여 필요한 객체들을 식별하고 해당 객체들에 대한 요청이 도착하기 전에 클라이언트로 보냅니다.

서버 푸시는 낭비적일 수 있다는 단점이 있습니다. 브라우저가 이미 캐시에 가지고 있는 리소스를 또 푸시할 수도 있고, 예측 실패 시 불필요한 낭비가 발생합니다. 현재는 많이 비활성화 하는 추세입니다.