개발 일기

[Computer Netowrk] HTTP/1.0, HTTP/1.1, HTTP/2.0, HTTP/3.0(QUIC) 본문

Computer Science/Computer Network

[Computer Netowrk] HTTP/1.0, HTTP/1.1, HTTP/2.0, HTTP/3.0(QUIC)

개발 일기장 주인 2025. 5. 7. 02:29

EC 스터디

 📁 INTRO 

  • HTTP (Hypertext Transfer Protocol) 웹에서 데이터를 주고받기 위한 통신 규약(프로토콜)
  • OSI 7계층 중 L7 즉, Application Layer에 해당
  • 클라이언트-서버 구조 (Request ↔ Response)
  • 우리가 주로 개발할때 가장 흔하게 접할 수 있는 프로토콜이며 아래 DevTools에서 네이버 화면을 띄웠을때도 h2 즉, HTTP/2.0이 사용되는 것을 확인할 수 있다.

  • 현재는 위 오른쪽 그림과 같이 HTTP/2.0이 주로 사용되고 있으며 유투브, 구글 등에서는 h3까지도 사용되고 있다.

 

🌱 HTTP/0.9 (1991년)

HTTP의 시작은 1989년 팀 버너 리(Tim Berners-LEE)에 의해 제안된 인터넷의 하이퍼 텍스트 시스템으로 최초의 HTTP 버전, 매우 단순한 설계되어 Static한 HTML 페이지(하이퍼텍스트 문서 - HTML)만 전송하는 데 사용된다.
초기에는 버전 번호가 존재하지 않았지만, 이후에 다른 http 버전들과 구분하기 위해서 0.9라고 붙힘
  • TCP기반
  • Short-Lived Connections : 요청마다 새로운 TCP 연결을 생성하고, 응답이 끝나면 바로 종료
  • HTTP Method: GET 메서드만 지원
  • 요청 형식: 단순히 GET /index.html 형태
  • 응답 형식: 하이퍼텍스트(HTML 문서)만 응답 가능
  • HTTP Header 및 Status Code X
[클라이언트 Request]
GET /index.html

[서버 Response]
<html>
  <head><title>Welcome</title></head>
  <body>
    <h1>Hello, HTTP/0.9!</h1>
  </body>
</html>

 

▼ 한번 읽어보시면 좋을 것 같아요

https://www.w3.org/Protocols/HTTP/AsImplemented.html

 

The HTTP Protocol As Implemented In W3

1991 The Original HTTP as defined in 1991 This document defines the Hypertext Transfer protocol (HTTP) as originally implemented by the World Wide Web initaitive software in the prototype released. This is a subset of the full HTTP protocol, and is known a

www.w3.org

🌿 HTTP/1.0 (1996년)

웹이 인기를 끌고 HTTP 스펙을 표준화하기위한 HTTP-WG (HTTP Working Group)이라는 조직이 탄생하였으며,
1996년 HTTP/0.9 버전에서 대폭 개선된 HTTP/1.0 스펙인 RFC1945가 발표(HTTP 1.0 프로토콜 통신 스펙에 관한 문서).
  • TCP 기반
  • Short-Lived Connections
  • 헤더 (기본적인 HTTP 메서드와 요청/응답 헤더 추가)
  • 응답 코드 (요청에 대한 성공/실패 여부를 담은 응답 코드 추가)
  • 리다이렉트
  • 다양한 파일 형식 지원(Content-Type 추가)

비교

  HTTP/0.9 HTTP/1.0 설명
정식 명세 없음 (사실상 구현 중심) RFC 1945 (1996) HTTP/1.0은 공식 표준 문서로 정의됨
요청 방식 GET /index.html GET /index.html HTTP/1.0 + 헤더 요청 형식이 명시적이고 유연해짐
지원 메서드 GET만 지원 GET, POST, HEAD 데이터 전송과 상태 확인 등이 가능
응답 포맷 HTML 본문만 상태 코드 + 헤더 + 본문 서버 응답 구조가 명확해지고 다양해짐
상태 코드 없음 존재 (200 OK, 404 Not Found 등) 성공/실패 여부 판단 가능
헤더 없음 다양한 요청/응답 헤더 지원 Content-Type, Content-Length, Host 등
파일 형식 HTML만 가능 다양한 MIME 타입 (image/png, text/css 등) 멀티미디어 콘텐츠 전달 가능
리다이렉션 없음 가능 (301, 302 등) 경로 이동에 유용
조건부 요청 없음 If-Modified-Since 등 지원 캐시 및 효율적인 데이터 전송 가능
압축 전송 없음 Content-Encoding (예: gzip) 대역폭 절약 가능
TCP 연결 요청마다 새 연결, 즉시 종료 기본은 요청당 새 연결, 일부 keep-alive 가능 비지속 연결 기본, 단 연결 재사용 시도 존재
Host 헤더 없음 Host 헤더 필수는 아님 (1.1부터 필수) 가상호스팅 준비 단계

 

 

❌ HTTP/1.0의 Short-lived Connections 문제점

  • HTTP/1.0에서는 요청(Request) → 응답(Response) 한 번 주고받으면, TCP 연결이 바로 끊긴다.
  • 아래 가장 왼쪽이 short-lived connections인데 보는 것과 같이 매 요청 응답 쌍 마다 연결 성립(TCP 3-way handshake) 및 연결 종료를 수행하기 때문에 그만큼 오버헤드가 심할 것이다.
  • 하나의 페이지 요청에 대해 HTML, CSS, 이미지 등 각각의 리소스에 대해 별도의 TCP Connection을 생성한다면 그만큼 지연이 있을 것이다.

사실 HTTP/1.0에서도 Connection: keep-alive을 지원하긴 하지만 이는 표준이 아니라 서버나 클라이언트가 지원하지 않으면 동작이 불확실했다. 따라서 이를 표준화할 필요가 있었다.

🌳 HTTP/1.1 (1997년)

HTTP/1.0이 나온지 정말 얼마 되지 않아 등장했다.
현재에도 일부 사용되고 있는 프로토콜이다.
  • TCP 기반
  • Persistent Connection
  • Pipelining
  • HOST 헤더 추가 : 동일 IP 주소에 다른 도메인을 호스트하는 기능 가능
  • Chunked Transfer Encoding → 동적 콘텐츠 처리 가능
  • PUT, DELETE, OPTIONS 등 메서드 추가

 

Persistent Connection

HTTP/1.0의 가장 큰 문제는 Short-lived connections 였고 HTTP/1.1에선 Persistence connection이란 이름으로 한 번 연결을 맺으면 지정한 timeout동안 지속적으로 연결을 유지하도록 이 문제를 보완했다.
즉, 두 엔드포인트간에 TCP 연결이 맺어지면 timeout동안 유지되며, 여러 개의 요청/응답을 주고받을 수 있는 구조
이런 지속 연결을 위해 HTTP/1.1에서는 기본적으로 연결을 유지하도록 설계되었기 때문에, 별도로 Connection: keep-alive 헤더를 명시하지 않아도 클라이언트와 서버 간의 연결이 자동으로 유지된다.

  • Connection: keep-alive
  • Connection: close
  • Keep-Alive: timeout=5, max=100 (유휴 상태로 5초까지 연결 유지,  최대 100개의 요청까지 이 연결을 사용)
TCP Keep-Alive?
HTTP keep-alive와 동일한 것인 줄 알았지만 엄연히 분리된 개념.
TCP ka는 전송계층, HTTP ka는 어플리케이션 계층으로
HTTP ka가 하나의 TCP Connection을 재사용하여 여러 HTTP 요청 및 응답을 처리하는 것이라면
TCP ka는 장시간 사용되지 않은 TCP 연결이 끊겼는지 확인하기 위한 목적으로 존재한다.

HTTP ka는 웹 서버/클라이언트에서 헤더로 다루는 설정이지만 TCP ka는 OS 레벨에서 동작하는 것이고 일정 시간마다 keep-alive 패킷을 전송한다.

 

Pipelining

HTTP Pipelining은 클라이언트가 여러 개의 HTTP 요청을 순차적으로 보내되, 응답을 기다리지 않고 연달아 보내는 방식이다.

단, 응답은 요청 순서대로(FIFO) 받아야 한다.

[요청1] → [응답1]
[요청2] → [응답2]
[요청3] → [응답3]

[요청1][요청2][요청3] → 
          [응답1][응답2][응답3]

 

그러나 대부분의 브라우저는 파이프라이닝을 사용하지 않았다.

그 이유는 아래와 같이 HOLB 그리고 구현에서의 어려움이 있다.

❌ HTTP/1.1의 문제점 1: Head of Line Blocking(HOLB)

위에서 소개한 파이프 라이닝은 어찌보면 정말 혁신적인 기술이지만, 보낸 요청 순서대로 응답을 받아야하는 규칙 부분에서 문제가 생기게 된다.
마치 FIFO(선입선출) 처럼 생각하면 되는데, 문제는 요청하는 데이터의 크기는 제각각 이기 때문에, 첫번째로 요청한 데이터가 용량이 큰 데이터라면, 두번째, 세번째 데이터가 아무리 빨리 처리되어도 우선순위 원칙에 따라 첫번째 데이터의 응답 속도가 늦어지면 후 순위에 있는 데이터 응답속도도 덩달아 늦어지게 되는 것이다.

→ 첫 번째 Request 처리에 오랜 시간이 걸리는 Big Task라면 그 후에 들어온 요청들도 모두 Delay된다.(성능이슈)

 

❌ HTTP/1.1의 문제점 2: 헤더 중복으로 인한 대역대 낭비

 

⚡ HTTP/2 (2015년)

HTTP 2.0은 기존 HTTP 1.1 버전의 성능 향상에 초점을 맞춘 프로토콜
  • TCP 기반
  • Binay Framing Layer
    Binary Framing Layer는 HTTP 메시지를 작은 Frame으로 나누고, 이를 Stream 단위로 나누어 전송
    - 즉, Frame은 HTTP/2.0에서 통신의 최소 단위이며 Header와 Data 등이 있다.
    - Message는 HTTP/1.1과 마찬가지로 요청 혹은 응답의 단위이며 다수의 Frame으로 이루어진 배열 라인이다. 
    - Stream은 연결된 Connection 내에서 양방향으로 Message를 주고 받는 하나의 흐름

 

 

  • Multiplexing
    하나의 TCP 연결(Connection) 내에서 여러 개의 Stream을 동시에 처리할 수 있게 해주는 기술
    이때, 각 Stream 별로 별도의 공간이 존재하는 것이 아닌 하나의 공간에서 여러 Stream의 Frame들이 오고 가는 것
    • Binary Framing Layer에 의해 쪼개진 Frame들은 이 고유한 Stream ID를 통해 서로 구분
    • Frame들은 반드시 순차적으로 정렬될 필요 없이 섞여서(interleaved) 전송된다.
      이를 통해 Head-of-Line Blocking 문제를 Application-Level에서 해결했다.
    • /index.html, /style.css, /script.js 요청이 동시에 발생하면, 각각의 응답이 동시에 병렬 처리되어 순서와 무관하게 빠르게 렌더링

 

  • Server Push
    클라이언트의 요청 없이도 서버가 필요한 리소스를 미리 전송할 수 있는 기능, 즉 Server Push를 지원.
    예를 들어, 클라이언트가 /index.html을 요청하면, 서버는 이 HTML 문서가 내부적으로 사용하는 이미지, CSS, JavaScript 파일 등을 사전에 예측하여 해당 리소스들을 클라이언트가 요청하기도 전에 미리 전송할 수 있다.

 

 

  • HTTP Header Data Compression(HPACK)
    만일 메세지 헤더에 중복값이 존재하는 경우, 위의 그림에서 Static / Dynamic Header Table 개념을 사용하여 중복 헤더를 검출하고, 중복된 헤더는 index값만 전송하고 중복되지 않은 Header 정보의 값은 호프만 인코딩(Huffman Encoding) 기법을 사용하는 HPACK 압축 방식으로 인코딩 처리 하여 전송하여, 데이터 전송 효율을 높였다.
    이번에 중복되지 않았던 것은 추후에 Table에 누적되어 인덱스를 활용할 수 있다.

 

 

❌ HTTP/2.0의 문제점 1: TCP 자체의 HOLB (Head Of Line Blocking)

  • HTTP/2는 여러 Stream을 하나의 TCP 연결로 멀티플렉싱하지만, TCP는 순차적 전송이 보장되어야 하는 프로토콜이다.
  • 따라서 TCP 레벨에서 패킷 손실이 발생하면, 해당 패킷이 재전송되기 전까지 이후의 모든 데이터 전송이 지연되는 문제가 발생한다.
  • 즉, 애플리케이션 레벨에서는 멀티플렉싱을 하더라도, 네트워크 레벨에서는 여전히 Head-of-Line Blocking 문제가 존재한다.

❌ HTTP/2.0의 문제점 2: TCP + TLS 연결 수립 시 지연

  • HTTP 프로토콜에서 대부분 HTTPS를 기반으로 동작한다.
  • 그런데 이때 HTTPS의 경우 기본적으로 TCP HandShaking에 더불어 TLS HandShaking의 과정까지 겪어야 하기 때문에 연결 수립 시 지연이 크다.

 

→ 즉, L7의 문제는 해결 했더라도 L4 전송 계층의 TCP 프로토콜 자체의 문제는 여전하다.

🚀 HTTP/3 (2022년 정식 표준화, QUIC 기반)

HTTP/3는 2022년 정식으로 표준화된 최신 HTTP 프로토콜로, 기존 HTTP/2의 성능 한계를 극복하기 위해 TCP가 아닌 UDP 기반의 전송 프로토콜인 QUIC 위에서 동작.
HTTP/1.1과 HTTP/2는 모두 TCP 기반이었기 때문에 위와 같은 문제가 있었으나 HTTP/3는 이러한 문제를 해결하고, 더 빠른 연결과 더 나은 사용자 경험을 제공하기 위해 개발됐다.

 

HTTP/3.0의 기반 프로토콜인 QUIC에 대해 먼저 정리해보자.

QUIC(Quick UDP Internet Connections)

  • HTTP/3의 가장 큰 특징은 기존의 HTTP/1, HTTP/2와는 다르게 UDP 기반의 프로토콜인 QUIC을 사용하여 통신하는 프로토콜
  • RFC 9000으로 표준화
  • QUIC은 내부적으로 TCP + TLS의 기능을 모두 가진 프로토콜
더보기

[UDP인데 어떻게 TCP + TLS 기능을 가지고 있나? 신뢰성과 패킷의 무결성을 보증하지 못하는 것 아닌가?]

 

→ UDP인데 어떻게 TCP 기능을 가지고 있냐고 생각할 수도 있는데, 이는 QUIC이 애초에 UDP 위에서 TCP의 핵심 기능들(신뢰성 있는 전송, 흐름 제어, 혼잡 제어 등)을 사용자 공간(User space)에서 직접 구현했기 때문이다. 즉, 전송 계층의 기능을 애플리케이션 계층에 가까운 위치에서 소프트웨어적으로 처리함으로써, TCP가 제공하던 기능을 유지하면서도 더 유연하고 빠른 연결을 가능하게 한 것이다.

TCP 세그먼트는 헤더에 순서 번호, 확인 응답 번호, 플래그 비트, 윈도우 크기 등 다양한 제어 정보들이 포함되어 있지만, UDP 데이터그램은 이러한 부가적인 제어 정보 없이 헤더가 간단하고 최소한의 정보만 담고 있다.
QUIC은 이러한 UDP의 단순한 구조를 활용하여, 필요한 전송 제어 기능들(예: 신뢰성, 흐름 제어, 순서 보장 등)을 사용자 공간에서 직접 구현함으로써, TCP의 기능을 대체하면서도 더 빠르고 유연한 통신을 가능하게 한다.

 

즉, UDP는 신뢰성이 없는게 아니라 탑재를 안했을 뿐이고 진짜 장점은 커스터마이징이 가능하다는 점이다.

 

더보기

RTT (Round Trip Time)
RTT(Round Trip Time)란, 요청(SYN)을 보낼 때부터 요청에 대한 응답(SYN+ACK)을 받을 때까지의 왕복 시간

 

 

 

HTTP/3.0

QUIC 위에서 동작하는 Application Layer Protocol

 

https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP-30-%ED%86%B5%EC%8B%A0-%EA%B8%B0%EC%88%A0-%EC%9D%B4%EC%A0%9C%EB%8A%94-%ED%99%95%EC%8B%A4%ED%9E%88-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90

  • 연결 시 Latency 감소
    • 연결 성립 과정 시 아래 그림과 같이 3 Way Handshaking 과정 없이 1 RTT만 소요
    • 심지어 한번 연결에 성공하면 서버는 해당 설정을 캐싱해두고 다음 연결 때 캐싱을 통해 바로 연결하기에 0RTT로 바로 통신

 

 

    • 네트워크가 변경 되어도 연결 유지
      • TCP에서는 Client IP + Client Port → Server IP + Server Port 이렇게 4가지 정보로 Connection 맺음
      • 이때 Wifi에서 LTE로 바꾸게 되면 동영상 등이 일시적으로 끊킬텐데 이는 Client 정보가 변경되기 때문에 TCP HandShaking과정을 다시 진행하여 연결을 생성해야한다.

      • 반면 QUIC은 Connection ID를 통해 연결을 생성하기 때문에 IP가 바뀌더라도 Connection은 유지된다.

Connection ID

 

  • TCP로 인해 잔존하던 HOLB 문제 해결 : 독립 스트림
    • 위에서 말했듯이 Application Layer는 해결됐지만 TCP로 인해 Transport Layer의 HOL Blocking의 문제가 해결되지 못했었다.
      → HTTP/2에서 스트림에서 여러가지 프레임들이 뒤 섞여 이동되게 되는데, 만일 어느 하나의 프레임에 문제가 생기면 상관없는 그 뒤의 프레임까지 영향이 가게 된다.

    • 따라서, HTTP/3.0부터는 아예 스트림 자체를 독립적으로 두는 독립 스트림이라는 개념을 통해 이를 해결했다.
      → 즉, 하나의 Request/Response 쌍마다 독립적인 스트림이 생기기 때문에 하나의 스트림에서 패킷 손실이 나더라도 나머지 스트림은 문제 없이 통신을 이어가는 것.

Transport Layer HOL Blocking 해결 전 / 후
독립 스트림

 

'Computer Science > Computer Network' 카테고리의 다른 글

[Computer Network] OSI 7계층  (0) 2024.12.17
[Computer Network] 실시간 웹 통신 - 5. 메세지 브로커(Message Broker) RabbitMQ& Kafka  (1) 2024.10.10
[Computer Network] 실시간 웹 통신 - 4. STOMP(Simple/Stream Text Oriented Message Protocol)  (2) 2024.10.09
[Computer Network] 실시간 웹 통신 - 3. 웹소켓 프로토콜(WebSocket Protocol)  (0) 2024.10.09
[Computer Network] 실시간 웹 통신 - 2. 소켓 통신  (10) 2024.10.09
'Computer Science/Computer Network' Related Articles more