HTTP3

HTTP3란?

HTTP/3은 HTTP/2 이후 새롭게 나온 개발 표준으로, 웹 브라우저와 서버가 통신하는 방식에 영향을 미치며, 성능, 안정성, 보안 등 사용자 경험을 크게 업그레이드했으며, 2022년 6월 6일 IETF(Internet Engineering Task Force) RFC 9114로 표준화되었다.

1991년 최초의 하이퍼텍스트 전송 프로토콜(HTTP)이 출시된 후, 이후 여러 차례 새로운 버전을 내놓으면서 기본 코드를 변경하지 않고도 웹 사이트를 더 빠르게 만들 수 있었다.

HTTP/2와의 차이점

빠른 속도

가장 중요한 차이점은 기존 TCP통신 방식의 HTTP/2와는 달리 UDP 기반의 QUIC 프로토콜을 사용하여 통신한다는 점이다.

UDP(User Datagram Protocol) 컴퓨터가 다른 컴퓨터와 데이터 통신을 하기 위한 프로토콜의 일종. OSI 모형(국제표준화기구가 개발한 네트워크 프로토콜 디자인 및 통신 계층)에서 전송 계층(Transport Layer)에서 사용하는 프로토콜이다.

QUIC 프로토콜은 구글이 만든 프로토콜로, 닉값하듯이 빠른 속도를 자랑한다. 훨씬 빠른 데이터 전송 속도를 자랑하며 더 많은 리소스를 병렬로 전송할 수 있다.

이 차이를 이해하기 위해서는 먼저 TCP의 Handshake에 대해 이해할 필요가 있다.

TCP의 3-Way Handshake

TCP 통신을 이용하여 데이터를 전송하기 위해 네트워크 연결을 설정하는 과정이다. 논리적인 접속을 성립시키기 위해 3-way handshake를 사용한다.

메커니즘

TCP는 PAR(Positive Acknowledgement with Re-transmission) 이라는 기능을 통해 안정적인 통신을 제공한다.

전송 계층의  PDU(Protocol Data Unit)를 세그먼트라고 하는데, PAR을 사용하는 장치는 승인을 받을 때까지 세그먼트를 다시 보낸다. 수신측에서 수신한 데이터 단위가 손상된 경우, 해당 세그먼트를 폐기하고 송신자는 다시 세그먼트를 보내야 한다.

여기서 송신자는 클라이언트, 수신자는 서버를 의미한다

이렇게 세그먼트를 보내는 과정에서 세 개의 세그먼트가 교환된다.

SYN(Synchronize sequence numbers) 연결을 요청할 때 SYN bit를 1로 설정, 나머지 경우에는 SYN bit를 0으로 설정한다.

ACK: Acknowlegment 패킷을 받았다는 응답을 할 때 사용한다. Acknowlegment Number가 유효한지 나타낸다.

• 1단계(SYN) : 클라이언트는 서버와 연결을 설정하기 위해 SYN이 포함된 세그먼트를 보낸다. 이 세그먼트에는 클라이언트가 통신을 시작할 것이라고 알리는 역할을 한다.
  • SYN bit를 1로 설정하면서 통신을 시작할 것임을 알린다
  • SYN 세그먼트를 전송 후 SYNSENT 상태로 서버의 ACK 세그먼트를 기다린다.
• 2단계(SYN + ACK) : 서버는 클라이언트의 요청인 SYN 세그먼트에 대한 ACK 세그먼트를 전송함과 동시에 서버가 클라이언트에 연결을 요청하는 SYN Segment를 전송한다.
  • 클라이언트는 SYN + ACK 세그먼트를 전송하고 SYN RCVD 상태로 클라이언트의 ACK를 기다린다.
  • 클라이언트는 ACK 세그먼트를 받고 연결이 완료된 ESTAB 상태가 된다.
• 3단계(ACK): 클라이언트는 서버의 SYN 세그먼트에 대한 ACK 세그먼트를 전송하고, 실질적으로 믿을 수 있는 데이터 교환 연결이 성립된다.
  • 서버는 ACK 세그먼트를 받고 연결이 완료된 ESTAB 상태가 된다.

돌아와서..

암튼 TCP에서는 새 연결을 설정하기 위해서는 Handshake 과정이 필요하다. 하지만 이러한 연결은 네트워크의 왕복이 필요하고, 여기서 지연이 발생할 가능성이 있다. 그래서 QUIC의 경우는 위와 같은 3-way Handshake 대신 1-RTT/0-RTT 세션을 통해 더 빠른 연결을 제공한다.

QUIC 0-RTT

왕복 시간 없는 연결의 재시작을 지원한다. 연결을 시작하면서 동시에 클라이언트가 바로 애플리케이션 데이터를 보낼 수 있다. 3-Way-Handshake처럼 따로 세그먼트의 교환이 필요가 없어 네트워크 왕복이 필요없으며, 이에 따라 지연되는 시간 또한 없다. 빠른 속도로 업데이트가 가능한 만큼, 라이브 트래픽에 주로 사용되며, 화상 회의나 게임 같은 곳에 유용하다.

TLS, TCP 및 QUIC의 Handshake 비교

보안

HTTP/2의 경우는 TLS(Transport Layer Security)를 사용하여 데이터를 암호화하지만, HTTP/3의 경우는 QUIC에 내장된 TLS 암호화를 사용하기 때문에 보안이 기본적으로 내장되어 있다.

또한 별도의 TLS Handshake 없이 보안 연결을 설정할 수 있기 때문에 패킷 헤더와 pyaload에서의 전송 계층 메타데이터도 암호화되기 때문에 여러 이점을 가진다.

• 더 빠른 속도
• 전송 및 암호화 Handshake를 하나로 결합하여 왕복 시간 절약과 함께 보안성 향상
• 완전히 암호화되어 네트워크의 미들박스가 내부 작동을 관찰하고 해석할 수 없다. 따라서 업데이트가 어려운 미들 박스 대신 최종 장치만 업데이트하면 되어 보다 업데이트가 용이하다.

미들박스 서로 통신하는 두 개의 최종 호스트 사이 경로에 있는 네트워크 내 디바이스로, TCP 연결의 경우 전송 중인 패킷 스크림을 모니터링, 필어틸, 변환이 가능하다.

다중화(Multiplexing)

HTTP/1.1에서는 리소스 로딩 프로세스에서 각 파일 자체에 대해 TCP연결이 제공되었고 각각의 연결에 오버헤드가 있었기 때문에 비효율적이었다.

HTTP/2에서는 이를 개선하고자 단일 TCP 연결을 통해 다양한 리소스들을 다운로드하는 바이트 스트림의 Multiplexing을 이용하였다.

이렇게 HTTP/1.1에서는 각 파일마다 TCP 연결 제공되었기 때문에 하나씩 순서대로 다운로드할 수밖에 없었다.

하지만 HTTP/2의 경우 이렇게 각각의 파일에 대해 조금씩 혼합하여 다운로드받기 때문에 HTTP/1.1보다 속도도 조금 낫도 오버헤드가 훨씬 낮다는 장점이 있다.

하지만 여기엔 TCP에 문제가 있는데, 여러 파일을 전송하지만 TCP는 이를 단일 파일 하나를 전송한다고 생각하기 때문에 중간에 데이터 패킷에 손실이 나면 하나만 안 뜨는게 아니라 이후의 파일들도 처리되지 못해 속도가 급격히 느려지는 현상이 나타난다. 이러한 현상을 HOL(Head-Of-Line) Blocking 문제라고 한다.

이러한 문제를 해결하는 것이 QUIC의 과제였는데 QUIC는 스트림 별로 패킷 손실 감지 및 복구 로직을 수행할수 있게 만듦으로써 HOL Blocking 문제를 해결하였다.

이런 식으로 손실된 데이터 패킷만 따로 빼놓고 복구시킴으로써 다른 데이터 패킷들이 다운로드 받을 수 있다.

1인용 에스컬레이터는 한 명이 꿋꿋하게 서 있으면 뒤에 있는 사람들은 걸어서 못 올라간다. 하지만 2인용 에스컬레이터는 한 줄로 서있는 줄과 따로 걸어서 올라가는 줄이 있어 한 줄이 막고 있어도 다른 줄로 걸어올라가면 된다. 이와 같은 차이라고 생각하면 될 것 같다.

연결 마이그레이션(Connection Migration)

QUIC의 연결은 TCP 연결보다 더 오래 지속될 수 있다. 이 이유에 대해 알기 위해서는 패킷이 연결되어 어떻게 목적지까지 전송되는 지에 대해서 알아야 한다.

인터넷에서 IP 주소는 두 개의 고유한 시스템 간에 패킷을 라우팅하는데 사용된다. 하지만 이 두 IP만 있어서는 충분하지 않다. 각 끝에서 동시에 여러 네트워크 프로그램을 실행할 수 있어야 하기 때문이다.

기존 TCP 연결에서 이러한 시스템과 애플리케이션 전반에 걸쳐 고유한 연결을 정의하기 위해서는 클라이언트 IP 주소 + 클라이언트 포트 + 서버 IP주소 + 서버 포트 4가지로 이루어진 4-tuple이 필요하다.

하지만 문제는 이 4-tuple 중 하나만 바뀌어도 연결은 무효화되고 새로 설정되어야 한다는 점이다. 여기서 parking-lot 문제라고 하는게 생긴다.

내가 집에서는 와이파이를 쓰기 때문에 클라이언트 IP 주소가 와이파이 IP 주소로 설정되어 있지만 주차장으로 가면 데이터로 바뀌기 때문에 클라이언트 IP 주소가 바뀌게 된다. 클라이언트 IP 주소가 바뀌게 되면 또 새롭게 연결을 시도해야 하는 것이다.

게다가 TCP 연결 자체가 워낙 오래된 연결이다보니 이러한 새로운 연결이 이루어졌다는 사실 조차 알 수 없으며, 기존의 연결조차 닫는 방법이 없다.

결국 새로운 Handshake를 실행해야 하기 때문에 애플리케이션 수준 프로토콜에 따라 진행중인 작업 또한 다시 시작해야 한다. 파일 다운로드 같은 경우에도 다시 요청해야 하는 경우도 생기는 것이다.

QUIC는 이러한 문제를 해결하기 위해 **연결 식별자(CID, Connection ID)**이라는 개념을 신규 도입한다. 기존의 4-Tuple 위에 다른 번호가 추가적으로 할당된다.

이 CID는 QUIC 자체 전송 계층에서 정의되어 네트워크 간 이동시 변경되지 않는다.

이런 식으로 CID를 통해 네트워크가 달라져도 연결은 변동이 없는 것이다. QUIC 서버와 클라이언트는 CID만 보고 같은 연결인지 확인하기 때문이다. 이러한 기능을 연결 마이그레이션(Connection Migration) 이라고 한다.

하지만 이렇게 같은 CID만 사용하면 네트워크를 통해 해커들이 사용자 추적과 물리적 위치 추론 등을 할 수 있기 용이하기 때문에 새 네트워크가 사용될 때마다 CID를 변경해야 할 필요성이 있다.

그렇다면 어떻게 하느냐

동일한 개념적 연결에 매핑되는 무작위 CID를 생성하면 된다. 연결을 X라고 하면 연결 X에 매핑되는 CID A,B,C,D… 등을 계속해서 만들어내면 되는 것이다. 이렇게 하면 공격을 시도하는 사람은 이러한 CID가 X라는 것을 알지 못하지만 클라이언트와 서버는 이를 알고 연결을 계속 유지할 수 있다.

유연성과 발전 가능성

유연성과 발전 가능성과 같은 경우는 위에서도 하나 언급했다시피 미들박스가 아닌 엔드포인트(클라이언트 및 서버)만 업데이트하면 되어 보다 업데이트가 용이하다는 장점이 있다.

추가적으로 유연성과 발전 가능성을 가지는 이유가 하나 더 있다. TCP와 달리 QUIC는 모든 프로토콜 메타 데이터를 전송하기 위해 단일 고정 패킷 헤더를 사용하지 않는다. 대신 QUIC는 짧은 패킷 헤더를 가지고 패킷 페이로드 내부의 다양한 프레임(소형 특수 패킷)을 사용하여 추가 정보를 전달한다.

이렇게 프레임을 사용하여 정보를 전달할 경우 최적화가 가능해 보다 바이트를 절약할 수 있으며 프레임 사용으로 미래에 QUIC를 확장하면서 새로운 프레임 유형을 정의하는 것이 쉽다는 점이 장점이다.

추가적으로, QUIC은 사용자 정의 Transport Parameter라는 TLS 확장을 사용한다. 이를 통해 클라이언트와 서버는 QUIC 연결에 대한 구성을 선택할 수 있다. 즉, 어떤 기능을 활성화하고 기본값을 따로 정의함으로써 프로토콜을 유연하게 만드는 것이다.

이러한 구현은 또한 사용자 공간에 수행되어 ‘kernel spance(커널 공간)‘에서 수행되는 TCP보다 QUIC 구현 변형 및 확장의 실험 및 배포가 훨씬 쉽다.

참고자료

https://www.geeksforgeeks.org/tcp-3-way-handshake-process/ https://mindnet.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-22%ED%8E%B8-TCP-3-WayHandshake-4-WayHandshake https://developer.mozilla.org/ko/docs/Glossary/TCP_handshake https://hojunking.tistory.com/106 https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/