HTTP의 발전 과정과 HTTP3

이 글은 '그림으로 배우는 TCP/IP'를 읽고 작성한 글입니다.

여러분은 웹에서 어떤 사이트에 접속하기 위해 http:// https://와 같이 URL을 입력해본 경험이 있을 것입니다. 웹브라우저는 최초의 'http' 부분을 보고 'HTTP로 액세스합니다.'라고 웹서버에게 선언하면서 요청을 송신합니다. 이에 대해 웹서버는 처리 결과를 응답으로 반환하죠.

오늘은 인터넷에서 흔히 사용되고 있는 HTTP(Hypertext Transfer Protocol)에 대해 알아보는 시간을 가져보고자 합니다.

HTTP란?

HTTP란 애플리케이션 계층에서 동작하는 프로토콜 중 가장 잘 알려진 프로토콜입니다. 원래 텍스트 파일을 다운로드하기 위한 목적의 간소한 프로토콜이었습니다. 지금은 텍스트를 넘어 실시간 메세지 교환, 동영상 송출 등 다양한 용도로 사용할 수 있도록 발전했으며 이로 인해 인터넷과 HTTP는 폭발적으로 전세계에 보급되었습니다.

HTTP 버전 

HTTP는 1991년에 등장한 이래 네 번의 버전 업그레이드가 있었습니다.

HTTP/0.9

HTTP/0.9는 HTML(Hypertext Markup Language)로 기술된 텍스트 파일(HTML 파일)을 서버에서 다운로드하기 위한 단순한 프로토콜이었습니다. 웹 브라우저에서는 웹 서버에서 단순히 텍스트파일을 다운로드만 할 수 있었습니다.

• 웹 브라우저에서는 웹 서버에서 단순히 텍스트파일을 다운로드만 할 수 있었습니다.
• 요청간 TCP 커넥션을 만들고 부수는 순서를 반복합니다.

HTTP/1.0

시간이 지나고 HTTP/1.0은 RFC1945 'Hypertext Transfer Protocol - HTTP/1.0'으로 표준화되었습니다. HTTP/1.0에서는 다음과 같은 주요 변경사항이 존재합니다.

• 텍스트 파일 이외에도 다양한 파일을 다룰 수 있게 되었습니다.
• 다운로드뿐만 아니라 업로드나 삭제도 가능해졌습니다.
• 메시지 포맷이나 요청, 응답의 기본적인 사용도 이 시점에 확립되었습니다
• 요청간 TCP 커넥션을 만들고 부수는 순서를 반복합니다.

HTTP/1.1

HTTP/1.1은 1997년에 RFC2068 'Hypertext Transfer Protocol - HTTP/1.1'로 표준화되어 1999년에 RFC2616 'Hypertext Transfer Protocol - HTTP/1.1'로 업데이트 되었습니다. 주요 변경사항은 다음과 같습니다.

• Keep alive(지속적 연결) 기능이 생겨 한 번 만들어진 TCP 커넥션을 재사용하는 기능입니다.
• 요청에 대한 응답을 기다리지 않고 다음 요청을 송신하는 파이프라인 기능이 새로 생겼습니다. 

HTTP/2

HTTP/2는 구글이 개발한 SPDY(스피디)라는 프로토콜을 기반으로 2015년 RFC7540 Hypertext Transfer Protocol Version 2(HTTP/2)' 로 표준화되었습니다. 

HTTP/2는 텍스트 형식의 메세지 단위로 교환하는 애플리케이션 데이터를 프레임이라 부르는 바이너리 형식 단위로 교환해 오버헤드 감소와 성능 향상을 목표로 고안되었습니다. 주요 변경사항은 다음과 같습니다.

• 멀티플렉싱 : 1개의 TCP 커넥션 안에 스트림이라는 가상 채널을 만들고, 스트림별로 요청과 응답을 교환하게 만듭니다.
  • 1개의 TCP 커넥션으로 파이프라인과 같은 병렬 처리를 구현할 수 있습니다.
• HPACK     : 메시지 헤더(HTTP 헤더)를 압축하는 기능
  • 메시지 헤더는 HTTP에 관한 제어 정보를 저장한 필드
  • 전송한 메시지 헤더를 숫자로 치환하고, 숫자를 동적으로 치환하는 등 헤더의 전송량을 줄이기 것을 목표로 합니다.
• 서버 푸시   : 클라이언트가 최초로 요청한 컨텐츠를 해석하고 다음에 올 요청에 대한 응답을 요청이 오기 전에 보냅니다.
  • 웹브라우저는 그 응답을 캐시해 다음에 요청할 때 캐시 영역에서 응답하도록 하여 속도 개선을 도모했습니다.

HTTP/3

HTTP/3은 아직 RFC 표준화가 되지 않은 상태이지만, 앞으로 차세대 통신의 핵심 프로토콜이 될 거라 예상되어 자세히 다루는 시간을 가져보고자 합니다. HTTP/3은 구글이 개발한 QUIC(Quic UDP Internet Connections)를 기반으로 하는 프로토콜이며 애플리케이션 데이터를 보내지 않는 시간을 극단적으로 줄이는 것을 목표로 고안된 프로토콜입니다.

여기서 중요하게 볼 것은 현재까지 사용되던 통신 프로토콜 TCP가 다른 프로토콜로 변경되었다는 점입니다. 그렇다면 QUIC는 무엇일까요?

QUIC(Quic UDP Internet Connections)란?

HTTP/3는 TCP가 아닌 QUIC를 기본 통신 프로토콜로 사용합니다. QUIC(Quic UDP Internet Connections)란, 구글에서 설계한 UDP 기반의 프로토콜로 빠른 통신을 목표로 합니다. 그렇다면 왜 HTTP/3에서는 그간 사용해왔던 TCP가 아닌 새로운 프로토콜을 설계해 사용할까요?

QUIC는 TCP의 단점을 효율적으로 극복해 냅니다.

TCP는 3 handshake를 통해 통신하는 프로토콜입니다. 서버와의 통신을 통해 커넥션을 맺고, 이후에 데이터를 전송하는 방식이죠. 이러한 통신의 문제점으로는 데이터를 송수신하는 과정에서 지속적인 커넥션 요청이 필요하다는 점입니다.

TLS+TCP는 세션키를 주고 받고 암호화된 연결을 성립한 후에 세션키와 함께 데이터를 교환합니다. 반면에 QUIC는 프로토콜 내에 TLS를 포함하여 데이터 전달과 암호화 절차가 동시에 수행되죠. 이러한 차이로 인해 네트워크 통신간 라운드 트립이 한 번 줄어들며 데이터 송수신간 latency가 줄어드는 이점을 가질 수 있습니다.

QUIC는 보안성이 강화됩니다

기존에는 HTTP 데이터만 암호화했다면 QUIC부터는 더 많은 영역을 암호화하여 보안성을 강화합니다.

QUIC는 여러 파일의 데이터를 동시에 통신할 수 있습니다.

HTTP 1 에서는 TCP 커넥션 한 번에 하나의 파일밖에 전송할 수 없었습니다. HTTP 2에 서는 이를 개선하여 하나의 TCP 커넥션 에서도 여러 파일을 전송할 수 있도록 만들었습니다. 하지만, TCP는 하나의 커넥션을 하나의 파일로 취급하기에 패킷 로스가 발생하면 해당 파일 뿐만 아니라 TCP 커넥션을 공유하는 다른 파일들의 패킷도 중단이 되는 문제가 발생할 수 있었습니다.

QUIC은 개별 파일을 구분하여 중간에 패킷 로스가 발생하더라도 해당 파일의 스트림만 정지되며 나머지 파일들의 통신은 정상적으로 수행됩니다.

QUIC는 네트워크가 바뀌더라도 커넥션이 유지됩니다.

QUIC에는 connection id라는 개념이 존재합니다. 서버와 클라이언트는 커넥션 ID를 기억해서 핸드셰이크를 처음부터 진행하지 않을 수 있도록 합니다. 네트워크가 바뀔 경우, connection id 또한 바뀌지만 이전에 사용하던 connection id 와 동일한 id라는 것을 네트워크상에서 인지하여 커넥션을 유지할 수 있습니다.

현재 전세계 HTTP는 어떨까?

HTTP/3를 사용하는 웹사이트는 현재 25%에 가까워져 있으며 이는 계속해서 증가하고 있습니다. 아무래도 동영상 시청이 늘어나는 상황에서 통신 속도가 빠른 HTTP/3 선택은 적합할테니까요. 

또한 IT의 기술을 선도해나가고 있는 구글과 동영상 플랫폼에서 압도적인 1위를 하고 있는 Youtube가 HTTP/3를 도입하여 사용중에 있으니 앞으로 더더욱 많은 곳에서 HTTP/3를 도입하지 않을까 생각됩니다.

그럼 HTTP/3가 최고일까요?

HTTP/2의 단점을 보완해 나온 HTTP/3는 프로토콜의 변경으로 인해 속도와 보안성 모든 측면에서 HTTP/2를 압도하고 있습니다. 그렇기에 전 세계적으로 HTTP/3를 도입하는 것은 시간문제라고 생각됩니다. 다만, 다음과 같은 문제점으로 인해 도입이 늦어지고 있습니다.

1. 기존 TCP 통신에서 UDP 통신으로 변경되는 문제 - 전환의 어려움
   • 기존에 프로토콜이 업그레이드 되는 과정에서는 근간이 변경됐었던 적은 없었습니다. 하지만 이번에는 통신 프로토콜 자체가 변경되기에 고려할 사항이 많아집니다. 이러한 문제로 인해 기존에 HTTP/1.1 HTTP/2에서 선뜻 HTTP/3를 도입하기에는 다소 어려운 부분이 존재하죠.
2. 프로토콜의 변화로 인한 새로운 보안적 위험요소 존재
   • UDP 프로토콜의 통신에서는 UDP 증폭 통신으로 인한 DDOS 문제가 존재하는 등 새로운 프로토콜의 사용률이 높아질수록 이와 관련된 다양한 공격 또한 증가하고 있습니다. 이러한 공격 기법들은 계속해서 증가하고 있으며 이들을 해결하기 위해 다앙햔 방어 기능들을 제공하고 있지만 현재 진행형이라는 점이 도입에 주저함을 가지도록 만듭니다.
3. 헤더의 암호화로 인해 식별의 어려움
   • 보안성이 강화되어 기존에 암호화하지 않고 있던 헤더 필드 영역까지 암호화하게 됨에 따라, 혹은 등의 정보에 쉽게 접근할 수 없게 되었습니다. 이런 헤더의 정보를 사용하는 ISP나 네트워크 중계회사들은 QUIC을 도입하는데 주저함이 클 것입니다.

결론

오늘은 HTTP의 발전 과정과 차세대 프로토콜인 HTTP3에 대해 알아보는 시간을 가져봤습니다. 

공부하다보니 앞으로 HTTP3의 도입은 RFC 표준화 이후 본격화되지 않을까라는 생각을 가지게 되었습니다. 영상과 관련된 사이트들은 HTTP3로의 전환으로 인해 얻는 이점이 많아 전환을 진행하겠지만, 나머지 웹 서비스에서는 그 정도로 중요한 개선 사항이 아닐 뿐더러 헤더 암호화에 부정적이어서 HTTP/2에서 머무르지 않을까 하는 의견을 드립니다.

각 버전별 HTTP 통신에 대해 조금 더 구체적으로 알고 싶거나 네트워크의 전반적인 이해를 원하실 경우 '그림으로 공부하는 TCP/IP 구조'를 읽어보시는 것을 추천드립니다.

읽어주셔서 감사합니다.

Reference

 QUIC and HTTP/3 : Too big to fail?!

https://www.hamadevelop.me/http3/

 HTTP3, 사실 진짜로 바뀐건 TCP 였다.