풀스택 서비스 네트워킹(10), QUIC & HTTP/3

풀스택 서비스 네트워킹(10), QUIC & HTTP/3

2022. 12. 12. 19:47ㆍ강의 내용 정리/풀스택서비스네트워킹

728x90

QUIC & HTTP/3

게임 서버의 경우에는 실시간으로 인터렉티브하게 계산해서 처리하는 게 많기 때문에 지연시간이 짧은 것도 중요하고, 틱을 일정하게 처리하는 것(지터)도 중요하다. 메타버스 컨텐츠에서 그래픽의 퀄리티를 줄이는 것은 딜레이가 발생하면 멀미를 하게 된다. 이에 따라 네트워크가 중요하게 된다. 현재 논문에서 보면 게임은 네트워크에 대한 지연시간보단 정보가 일정한 시간동안 전달되는 것이 더 중요하다는 내용이 있다. 이러한 맥락에서는 게임을 하기엔 HTTP 1와 HTTP 2보단 HTTP 3를 사용하는 것이 더욱 지연시간을 줄일 수 있게 된다.

QUIC의 특징

지연을 줄이고자 한다.

HTTP 2가 찢어져서 윗부분과 아랫부분이 나눠진다. TCP가 아닌 UDP를 사용한다.

구글의 크롤링 작업은 HTTP1.1을 사용한다.

- 모든 서버가 HTTP 2를 사용하는 것은 아니기 때문

- 안정성을 위해서

따라서 필요한 곳에 필요한 프로토콜을 사용하는 것이 중요하다. 즉, 문제 상황이 발생했을 때 적용과 검증을 계속 하는 것이 중요하다.

최근에는 오픈 소스 중에 표준이 나오는 것이 많다. 즉, 새로운 것을 알기 위해서는 오픈 소스를 아는 것, 커뮤니티 컨퍼런스 등에 가서 경험하는 것이 중요하다.

1. 들어가는 글

1) 커널에서 벗어난다.

어플리케이션단으로 넘어가고 있고, 유연성을 강조한다.

2) 오픈 소스로 기준이 옮겨간다.

3) TCP를 벗어난다.

UDP 위에서 짜는 경우가 많아진다. UDP는 표준화되었고, 검증이 되었기에 이를 사용하는 것으로 간다. 하지만 이는 현재 진행형이다. TCP는 지속적으로 발전해왔기때문에 성능 개선이 이뤄졌지만 UDP는 그렇지 않기 때문에 속도가 더 빠를 것으로 예상했지만 이를 반영하지는 못했다.

2. QUIC 소개

TCP를 대체하기 위해 범용 목적의 전송 계층의 통신 프로토콜이다.

초기에는 UDP 베이스로 신뢰성을 확보하는 것에 자신이 없었다. 이에 따라 네트워크망이 좋은 상황에서 통신을 진행했을 때 괜찮다고 했다. 즉, 바로 옆에 있는 컴퓨터간에 통신을 하는 경우에는 그냥 UDP를 사용하자고 얘기를 했었다.

퀵은 스트림, 멀티플렉싱 등의 HTTP2에 있던 기능을 그대로 가져온다. 퀵은 구글이 만들었을 때에는 UDP 베이스로 한다고 이름을 명확히 했다. 하지만 IETF가 이 이름을 거절했고, QUIC이라고 이름을 정했다.

퀵에서의 속도가 빠른 이유

- UDP를 사용하기에 속도가 빠르다.(추측)

- 인터넷을 통한 커넥션이 빠르다. 즉, 최초 연결 설정이 빠르다.

퀵에서는 표준화 단체의 메인 사이트에 기존에 표준화 단체 메인 사이트에 있던 내용과 더불어 오픈 소스도 들어간다. 즉, QUIC의 구현과 관련된 내용이 나온다.

1) QUIC 관련 표준

HTTP 2의 가장 큰 장점은 멀티플렉싱이다. 1 2 3으로 왔더라도 이대로 처리하지 않아도 된다. 두번째로는 보안이 있다. 대부분의 서버들이 보안을 유지한다. 이 장점들을 HTTP 2에서 떼어낸 뒤, 사용한다. TLS를 QUIC에 붙이기도 한다.

QUIC의 성능이 처음에 잘 안나온 이유는 UDP가 많이 쓰이지 않아서 이 쪽으로 개발을 많이 하지 않았다. 이에 따라 최적화가 되지 않았었다. 또한 TCP는 하드웨어를 동원해서 보안을 처리하기에 조금 빠르기도 하다. 하지만 UDP는 TLS를 처음 올렸기에 느리다.

2) QUIC 관련 라이브러리 개발 현황

아직 표준 라이브러리로 나오기에는 완료되지 않았다.

3. QUIC & HTTP/3 출현 배경

실제 HTTP/2와 유사하다. 하지만 TCP의 문제점이 눈에 띄기 시작했다. 또한 HTTP/2의 장점을 더욱 강조하고자 한다. 암호화를 감싼다.

1) 화석화(Ossification) 탈피

암호화를 하는 이유에 대해 강조한다. 하지만 실질적으로는 이것보단 TCP연결의 문제점, HTTP/2에서보다 개량된 기술이 QUIC과 HTTP/3의 출현 배경으로 해석하는 것이 더 적절할 수 있다.

2) TCP 측면

시작할 때 매우 느리고, 에러가 발생하면 한번에 주저 앉는다. 네트워크가 빨라지니 문제가 보인다.

TCP의 줄이 하나로 연결되어있을 때 에러가 발생하면 모든 서비스가 막히게 된다. HoL 문제가 발생한다.

4. QUIC의 특장점

1) UDP based NEW Transport Protocol

QUIC은 TCP와 유사하게 에러 검출 및 복구도 하고, 혼잡도 제어도 한다. 또한 TLS를 필수로 한다. 모든 HTTP/3는 암호화한다. 따라서 결국 TCP 대신 QUIC을 사용했고, 이 위에서 HTTP/3 통신을 하게 된다.(이는 HTTP/2와 실질적으로 큰 차이가 없다.)

QUIC은 transport protocol로 이해해야한다. 즉, 엔드 투 엔드에서 에러 검출 및 복구, 혼잡 제어를 한다. 특히 속도/우선순위 제어 등등을 할 수 있다. QUIC과 HTTP/3는 상하관계이다. 따라서 HTTP/3가 QUIC 위에 있는 첫 어플리케이션 계층 프로토콜이 된다.

2) Connection based transport

HTTP/2의 단어와 개념이 유사하다. QUIC도 connection이 있어서 논리적인 연결을 사용한다. 이 안에서 암호화/우선순위 등등 사용한다. 이때 TCP처럼 연결 설정의 과정을 거친다. 단, 지연시간을 줄여준다.

실제 정보를 주고 받을 때 stream이 있어서 하나 이상의 스트림을 전송할 수 있다.

Connection마다 ID를 줄 수 있다. IP 어드레스와 Connection ID는 독립적이게 된다. Connection ID는 ip address 정보를 갖지 않는다. 대부분 TCP/UDP는 소켓번호를 가지고 통신을 한다. 이에 따라 IP 주소가 달라지면 연결을 끊었다. 하지만 QUIC은 connection ID가 유지되면 상관없다.

Connection ID는 밑에 있는 것과 연결되어있지 않다. wifi에서 모바일 네트워크 연결을 하더라도 연결이 끊어지지 않는다. 따라서 이동하더라도 서비스가 끊기지 않고 계속 연결된다는 장점이 있다. IP 주소가 바뀌더라도 서비스가 지속된다!

3) Stream based Transport

QUIC 위에 HTTP/3가 돌아간다. 이에 따라 HTTP/3에 대해 얘기하지 않는다. QUIC은 연결이 있고, 스트림을 통해 내용을 주고받는다. HTTP/3는 즉, QUIC의 예제가 된다.

스트림의 ID를 매우 크게 줬다. 에러 검출과 흐름 제어를 한다. 이는 연결 단계에서나 스트림 모두에서 할 수 있다. 우선순위 작업과 같은 것은 전송과 관련된 것은 QUIC에서, HTTP와 관련된 것은 HTTP/3에서 진행한다.

4) Independent Streams avoid HOL blocking

UDP 베이스이기에 나갔던 것이 막혔다고 해서 뒤에있는 것이 도착하지 않지 않는다. 스트림을 동시다발적으로 주고받을 수 있다.

5) Secure Communication

보안을 위해서 TLS를 사용한다. 보안적인 측면에서 QUIC이 자체적으로 하는 것은 연결설정 및 과정을 TLS와 밀결합되어서 동작하는 것밖에 없다.

6) Reduced {Signaling} Latency

1-RTT는 보내고 다시 받는 데 걸리는 시간을 의미한다. 즉, 메세지를 주고받는 개수가 줄어들고, 이에 따라 데이터가 나갈 때까지의 시간이 단축된다. 추가적으로 연결설정을 하면서 데이터를 보내는 early data를 지원한다.

cf) RTT(Round Trip Time)

왼쪽은 TCP/TLS를 하는 것을 보여준다. 이는 TCP 연결설정 이후 TLS를 하는 것을 보여준다. 하지만 QUIC은 연결설정 및 해제 과정 안에 TLS와 밀결합되어있다. 이에 따라 대기시간이 확 짧아지게 된다. 따라서 QUIC의 연결설정 시간이 짧아진다.

연결설정을 한 뒤 QUIC은 상대방에 대한 보안관 정보를 가지고 있다. 이에 따라 재연결을 할 때에는 주고받는 과정에서 바뀐 정보가 없다면 데이터를 바로 보낸다. 즉, 재연결을 할 때에는 캐시를 사용하기에 연결설정을 하면서 데이터를 같이 전송한다. 이에 따라 0-RTT가 나온다.

첫 연결과, 재연결 시에 시간이 모두 줄어드는 것을 볼 수 있다.

5. HTTP/3 개요

1) HTTP/3 over QUIC

cf) QUIC에서 HTTP/3를 언급하지 않는 이유: QUIC은 TCP에 상응하는 프로토콜이기 때문에 HTTP를 언급하지 않는다. 실질적으로 QUIC 위에 HTTP/3가 돌아가는 별도의 프로그램이다. HTTP/3는 QUIC 위에서 돌아가도록 만든 새로운 프로토콜이다.

2) URL

HTTP/3의 URL은 그대로 유지하고 있다. 다만 클라이언트가 서버에 연결을 할 때에는 어떤 것을 연결할지 고민한다. 하지만 HTTP/3는 UDP 기반이기에 TCP 연결을 받지 않는다. 서버는 HTTP/3를 지원하는 입장에서 이를 어떻게 처리하는지가 주요하다. 아마도 클라이언트와 서버는 가장 많이 사용하는 HTTP/2로 연결설정을 사용하지만 HTTP/3도 사용한다는 점을 서버가 알려준다.

3) Alt-svc

즉, HTTP/2나 HTTP/1으로 초기 연결이 진행되지만 서버가 HTTP/3을 사용할 수 있을지 묻는 식으로 진행된다. 이는 Alt-Svc를 전달해서 사용한다. 이는 과도기적으로 지금 사용적인 것이다. 따라서 크롬브라우저에서 HTTP/1,2,3를 모두 지원할 때에 이야기하고 있다.

4) HTTP/3 Frame

request의 헤더와 데이터를 나눈다. HPACK에서 QPACK으로 압축 방법이 바뀌었다. 또한 GOAWAY를 통해 연결을 종료하는 방식을 추가했다.

request의 헤더와 데이터를 나눠서 보내고, 데이터가 여러개면 이를 여러개로 나눠진다.

이 또한 마찬가지이다.

5) 우선순위 제어

종속관계면 상위에 있는 것부터 먼저 처리하고, 동일하다면 가중치에 따라 처리한다. 세부적으로 실행하는 방법만 차이가 있지만 이는 http/2와 유사하다.

6) 서버 푸시

http/2의 서버 푸시와 유사하다.

PUSH_PROMISE도 계속 지원되지만 클라이언트가 푸시에 대해 개별 스트림을 취소할 수 있는 것들이 추가되었다.

7) HTTP/2와 HTTP3의 유사정

전체적인 입장에서는 매우 유사하다. 세부적인 입장에서는 살짝 다를 수 있지만 대부분 유사하다.

8) HTTP/2와 HTTP3의 차이점

가장 큰 차이점이자 장점은 빠르다는 점이다. 0-RTT 핸드쉐이크 덕분에 매우 빠르다. TCP + TLS가 아닌 QUIC 내부에 있는 QUIC 덕분에 빠른 것으로 보인다.

HTTP/2에서 암호화는 선택사항이다. 하지만 HTTP/3에서 암호화는 필수이다.

ALPN은 여러 서비스가 있을 때 그 서비스의 특징을 협의하는 건데 이때 주고받는 메세지가 많다. 이에 따라 복잡하게 동작하는데, HTTP/3를 사용하면 어떤 버전을 선택할 지에 대해서 간단하게 처리가 가능하다.

6. HTTP 기술 변화 정리

1) HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1은 사람이 읽을 수 있다. 2에서부터는 이를 바이너리로 처리한다. 또한 이를 다중화를 했다. 3에서는 TCP가 아닌 UDP 베이스로 했고, UDP 위에 쌓은 프로토콜도 바이너리로 했다. 또한 다중화로 처리를 했고 QUIC을 사용했고, 그 위에 HTTP/3에서 사용한다.

2) HTTP/1,1

TCP/TLS를 사용했다. 많이 하기 위해 TCP 연결을 여러개로 만들어서 가속화를 했다. 이를 어플리케이션 레벨에서 했다.

3) HTTP/2

TCP 연결은 하나이지만 다중화를 처리했고, 압축했다.

4) HTTP/3

UDP로 이를 처리했고, 위의 특징들이 모두 반영되었다.

7. QUIC 이슈 및 발전 방향

1) Non Socket API

퀵은 운영체제가 제공하는 커널 안에 있지 않고, 그 위에 존재한다. 따라서 표준 API가 없기에 누가 이를 구현했는지에 따라 어떤 API를 제공하는 지가 달라질 수 있다. 즉, 그 라이브러리가 제공하는 API를 제공했기에 다른 것으로 돌리기 어렵다. 유지보수 측면에서 어려울 수 있다.

2) Kernel & Code Optimization

커널 내부에 있는 소프트웨어와 커널 바깥의 소프트웨어는 차이가 있다. TCP 대비 UDP는 혼잡제어가 없고, 연결 설정이 없기에 더 빠르다고 생각할 수 있지만 최적화가 되어있지 않기에 더 느리다. 이는 실질적으로 더 큰 문제가 된다. TCP는 많은 사람들이 관심을 가져서 코드 최적화가 더 잘 되어있다.

3) QUIC & HTTP/3 현황

(1) site

여러 사이트에서 h3를 사용하고 있다.

(2) 서버

설치해서 사용하는 웹서버의 경우에는 http/3를 제공하고 있다. Nginx, LiteSpeed, Caddy 등이나 Cloudflare 등도 지원하고 있다, Apache는 아직 지원하지 않고, 지원 계획도 없다.

(3) Browser

사파리를 제외하곤 대부분 지원한다.

(4) Programming library

클라이언트를 구현하면 h3를 지원하는 서버에 붙어서 이를 확인할 수 있다. curl을 사용해 클라이언트를 대신할 수도 있다.