naknak

CS 지식/네트워크

HTTP 버전

naksnaks 2023. 3. 6.
반응형

HTTP의 역사

HTTP/0.9 (1991년)
HTTP/1.0 (1996년)
HTTP/1.1 (1997년) : 가장 많이 이용

  • RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
  • 현재 표준 스펙을 보려면 RFC7230을 봐야 합니다.
    HTTP/2.0 (2015년) : HTTP/1.1의 성능 개선 및 확장
    HTTP/3.0 (진행중)

HTTP 0.9

  • HTTP 초기 버전
  • 요청 : 단일 라인으로 구성 / Method : GET만 존재
  • HTTP 헤더 X, HTML파일만 전송 가능

    ex)

    <HTML>
Test case
<HTML>

    HTTP 1.0

  • HTTP Header 개념 도입, 메타데이터를 주고 받고, 확장가능하도록 개선
  • 버전 정보, 요청 method가 함께 전송
  • 상태 코드라인 추가 (응답의 시작 부분에 추가 -> 요청의 성공 유무 파악) (해당 결과에 대한 로컬 캐시 갱신 기능도 가능)
  • Content-Type 도입 -> HTML 이외 문서 전송 가능

단점

  • 커넥션 하나 당 요청 하나와 응답 하나만 처리 가능

HTTP 1.1

  • Persistent Connection 추가 (지정한 timeout 동안 커넥션을 닫지 않는 방법 -> 커넥션의 사용성 ↑
  • Pipelining 추가
    • 순차적인 여러 요청을 연속적으로 보내고, 순서에 맞춰 응답 받음
    • Multiplexing(동시에 여러 요청 처리)은 되지 않음

단점

  • Head Of Line Blocking (HOL) : 앞 요청의 응답이 오래걸리면 뒤 요청은 Blocking 상태
  • Header 구조의 중복 : 연속된 요청의 헤더의 많은 중복 발생

HTTP 2.0

  • 기존 1.1에서의 확장
    1. HTTP 메세지 전송 방식의 전환
    1. Multiplexed Streams
    1. Stream Prioritization
    1. Server Push
    1. Header Compression

1. HTTP 메세지 전송 방식의 전환

  • 기존 : 텍스트 형식
  • 현재
    • Binary Framing 계층을 추가하여 보내는 메시지를 frame 단위로 분할, Binary로 인코딩 (Binary 사용으로 파싱속도↑, 전송속도↑, 오류 발생 가능성 ↓)

2. Multiplexed Streams

  • 기존 : Pipelining으로 여러 요청을 받지만, 동시 처리 불가
  • 현재
    • 구성된 연결 내에 Stream(전달되는 바이트의 양방향 흐름)으로 요청. (하나의 커넥션 안에 여러 Stream 존재 가능)
    • 메시지가 Frame(이진화된 텍스트)으로 나뉘어 요청마다 구분되는 Stream을 통해 전달

Stream Prioritization

  • 리소스간 우선순위 설정
  • Stream에 우선순위를 부여하여 인터리빙되고 전달하는 것 가능

Server Push

  • 단일 클라이언트 요청에 여러 응답을 보낼 수 있는 특징 -> Server에서 Client에 필요한 추가적인 리소스를 push하는 기능

Header Compression

  • 기존 : 연속된 요청은 많은 헤더의 중복으로 인하여 오버헤드 발생
  • 현재
    • 요청과 응답의 헤더 메타데이터를 압축하여 오버헤드 감소
        1. 전송되는 헤더 필드를 static dynamic table로 서버에서 유지
        1. 이전에 표시된 헤더를 제외한 필드를 허프만 인코딩을 수행하여 데이터를 압축

단점

  • 각 요청마다 Stream으로 구분했지만, TCP 고유의 HOL Blocking 존재
  • 하나의 Stream에서 유실이 되거나 문제가 생기면, 다른 Stream도 문제가 해결될 때 까지 지연
  • 이를 해결하기 위해 QUIC/HTTP 3.0 등장

QUIC / HTTP 3.0

  • [QUIC]
    • Google에서 개발한 UDP 기반의 전송 프로토콜 (Quick UDP Internet Connections)
    • 만든 이유 : TCP의 구조적 문제로 성능 향상이 어렵다고 판단 -> UDP 방식 채택
    • TCP의 3-way handshake과정을 최적화 하는 것에 초점
    • TCP의 Stream은 하나의 chain으로 연결되는 것과 다르게, 각 Stream 당 독립된 Stream chain을 구성하여 TCP HOL Blocking을 해결
  • HTTP 3.0
    • QUIC을 기반으로 나온 HTTP 메이저 버전

출처
Semantics님 - HTTP - version별 특징
꾸미님 - HTTP 1.1 vs HTTP 2.0 vs HTTP 3.0

반응형

'CS 지식 > 네트워크' 카테고리의 다른 글

URL이란?  (0) 2023.03.09
브라우저에 URL을 입력했을 때의 과정  (0) 2023.03.09
HTTP 구조  (0) 2023.03.06
HTTP와 HTTPS란?  (0) 2023.03.02
TCP와 UDP  (0) 2023.02.27

댓글

💲 추천 글

티스토리툴바