HTTP3 란 무엇일까
HTTP/3는 HTTP 프로토콜의 3번째 메이저 업데이트 버전이다.
HTTP/2 버전이 배포된지도 약 4년 밖에 안지났는데 벌써 3버전이 배포된 것은, HTTP 프로토콜이 모든 웹 통신의 근간이 되는 프로토콜인 점, 1.1버전 이후 2버전이 발표되기 까지 걸린 시간이 18년이라는 점, 결정적으로 3버전에서는 그동안 변하지 않고 TCP를 기반으로 설계되어 왔던 토대를 모두 버리고, UDP에 근간을 두는 선택을 보면, 이번 메이저 발표는 매우 충격적이면서 이례이라고 볼 수 있다.
당장 HTTP 2버전에 대해서도 제대로 알지 못하고 있었던 나 자신에 대해서 반성하며, 지금까지의 HTTP와 함께, 완전히 새롭게 태어난 HTTP 프로토콜에 대해서 알아보는 시간을 가져보려고 한다.
지금까지의 HTTP
HTTP/0.9
버전번호가 따로 없는 상태로 발표되었던 초기 HTTP는 요청이 단일 라인으로 구성되며 가능한 메서드는 get이 유일했다.
GET /mypage.htmlHeader 따위는 없었고, 그 때문에 오직 HTML 파일만 전송이 가능했으며, 상태 확인을 위한 코드도 존재하지 않았다.
<HTML>
A very simple HTML page
</HTML>HTTP/1.0
매우 기능이 제한적인 기존의 것을 개선하여 나온 HTTP는 1.0이라는 버전번호를 달고 나오게 되었고, 자연스럽게 그 이전의 저번은 0.9 버전으로 기억하게 되었다. 새로운 버전에서는 다음과 같은 기능이 추가 되었다.
- 요청에 버전 정보가 붙어서 붙어서 전송되기 시작
- 응답 시작 부분에 상태 코드가 추가됨
- 모든 요청과 응답에 헤더 개념이 추가됨(확장성 up, 다른 타입의 문서도 전달 가능해짐, 기타 기능 강화 업)
GET /img_sample.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
---
200 OK
Date: Thr, 06 Dec 1996 01:12:30 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
.............img..........stream.............HTTP/1.1
1.0이 발표될 당시에 다양한 표준화가 진행되고 있었고, 1.0 발표가 된지 몇달 지나지 않아 HTTP의 첫번째 표준버전인 1.1이 발표되었다. HTTP/1.1 버전은 많은 개선사항을 도입하였다.
- 커넥션의 재사용 가능(기존 연결에 대해서 handshake 생략가능)
- 파이프라이닝 추가, 이전 요청에 대한 응답이 완전히 전송되기 전에 다음 전송을 가능헤 하여, 커뮤니케이션 레이턴시를 낮춤
- 청크된 응답 지원(응답 조각)
- 캐시 제어 메커니즘
- 언어, 인코딩 타입등을 포함한 컨텐츠 전송
- 동일 IP 주소에 다른 도메인을 호스트하는 기능 가능 (HOST header)
발표 이후에도 1.1은 계속 발전하여 오랫동안 사랑받고 있다.
GET /q=a=1 HTTP/1.1
Host: 127.0.0.1
GET /flag HTTP/1.1
Host: www.modusecurity.xyz
User-Agent: curl/7.66.0
Accept: */* HTTP/1.1
Host: www.modusecurity.xyz
User-Agent: curl/7.66.0
Accept: */*HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 7872
ETag: W/"1ec0-0RmELqv7Q+F1+foGfUNa4OeTH1k"
* Added cookie connect.sid="s%3AAy0PPE659bH1rd9NURtAPhi0mTOWdNWa.Z0QvE5cxK1kVcOQuxS4RZ0HrcZVHcEVwfd0aqqQ3SdE" for domain www.modusecurity.xyz, path /, expire 0
Set-Cookie: connect.sid=s%3AAy0PPE659bH1rd9NURtAPhi0mTOWdNWa.Z0QvE5cxK1kVcOQuxS4RZ0HrcZVHcEVwfd0aqqQ3SdE; Path=/; HttpOnly
Date: Fri, 14 Feb 2020 13:40:56 GMT
Connection: keep-alive
<!DOCTYPE html>
<html lang="en">
..... 생략.....HTTP/2
HTTP/1.1을 통해 많은 개선사항이 있었고, 그 중 keep-alive 헤더 등의 역할은 클라이언트와 서버간의 연결 비용을 줄이는데 큰 역할을 하였다. 하지만, 웹이 발전함에 따라 브라우저가 웹페이지를 가져오고 렌더링 할 때 필요한 리소스의 가짓수(CSS, JavaScript, 이미지, html )등이 크게 증가함에 따라 점점 더 많은 동시성을 요구하게 되었고, 그 결과 단일 컨텐츠 조회에 대해서 여러개의 TCP 연결을 병렬 수행하는 것이 필요하게 되었고, 결국 이러한 각각의 TCP 스트림들은 다시 연결비용의 증가를 초래하게 되었다.
HTTP/2의 등장은 이를 해결할 해결책으로 "streams"라는 개념을 도입하였다. 이것은 서로 다른 HTTP 연결들을 하나의 TCP 스트림으로 다중화하여 추상화 할 수 있는 개념으로, 브라우저에서 보다 효율적으로 TCP연결을 재사용 할 수 있도록 지원하는 개념이다.
하지만 이러한 노력에도 피해갈 수 없는 문제인 HOLB라는 걸림돌이 있었다. HOLB(Head of line Blocking)은 TCP 패킷이 네트워크 경로에서 손실되면 스트림에 공백이 생겨, 손실 된 바이트 다음에 오는 올바른 바이트들도 재전송으로 인해 전달이 되지 않아 발생하는 불필요한 지연을 말한다. 프로토콜이 TCP를 사용한는 한 피해갈 수 없는 문제인 것이다.
특히, HTTP/2의 경우에는 여러개의 HTTP 스트림을 하나의 TCP 커넥션으로 처리하기 때문에 더 크게 영향을 받게 된다.
HTTP + TCP + TLS
대망의 HTTP/3의 소개로들어가기 전에, 기존의 HTTP 프로토콜에 SSL을 적용할 경우 발생하는 오버해드를 소개한다. 더 자세한 설명은 HTTP/3의 장점을 설명하면서 같이 설명하겠다.
HTTP/3
HTTP/3는 매우매우매우 이례적으로 기반 프로토콜을 UDP를 사용한다. 정확하게는 UDP를 기반으로 하는 QUIC를 사용한다. UDP를 사용하지만 그렇다고 기존의 신뢰성 있는 통신이라는 타이틀을 포기한 것은 아니다.
QUIC
HTTP/3의 장점을 설명하기 위해서는 기존의 TCP를 포기하고 QUIC를 채택하면서 얻게 된 장점을 설명해야한다.
- 암호화가 프로토콜의 일부기능으로 포함되어 있다
- 스트림 연결과 암호화 스펙등을 포함한 모든 핸드쉐이크가 단일 요청/응답으로 끝난다
- 패킷이 개별적으로 암호화 되며, 다른 데이터 부분의 패킷을 기다릴 필요가 없다
- 통신이 멀티플렉싱 되며 이를 통해 HOLB를 극복할 수 있다
- QUIC는 운영체제 커널과 독립적으로 응용 프로그램 공간내에서 구현할 수 있으며, 덕분에 데이터의 이동에 따른 컨텍스트 전환에 의한 오버헤드가 없어진다
- Source Address와 무관하게 서버에 대한 연결을 고유하게 식별하는 연결 식별자가 포함되어 있어, IP주소가 변경되더라도 커넥션을 유지할 수 있다
(설명하고 싶은 내용과 가장 가까운 그림이라 사용하긴 했지만, QUIC도 3WAY 핸드셔이크는 하는것으로 아는데..?)
HTTP/3
이러한 QUIC를 이용하는 HTTP/3는 새로운 연결에 대해서 핸드세이크로 인한 지연, 패킷 손실이 다른 스트림에 미치는 영향, 패킷 손실로 인한 지연으로부터 자유로울 수 있다.
그런데, 결국 QUIC가 다한거면 QUIC위에 단순히 기존의 HTTP/2를 올리기만 해서 사용하면 되는게 아닌가? HTTP/2도 스트림 멀티플렉싱을 지원한다면서? 다른 수정이 필요해?
결론적으로보면 니 생각보다 복잡하다이다. HTTP/2의 일부 기능들은 QUIC 위에서도 별도의 변환 없이 그대로 적용할 수 있지만, 몇몇 기능들은 그렇지 않다. 대표적으로 예를 들자면, HPACK 이라는 HTTP/2에서 사용하던 헤더 압축 체계는 응답의 전달순서에 따라 크게 좌우되는데, QUIC는 스트림간의 순서를 보장하지 않기 때문에 사용할 수 없다.(이러한 경우 QPACK이라는 새로운 HTTP 헤더 압축체계를 작성했다고 한다.)
지금 사용중인가?
빠른 콘텐츠 전달이 생명인 CDN들은앞 다투어 서비스들을 적용하고 있고, 당연히 해당 CDN을 이용하는 서비스 제공자들은 HTTP/3를 지원한다.
구글에서 제공하는 상당수의 컨텐츠들(유튜브 포함), 페이스북 등이 지원하도록 구성되었고, 클라이언트는 크롬, 엣지 브라우저, curl 등이 이미 지원하고 있다.
Chrome
https://www.youtube.com/
http/2+quic/46이라고 표기된 프로토콜이 HTTP/3이다.