HTTP의 진화(버전별 특징)

hs·2025년 11월 4일
  • 1990년 월드와이드웹(WWW) 등장
  • 하이퍼텍스트 문서를 표현하기 위한 '하이퍼텍스트 마크업 언어' (HTML)
  • 하이퍼텍스트 문서를 교환하기 위한 프로토콜 '하이퍼텍스트 전송 프로토콜' (HTTP)

HTTP/0.9 (1991)

  • 최초의 HTTP
  • get 메서드만 지원
  • 간단한 HTML만 전송
  • 원래는 버전 번호가 없었으나 이후 버전과 구별하기 위해 0.9로 불리게 됐다.

HTTP/1.0 (1996)

  • 각 요청 안에 버전 정보가 포함되어 전송(HTTP/1.0 이 GET 라인에 붙은 형태).
// 요청
GET /mypage.html HTTP/1.0
User-Agent: Mozilla/5.0

// 응답
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html

내용..
  • HTTP 헤더 개념이 도입되어 메타데이터 전송 가능해졌고, 프로토콜이 유연하고 확장성이 높아졌다.
  • Content-Type 헤더를 통해 HTML 외에 다양한 파일 형식을 전송 가능
  • POST, HEAD 메소드 추가
  • 상태 코드가 도입되어 브라우저가 요청에 대한 성공과 실패를 알 수 있게됨
    • 결과에 대한 동작(예, 특정 방법으로 로컬 캐시를 갱신하거나 사용)을 할 수 있게됨
  • 요청할 때마다 새로운 TCP 연결 → keep-alive 헤더를 사용해서 개선

HTTP/1.1 (1997)

  • 지속적 연결을 기본으로 제공(Persistent Connection, keep-alive)

    • 여러 요청을 하나의 TCP 연결로 처리
  • 파이프라이닝 도입으로 응답을 기다리지 않고 여러 요청을 보낼 수 있음

    • 통신 지연 시간이 단축
  • 호스트 헤더 추가로 동일한 IP 주소에서 여러 도메인 호스팅 가능

  • HTTP 메소드 추가 → PUT, DELETE, OPTIONS, TRACE 등

  • 청크 응답 지원

    • 데이터를 일정 크기(청크, chunk)로 나누어 전송
    • 응답의 전체 크기를 알지 못하는 경우에도 데이터를 점진적으로 전송할 수 있다
      • 데이터베이스 쿼리나 대용량 파일 생성 등 실시간으로 콘텐츠 생성 등
    • 서버가 전체 응답을 메모리에 로드하지 않고도 점진적으로 전송할 수 있어 리소스 사용이 효율적이다.
  • 캐싱 메커니즘 개선

    • Cache-Control 헤더 추가로 캐시 정책을 세밀하게 설정가능
      • max-age: 캐시 유지 시간을 초 단위로 지정
      • public, private: 공유 캐시와 비공유 캐시 구분
      • no-cache, no-store: 캐싱 동작을 세밀하게 제어
      • must-revalidate: 만료된 캐시는 반드시 서버에 확인하도록 강제
    • Entity Tag(ETag)
      • 컨텐츠의 특정 버전을 식별하는 고유한 문자열
      • 날짜 기반 검증보다 더 정확한 캐시 유효성 검증 가능
    • 조건부 요청 확장
      • If-Modified-Since: 특정 날짜 이후에 변경된 경우에만 요청
      • If-None-Match: ETag가 변경된 경우에만 요청
  • 헤드 오브 라인(Head-of-Line) 차단 문제가 발생할 수 있다

    • 파이프라이닝에서 앞의 요청 처리가 지연되면 뒤의 모든 요청이 차단된다.
  • 헤더 압축 없음 쿠키와 같은 큰 헤더가 매 요청마다 반복적으로 전송된다.

HTTP/2.0 (2015)

  • SPDY 을 기반으로 구현됐다.
    • HTTP/1.1의 성능을 개선하기 위해 Google 구현한 프로토콜
  • 바이너리 프로토콜
    • 데이터 크기가 작아짐
    • 빠른 파싱 가능
    • 불필요한 공백 제거
  • 헤더 압축(HPACK)을 통해 헤더 정보를 효율적으로 압축하여 전송
  • 서버 푸시(Server Push)기능 추가
    • 클라이언트 요청 전에 서버가 필요한 리소스를 미리 전송

구조

  • 프레임
    • HTTP/2 통신의 가장 기본적인 단위
    • HTTP/2에서는 모든 통신이 이진(binary) 프레임으로 구성된다.
  • 메시지
    • 완전한 HTTP 요청 또는 응답을 나타낸다.
    • 메시지가 여러 프레임으로 나뉘어 전송될 수 있다.
  • 스트림
    • 클라이언트와 서버 사이의 가상의 독립적인 통신 채널 (요청-응답 쌍으로 구성)
    • 클라이언트와 서버가 동시에 데이터를 주고받을 수 있다. (양방향성)
    • 하나의 TCP 연결 내에서 여러 스트림을 동시에 처리할 수 있다. (멀티플렉싱)
    • 우선순위 지정 → 중요한 요청을 먼저 처리할 수 있도록 스트림의 우선순위 설정할 수 있다.

HTTP/3.0 (2022)

  • UDP 기반 QUIC(Quick UDP Internet Connections) 프로토콜 사용: TCP 대신 UDP 위에서 동작
    • Google에서 개발한 UDP 기반의 전송 계층 프로토콜
  • TLS 1.3이 프로토콜에 내장되어 있어 별도의 핸드셰이크 과정이 필요 없다.
  • IP 주소가 아닌 고유 식별자로 연결을 유지하므로 네트워크 전환시에도 연결이 유지된다.
  • TCP처럼 순차적이지만 독립적인 여러 스트림을 지원한다.
  • TLS 1.3의 0-RTT 재연결 기능을 확장하여 이전에 방문한 서버에 대해 연결 설정과 동시에 데이터를 전송할 수 있다
    • RTT(Round Trip Time)
    • 데이터 패킷이 출발지에서 목적지까지 갔다가 다시 출발지로 돌아오는 데 걸리는 시간
profile
sh

0개의 댓글