HTTP/1.1와 HTTP/2.0 비교 (작성 중)

개요

1. HTTP/1.1이란?

2. HTTP/2.0이란?

3. Buffer Overflow 측면

4. Resource Requests 측면

5. Compression 측면

HTTP/1.1이란?

HTTP는 Hypertext Transfer Protocol의 약자로 클라이언트*와 서버*가 정보를 요청하고 보내는 데 사용하는 방법 중 하나입니다.

클라이언트(Client)* : 웹 사이트에 접속하는 사용자를 의미하며, 이 글을 보고 있는 당신(의 컴퓨터) 이라고 이해하여도 무방할 것 같습니다.
서버(Server)* : 웹 사이트에 접속할 때, 그 사이트에 대한 정보를 반환해주는 주체라고 이해하여도 무방할 것 같습니다.,

이와 관련해서 많은 내용들을 이미 HTTP/1.0이란? 게시글에서 논의하였습니다.

HTTP/2.0이란?

HTTP/2.0란 Hypertext Transfer Protocol의 약자로 클라이언트*와 서버*가 일정한 커넥션(Connection)*을 맺고 모든 통신을 스트림(Stream)* 기반으로 진행한다는 점이 특이합니다. 스트림(Stream)의 데이터는 추가적으로 프레임(Frame)으로 세분화됩니다.

이러한 세분화를 Binary Framing Layer라고 부르며,
모든 프레임(Frame)*은 단일 채널(Channel)*을 통하며 멀티플렉싱(Multiplexing)*를 사용하여 대기 상태를 최소화 하게 됩니다.

채널에서 어떤 스트림이 먼저처리될지는 부모아이디(PID)*와 가중치(Wt)*로 결정됩니다. 이를 스트림 우선순위 지정(Stream Prioritization)이라고 부릅니다.

이를 통해서 HTTP/2.0은 HTTP/1.1이 가진 HoL 문제를 해결하였습니다.

Buffer Overflow 측면

TCP Connection에서는 Buffer*가 존재합니다.
Buffer는 TCP Connection에서 아직 처리되지 않은 요청을 보관합니다.

때로 Buffer의 공간이 부족하면 Buffer Overflow* 현상이 일어납니다.

1. 서버가 제한된 Buffer 크기를 가지고 있을 경우

2. 서버가 낮은 Network I/O Bandwidth를 가지고 있을 경우

3. 클라이언트가 어플리케이션이 처리할 수 없는 속도로 데이터를 푸쉬할 경우

HTTP/1.1은 Flow Control을 오로지 TCP Connection에 의존합니다.
서버가 클라이언트 요청을 받으면 남은 Buffer Size를 ACK 패킷과 응답합니다.
클라이언트는 ACK 패킷 안에 Buffer Size가 0이면 추가 요청을 보내지 않고 대기합니다.

HTTP/2.0은 클라이언트와 서버가 TCP Connection을 맺습니다.
Connection 내부에서는 복수의 Stream 기반으로 통신을 합니다.
Stream은 Frame 단위로 단일 요청을 쪼개고 Multiplexing으로 병렬 통신을 합니다.
따라서 HTTP/2.0은 Application Layer에서 사용 가능한 Buffer Size을 전달하면 Multiplexing Stream Level에서 수신가능한 Window Size를 정하게 됩니다.
주기적으로 WINDOW_UPDATE Frame을 주고 받으며 Window Size를 조절합니다.

정리하면 HTTP/1.1은 TCP Connection에 의존하며 Buffer Overflow를 대비합니다.
또한 HTTP/2.0은 Application Layer(OSI:7)에서 Stream 마다 일정한 Buffer Size를 할당 받습니다. 그리고 이를 주기적으로 조절할 수 있습니다.

결론적으로 HTTP/2.0이 더욱 세밀한 Flow Control이 가능합니다.

Resource Requests 예측 측면

일반적인 웹 어플리케이션은 GET 요청을 받으면 HTML을 반환합니다.
클라이언트는 HTML을 보고 CSS, Javascript, Image에 대해 추가로 GET 요청을 합니다.

HTTP/1.1에서는 클라이언트가 요청 추가 리소스(e.g. CSS, …)를 미리 알면
개발자는 HTML과 함께 반환하는 Resource Inlining*을 사용할 수 있습니다.
하지만 이 방법은 세밀한 Resource Control이 불가능하며 초기 로드가 오래되

HTTP/1.1에서는 개발자가 클라이언트가 요청할 추가 리소스(e.g. CSS, JavaScript,…)를 미리 알고 있으면 이를 HTML과 함께 반환하는 Resource Inlining*을 쓸

Compression 측면