도입만 해도 기사가 줄줄 나오는 기술이 있다...?
뭐가 그렇게 좋길래!
도입 사례
1.네이버
네이버는 검색요청의 경우에만 HTTP3 프로토콜 통신을 이용하는것 보여진다.
네이버는 크로스브라우징이 중요하기 때문에 모든 브라우저를 지원하지 않는 HTTP3 프로토콜을 소극적 도입을 한게 아닐까? 라는 혼자만의 추측..(그럼 구글은....? 네이버 형님들의 도입 히스토리를 간절하게 들어보고 싶다ㅠㅠ)
2. 토스페이먼츠
별도의 네트워크 탭을 확인하기는 어려우나 토스도 이미 도입한것으로 보여진다 (역시나 기사가 쏟아졌다)
3.구글
구글은 적극적으로 도입중인 것으로 확인된다. 크롬으로 접속시 HTTP3 프로토콜을 적극적으로 이용하고
HTTP3 프로토콜을 지원하지 않는 사파리 브라우저 이용시 HTTP2를 이용하여 서빙하는 것으로 보여진다
외에도 유튜브, 메타, 넷플릭스등 빅테크들 또한 서포트 하는 브라우저의 경우에는 적극적으로 HTTP3 프로토콜을 이용하고 있다.
HTTP3는 뭐가 다를까?
HTTP2와 HTTP3의 가장 큰 차이점은 계층 프로토콜이다. 우리가 열심히 학습했던 OSI7 계층 중 4번째 layer다.
HTTP/3는 QUIC(Quick UDP Internet Connections)을 기반으로 동작하고, HTTP/2는 TCP를 기반으로 동작한다는 점이다.
QUIC도 역시 웹 표준이며 RFC 9000으로 표준화되어 있다.
여태껏 봐왔던 7계층 피라미드에서 TCP/UDP와 추가로 QUIC를 넣어 업데이트 해야된다
(좀 더 알아보니 4번째 레이어(전송계층)에 처음 들어보는 다른 프로토콜이 엄청 많다.)
QUIC란
QUIC는 Quick UDP Internet Connections 의 약자로 2013년에 구글에서 발표한 프로토콜입니다.
TCP는 연결을 기반으로하기때문에 속도를 개선하고자 UDP를 채택해서 전달속도를 개선하고 클라이언트와 서버간 연결수를 최소화 하고, 대역폭을 예상해서 혼잡상황을 피하는것이 주요 특징입니다.
또한 통신이 멀티플랙싱 되어 HOLB 극복 및 패킷도 개별적으로 암호화되고 새로운 연결에 대해서 TCP 핸드세이크로 인한 지연 및 패킷 손실등에서 자유롭습니다.
QUIC를 이용한 HTTP/3은 뭐가 좋을까?
QUIC으로의 전환은 HTTP/2의 주요 문제점인 'head of line blocking(HOL)' 을 해결하는 데 큰 도움이 됩니다.
TCP의 손실 회복 메커니즘은 기본적으로 HTTP/2 멀티플렉싱의 병렬성에 대해 지원하지 않습니다. 따라서 트랜잭션이 특정 패킷의 영향을 받는지와 상관없이 패킷이 유실되거나 순서가 재조정되면 활성화된 모든 트랜잭션의 동작이 멈추게 됩니다.
QUIC은 기본적으로 멀티플렉싱을 지원하기 때문에 유실된 패킷은 데이터가 삭제된 스트림에만 영향을 줍니다.
HTTP/3로 업그레이드하면 열악한 인터넷 연결에 대한 지연 시간을 효과적으로 단축할 수 있습니다.
QUIC은 거의 완전히 암호화되어있고 이는 HTTP/3에서 보안이 크게 향상된다는 의미이기도 합니다.
이러한 빌트인 암호화는 중간자 공격(MitM) 에 노출될 가능성을 낮춰줍니다. 또한 QUIC은 서비스 거부 공격(Denial of Service, DoS)으로부터 보호해줄 여러 기능이 있습니다.
QUIC은 단일 왕복 내에 새 서버와 연결할 수 있는 방식으로 암호화 기술과 전송 핸드셰이크를 결합합니다. 이를 통해 클라이언트는 최초 연결 시 암호화된 애플리케이션 데이터를 송신하고, 중단된 연결을 신속히 재개할 수 있습니다.
QUIC은 암호화 핸드셰이크를 위한 구성 요소로 TLS 1.3을 사용합니다.
정리하자면
1. HOL을 해결하여 송신 딜레이 타임 감소
2. 0-RTT
3. 인터넷 연결 지연 시간 단축
4. IP가 바뀌어도 연결이 유지
5. socket과 같은 주기적인 통신에 강한 이점이 있다.
6. TLS 암호화를 기본적으로 사용하기 때문에 보안에도 이점이 있다.
HOL 이란?
[참고]
HOL 차단에 대한 단일 기술 정의를 제공하기는 어렵습니다. 이 블로그 게시물에서만 HOL 차단의 4가지 변형을 설명하기 때문입니다. 그러나 간단한 정의는 다음과 같습니다.
단일(느린) 개체가 다른/다음 개체의 진행을 방해하는 경우
좋은 실제 비유는 계산대가 하나뿐인 식료품점입니다. 많은 품목을 구매하는 한 고객은 선입선출 방식으로 고객에게 서비스를 제공하기 때문에 뒤의 모든 고객을 지연시킬 수 있습니다. 또 다른 예는 차선이 하나뿐인 고속도로입니다. 이 도로에서 한 번의 자동차 충돌로 인해 전체 통로가 오랫동안 막힐 수 있습니다. 따라서 "헤드"의 단일 문제라도 전체 "라인"을 "차단"할 수 있습니다.
이 개념은 해결하기 가장 어려운 웹 성능 문제 중 하나였습니다.
- HTTP/1.1은 전체 응답을 보내야 하고 다중화할 수 없기 때문에 HOL 차단이 있었습니다.
- HTTP/2는 각 리소스 청크가 속한 "스트림"을 나타내는 "프레임"을 도입하여 이를 해결합니다.
- 그러나 TCP는 이러한 개별 "스트림"에 대해 알지 못하고 모든 것을 하나의 큰 스트림으로 봅니다.
- TCP 패킷이 손실되면 이후의 모든 패킷은 서로 다른 스트림의 관련 없는 데이터를 포함하더라도 재전송을 기다려야 합니다. TCP에는 전송 계층 HOL 차단 기능이 있습니다.
그래서 QUIC 및 HTTP/3이 HOL 차단을 정말 완전히 제거합니까?
=> 아닙니다. QUIC은 단일 리소스 스트림 내에서 순서를 유지합니다.
이는 QUIC에서도 여전히 HOL 차단의 형태를 가지고 있음을 의미합니다.
단일 스트림 내부에 바이트 간격이 있는 경우 스트림의 후반 부분은 여전히 그 간격이 채워질 때까지 대기하고 있습니다.
하지만 QUIC는 단일 리소스 스트림 내에서 순서를 유지하지만 더 이상 개별 스트림 간에는 순서를 유지하지 않습니다. 이것이 HOL 현상에 좀 더 도움을 줄 수 있다는 점입니다.
그렇다면 HTTP3 HOL이점을 이용하려면
- QUIC의 HOL 차단 제거로 이익을 얻으려면 다중화된 리소스 보내기 (스플릿팅)
- 브라우저가 핵심 리소스를 최대한 빨리 처리할 수 있도록 하려면 리소스를 순차적으로 전송합니다 (preload).
수치상 비교
[참고]
QUIC과 TCP의 웹 경험 비교
그림 3. 실험환경 구성
QUIC과 TCP의 성능을 비교하기 위하여 그림 3의 환경에서 실험을 진
행하였다. 실험은 Google Chrome의 chrome://flags에서 QUIC의 사용을
Enabled 및 Disabled 하여 파일 다운로드, 웹페이지 로딩 시간, Youtube
스트리밍 시간을 측정하였다. 이때, QUIC은 클라이언트가 서버와 한 번이
라도 연결을 한 경우 0-RTT (handshake 협상과정)로 작동한다.
Google Drive를 통해 1 ~ 35MB 크기의 파일의 다운로드 시간을 그림
4.(a)에 나타내었다. 재연결된 QUIC은 0-RTT의 연결 시간으로 인해 처
음 연결하는 QUIC보다 빠른 다운로드 속도를 보였고 TCP가 가장 긴 시
간이 걸렸다.
Support (2023/06/14)
