http, http2, https, http3

이전에 여러 프로토콜을 공부하면서, 프로토콜은 서로를 대체하기 위해 존재하기보다는 각자가 해결하지 못하는 영역을 보완하는 방향으로 진화해 왔다는 점이 인상 깊었습니다. 즉, 하나의 프로토콜이 모든 문제를 해결하는 구조가 아니라, 역할을 분리하고 그 위에 다른 기술을 결합하는 방식으로 전체 구조가 완성된다는 관점입니다. 이 관점을 웹에 그대로 적용해 보면, 웹 애플리케이션 계층의 중심에는 여전히 HTTP가 존재합니다. 그리고 우리가 흔히 말하는 HTTP/1.1, HTTP/2, HTTP/3는 서로 다른 목적의 별도 프로토콜이 아니라, 동일한 HTTP 모델을 유지한 채 성능과 연결 관리의 한계를 개선해 온 진화 과정에 가깝습니다. 한편 HTTPS는 새로운 프로토콜이 아니라, HTTP 통신 위에 TLS를 결합하여 보안 요구사항을 충족시키는 방식입니다. 그럼에도 불구하고, 오늘날의 웹은 여전히 HTTP/1.1만으로도 동작할 수 있습니다. 이 사실은 웹 통신 기술들이 서로를 대체하기 위해 존재하는 것이 아니라, 각 시점의 병목과 한계를 분담해서 해결하기 위해 상호 보완적으로 설계되어 왔다는 점을 보여줍니다. 이 글에서는 HTTP의 동작 방식이나 각 버전의 세부 기능을 설명하지 않습니다. 대신, HTTP, HTTP/2, HTTP/3, 그리고 HTTPS가 웹 통신 구조 안에서 어떤 관계로 결합되어 있으며, 어떤 문제를 각자의 위치에서 분담해 해결하고 있는지, 즉 기술 자체가 아니라 역할과 관계에 집중해 살펴보고자 합니다.

HTTP/1.1의 목적과 한계

HTTP는 알파시피 TCP를 웹에 사용하기 위해 만들어진 프로토콜입니다.  
HTTP/1의 목적은 웹을 실제 서비스 수준에서 쓸 수 있게 만드는 것이었습니다.
HTTP/1.0이 개념 증명이었다면, HTTP/1.1은 운영 가능한 웹 프로토콜을 목표로 하였습니다.

HTTP/1.1의 목적

HTTP/1.0의 가장 큰 한계는 요청 하나마다 TCP 연결을 새로 생성해야 했다는 점입니다.
이는 곧, 각 요청마다 TCP 3-way handshake가 반복적으로 발생한다는 의미이며,
네트워크 지연과 서버 자원 소모를 불필요하게 증가시키는 구조였습니다.

특히 웹 페이지는 단일 HTML 문서만 전송하는 구조가 아니라, CSS, JavaScript, 이미지, 폰트 등 다수의 리소스를 함께 요청합니다.
HTTP/1.0 환경에서는 이러한 각 리소스 요청이 모두 독립적인 TCP 연결로 처리되었습니다.

즉, 문제의 본질은 "요청 수가 많다"가 아니라, 리소스 단위로 TCP 연결이 생성되는 구조 자체가 성능 병목이 된다는 점이었습니다.

HTTP/1.1의 주요 목적 중 하나는 바로 이 지점을 개선하는 것이었습니다.
이를 위해 HTTP/1.1은 하나의 TCP 연결을 재사용하여 여러 요청을 처리할 수 있도록 하는 지속 연결(persistent connection) 모델을 기본 동작으로 채택하였고, 이를 통해 불필요한 handshake 비용과 연결 생성 오버헤드를 줄이고자 했습니다.

정리하면, HTTP/1.1이 해결하려 했던 것은 단순한 최적화가 아니라,
웹이 다수의 리소스를 동시에 요청하는 구조라는 현실을 전제로, TCP 연결 비용을 구조적으로 줄이기 위한 설계 변경이었습니다.

HTTP/1.1의 한계

HTTP/1.1은 지속 연결(persistent connection)을 도입함으로써 HTTP/1.0에 비해 TCP 연결 생성 횟수를 크게 줄였습니다.

그러나 웹이 단순한 문서 전송을 넘어, 하나의 페이지 요청이 수십 개 이상의 리소스를 동시에 요청하는 구조로 확장되면서,
이 방식 역시 구조적인 한계에 도달하게 됩니다.

문제의 핵심은 연결을 재사용하느냐가 아니라,
하나의 TCP 연결 위에서 요청과 응답이 하나의 순서 흐름으로 처리되는 메시지 처리 모델에 있습니다.

HTTP/1.1에서는 앞선 요청의 응답이 지연될 경우, 이미 처리가 완료된 뒤의 요청 응답까지도 함께 대기하게 되며,
이로 인해 이른바 Head-of-Line Blocking 문제가 발생합니다.
*Head-of-Line Blocking: 앞에 위치한 하나의 작업 지연이 뒤에 있는 모든 작업의 진행을 막는 현상.

결과적으로 HTTP/1.1은 TCP 연결 수는 줄이는 데에는 성공했지만, 다수의 리소스 요청이 동시에 발생하는 현대 웹 환경에서,
개별 요청들의 지연을 서로 분리하지 못하는 구조로 인해 메시지 처리 모델 자체가 병목이 되는 단계에 이르게 되었습니다.

즉, HTTP/1.1의 한계는 단순한 성능 튜닝의 문제가 아니라, 하나의 연결 안에서 모든 응답 흐름이 하나의 순서 큐에 묶여 있어,
요청 간 지연이 서로 독립적으로 처리되지 못하는 프로토콜 구조에서 비롯된 한계라고 볼 수 있습니다.

한 줄로 정리하면, HTTP/1.1의 한계는 느리기 때문이 아니라, 응답 흐름의 동시성이 존재하지 않는 단일 스트림 구조에 있습니다.

 HTTP/1.1의 극복?

HTTP/1.1에서 시도한 유일한 방법은 pipelining입니다. 이 방식은 하나의 TCP 연결에서 요청A,B,C를 응답을 기다리지 않고
연속으로 보내는 방식입니다. 즉, HTTP/1.1은 요청이 미리 여러개 보내면 대기 시간이 줄지 않을까 이렇게 접근하였습니다.
하지만 RFC 레벨에서도 명확하게 작성되있듯이 응답 순서는 반드시 요청 순서를 따라야 했습니다.
요청을 빠르게 보낼 수 뿐 응답은 여전히 하나의 큐에 묶여 있었습니다.
어떻게 보면 이는 극복은 아니고 부분완화였습니다. 결국 HTTP/1.1은 동시 응답에 대한 이슈를 해결하지는 못했습니다.
현재는 거의 모든 브라우저 벤더에서 disable된 상태라고 합니다. 
그래서 나온것이 HTTP2입니다.

HTTP/2

앞에서 HTTP/1.1의 목적과 한계를 살펴보면서,
마치 HTTP/2가 HTTP/1.1을 대체하기 위해 등장한 것처럼 보였을 수도 있습니다.
하지만 서두에서 이야기했듯이, 웹 프로토콜의 진화는 교체가 아니라 구조적 한계를 보완하는 방향으로 이루어져 왔습니다.

HTTP/2 역시 HTTP/1.1을 부정하거나 폐기하기 위해 등장한 기술이 아닙니다.
HTTP/1.1이 해결하지 못했던 문제, 즉 하나의 연결 안에서 모든 응답 흐름이 하나의 순서 큐에 묶여
지연이 분리되지 못하는 구조 를 그대로 유지한 채, HTTP 계층 내부의 메시지 처리 방식만을 재설계한 것이 HTTP/2의 출발점입니다.

다시 말해 HTTP/2는,
기존 HTTP 의미 체계(method, status, header, URI)를 유지하면서 전송 방식만 바꿔
HTTP/1.1의 구조적 병목을 보완하는 방향으로 설계되었습니다.

이제부터는, HTTP/2가 HTTP/1.1을 어떻게 "대체"했는지가 아니라,
HTTP/1.1이 가지던 단일 응답 흐름 구조를 어떤 방식으로 보완했는지에 집중해서 살펴보겠습니다.

HTTP/2가 보완하는 방식

 

앞에서 정리한 HTTP/1.1의 핵심 한계는, 하나의 연결 안에서 모든 응답이 하나의 순서 큐에 묶여 지연이 분리되지 못한다는 점이었습니다.
HTTP/2는 이 구조를 HTTP의 의미 체계는 그대로 유지한 채, 메시지를 전달하는 방식만 변경함으로써 보완합니다.

구체적으로 HTTP/2는, HTTP 메시지 자체는 그대로 두고,
그 아래에 전송을 담당하는 래퍼 계층(binary framing layer)을 하나 추가한 구조입니다.
이 래퍼 계층은 요청과 응답 메시지를 프레임 단위로 분해하고,
각 프레임에 스트림 식별자를 부여하여 하나의 연결 위에서 여러 응답 흐름을 동시에 전송할 수 있도록 합니다.
그 결과, HTTP/1.1에서 발생하던 하나의 응답 지연이 전체 응답 흐름을 막아버리는 구조가, 스트림 단위로 분리되어 완화됩니다.

참고로 설정하는 방법은 웹 서버에서 HTTP/1.1를 쓸지 HTTP/2를 쓸지 선택하면 된다고 합니다. (이거는 글의 주제와 벗어나기때문에 언급만하고 넘어가겠습니다.)

HTTPS

기존 HTTP는 전송 구간에서 아무런 보안 보장도 제공하지 않습니다.
즉, 요청과 응답이 평문(plain text) 으로 전달되기 때문에, 중간 경로에서 도청·변조·위조가 모두 가능합니다.

이 문제를 해결하기 위해 HTTP 자체를 바꾼 것이 아니라, 전송 계층에 TLS를 결합한 방식이 바로 HTTPS입니다.

정확하게 말하면, HTTPS는 새로운 프로토콜이 아니라, HTTP 위에 TLS를 적용한 보안 전송 방식입니다.

HTTPS에서 TLS가 보장하는 핵심은 다음 세 가지입니다.

• 기밀성(Confidentiality)
  → 전송 데이터 암호화
• 무결성(Integrity)
  → 전송 중 데이터 변조 방지
• 서버 인증(Authentication)
  → 인증서를 통한 서버 신원 검증

중요한 점은 HTTPS는 HTTP의 의미 체계(method, header, status, URI, body)를 전혀 변경하지 않습니다.
단지  이 HTTP 메시지를 어떤 전송 경로로 안전하게 보내는것에 있습니다.

그렇다면 어째서 HTTP/2는 HTTPs가 필수인가?

사실 HTTP/2는 HTTPS가 필수가 아닙니다. 하지만, 웹(브라우저) 환경에서는 사실상 HTTPS가 필수처럼 동작합니다.
이유는 스펙이 아니라 브라우저 정책 때문입니다.

HTTP/2는 원래 TLS 위에서도 가능하고 평문 TCP 위에서도 가능합니다.
평문 버전은 보통 이렇게 부릅니다.

h2c

즉, 스펙상으로는 HTTP/2 = HTTPS 필수는 아닙니다.

 

그럼에도 불구하고 필수 처럼 보이는 이유는 전적으로 브라우저 벤더들의 선택 때문입니다.

Chrome, Firefox, Safari 등 주요 브라우저는 평문 HTTP/2(h2c)를 거의 지원하지 않습니다.
즉, 서버가 h2c를 열어놔도 브라우저는 그 경로로 HTTP/2를 쓰지 않습니다.

또한, 브라우저에서는 HTTP/2를 TLS연결할때만 사용이 되어진다고 합니다.
즉, 브라우저는 HTTP/2 협상 자체를 TLS 안에서만 수행이 되어집니다. 
브라우저가 이렇게 선택한 이유는 중간 프록시, 네트워크 장비, DPI 장비, HTTP/1.x 가정에 의존하는 인프라, 프로토콜 변형, 깨짐, 오동작
이런 것들을 피하려고 "새 프로토콜은 보안 채널 안에서만 쓰자" 라는 선택을 한 것입니다.

HTTP3

HTTP/3는 구글에서 제안한 QUIC 기반 전송 방식을 바탕으로 표준화된 프로토콜로,
기존에 TCP 위에서 동작하던 HTTP/2와 달리 UDP 기반의 QUIC 위에서 동작합니다.

다만 HTTP/3의 핵심은 단순히 TCP 대신 UDP를 사용해서 더 빠르다가 아닙니다.

HTTP/3 역시 HTTP/2와 마찬가지로, 기존 HTTP의 메시지 의미 체계(method, header, status, body 등)는 그대로 유지합니다.

즉, 달라진 것은 HTTP의 의미가 아니라, HTTP 아래에서 동작하는 전송 계층 구조입니다.

HTTP/2까지는 여러 스트림을 제공하더라도, 전송 계층이 TCP이기 때문에
패킷 손실이 발생하면 모든 스트림이 함께 멈추는 전송 계층 수준의 지연 문제가 남아 있었습니다.

HTTP/3는 HTTP를 QUIC 위에서 동작시키고, 스트림을 전송 계층 단계부터 독립적으로 처리함으로써
이러한 전송 계층 수준의 지연 전파 문제를 보완합니다.

정리하면 HTTP/3는, 기존 HTTP의 메시지 전달 체계는 그대로 유지하면서,
전송 계층을 QUIC으로 교체하여 HTTP/2에서 남아 있던 전송 계층 수준의 병목을 해결한 방식입니다.

마무리

이번 글에서는 HTTP에서 HTTP2, HTTP3로 어떻게 변화하는지에 초첨을 맞춰서 작성하였습니다. 그러다 보니 HTTP2,HTTP3,HTTPS에 대해 자세하게 작성하지는 않았다는 생각이 듭니다. 이걸 작성했던 이유는 HTTP/1.1을 그냥 쓰지 말고 HTTP/2만 쓰면 되는거 아냐 대체하는거 아냐 라는 생각으로 시작하게 되었습니다. 라이프사이클 같은걸 기대했는데 알고보니 그런그림은 전혀 아니었네요.