HTTP (1) - version 별 특징 (0.9 / 1.0 / 2.0 / 3.0)

김정욱·2022년 3월 5일
HTTP 0.9HTTP 3.0httphttp 1.0http 2.0quic
6

HTTP

목록 보기
1/7
post-thumbnail

[ HTML 역사 ]

  • 전체
    • 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 1.1 이 모든것의 기반이기 때문에 잘 알고 그 다음에 2.0 / 3.0을 알아두면 좋다
    • 추후 사용될 HTTP 3.0도 인지해두자

[ HTTP 0.9 ]

  • 특징
    • HTTP 초기 버전을 구분하기 위해 부르는 버전 (1991년)
    • 요청은 단일 라인으로 구성되며, 리소스에 대한 method는 GET만 존재
    • 응답도 극도로 단순 (파일 내용 자체로만 구성)
    • HTTP 헤더도 없고, HTML파일만 전송 가능했던 것이 특징
/* 요청 */
GET /mypage.html

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

[ HTTP 1.0 ]

  • 특징
    • HTTP 헤더(header) 개념이 도입되어 요청과 응답에 추가되며, 메타데이터를 주고 받고 프로토콜을 유연하고 확장 가능하도록 개선됨 (1996년)
    • 버전 정보와 요청 method가 함께 전송되기 시작
    • 상태 코드 라인도 응답의 시작부분에 추가되어 브라우저 요청의 성공과 실패를 파악 가능해짐
      (해당 결과에 대한 로컬 캐시 갱신 등의 사용이 가능해짐)
    • Content-Type 도입으로 HTML 이외의 문서 전송 기능이 가능해짐
  • 한계
    • 커넥션 하나당 요청 하나와 응답 하나만 처리 가능했음
      -> 지금 생각해보면 매우 비효율적인 동작으로 보이며, 서버 부하도 문제
      -> HTTP 1.1에서 개선
/* 요청 */
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.1 ]

  • 특징
    • 1997년 등장
    • Persistent Connection 추가
      • 지정한 timemout 동안 커넥션을 닫지 않는 방법을 통해 커넥션의 사용성이 높아짐
    • Pipelining 추가
      • 앞 요청의 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내고 그 순서에 맞춰 응답을 받는 방식이 등장
      • 순차적으로 하나씩 요청 / 응답이 처리되는 기존 방식을 개선
      • 하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해 응답으로 보내주는 것은 아니다 (multiplexing 되지는 않음)
  • 한계
    • Head Of Line Blocking (HOL)
      : 결국 앞 요청의 응답이 너무 오래걸리면 뒤 요청은 Blocking 되어버림
    • Header 구조의 중복
      : 연속된 요청의 헤더의 많은 중복이 발생
/* 요청 */
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)

[ HTTP 2.0 ]

  • 설명
    • 기존 HTTP 1.X 버전의 성능 향상에 초점을 맞춘 프로토콜 (2015년 등장)
    • 표준의 대체가 아닌 확장 (표준 : HTTP 1.1)
  • 특징
    • 1) HTTP 메시지 전송 방식의 전환
    • 2) Multiplexed Streams
    • 3) Stream Prioritization
    • 4) Server Push
    • 5) Header Compression

HTTP 메시지 전송 방식의 전환

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

Multiplexed Streams

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

Stream Prioritization

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

Server Push

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

Header Compression

  • 기존 : 연속된 요청의 경우 많은 중복된 헤더의 전송으로 오버헤드가 많이발생했음
  • 개선
    • 요청과 응답의 헤더 메타데이터를 압축해서 오버헤드를 감소
    • 1) 전송되는 헤더 필드를 static dynamic table로 서버에서 유지
    • 2) 이전에 표시된 헤더를 제외한 필드를 허프만(huffman) 인코딩을 수행해서 데이터를 압축

[ HTTP 2.0 한계 ]

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

[ QUIC / HTTP 3.0 ]

  • QUIC ?
    • Google에서 개발한 UDP 기반의 전송 프로토콜 (Quick UDP Internet Connections)
    • Google에서 TCP의 구조적 문제로 성능 향상이 어렵다고 판단하여 UDP 기반을 선택
    • QUIC은 TCP의 3-way handshake과정을 최적화 하는 것에 초점을 두고 개발됨
    • QUIC은 TCP의 Stream은 하나의 chain으로 연결되는 것과 다르게 각 Stream당 독립된 Stream chain을 구성하여 TCP HOL Blocking을 해결하였다
  • HTTP 3.0
    • QUIC을 기반으로 나온 새로운 HTTP 메이저 버전
profile
김정욱
Developer & PhotoGrapher
다음 포스트

HTTP (2) - URI, URL / HTTP 메시지

0개의 댓글