보안 전문가들은 이제 막 HTTP/2에 몰두하고 있지만, 웹 분야의 영향력 있는 사람들은 이미 HTTP/3로 업데이트를 진행하고 있습니다.
HTTP/3는 큰 성능 향상과 보안상의 이점을 제공하지만, 웹 작동 방식에 있어 변화보다 진화에 가까운 HTTP/3 앞에 놓여있는 많은 배포 이슈를 먼저 해결해야 합니다.
HTTP/3란 무엇일까요?
HTTP/3는 웹상에서의 정보 전달을 지원하는 Hypertext Transfer Protocol (HTTP)의 주요 개정 버전입니다.
HTTP/3는 QUIC 을 기반으로 동작합니다. QUIC은 단일 연결에서 여러 데이터 스트림을 멀티플렉싱(multiplex)하는 암호화된 범용 전송 계층 프로토콜입니다.
QUIC은 구글에서 처음 개발되었습니다. 이 프로토콜은 User Datagram Protocol(UDP) 을 기반으로 공간 혼잡 제어 기술을 활용합니다.
HTTP, HTTP/2, HTTP/3 는 어떤 관련이 있을까요?
HTTP는 실제 'TCP 기반의 HTTP'입니다. HTTP/2는 'TCP 기반의 HTTP'라고 설명될 수도 있습니다. 그리고 HTTP/3는 'QUIC 기반의 HTTP/2'로 가장 잘 설명됩니다.
2020 블랙햇 아시아 가상 콘퍼런스에서 구글의 엔지니어 Nick Harper가 HTTP/3와 QUIC이 HTTP/2와 어떻게 차이가 있는지 깊이 있게 설명했습니다.
Harper는 HTTP/3 프로토콜 스택이 "HTTP/2와 유사한 정도의 보안성"을 지닌다고 말하며, HTTP/3는 QUIC을 사용하여 성능이 향상되고 QUIC은 프라이버시 를 강화한다고 덧붙였습니다.
벨기에 Hasselt 대학교 웹 성능 분야의 PhD 연구원인 Robin Marx는 HTTP/3와 HTTP/2의 구현은 다르지만 상위 계층 기능에서는 유사한 측면을 보인다고 설명했습니다.
HTTP/3를 가장 잘 묘사하는 표현은 아마 'QUIC기반의 HTTP/2'일 것입니다.
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을 사용합니다.
HTTP/3는 얼마나 잘 지원되고 있을까요?
2020년 10월 기준 HTTP/3 프로토콜은 인터넷 표준 초안 이며 여러 가지 구현체가 존재합니다.
W3Techs의 통계 에 따르면 상위 1000만 웹 사이트 중 거의 8%가 HTTP/3를 지원하고 있습니다.
참고 : 2022년 3월 기준 전체 웹 사이트의 약 25%가 HTTP/3를 지원하고 있습니다.
HTTP/3는 안정적인 버전의 Chrome 브라우저(2019년 12월부터)와 Firefox(2020년 1월부터)에 대해 기본값이 아닌 지원을 제공합니다.
HTTP/3가 확산되면 어떠한 이점을 얻을 수 있을까요?
HTTP/3의 지지자들은 이 기술이 손실이 발생하기 쉬운 네트워크에서 웹 사이트의 로딩 시간을 단축하고 더 나은 성능을 제공할 것으로 예상합니다.
Cloudflare의 프로덕트 매니저인 Achiel van der Mandele은 "간단히 말하면 HTTP/3가 모든 사람에게 더 나은 인터넷을 제공할 것으로 생각합니다. HTTP/3는 HTTP/2의 후속 버전으로 웹 사이트를 로드할 때 향상된 성능을 제공합니다." 라고 말했습니다.
또한 Mandele은 "HTTP/3 사용자들은 패킷 유실이 많은 저품질 네트워크상에서 빠른 연결 설정과 더 나은 성능 향상의 이점을 얻을 수 있습니다. 이러한 개선으로 웹사이트를 보다 빠르고 안정적으로 로딩할 수 있습니다." 라고 덧붙였습니다.
Marx는 HTTP/3의 이점에 대해 좀 더 신중한 태도를 취했습니다.
Marx는 "성능상의 이점을 얻을 수는 있지만, 실제로 그런 경우가 많지는 않습니다. head of line blocking의 제거는 웹 페이지 로딩과 같은 상황에서 그렇게 중요하지 않습니다." 라고 말했습니다.
그는 HTTP/3와 QUIC은 "혁명이 아닌 진화"라고 덧붙이며 "대부분의 이점은 핸드셰이크 설정 시간의 단축에 있습니다." 라고 설명했습니다.
마지막으로 Marx는 "성능은 좋아지겠지만 웹 브라우징과 같은 작업에서는 눈에 띌 정도는 아닐 것입니다. 보안은 더 좋아지고, 여러 공격 유형들로부터의 보호를 제공해줄 것입니다." 라고 설명했습니다.
HTTP/3는 더 빠른 웹사이트 로딩 시간과 더 나은 성능을 제공한다고 합니다.
HTTP/3의 배포 앞에는 어떤 과제가 있을까요?
Cloudflare의 제품 이사인 Rustam Lalkaka는 HTTP/3의 배포 시 극복해야 할 여러 지점을 제시했습니다. 여기에는 로드 밸런서의 동작, 소위 '미들박스' 라고 불리는 심층 패킷 검사 장치, 그리고 브라우저 지원 구축이 있습니다.
QUIC과 HTTP/3를 지원하는 소프트웨어는 여전히 새롭고 빠르게 발전하고 있습니다. "상호 운용성 문제가 발생할 때 이를 해결하기 위해 강력한 산업 간 파트너십이 잘 작동하는 모습은 매우 고무적이었습니다. 표준과 다양한 구현이 발전함에 따라 계속해서 문제를 찾으며 수정하기를 기대합니다."
네트워크 간의 트랜짓 프로바이더(또는 경우에 따라서는 ISP)에서는, 지금까지 UDP 트래픽에 대해서 적대적이었던 미들 박스 를 가동하는 경우가 있습니다. "QUIC의 장점을 최대한으로 끌어내고 모든 클라이언트가 이를 사용할 수 있도록, 적대적인 미들 박스를 갖는 일부의 네트워크에서는 설정을 조정할 필요가 있습니다."
많은 서버 오퍼레이터에서 QUIC를 유효하게 하는 것은 복잡합니다. "예시로 Cloudflare 고객의 경우 HTTP/3를 활성화하는 것은 간단합니다. 대시보드의 HTTP/3 토글만 누르면, 호환되는 브라우저를 통해 사이트를 방문하는 모든 사람들이 새로운 프로토콜을 통해 접근 할 수 있습니다."
클라이언트 지원은 아직 완전히 주류인 것은 아닙니다. "구글 크롬 은 최근 브라우저의 95%에 대해 QUIC에서의 HTTP/3를 활성화했습니다. 이제 QUIC IETF 표준을 갖춘 HTTP/3가 최종 초안 작업에 들어갔기 때문에 다른 주요 브라우저도 이를 따를 것으로 예상됩니다. Firefox와 Safari 는 도입 초기 단계입니다."
Cloudflare는 기술 블로그 글 에서 어떻게 HTTP/3를 도입했는지에 대해 자세히 기술했고, 이는 HTTP/3에 대해 잘 소개하고 있습니다.
Marx는 예를 들어 방화벽이 접속 설정이나 QUIC 전송 헤더 정보를 추적할 수 없으므로 "일부 네트워크는 의도적으로 QUIC을 차단한다." 라고 덧붙였습니다.
그리고 Marx는 "패킷 번호, 확인 응답, 옵션들은 모두 QUIC으로 암호화되어 있습니다. QUIC은 암호화되어 있을 때만 작동하고 브라우저는 현재 자체 서명된 인증서 또는 '내부' 루트 인증서와는 제대로 작동하지 않습니다." 라고 설명했습니다.
QUIC의 연결 ID 및 연결 마이그레이션 기능을 처리하기 위해 로드 밸런서를 조정해야 합니다.
0-RTT(round trip time)와 같은 고급 기능은 Session Ticket 암호화 키 생성과 리플레이 공격으로부터 보호하는 강력한 보안 측면을 가지고 있다고 Marx는 덧붙였습니다.
언제쯤 QUIC과 HTTP/3가 주류가 될까요?
QUIC에 대한 탐색은 복잡합니다. 왜냐하면 QUIC은 TCP가 아닌 UDP를 기반으로 동작하기에 HTTP/1.1에서 HTTP/2로 업그레이드한 것과 같은 방식으로 HTTP/2를 단순히 QUIC으로 업그레이드할 수는 없기 때문입니다.
이러한 구현 장벽에 대해 Marx는 "향후 몇 년간 HTTP/3는 콘텐츠 전송 네트워크(CDN)나 외부 서비스 제공자를 사용할 때 얻을 수 있는 것일 뿐, 대부분 사람들이 자신의 서버에 설정할 수 있는 것은 아닙니다." 라고 말했습니다.
QUIC 기반의 HTTP/3에 관한 Marx의 콘퍼런스 토크 및 블로그 글 에서는 이 기술이 직면한 많은 현실적인 문제에 대해 논의하고 있습니다.
Marx는 다음과 같이 결론지었습니다. "QUIC은 여전히 매우 강력한 프로토콜입니다. QUIC은 TCP보다 진화/조정이 훨씬 쉽기 때문에 많은 성능 향상이 곧 나타날 것이며 새로운 모범 사례들이 등장할 것입니다.
"하지만 이것은 매우 복잡하며, 더 넓은 커뮤니티에서 QUIC의 동작 방식과 사용법을 받아들이기까지 시간이 걸릴 것입니다."
