Medium - HTTP 3 is Out and About!
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - HTTP3이 나왔습니다! 그것에 대해 알아봅시다! HTTP1에서 HTTP3까지, HTTP의 진화
What is HTTP?
HTTP는 하이퍼텍스트 전송 프로토콜입니다. 여러분의 인터넷 브라우저에 서버로부터 웹페이지를 받아서 전달하는 규칙들을 정의하는 것이죠. HTTPS는 동일한 프로토콜에 암호화 레이어를 추가해서 프라이버시 기능을 강화한 것입니다.
HTTP and its layers (TCP/IP Stack). Source: Mozilla Dev :.figure
OSI 인터넷 통신 명세에 친숙하신 분이라면 ( Open Systems Interconnections ) HTTP가 어플리케이션 레이어라는 것을 아실겁니다. 이 말은 하드웨어 구조나 미디어 같은 하위 계층과는 전혀 상관 없다는 것이죠. 때문에 HTTP 명세는 대역폭 증가와 기타 개선, 업그레이드 사항에 있어서 유연함을 가집니다. 이와 같은 일이 어떻게 이루어지는지 아래의 그림을 봅시다.
Fetching a web page. Source: Mozilla Dev :.figure
HTTP는 클라이언트-서버 프로토콜입니다. 리퀘스트는 오직 user-agent 하나에게서 전송됩니다. ( 프록시를 통해서 올 수도 잇습니다. ) 거의 대부분 user-agent는 웹 브라우저 입니다만 검색 엔진 인덱스를 유지보수하는 크롤링 봇과 같이 다른 것도 될 수 있습니다.
여기서 user agent는 클라이언트를 말합니다. 이것은 브라우저가 될 수도 있고 HTTP 프로토콜을 서버에 요청하는 모든 것이 될 수 있습니다. 웹 서버는 요청받은 서버의 컨텐츠를 전달합니다. 프록시는 서버와 user agent 사이에서 통신을 전달합니다. 프록시의 기능은 다음과 같습니다.
- Caching
- Filtering ( 성인물, 지역 기반 컨텐츠 차단 )
- Load balancing ( 유휴 서버로 리퀘스트 전달 )
- Authentication ( 유저마다 다른 서버와 통신을 하도록 허용 )
- Logging ( 비정상 행동등을 감지하기 위한 HTTP 로깅 )
HTTP1, HTTP1.1은 간단하게 위의 작업들을 수행할 수 있었습니다. 2009년에 HTTP2가 등장하기 전까지는요.
HTTP2
HTTP2는 HTTP1의 네트워크 기술과 대역폭의 발전으로 인해 HTTP1의 제약사항을 해결하기 위해 제안되었습니다.
- Need to Perform Multiplexing: 이것은 동일한 TCP 커넥션에서 여러개의 리퀘스트를 가능하게 합니다. 자원 효율에 도움이 됩니다.
- 브라우저에게 웹페이지 로딩을 빠르게 하기 위해서 어떤 컨텐츠를 먼저 Fetching할 지 알려줍니다.
- HTTP 헤더를 가볍게 했습니다.
- 서버에서 웹 브라우저에게 요청 받기 전에 보낼 수 있는 자원이 있으면 먼저 푸시합니다. 이 때문에 컨텐츠를 re-fetch할 때 HTML을 더욱 짧게 할 수 있습니다.
HTTP2는 더욱 빠르고 우수한 보안성을 제공했습니다. akami cloud provider 에서 데모를 수행해 보실 수 있습니다.
HTTP3 the New Member
이 프로토콜은 아직까지는 나오지 않았습니다. 그러나 Youtube는 이미 크롬 브라우저에서 HTTP3을 쓰고 있다는 것을 발견했습니다. 제가 어떻게 알았냐구요? 왜냐면 전 HTTP 프로토콜을 보는 플러그인을 사용 했거든요 ( HTTP’2 and SPDY indicator )
What’s new?
새로운 스펙은 당연하겠지만 더 빠르고 우수하고 보안성이 개선되었습니다. 과연 어떤 방식으로 그렇게 되었을까요?
HTTP3는 TCP 핸드세이크를 단순화 했습니다. ( 3-way 핸드세이크로 hi, hi again, ok you got my hi 를 통해 커넥션을 구축합니다 ). 하위계층에서 QUIC 프로토콜을 사용해서 커넥션을 더욱 빠르게 구축할 수 있도록 한 것이죠.
강화된 커넥션 구성은 와이파이 연결과 모바일 네트워크 등 기타 연결도 더욱 개선되어 통합되었습니다. 이런 커넥션 통합은 같은 네트워크 안에 라우터간에 이루어지는 게 아닙니다. 더욱 복잡하고 철학적이죠.
최근 QUIC는 더욱 빠른 속도를 내기위해 TCP의 slow start를 개선하려고 했습니다. QUIC에서는 congestion window를 급격하게 늘려서 이것을 해결하려고 했죠. Stadia ( 구글의 클라우드 게이밍 서비스 )나 UHD 비디오 스트리밍에 아주 중요하게 작용할 것입니다. 이것이 유튜브가 HD 영상을 실행할 때 버퍼링없이 빠르게 수행될 수 있는 이유일 수도 있습니다. 그러나 정확한 스펙은 아마 올해 말쯤은 되어야 공개 될 것입니다.
Summary
- HTTP3은 유튜브에서 이미 쓰이고 있다
- QUIC는 TCP의 슬로우 스타트를 개선했다 ( 커넥션 구축 부분을 빠르게 함 )
- 올해 말에나 정확한 스펙이 공개되겠지만 클라우드 게이밍 서비스, UHD 비디오 스트리밍 등 더욱 속도가 중요한 서비스에 많은 영향을 미칠 것이다.
