HTTP Version

HunkiKim·2022년 9월 13일

HTTP Version

HTTP/0.9

원-라인 프로토콜
요청 : GET /mypage.html
응답 :

<HTML>
A very simple HTML PAge
</HTML>

헤더 없이 GET 메서드만 가능했었음

HTTP/1.0

확장성 추가

요청

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>

응답

GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

버전 정보 추가
POST, HEAD 메서드 추가
헤더 추가
헤더가 추가돼서 HTML 이외의 데이터도 전송 가능
Persistent Connection (Keep-Alive) 추가 (정확히 1.0이후 1.0+버전에서 나옴)
그러나 기본적으로 connectionless 여서 한 번 통신후 커넥션을 종료 후 매번 커넥션을 연결 -> 비용이 크다.

HTTP/1.1

표준 프로토콜이다.

커넥션 재사용 가능
파이프라이닝 추가
Conncetion 헤더 없이도 모든 요청과 응답은 기본적으로 Persistent Connection을 지원, 따라서 끊을때에만 헤더에 추가 정보를 보낸다.
캐시 기능 추가
메서드 OPTION, PUT,DELETE, TRACE 등 추가

파이프 라이닝

하나의 커넥션에서 한 번에 순차적인 여러 요청을 보내고 기다리는 방식
그러나이 방법은 HOL(Head Of Line) 문제가 발생해서 현재는 대부분의 브라우저가 막고 있음.
- HOL : 맨 앞의 요청이 처리가 안되면 뒤의 요청이 기다려야 하는 현상
따라서 파이프 라이닝 사용하지 않고 HTTP/1.1 버전은 병렬 커넥션을 사용해 다수의 커넥션에서 1개의 요청을 보내는 방식으로 속도를 개선함. 즉 1개의 요청을 여러개의 커넥션을 통해 보내는 방식을 사용한다.

HTTP/2.0

HTTP/1.1과는 달리 텍스트가 아닌 바이너리 프레이밍을 통해 보내진다.
HTTP/1.1보다 빠르고 효율적이다.
HTTP/1.1의 확장으로 하나의 커넥션으로 여러 개의 요청을 보낼 수 있다.

특징

바이너리 프레이밍 계층
멀티 플렉싱
우선순위 설정
헤더 압축
서버 푸쉬

바이너리 프레이밍 계층

Application 계층안에 포함된다.

Application 계층[Binary 계층] - Session(TLS) (Optional) - Transport(TCP) - Network (IP)
식으로 이루어져 있다.

여기서 TLS는 IP Spoofing / Replay Attack을 방지해 줌으로써 보안성을 향상시켜준다. QUIC에서는 기본적용 되어있다.

1.1이 HTTP 메세지가 시작줄-헤더-바디 부분으로 이루어져서 보내지는 것과 다르게 HEADERS frame과 DATA frame으로 나누어져서 보내진다. HEADERS frame에는 시작줄과 헤더가 담겨있고 DATA FRAME에는 Message Body부분으로 되어있다. 기존에 Plain Text와 다르게 바이너리 포맷으로 인코딩된 Messaage,Frame으로 구성된다. 이러한 특징으로 HTTP/1.x와 HTTP/2 는 서로 해석하지 못한다.

스트림, 메시지 및 프레임

스트림 : 구성된 연결 내에서 전달되는 바이트의 양방향 흐름이며, 하나 이상의 메시지가 전달될 수 있다.
메시지 : 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스이다.
프레임 : HTTP/2에서 통신의 최소 단위이며 각 최소 단위에는 하나의 프레임 헤더가 포함된다. 이 프레임 헤더는 최소한으로 프레임이 속하는 스트림을 식별한다.

즉 스트림이라는 흐름 안에 메시지들이 오가가는데 이 메시지 안에 HEADERS frame, DATA frame이 들어있다.

요청 및 응답 다중화 (멀티 플렉싱)

기존 HTTP/1.x는 속도 개선을 위해 병렬 커넥션을 통해 병렬 요청을 보내야 했음
위와 같은 방법은 TCP 연결의 비효율성과 커넥션에 따른 자원을 생각하면 매우 비효율적이다.
HTTP/2는 바이너리 프레이밍 계층을 통해 이러한 제한을 없애고 하나의 커넥션에서 응답 다중화를 지원한다.

HTTP/1.1에서는 요청과 응답이 동시처리는 이루어지나 결국 응답처리를 지연시키는 블로킹 방식이었기 때문에, 한 개의 Connection이 하나의 Request/Response 를 처리하는 한계를 극복하기는 어려웠으며 그로 인해 HOL 문제 발생과 연결에 비효율성이 있었다.

하지만 HTTP/2에서는 개선된 멀티플렉싱을 통해 , Connection이 하나에서 다수의 입출력이 가능하게끔 지원한다. 이것이 가능한 이유는 HTTP/2는 패킷을 Frame단위로 세분화하여 순서에 상관없이 받는쪽에서 조립하도록 설계되었기 때문이다. 그렇기 때문에 HTTP/2에서는 각 요청과 응답을 병렬로 전달할 수 있으며 하나의 Connection에서도 여러 응답 / 요청을 처리할 수 있게 되었다.

이 스트림은 순서가 뒤죽박죽이여도 프레임 헤더를 통해 다시 조립이 가능하다.

스트림 우선순위 지정

각 스트림에는 1~256사이의 정수 가중치가 할당될 수 있다.
각 스트림에는 다른 스트림에 대한 명시적 종속성이 부여될 수 있다.
각 스트림에 우선순위를 부여할 수 있기 때문에 중요한 데이터부터 (예를들면 화면에 가장 먼저 띄워야 하는 데이터) 보낼 수 있음

서버 푸시

HTTP/2는 서버가 클라이언트에서 보낸 요청의 추가적으로 필요한 요청을 클라이언트의 요청이 오기 전에 보낼 수 있음

헤더 압축

바이너리라 가능하다.
연속적인 요청에는 많은 헤더가 중복된다.
이는 GET 메서드만 생각해봐도 매우 큰 자원 낭비이다.
따라서 이를 압축하여 중복되는 헤더는 참조를 통해 압축하여 보내서 자원을 절약 (압축방식은 Huffman)
- 이 방식에서 static table과 dynamic table을 두어 중복들을 검출해 내고 Huffman 방식으로 압축을 하여 보내게 된다.
헤더 데이터 크기가 85~88% 감소되고 지연 또한 상당히 개선됨
즉 중복되는 헤더는 빼고 보내는 방식이다.

HTTP/3

다른 HTTP 버전들과 달리 UDP를 사용하여 통신하고 이를 개발자가 따로 신뢰성을 확보함
구글이 개발한 전송 계층 통신 프로토콜인 QUIC를 사용
첫 연결 설정에서 필요한 정보와 함께 데이터를 전송하며 연결 성공 시 설정을 캐싱하여 다음 연결에 바로 핸드셰잌 없이 전송 가능하게 하였다.
- 이게 가능한 이유는 Connection UID를통해 고유한 식별자로 서버와 연결을 하여 커넥션 재수립할 필요가 없다.
HTTP2 에서도 한 개의 커넥션이기 때문에 헤드 오브 라인 블로킹문제가 발생할 수 있는데 이를 해결할 수 있음
- 다시말해 TCP를 사용하기 때문에 앞에 데이터가 손실이 날 경우 그 데이터를 다시 전송받을때 까지 기다려야 하기 때문에 Head Of Line Blocking 문제가 발생할 수 있다.
실제로 구글 대부분의 서비스에서 쓰고있음
- 유튜브 버퍼링 30퍼이상 개선