한국어
메뉴

HTTP/1.1·HTTP/2·HTTP/3의 차이: 전송 방식·다중화·HOL 블로킹·헤더 압축·암호화 비교

세 버전은 메서드, 상태 코드, 헤더 필드 같은 HTTP의 의미(RFC 9110)를 공유하며, 다른 것은 그것을 운반하는 형식과 트랜스포트입니다. HTTP/1.1(RFC 9112)은 TCP 위에서 텍스트 메시지를 보내고, 각 연결에서 응답을 하나씩 돌려줍니다. HTTP/2(RFC 9113)는 메시지를 바이너리 프레임으로 나누고, 하나의 TCP 연결 위에서 여러 스트림을 다중화합니다. HTTP/3(RFC 9114)는 UDP 위에서 동작하는 QUIC(RFC 9000)을 쓰며, 스트림 다중화와 TLS 1.3 암호화를 트랜스포트에서 처리합니다. 이로써 패킷 하나의 손실이 모든 스트림을 멈추게 하는 TCP의 HOL 블로킹(head-of-line blocking)을 피합니다.

비교 항목HTTP/1.1HTTP/2HTTP/3
사양RFC 9112(의미는 세 버전 공통인 RFC 9110)RFC 9113RFC 9114(QUIC은 RFC 9000)
트랜스포트TCPTCPQUIC(UDP 위에서 동작)
메시지 형식텍스트: 요청 줄과 헤더 필드를 한 줄에 하나씩 씁니다바이너리 프레임바이너리 프레임(QUIC 스트림 위)
다중화없음. 한 연결은 한 번에 요청과 응답 하나만 처리하므로, 병렬로 가져오려면 여러 연결을 열어야 합니다하나의 TCP 연결 위에서 여러 스트림을 병렬로 보냅니다여러 QUIC 스트림을 병렬로 보냅니다. 스트림은 트랜스포트가 관리합니다
HOL 블로킹HTTP 계층에서 일어납니다. 같은 연결에서는 앞의 응답이 끝날 때까지 다음 응답을 보낼 수 없습니다(파이프라이닝을 써도 응답은 요청 순서대로 돌아옵니다)HTTP 계층에서는 해소되었지만, TCP가 바이트를 엄격히 순서대로 전달하므로 패킷 하나가 손실되면 모든 스트림이 재전송을 기다립니다QUIC이 스트림마다 순서를 관리하므로, 손실은 데이터를 잃은 스트림에만 영향을 줍니다
헤더 압축없음(본문은 압축할 수 있지만 헤더는 평문 텍스트로 보냅니다)HPACK(RFC 7541)QPACK(RFC 9204). 스트림이 순서대로 도착하지 않아도 동작하도록 HPACK을 고친 방식
암호화선택. https는 TLS를 쓰고, http는 평문으로 보냅니다사양은 TLS 위(h2)와 평문(h2c)을 모두 정의하며, TLS 위에서는 TLS 1.2 이상을 요구합니다. 주요 브라우저는 TLS 위의 HTTP/2에만 대응합니다필수. TLS 1.3이 QUIC에 내장되어 있으며 평문 모드는 없습니다
연결 수립까지의 왕복 횟수TCP에 1왕복, TLS 1.3이면 1왕복이 더해져 모두 2왕복 뒤에 요청을 보냅니다HTTP/1.1과 같음(TCP와 TLS로 2왕복)QUIC은 트랜스포트와 암호 핸드셰이크를 합쳐 1왕복으로 끝냅니다. 이전에 접속한 서버에는 첫 송신에 데이터를 싣는 0-RTT도 쓸 수 있습니다
네트워크가 바뀔 때TCP 연결은 출발지·목적지의 주소와 포트로 식별되므로, IP 주소가 바뀌면 새 연결이 필요합니다HTTP/1.1과 같음QUIC은 연결 ID로 연결을 식별하므로, 무선 LAN에서 모바일 네트워크로 바뀌어도 같은 연결을 이어 갈 수 있습니다(연결 마이그레이션)

수치는 대략적인 자릿수 기준이며, 공정 세대와 제품에 따라 달라져요.

상황별 선택 기준

HTTP/1.1
모든 클라이언트와 서버가 쓸 수 있는 기본 버전. 서버 시스템 내부의 통신이나 기기 설정 화면 같은 간단한 웹 인터페이스에도 쓰입니다.
HTTP/2
작은 파일을 많이 불러오는 웹 페이지를 하나의 연결로 효율적으로 전송하고 싶을 때. UDP를 막는 네트워크에서도 동작하므로, HTTP/3를 지원하는 사이트에서도 대체 수단이 됩니다.
HTTP/3
모바일 네트워크처럼 손실이 있고 지연이 큰 회선에서 스트림끼리 서로 멈추게 하지 않고 싶을 때나, 연결 수립을 빠르게 하고 싶을 때. UDP를 막는 네트워크도 있으므로 사이트는 보통 HTTP/2나 HTTP/1.1도 함께 지원합니다.

자주 묻는 질문

HTTP/2에서 HOL 블로킹이 없어진 것 아닌가요?

HTTP 계층에서는 없어졌지만 TCP 계층에는 남아 있습니다. HTTP/2는 하나의 TCP 연결 위에서 여러 스트림을 다중화하지만, TCP는 데이터가 어느 스트림의 것인지 모르고 바이트를 엄격히 순서대로 전달합니다. 그래서 패킷 하나가 손실되면 관계없는 스트림의 데이터도 재전송이 도착할 때까지 수신 애플리케이션에 넘겨지지 않습니다. HTTP/3에서는 QUIC이 스트림마다 순서를 관리하므로, 손실된 데이터가 있는 스트림만 기다리면 됩니다.

클라이언트는 서버가 HTTP/3를 지원한다는 것을 어떻게 아나요?

HTTP/3는 UDP를 쓰므로 TCP 연결과는 따로 시작해야 합니다. 보통 클라이언트가 먼저 TCP 위의 HTTP/1.1이나 HTTP/2로 접속하고, 서버가 Alt-Svc 응답 헤더로 HTTP/3(h3)를 쓸 수 있다고 알립니다. 그 뒤의 연결에서 클라이언트는 QUIC을 씁니다. 이와 별개로, TLS 위에서 HTTP/1.1과 HTTP/2 중 무엇을 쓸지는 TLS 핸드셰이크 중의 ALPN으로 정합니다.

HTTP/3의 0-RTT에 주의할 점이 있나요?

있습니다. 0-RTT로 보낸 데이터는 공격자가 기록해 다시 보낼 수 있습니다(재전송 공격). 그래서 0-RTT에서는 여러 번 받아도 해가 없는 GET 같은 요청만 보내는 등의 주의가 필요합니다.

HTTP/2나 HTTP/3를 위해 웹 애플리케이션을 다시 만들어야 하나요?

대부분은 그렇지 않습니다. 메서드, 상태 코드, 헤더 필드의 의미는 세 버전이 공유하며(RFC 9110), 다른 것은 운반 방식뿐입니다. 버전은 연결마다 정해지므로, 리버스 프록시나 CDN이 브라우저로부터 HTTP/2나 HTTP/3를 받고 뒤의 애플리케이션 서버와는 HTTP/1.1로 통신하는 구성이 흔합니다.

이해도 확인

HTTP/1.1 요청의 첫 줄(요청 라인)에 나열되는 요소의 조합으로 올바른 것은?

  1. A메서드, 요청 대상(경로 등), HTTP 버전
  2. BHTTP 버전, 상태 코드, 이유를 나타내는 짧은 문구
  3. C출발지 IP 주소, 목적지 포트 번호, 메서드
정답과 해설 보기

정답: A. 메서드, 요청 대상(경로 등), HTTP 버전

HTTP 요청은 요청 라인, 헤더(한 줄에 하나씩 '이름: 값'), 빈 줄, 본문의 순서로 나열됩니다. 예를 들어 'GET /docs/index.html HTTP/1.1'은 GET 메서드로 /docs/index.html을 요구하는 줄입니다. HTTP/1.1에서는 Host 헤더도 반드시 보내, 같은 IP 주소로 여러 사이트를 운영하더라도 어느 사이트에 대한 요청인지 서버가 판단할 수 있게 합니다. 응답의 첫 줄은 상태 라인으로, 'HTTP/1.1 200 OK'처럼 버전, 상태 코드, 이유 구문이 나열됩니다.

HTTP/2와 HTTP/3에 대한 설명으로 올바른 것은?

  1. AHTTP/2는 하나의 TCP 연결로 여러 요청을 병렬로 처리할 수 있지만 패킷 손실로 다른 스트림도 기다리게 되는 경우가 있으며, HTTP/3은 UDP 위의 QUIC으로 이를 줄였다
  2. BHTTP/2는 HTTP/1.1과 같은 텍스트 형식의 메시지를 사용하고, 요청마다 새로운 TCP 연결을 병렬로 만들어 여러 리소스를 동시에 받을 수 있게 한 버전이다
  3. CHTTP/3은 HTTP/2와 마찬가지로 TCP 위에서 동작하며 헤더를 압축하는 방식만 고친 버전으로, 패킷 손실의 영향은 HTTP/2와 다르지 않고 UDP는 사용하지 않는다
정답과 해설 보기

정답: A. HTTP/2는 하나의 TCP 연결로 여러 요청을 병렬로 처리할 수 있지만 패킷 손실로 다른 스트림도 기다리게 되는 경우가 있으며, HTTP/3은 UDP 위의 QUIC으로 이를 줄였다

HTTP/1.1에서도 지속 연결(keep-alive)로 하나의 TCP 연결을 재사용할 수 있지만, 하나의 연결에서는 응답을 하나씩 차례로 받기 때문에 브라우저는 여러 연결을 병렬로 열었습니다. HTTP/2는 메시지를 바이너리 프레임으로 나누고, 하나의 TCP 연결 위에 여러 스트림을 다중화하여 병렬로 보냅니다. 다만 TCP는 바이트열을 순서대로 전달하므로, 패킷이 하나 손실되면 재전송이 도착할 때까지 관계없는 스트림의 데이터도 기다리게 됩니다(HOL 블로킹, head-of-line blocking). HTTP/3은 UDP 위에서 동작하는 QUIC을 사용하여 스트림마다 순서를 관리하므로, 손실의 영향이 그 스트림에만 머뭅니다.

RTT가 40 ms인 웹 서버에서 HTML 하나와 거기서 참조하는 이미지 4개를 하나씩 차례로 가져온다. TCP 연결 설정에 1왕복, 각 요청과 응답에 1왕복이 걸린다고 하고, 데이터 전송 시간, 서버의 처리 시간, TLS, 연결 종료는 고려하지 않는다. 객체마다 새로운 TCP 연결을 여는 경우와 하나의 TCP 연결을 재사용하는 지속 연결의 경우에 걸리는 시간의 차이는?

  1. A160 ms
  2. B200 ms
  3. C400 ms
정답과 해설 보기

정답: A. 160 ms

객체는 모두 5개입니다. 매번 새로 연결하는 경우에는 객체마다 연결 설정과 요청·응답의 2왕복이 걸려 5 × 2 × 40 = 400 ms입니다. 지속 연결에서는 처음에 한 번만 연결을 설정하고 그 후에는 5번의 요청과 응답뿐이므로 (1 + 5) × 40 = 240 ms입니다. 차이는 400 − 240 = 160 ms이며, 줄일 수 있는 것은 4번분의 연결 설정입니다. HTTP/1.1에서는 지속 연결이 표준 동작으로 되어 있습니다.

  1. RTT(왕복 시간)가 100 ms인 웹 서버에 HTTPS(TCP 위의 TLS 1.3)로 새로 접속하여, 첫 요청을 보내고 응답을 받기 시작할 때까지 걸리는 시간에 가장 가까운 것은? DNS 이름 해석은 끝났으며, 서버의 처리 시간과 데이터 전송 시간은 무시한다.
  2. HTTPS(HTTP를 TLS로 보호한 통신)로 보호되는 것으로 올바른 것은?

웹 기술 기초 문제 풀기

주요 용어 설명

HTTP(하이퍼텍스트 전송 프로토콜)
웹 브라우저와 웹 서버 등의 사이에서 HTML이나 이미지, 데이터를 주고받기 위한 응용 계층의 프로토콜. 클라이언트가 메서드, URL, 헤더, 본문으로 이루어진 요청을 보내고, 서버가 상태 코드, 헤더, 본문으로 이루어진 응답을 돌려준다. 프로토콜로서는 무상태이며, 로그인 같은 상태는 Cookie 등을 사용하여 유지한다. HTTP/1.1은 텍스트 형식으로 지속 연결을 사용하고, HTTP/2는 하나의 TCP 연결 위에서 여러 스트림을 다중화하며, HTTP/3은 UDP 위의 QUIC을 사용한다. TLS로 보호한 것을 HTTPS라고 한다.
TLS
Transport Layer Security의 약자. 통신의 암호화, 변조 검출, 인증서에 의한 서버 인증을 수행하는 프로토콜. HTTPS는 HTTP를 TLS로 보호한 것이다.
3-way 핸드셰이크(Three-way Handshake)
TCP에서 연결을 설정하는 절차. 클라이언트의 SYN, 서버의 SYN+ACK, 클라이언트의 ACK의 세 번의 교환으로 서로의 초기 시퀀스 번호를 확인한다.
HTTP 메서드(HTTP Method)
HTTP 요청에서 리소스에 대해 수행하려는 조작을 나타내는 말. GET(조회), HEAD(헤더만 조회), POST(처리나 생성), PUT(교체), PATCH(일부 갱신), DELETE(삭제), OPTIONS(사용할 수 있는 기능 문의) 등이 있다. 서버의 상태를 바꾸지 않는 것을 '안전', 몇 번 보내도 한 번 보냈을 때와 같은 상태가 되는 것을 '멱등'이라고 한다. GET은 안전하고 멱등이며, PUT과 DELETE는 멱등이지만 안전하지 않고, POST는 일반적으로 어느 쪽도 아니다.
HTTP 상태 코드(HTTP Status Code)
HTTP 응답의 첫 줄에 들어가는 3자리 수로, 요청의 결과를 나타낸다. 백의 자리로 분류하며, 1xx는 정보, 2xx는 성공(200 OK, 201 Created, 204 No Content), 3xx는 리다이렉트(301 Moved Permanently, 302 Found, 304 Not Modified), 4xx는 클라이언트 측 오류(400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found), 5xx는 서버 측 오류(500 Internal Server Error, 503 Service Unavailable)를 나타낸다. 401은 인증 정보가 없거나 올바르지 않을 때, 403은 인증되었더라도 권한이 없을 때 사용한다.
리버스 프록시(Reverse Proxy)
웹 서버 앞에 놓여, 이용자로부터의 요청을 서버 대신 받아 뒤에 있는 한 대 또는 여러 대의 서버로 중계하는 서버. HTTPS 암호 처리를 한곳에서 모아 수행하는 것(TLS 종료), 자주 사용되는 응답을 저장해 두었다가 돌려주는 것, 여러 서버에 부하를 나누는 것, 뒤쪽 서버의 구성을 숨기는 것과 같은 역할을 담당한다. 이용자 쪽에 놓여 이용자 대신 외부 사이트에 접속하는 포워드 프록시와는 놓이는 장소와 지키는 대상이 다르다.

관련 비교