http

Reference

HTTP의 진화
그림으로 쉽게 보는 HTTP변천사
Introduction to HTTP/2


HTTP란?

HTTPHyper Text Transfer Protocol의 약자록 인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다.


HTTPWorld Wide Web에 내제된 프로토콜로 1989년CERN(유럽 입자 물리학 연구소)의 팀 버너스 리(Tim Berners-Lee)에 의해 World Wide Web 을 제안했다.


이때 문서 기술 언어로는 SGML을 베이스로하는 HTML, 문서 전송 프로토콜인 HTTP, 문서의 주소를 지정하는 방법인 URL(Uniform Resource Locator) 등이 같이 제안 되었다.


HTTP/0.9

HTTP 초기 버전에는 버전 번호가 없었고 이 후 버전과 구별하기 위해서 0.9라고 불리게 되었다.

초기 HTTP는 요청은 단일 라인으로만 구성되었고 가능한 메서는 GET이 유일했다.
이때문에 원-라인 프로토콜이라고도 불린다.

위와 같이 오로지 파일 내용 자체로만 구성된다.
이 후 버전들과는 다르게 HTTP header가 없이 HTML파일만 전송 될 수 있으며 다른 유형의 문서는 전송 될 수 없고 상태코드나 오류 코드 또한 없다.
그리고 커넥션 하나당 1요청, 1응답만 가능하여 매번 새로운 연결로 성능이 저하되고, 서버 부하 비용이 올라갔다.


HTTP/1.0

이전 버전인 0.9가 매우 제한적이었던과 달리 브라우저와 서버가 모두 융통성을 가지도록 확장 되었다.

HTTP의 버전 정보나 상태 코드들을 전송 할 수 있게 되었고 HTTP header개념의 도입되어서 HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가 되었다.(Content-Type 덕분에)


HTTP/1.1

HTTP/1.1은 이전 버전의 모호함을 명확하게 하고 개선하였다.

이전 버전에서는 동일한 컴퓨터 사이에서 여러 개의 요청을 해도 매 번 새 연결을 했어야한다.
특히 한번 연결할 때마다 TCP에서는 3-way handshaking가 일어나기 때문에 통신 속도가 느려지게 된다.

그래서 persist connection를 도입하여 한번 TCP연결을 맺으면 끊어지지 않고 계속 유지 할 수 있게 했다.(지정된 시간동안 커넥션을 닫지 않아서 그 시간동안은 계속 그 커넥션을 사용할 수 있음)

그리고 pipelining를 도입해서 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄인다.

하지만 이때는 처음 요청이 오래 걸리면 그 뒤에 오는 요청이 이전 요청을 기다리는 Head Of Line Blocking이라는 문제가 있었고 연속된 요청의 경우 Header구조가 중복 될 수 있는 문제가 있다.

HTTP/2.0

HTTP/2.0은 2015년도에 발표 되었으며 구글의 SPDY(스피디)라는 네트워크 프로토콜에 기반하여 개발 되었다.

우선 HTTP/2.0에서는 데이터 교환 방식이 바뀌었다.

HTTP용어


바이너리 프레이밍
바이너리 프레이밍

HTTP/2.0에 도입된 새로운 데이터 교환 방식은 바이너리 프레이밍(binary framing) 으로 HTTP 메시지를 더 작은 단위로 쪼개 바이너리 형태인 프레임 단위로 캡슐화하여 파싱, 전송속도를 높이고 오류 발생 가능성을 줄였다.


요청 및 응답 다중화
요청 및 응답 다중화

그리고 이 프레임 단위는 먼저 도착하는 데이터를 전송 받은 측에서 조립을 할 수 있어서 Head Of Line Blocking을 어느정도 해결 할 수 있게 되었다.


스트림 우선 순위 지정
스트림 우선 순위 지정

Stream Prioritization으로 리소스간에 우선 순위를 설정 할 수 있어서 먼저 전송 하고자 하는 데이터를 먼저 보낼 수 있다.


각 스트림에 1~256사이의 정수 가중치를 할당하고 각 스트림에는 다른 스트림에 대한 명시적 종속성을 부여 할 수 있다. 스트림의 종속성 및 가중치 조합을 이용하여 '우선순위 지정 트리'를 구성하여 우선순위가 높은 응답이 클라이언트에 최적으로 전달되도록 대역폭을 할당한다.


스트림 우선 순위 지정
스트림 우선 순위 지정

그리고 서버가 단일 클라이언트 요청에 대해 여러 응답을 보낼 수 있는 ServerPush가 도입되었다.

ServerPush로 서버는 클라이언트가 요청하지 않아도 추가적인 리소스를 클라이언트에 전송 할 수 있다.

만약 html파일에 참조된 css,js파일들을 html파일과 같이 클라이언트에 먼저 전송을 하게 되어 클라이언트가 html읽고 난뒤 요청학 전에 미리 전송을 할 수 있다.


헤더 압축
헤더 압축

이전 버전에서는 header값이 중복되더라도 모든 header값을 보냈지만 Header Compression을 통해서 중복된 부분을 줄여서 header자체의 크기를 줄여서 페이지 로드 시간을 감소 시켰다.


HTTP/3.0

HTTP/3.0은 구글에서 2013년도에 발표한 QUIC(Quick UDP Internet Connections) 을 사용한다. (2018년에 QUIC 경우 HTTP를 HTTP/3.0로 호칭하기로 했다.)
QUIC는 현재 구글에서는 대부분 서비스에 도입하고 있다.

QUIC은 TCP가 아닌 UDP를 기반으로 사용한다.
http는 신뢰성 있는 연결을 할 수 있으면 TCP방식이든 UDP 방식이든 상관이 없다.

TCP
TCP

UDP
UDP

출처 : wikipedia

UDP방식을 도입한 이유는 TCP는 신뢰성을 확보하기위해 구조가 커서 지연을 줄이기 힘들었기 때문에 UDP를 바탕으로 QUIC을 만들었다.

UDP는 데이터 전송에 집중이 되있는 설계로 별도의 기능이 없고 원하는 기능을 개발자가 구현 할 수 있어서 TCP의 지연을 줄이면서 TCP만큼의 신뢰성을 확보 하였다.


QUIC는 첫 연결 설정에서 필요한 정보와 함꼐 데이터를 전송하여 연결 성공 시 설정을 캐싱하여 다음 연결때 바로 성립이 가능하다.

Connection UUID라는 고유한 식별자로 서버와 연결하여 클라이언트가 이 식별자를 가지고 있으면 커넥션을 재수립 하지 않아도 된다.

IP가 변경되거나 wifi에서 LTE로 변경되어도 기존의 커넥션을 유지 시킬 수 있다.


HTTP/2.0에서도 멀티 플렉싱이 가능은 했었는데 스트림이 병렬로 처리 될때 데이터 자체가 손실이 되게 되면 Head Of Line Blocking 이슈가 다시 생기게 된다.

하지만 QUIC은 독립 스트림을 사용하여 향상된 멀틱 플렉싱이 가능하다.

또한 QUIC 프로토콜에는 일반 텍스트 버전이 없고 항상 TLS를 사용해서 암호화 및 보안을 수행하여야 하기 때문에 보안 면에서도 뛰어나다.


W3techs에 따르면 2022년 1월 기준 HTTP/3.0은 전체 웹사이트의 24.6%에 사용되고 있다.