HTTP/1.1, HTTP/2, QUIC

---

1. HTTP 1.1

  HTTP는 인터넷에서 문서를 교환하기 위하여 사용되는 통신규약(Protocol)으로, tcp를 사용한다. 

  과거 HTTP 0.9에서는 GET요청뿐이었으며, HTML 문서만 주고 받았다. HTTP 1.0에서는 헤더와 응답코드가 생겼으며, POST, HEAD 메소드가 생겼다. 헤더 'Content-Type'로 HTML 파일 이외의 다른 문서들도 전송이 가능해지고, 응답코드로  성공과 실패를 바로 확인할 수 있게 된 것이다. 그러나 같은 요청을 여러 번 하더라도 매번 새로운 연결을 하므로 성능이 저하되고, 헤더가 중복되므로 서버 부하 비용이 크다는 문제가 있었다. 

 

  HTTP 1.1은 OPTIONS, PUT, DELETE, TRACE 메소드가 추가되었으며, Accept(클라이언트의 사용가능 미디어타입), Via(중계서버 정보)와 같은 헤더가 추가되었다. 그 외에도 기능향상을 위한 기능들이 추가되었다. 그 중 하나는 Persistent Connection이다. 매 요청마다 연결을하는 것이 아니라 하나의 TCP 연결을 사용하여 Timeout 까지 연결을 닫지 않으므로 복수의 HTTP요청/응답을 주고받을 수 있는 개념이다. Pipelining 또한 추가되었다. 파이프라이닝은 첫번째 요청에 대한 응답을 받기 전에 두번째 요청 전송을 가능하게 하는 방법이다. 즉, 하나의 연결에서 응답을 기다리지 않고 순차적으로 여러 요청을 연속적으로 보내며, 응답은 요청 순서대로 받는 방식이다. 

 

2. HTTP 2.0

  HTTP/2.0은 기존 HTTP/1.X 버전의 성능을 향상시킨 프로토콜이다. HTTP/2.0의 가장 큰 차이는 Binary Framing 계층이 생긴 것이다. 이전에는 일반 텍스트를 보냈다면 HTTP/2.0은 바이너리로 인코딩해서 데이터를 전송되며, 데이터는 프레임이란 단위로 나누어진다. 즉, 헤더와 메시지 페이로드가 각각 따로 프레임화 되어 보내지며, 메시지 페이로드도 여러 개의 프레임으로 분리될 수 있는 것이다. 프레임들은 프레임의 헤더에 삽입된 스트림 식별자를 통해 이 프레임을 재조립할 수 있다. Binary Framing으로 데이터가 바이너리화 되어 주고받기 때문에 파싱, 전송속도가 높고 오류발생 가능성이 줄어든다.(바이너리프로토콜장점) 또한 다음 문단 내용인 Request and response multiplexing 내용이 사실 프레임단위로 쪼개졌기 때문에 가능해진 성능향상이다.

 

  HTTP/2.0은 프레임 단위로 데이터를 주고 받기 때문에 요청과 응답의 순서에 의미가 없어진다. 프레임들은 프레임의 헤더에 삽입된 스트림 식별자를 통해 프레임이 재조립되므로 프레임이 순서대로 가지 않더라도 상관이 없으며, 여러 요청과 응답을 섞어서 보내도 상관이 없다. 

 

  HTTP/2.0에서 헤더의 크기를 크게 압축되었다. 같은 서버로 요청을 여러번 하게 되면 헤더의 내용이 겹치는 경우가 많다. HTTP/2.0에서 서버와 클라이언트는 요청에 대해 헤더 값과 인덱스를 기억하고 있다. 이 후 새로운 요청을 할 때 값이 겹치는 부분은 인덱스만 보내고, 값이 겹치지 않는 부분만 값과 함께 새롭게 보내는 것이다. 또한 Huffman 코드로 인코딩하여 값 자체도 압축시켰다.

 

  Server Push라는 기능이 새롭게 추가되었다. 서버에서 클라이언트가 요청하지 않은 데이터를 미리 보내주는 것이다. 예를 들어 page.html에 대한 요청이 들어왔을 때 이와 관련있는 script.js, style.css에 대한 요청이 들어오지 않았어도 함께 보내준다.

 

  Stream Prioritization. 즉, 리소스간 우선순위를 정해 어떤 데이터를 우선적으로 통신할 것인지에 영향을 줄 수 있다. 이 떄 영향을 줄 수 있는 것. CPU, 메모리 및 기타 리소스의 할당을 제어하는 것일 뿐으로 가중치라는 의미가 강하고, 특정 순서로 처리되도록 강제할 수 는 없다.

 

3. QUIC

  2013년 구글에서 UDP 기반으로 통신을 하기 위한 프로토콜을 새롭게 발표하였다. QUIC는 현재 구글 관련 서비스에 거의 적용되어있다. TCP는 데이터의 안정성을 위한 많은 구조가 이미 포함되어있기 때문에 속도를 빠르게 하는 것에 한계가 존재한다. 그러나 UDP는 데이터 전송에만 집중된 설계로 별도의 기능이 없어 개발자가 원하는 기능을 넣기 쉽다. 따라서 빠른 UDP에 TCP 만큼의 신뢰성을 확보하기 위한 요소들을 추가한 것이 QUIC이다.

 

  QUIC는 연결 자체에 Connection UUID라는 고유한 식별자를 갖게한다. 따라서 연결 재수립이 필요없는 것이다. 예를 들어 와이파이였다가 LTE로 연결을 변경하더라도 클라이언트-서버간의 기존 연결은 유지되는 것이다. 또한 QUIC는 기본적으로 TLS가 기본적으로 적용되어있으며, IP Spooifing/Replay Attack을 막기위한 대비가 되어있다. 그리고 2개의 종단점간(서버-클라이언트) 다중화된 연결을 제공한다. 따라서 여러 데이터 스트림들이 개별적으로 모든 종단점에 도달할 수있고, 여러 요청이 있다면 요청1에서의 패킷손실이 요청2에 영향을 주지 않는다.

 

  QUIC를 기반으로 HTTP/3.0이 발표되었으며, 현재 W3Techs에 따르면 10,000,000개 웹사이트 중 8%가 HTTP/3.0를 지원하고 있다. 아직  파이어폭스와 크롬 안정판은 현재 HTTP/3을 지원하지만 기본적으로 비활성화되어있다. HTTP/2.0이 아직 점유율이 40%인 상황에서 QUIC를 기반으로한 HTTP/3.0는 어떻게 될지는 지켜봐야할 것이다.

---

MDN: https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP

http 버전별 차이: https://falsy.me/http%EC%9D%98-%EB%B2%84%EC%A0%84-%EB%B3%84-%EC%B0%A8%EC%9D%B4%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B3%A0-ubuntu-nginx%EC%97%90-http-2%EB%A5%BC-%EC%A0%81%EC%9A%A9%ED%95%B4/

구글 Developer HTTP 2.0: https://developers.google.com/web/fundamentals/performance/http2#%EB%B0%94%EC%9D%B4%EB%84%88%EB%A6%AC_%ED%94%84%EB%A0%88%EC%9D%B4%EB%B0%8D_%EA%B3%84%EC%B8%B5https://developers.google.com/web/fundamentals/performance/http2#%EB%B0%94%EC%9D%B4%EB%84%88%EB%A6%AC_%ED%94%84%EB%A0%88%EC%9D%B4%EB%B0%8D_%EA%B3%84%EC%B8%B5

HTTP 2.0: https://www.oreilly.com/library/view/high-performance-browser/9781449344757/ch12.html

HTTP 2.0의 탄생: https://americanopeople.tistory.com/115