HTTP 란? 버전별 특징

GwanMtCat·2023년 9월 15일
http
0

HTTP 란?

HyperText Transfer Protocol

월드 와이드 웹에서 정보를 주고 받을 수 있는 프로토콜, HTML 문서를 주고받는 데에 사용한다.
주로 TCP 를 사용하고, HTTP/3 부터는 UDP(TCP의 장점을 몇가지 포함한...) 를 사용하며 80 번 포트를 사용하고 있다.

클라이언트와 서버 사이에 이루어진 요청, 응답 프로토콜로 http 로 시작하는 URL 로 조회 가능하다.

HTTP 버전 별 특징

HTTP/0.9 (1991년)

  • HTTP 초기 버전
  • 요청은 단일 라인으로 구성, method는 GET만 존재
  • 응답도 단순
  • HTTP 헤더도 없고, HTML 파일만 전송 가능했던 특징
```html
/* 요청 */
GET /mypage.html

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

HTTP/1.0 (1996년)

  • 각 요청·응답 사이에서 버전 정보가 명시되었음

  • GET, HEAD, POST로 메서드가 확장됨

  • 상태 코드가 추가되어 클라이언트 측에서 요청 결과에 따라 동작이 가능

  • 요청과 응답에 대한 부가적인 메타데이터를 담는 헤더 필드가 생김

  • HTTP 헤더(Content-Type) 의 도움으로 HTML 이외의 파일을 전송 가능하게 되었음,

  • 커넥션 하나 당, 요청 하나와 응답 하나만 처리 가능해서 매우 비효율적이고 서버 부하 문제가 있었음

/* 요청 */
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년)

다음과 같은 목적으로 설계 되었다.

HTTP/1.0 설계에서 불완전하고 고려되지 않은 부분 (계층적 프록시, 캐싱, 연결 지속 등)이 있음
HTTP/1.0 으로 통신한다고 선언했지만 지키지 않은 서버와 클라이언트가 많음

장점

  • 지속 커넥션(Persistent Connection)추가, 일정 시간 동안 커넥션을 닫지 않아 커넥션의 사용성이 증가

  • 파이프라인(Pipeline Connection) 추가, 앞 요청의 응답을 기다리지 않고, 순차적인 여러 요청을 연속적으로 보내고, 그 순서에 맞춰 응답을 받음 하나의 커넥션에 여러개의 요청이 들어 있을 뿐, 동시에 여러개의 요청을 처리해주지는 않음

  • 호스트 헤더 (Host Header) 추가, 1.1에서는 IP 하나에 여러 개의 도메인이 가능해져 가상 호스팅이 가능

  • 추가적인 캐시 제어 메커니즘이 도입되었음

  • OPTION, PUT, DELETE, TRACE method 가 추가되었음

단점

  • Head Of Line Blocking

    • HOL, 앞의 요청이 너무 오래 걸리면, 뒤 요청은 Blocking 되어버림

  • Header 구조의 중복

    • 연속된 요청의 헤더의 많은 중복이 발생
    • 본문은 압축이 되나 헤더는 압축이 되지 않는 문제가 있음 

GET /ko/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/ko/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)


GET /static/img/header-background.png 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: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/ko/docs/Glossary/Simple_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)

HTTP/2.0 (2015년)

기존의 HTTP 1.X 버전의 성능 향상에 초점을 맞춰 대체가 아닌 확장을 하려고 함
구글의 SPDY 프로토콜을 기초

장점

  • HTTP 메시지 전송 방식의 전환
    • 기존 HTTP/1.1 은 텍스트 기반 프로토콜로 아스키 코드로 작성, 사람이 읽기 편하나 데이터가 큰 문제
    • 보내야 할 데이터를 바이너리로 변환하는 계층 (Binary Framing)이 있어 훨씬 더 효율적으로 데이터를 전송할 수 있음(이진 프로토콜), 메시지를 프레임 단위로 분할하여 전송 가능
      • 메시지를 바이너리 프레임으로 변환해야 헤더를 압축하고 다중 통신이 가능하였음

  • Multiplexed Streams (다중 통신)
    • HTTP 1.1의 파이프라이닝으로 하나의 커넥션에 여러 요청이 있었지만, 동시에 여러 요청을 처리해 응답으로 주지는 못하였음 (HTTP/1.1의 HOLB 해결)
    • 하나의 TCP 커넥션에서 여러 요청을 동시에 처리할 수 있게 stream, frame, message 라는 단위로 더욱 세분화하였음
  • Stream : 요청과 응답이 양방향으로 오가는 논리적 연결 단위, TCP 연결에서 여러 개의 스트림이 동시에 존재할 수 있음
  • Message: 하나의 요청과 응답을 구성하는 단위
  • Frame : 메시지를 구성하는 최소 단위, 잘게 쪼개어 전송되기 때문에 수신 측에서 다시 조립하여 사용
  • 헤더 필드 압축을 지원 (Header Compression)
    • HPACK 이라고 부르는데 달라진 부분만 다시 전송하는 허프만 인코딩(Huffman Coding) 기법을 지원
    • 달라지지 않은 부분은 전송하지 않아 불필요하게 발생하는 오버헤드 최소

  • 스트림 우선순위 (Stream Prioritization)
    • 리소스간 우선순위를 설정이 가능

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

단점

  • Stream으로 구분해서 병렬적으로 처리하지만, 결국 이에는 TCP 고유의 HOL Blocking 이 존재함

  • 서로 다른 Stream 이 전송되고 있을 때, 하나의 Stream에서 유실이 발생되거나 문제가 생기면 결국 다른 Stream도 문제가 해결될 때 까지 지연되는 현상이 발생

  • TCP의 태생적인 HOL Blocking 을 해결하기 위해 HTTP 3.0 이 출현


HTTP/3.0 (진행중)

  • TCP의 구조적 문제로 성능 향상이 어렵다고 판단하였음
  • QUIC (Quick UDP Internet Connections) 이라는 구글에서 개발한 UDP 기반의 전송 프로토콜을 사용
  • 패킷 재전송, 혼잡 제어, 흐름 제어 등을 직접 구현한 UDP

  • QUIC 은 TCP의 3-way handshake 과정을 최적화 하는 것에 초점을 두고 개발

  • 0-RTT 기능이 있어 연결 정보를 캐싱하여 재사용 할 수 있다. TCP는 최초 연결 수립 시 3-way handshake 가 필요하지만, HTTP/3 은 최초 연결 설정에서 연결에 필요한 정보들과 데이터를 함께 전송하여 1-RTT 로 시간을 절약한다. 성공한 연결은 캐싱해 놓았다가 다음 연결 때 캐싱된 정보를 바탕으로 바로 연결을 수립해 0-RTT 가 가능하다.

  • 연결 다중화를 지원하여, 각 스트림이 독립적으로 동작한다. HTTP/2 에서는 연결 다중화가 지원되어, 여러 스트림이 동시에 동작할 수 있지만, TCP 의 특성상 데이터의 손실이 발생하면 데이터 복구를 우선 처리하게 되어 결국 HOLB가 발생한다.

  • QUIC 기반의 HTTP/3 에서는 연결 내 스트림이 완전히 독립적이기 때문에 데이터 손실이 발생해도 다른 스트림에 영향을 주지 않는다.

  • HTTP/3은 IP 기반이 아닌, 연결 별 고유 UUID(Connection ID)를 이용해 각 연결을 식별한다. TCP의 경우, WIFI -> 셀룰러 환경 으로 이동하는 경우에 IP주소가 변해 결국 연결을 재 수립해야하지만 QUIC은 연결 ID 기반이므로 연결을 그대로 유지할 수 잇다.

  • HTTP/2와 마찬가지로 TLS 연결 설정 과정이 QUIC 내부에 포함되어 있어, HTTPS 사용이 강제되고, 우선순위 제어, 서버 푸시 등의 기능을 마찬가지로 제공한다.

  • 또한 HTTP/2.0의 HPACK 과 유사하게 QPACK을 이용해 헤더 프레임을 압축하여 전송한다.

참조한 책 및 사이트

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
https://yozm.wishket.com/magazine/detail/1686/
https://haengsin.tistory.com/74
profile
GwanMtCat
이전 포스트

CPU 스케쥴링 알고리즘 (2)

다음 포스트

HTTPS 란?

0개의 댓글