[Network] HTTP 버전 별 특징: HTTP v0.9 v1.0 v1.1 v2 v3

Study: ComputerScience(CS)/CS: Network

[Network] HTTP 버전 별 특징: HTTP v0.9 v1.0 v1.1 v2 v3

DrawingProcess 2023. 2. 15. 11:08

💡 본 문서는 'HTTP 버전 별 특징: HTTP v0.9 v1.0 v1.1 v2 v3'에 대해 정리해놓은 글입니다.
HTTP는 여러 과정을 거쳐 현재의 웹의 표준으로 자리잡게 되었는데, 하단에서는 HTTP의 역사와 함께 변천과정에 대해 살펴보며 HTTP에 적용된 기술에 대해 정리하였으니 참고하시기 바랍니다.

1. HTTP 란?

HTTP는 Hyper Text Transfer Protocol의 약자로, 상당히 확장 가능하며 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 합니다. 클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성됩니다.

이러한 HTTP는 여러 과정을 거쳐 현재의 웹의 표준으로 자리잡게 되었는데, 하단에서는 HTTP의 역사와 함께 변천과정에 대해 살펴보며 HTTP에 적용된 기술에 대해 살펴보도록 하겠습니다.

2. HTTP 버전 별 특징

2.0 통신 프로토콜의 역사

HTTP를 포함한 다양한 통신 프로토콜의 역사에 대해서 알아보겠습니다.

Socket API (1983, 4.2BSD Unix OS)
HTTP/0.9 (1991)
HTTP/1.0 (1996)
HTTP/1.1 (1997, 표준) : 가장 많이 사용중
- RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
- 현재 표준 스펙을 보려면 RFC7230 이후를 봐야 함
ZMQ (2007, Opensource)
WebRTC (2011, Opensource)
HTTP/2 (2015, SPDY(표준)) : HTTP 1.1의 성능 개선 및 확장
gRPC (2016, Opensource)
HTTP/3 (2021, QUIC(표준))

HTTP 1.1 이 모든 것의 기반이기 때문에 잘 알고 그 다음에 2.0 / 3.0을 알아두면 좋으며, 추후 사용될 HTTP 3.0도 인지해두자!

2.1 HTTP/0.9 (One-Line Protocol)

요청은 단일 라인으로 구성되며, 리소스에 대한 method는 GET만 존재
응답도 극도로 단순 (파일 내용 자체로만 구성)
HTTP헤더가 없었으며, HTML 파일만 전송 가능
상태 혹은 오류 코드가 없었음

/* 요청 */
GET /mypage.html

/* 응답 */
<HTML>
A very simple HTML page
</HTML>

2.2 HTTP/1.0

HTTP/1.0 특징

HTTP 헤더 개념을 통해, 요청 / 응답 모두 Meta data 전송을 허용하여 프로토콜을 유연하고 확장 가능하도록 함
버전 정보와 요청 method가 함께 전송되기 시작
Response 시작 부분에 상태 코드 라인이 추가되어 브라우저 요청의 성공/실패를 파악 가능
- 해당 결과에 대한 로컬 캐시 갱신 등의 사용 가능
Content-Type 도입으로 HTML 이외의 문서 전송 기능이 가능해짐

/* 요청 */
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

/* 응답 */
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

HTTP/1.0 한계

커넥션 하나당 요청 하나와 응답 하나만 처리 가능하여, 매우 비효율적이며 서버 부하도 문제

2.3 HTTP/1.1 (표준 프로토콜의 등장)

HTTP/1.1 특징

모호함을 명확하게 하고 많은 개선 사항을 도입한 HTTP의 첫번째 표준 버전
Persistent Connection
- 지정한 timemout(Keep-Alive) 동안에 커넥션 재사용 가능하게 하여, 기존 연결에 대해 Handshaking 생략
Pipelining 추가
- 앞 요청의 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내고 그 순서에 맞춰 응답을 받는 방식이 등장
- 순차적으로 하나씩 요청 / 응답이 처리되는 기존 방식을 개선
- 하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해 응답으로 보내주는 것은 아니다 (multiplexing 되지는 않음)

HTTP/1.1 한계: High Latency

Head Of Line Blocking (HOL)
- 순서대로 처리(요청/응답)하는 TCP의 특성으로, 첫 번째 처리가 완료되기까지 다른 요청들이 모두 대기하게 되는 문제
- 결국 앞 요청의 응답이 너무 오래걸리면, 뒤 요청은 Blocking 되어버림
RTT (Round Trip Time)
- 하나의 Connection에 하나의 요청을 처리하는 특성 상, 3 way handshake 반복 등 latency가 증가하게 됨
Fat message headers
- HTTP/1.1 헤더에는 많은 Meta data가 있음
- 매 요청 시 마다 중복된 Header 값을 전송하게 되며 (별도의 domain sharding을 하지 않았을 경우), 또한 해당 domain에 설 정된 cookie 정보도 매 요청 시 마다 헤더에 포함되어 전송함
  - domain sharding:
- 전송하려는 값보다 헤더 값이 더 큰 경우도 자주 발생함
이 외에도 Limited priorities(우선순위 없음), Client-driven Transmission(정보 요청을 해야만 통신가능)

/* 요청 */
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

/* 응답 */
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)

2.4 HTTP/2

기존 HTTP 1.X 버전의 성능 향상에 초점을 맞춘 프로토콜로 표준(HTTP 1.1)의 대체가 아닌 확장되는 개념으로 등장하였습니다. HTTP/2를 표준화함에 있어 참고 규격으로 구글의 SPDY(Proprietary Solution)을 사용하였습니다.

2.4.1 Google SPDY (Proprietary Solution)

SDPY 개요

웹 콘텐츠 전송을 위해 구글이 개발한 비표준 네트워크 프로토콜
웹 페이지 전송 지연를 줄이고 웹 보안을 개선하는 목표로, 압축, 다중화, 우선 순위 설정 등을 통한 전송 지연 감소
SSL/TLS는 암호화 되지 않은 연결을 지원하지 않음

SDPY 연혁

2009년 구글의 내부 프로젝트로 공개
2010년 크롬 브라우저의 오픈소스 엔진에 탑재
2011년 구글의 모든 서비스에 도입
2012년 아파치 서버용 구글 SPDY 패치 제공 & Nginx의 지원 공개 2012년 IETF 단체를 통한 표준화 추진
2015년 HTTP/2가 RFC 7540 표준화 되면서, SPDY 중단

2.4.2 HTTP/2 특징

HTTP 메시지 전송 방식의 전환

기존 : 일반 텍스트 형식

개선: 추가적인 Binary Encoding

Binary Framing 계층을 추가해서 보내는 메시지를 프레임(frame)이라는 단위로 분할하며 추가적으로 바이너리로 인코딩을 한다
바이너리 형식 사용으로 파싱속도 및 전송 속도가 빠르고 오류 발생 가능성이 낮아짐

Stream, Message & Frame

HTTP/2 basic terms

스트림: 구성된 연결 내에서 전달되는 바이트의 양방향 흐름이며, 하나 이상의 메시지가 전달될 수 있음
메시지: 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스임
프레임: HTTP/2에서 통신의 최소 단위이며 각 최소 단위에는 하나의 프레임 헤더가 포함됨. 이 프레임 헤더는 최소한으로 프레임이 속하는 스트림을 식별함

Relationship between basic terms

모든 통신은 단일 TCP 연결을 통해 수행되며, 전달될 수 있는 양방향 스트림의 수는 제한이 없음
각 스트림에는 양방향 메시지 전달에 사용되는 고유 식별자와 우선순위 정보(선택 사항)가 있음
각 메시지는 하나의 논리적 HTTP 메시지(예: 요청 또는 응답)이며 하나 이상의 프레임으로 구성됨
프레임은 통신의 최소 단위이며 특정 유형의 데이터(예: HTTP 헤더, 메시지 페이로드 등)를 전달함. 다른 스트림들의 프레임을 interleaving한 다음, 각 프레임의 헤더에 삽입된 스트림 식별자를 통해 이 프레임을 다시 조립할 수 있음

Multiplexed Streams

기존: HTTP 1.1의 Pipelining 으로 하나의 커넥션에 여러 요청이 있지만, 결국 동시에 여러 요청을 처리해 응답으로 주지는 못하였음

개선: 병렬 요청(Request)이 이루어지는 다중화 프로토콜(Multiplexed Streams).

구성된 연결 내에 전달되는 바이트의 양방향 흐름을 의미하는 Stream으로 요청 / 응답이 교환됨(하나의 커넥션 안에 여러개의 Stream 존재 가능)
메시지가 이진화된 텍스트인 프레임(frame)으로 나뉘어 요청마다 구분되는 Stream을 통해 전달
즉, 프레임(frame)이 각 요청의 스트림(stream)을 통해 전달되며, 하나의 커넥션 안에 여러개의 스트림(stream)을 가질 수 있게되어 동시에 여러 요청을 처리하는 다중화(multiplexing)가 가능해짐
- Stream을 통해서 각 요청의 응답의 순서가 의미가 없어져서 HOL Blocking이 자연스럽게 해결됨

Stream Prioritization

리소스간 우선순위를 설정하는 기능으로 Stream에 우선순위를 부여해서 인터리빙되고 전달하는 것이 가능해짐
이를 용이하게 하기 위해 HTTP/2 표준에서는 클라이언트가 요청한 각 스트림이 연관된 가중치(1~256)와 종속성을 갖도록 허용함

Flow Control

흐름 제어를 구현하기 위한 특정 알고리즘을 지정하지 않으나, 개발자가 직접 구현하여 리소스 사용과 할당을 제어할 수 있음
종단간 방식(End-to-End)이 아닌 홉 방식(Hop-by-Hop)이기에, proxy와 같은 중개자의 흐름제어도 가능함

Server Push

단일 클라이언트 요청에 여러 응답을 보낼 수 있는 특징을 통해 Server에서 client에게 필요한 추가적인 리소스를 push해주는 기능
요청의 중복이 생기지 않도록, 모든 서버 푸시 스트림은 HTTP 헤더를 포함한 PUSH_PROMISE 프레임을 통해 시작됨

Header Compression

기존: 연속된 요청의 경우 많은 중복된 헤더의 전송으로 오버헤드가 많이발생했음

개선: 요청과 응답의 헤더 메타데이터를 중복 제거 및 압축해서 오버헤드를 감소

전송되는 헤더 필드를 static/dynamic table로 서버에서 유지
- Static table is defined in the specification and provides a list of common HTTP header fields that all connections are likely to use (e.g., valid header names)
- Dynamic table is initially empty and is updated based on exchanged values within a particular connection
이전에 표시된 헤더를 제외한 필드를 허프만(huffman) 인코딩(HPAC 압축)을 수행해서 데이터를 압축
- 정확히는 이전에 표시됬던 헤더의 경우 static table에 저장되어 있으며 해당 인덱스를 인코딩할 때 넣어주어 압축

2.4.3 HTTP/2 한계

각 요청마다 Stream으로 구분해서 병렬적으로 처리했지만, TCP 고유의 HOL Blocking이 존재합니다. 서로 다른 Stream이 전송되고 있더라도 하나의 Stream에서 유실이 발생되거나 문제가 생기면 결국 다른 Stream도 문제가 해결될 때 까지 지연되는 현상이 발생되기 때문입니다. 즉, 이러한 TCP의 태생적인 HOL Blocking을 해결하기 위해 UDP 기반 프로토콜인 'QUIC / HTTP3.0'이 등장 하였습니다.

2.5 HTTP/3: QUIC

HTTP 3

QUIC을 기반으로 나온 새로운 HTTP 메이저 버전으로 HTTP 시멘틱스는 이전 버전들과 동일합니다(Method, Msg Field, Status ... ). 그렇다면 QUIC이란 뭘까요?

QUIC(Quick UDP Internet Connections)?

QUIC은 TCP를 대체하는 범용 목적의 전송 계층(Transport Layer) 통신 프로토콜로서, 구글의 짐 로스킨드가 처음 설계하였습니다. 이는 국제 인터넷 표준화 기구에 기술되었고, 2021년 5월 IETF RFC9000(+RFC9001/9002/8989)으로 정식 표준화 되었습니다. 또한 이미 구글 크롬에서부터 구글 서버에 이르는 모든 연결의 절반 이상에 사용되고 있으며, 크롬/MS 엣지/모질라 파이어폭스/사 파리에서 지원합니다.

QUIC은 UDP와 동일하게 Transport Layer에서 구동되지만, UCP 위에 새로운 계층을 추가함으로써 신뢰성을 제공합니다. 추가된 계층은 TCP에 존재하는 패킷 재전송, 혼잡 제어, 속도 조정 및 다른 기능들을 제공합니다.

QUIC 특징

UDP based NEW Transport Protocol

Google에서 TCP의 구조적 문제인 HOLB로 성능 향상이 어렵다고 판단하여 UDP 기반을 선택
QUIC은 UDP와 동일하게 Transport Layer에서 구동되지만, UCP 위에 새로운 계층을 추가함으로써 신뢰성을 제공함
추가된 계층은 TCP에 존재하는 패킷 재전송, 혼잡 제어, 속도 조정 및 다른 기능들을 제공함

Connection based Transport: 하나의 Stream chain으로 연결되는 TCP와 달리, 각 Stream 당 독립된 Stream chain을 구성하여 TCP HOL Blocking을 해결

QUIC Connection
- QUIC의 연결 설정은 버전 협상, 암호화, 전송 핸드쉐이크로 구성되어 있으므로 연결 설정의 지연시간을 줄여줌
- QUIC의 연결을 통해 실제 데이터를 보내려면 하나 이상의 스트림을 만들어서 사용해야 함
QUIC Connection ID
- 각 연결은 연결 식별자나 연결 ID를 가지므로 이를 통해 연결을 식별함
- 엔드포인트가 자유롭게 연결 ID를 선택하며, 각 엔드포인트는 엔드포인트의 피어가 사용할 연결 ID를 선택함
- 연결 ID의 주요 기능은 하위 프로토콜 계층(UDP, IP 혹은 그 아 래 계층)에서 주소가 변경되더라도 QUIC 연결의 패킷이 잘못된 엔드포인트로 전달되지 않도록 보장하는 것임
  - e.g. 사용자가 WiFi에서 다운로드하다가 느려서 셀룰러 네트워크로 변경하더라도 계속 다운로드를 진행가능

Stream based Transport

하나의 연결로 다수의 병렬 스트림을 전송하며, 스트림 간에 영향을 주지 않고 데이터를 동시에 전송함
스트림은 62비트 정수의 스트림 ID 식별자로 구분함
스트림은 순서대로 전달되고 신뢰할 수 있지만 서로 다른 스트림은 순서 없이 전달될 수 있음
QUIC은 연결과 스트림 모두에서 흐름 제어를 제공함
QUIC을 사용하는 상위 계층을 통해서 스트림에 대한 우선 순위를 요청받아, 이를 토대로 정보 교환을 할 수 있음

Secure Communication

QUIC은 일반 텍스트 버전이 없고, QUIC 연결과 협상하려면 TLS 1.3을 사용해서 암호화 및 보안을 수행해야 함
이전 버전의 TLS와 비교해서 TLS 1.3에 몇몇 장점이 있지만 QUIC이 TLS 1.3을 사용한 주된 이유는 핸드쉐이크에 더 적은 라운드 트립이 필요하도록 바뀌었기 때문으로, 프로토콜 지연을 줄여줌
TLS를 기본으로 사용하므로, 웹 사용자가 기대하고 원하는 HTTPS의 모든 보안 속성을 지원함

Reduced {Signaling} Latency

QUIC는 0-RTT, 1-RTT 핸드쉐이크를 제공하는데 이는 새로운 연결을 협상하고 설정하는데 걸리는 시간을 줄여줍니다.

참고로 RTT란 메시지를 주고 받는 것을 말하며 1-RTT는 한번 주고 받음을 의미함
여기서 TCP는 3-way handshake 으로 RTT로 표현하면 1.5-RTT(?)라고 표현할 수 있음

QUIC은 추가로 더 많은 데이터를 허용하는 "early data"를 처음부터 지원하여, 핸드쉐이크 과정에서 TLS 연결설정 및 해제도 동시에 처리합니다.

또한 기존에 존재하는 연결이 끝나기를 먼저 기다릴 필요 없이 같은 호스트로의 또 다른 논리 연결도 동시에 처리될 수 있습니다.

새로운 연결을 설정하는데 필요한 시간을 줄이려고 이전에 서버에 연결했던 클라이언트는 해당 연결의 특정 파라미터 를 캐시한 뒤 이어서 서버와 0-RTT 연결을 설정할 수 있음
이로 인해서 클라이언트는 핸드쉐이크가 완료되기를 기다리지 않고 바로 데이터를 보낼 수 있음 (0-RTT)

참고

[모질라]: https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
[Blog] HTTP (1) - version 별 특징 (0.9 / 1.0 / 2.0 / 3.0): https://velog.io/@neity16/HTTP-HTTP-%EB%B2%84%EC%A0%84-%EB%B3%84-%ED%8A%B9%EC%A7%95

저작자표시 비영리 변경금지