HTTP 통신은 어떻게 진화하고 있나

HTTP는 웹사이트를 방문하면 서버와의 통신에서 이용한다. HTTP/3은 이런 HTTP의 새로운 버전이다. 지금까지 HTTP 통신 문제가 HTTP/3에선 어떻게 해결될까.

1990년 말 세계 첫 웹페이지가 등장하고 이듬해인 1991년 HTTP/0.9가 등장했다. 당시에는 단순히 서버에서 특정 문서를 다운로드하는 간단한 것이었다. 1996년에 이르러 업로드에 대응하는 등 확대 기능을 업데이트한 HTTP/1.0이 책정된다. 이는 오늘날 HTTP 통신의 원형이라고 할 수 있다. HTTP/1.0에선 모든 요청에서 새로운 TCP 연결을 만들 사양으로 되어 있기 때문에 핸드셰이크(handshake) 지연이 문제가 된다.

이 문제를 해결하기 위해 HTTP/1.0이 나오고 반년 뒤에 이를 수정한 HTTP/1.1이 책정된다. HTTP/1.1에는 킵얼라이브(keepalive)를 도입해 여러 요청을 하나의 연결로 처리할 수 있게 됐다. HTTP/1.1은 오랫동안 웹 통신을 지원해오고 있으며 2015년 다음 버전인 HTTP/2가 공식 사양이 됐지만 HTTP/2 수립 이후에도 HTTP/1.1 통신을 하는 사이트가 많다.

HTTP/1.1은 등장 이후 20년 이상 쓰였지만 그 사이 웹사이트는 크게 진화했다. 이미지와 자바스크립트, CSS 같은 사이트를 표시하는데 필요한 리소스가 HTTP/1.1 등장 당시와 비교하면 큰 폭으로 증가한 것. 따라서 브라우저가 웹서이트를 쉽게 볼 수 있고 많은 연결을 동시에 할 필요가 생겼다. 하지만 HTTP/1.1에선 한 번에 할 수 있는 요청은 하나 뿐이다. 여러 요청을 수행하려면 이전 요청이 끝날 때까지 대기해야 한다는 제한이 있었다. 동시 연결을 하려면 여러 HTTP/1.1 연결을 할 수 밖에 없었다.

HTTP/1.1은 연결 유지를 한 번 연결에 여러 리소스를 다운로드할 수 있는 특징이 있었지만 여러 HTTP/1.1 연결을 실시하는 건 각각의 연결에서 핸드셰이크를 해 원래 HTTP/1.0 상태가 되어 버린다.

2015년 HTTP/2가 등장하면서 하나의 연결에서 여러 자원을 동시에 다운로드할 수 있게 된다. HTTP/2 등장으로 하나의 TCP 연결을 효율적으로 이용하는 게 가능하게 된 것이다. 하지만 이번에는 이 통신이 TCP에서 이뤄지고 있는 게 문제가 됐다. TCP는 데이터 전체를 올바른 순서로 전송하기 위한 프로토콜이며 TCP 패킷 일부가 네트워크에서 끊어질 때 그 패킷이 재전송될 때까지 후속 패킷을 차단해버린다. 다른 리소스에 대한 요청을 하나의 TCP 연결로 정리하는 사정상 뭔가 리소스에 대한 요청 패킷 손실이 발생하면 동일한 TCP 연결을 이용하는 다른 리소스에 대한 요청까지 모조리 중단되어 버린다.

이런 이유로 HTTP/3에선 새롭게 QUIC이라는 프로토콜이 개발되고 TCP 대신 이용된다. 이론상 QUIC는 TCP와 UDP에 함께 전송 프로토콜로 만들어 좋지만 새로운 전송 프로토콜을 보급하려면 현재 네트워크 장비를 모두 바꿔야 할 만큼 노력과 시간이 필요하다. 이 문제로 QUIC는 UDP를 이용해 구현되어 있다.

QUIC는 여러 요청을 차단하지 않고 흘릴 뿐 아니라 통신을 시작할 때의 핸드셰이크도 단축되고 있다. 지금까지는 TCP나 TLS 핸드셰이크를 따로 실시했지만 QUIC을 이용하면 연결 인증과 암호화를 함께 해 서버와의 통신 횟수를 줄일 수 있다.

HTTP/3 연결은 지금 당장은 개발자용 크롬 카나리(Chrome Canary)에서만 써볼 수 있고 해당 서버도 제한적이다. 하지만 앞으로 보급되면 더 쾌적한 웹사이트를 볼 수 있게 될 것이다. 관련 내용은 이곳에서 확인할 수 있다.