30년 이상이 지났지만 아직도 HTTP는 브라우징, 비디오 시청, 음악 듣기 뿐만 아니라 앱, 기계 간 통신, 다른 프로토콜을 구축할 기반에 이르기까지 웹의 기초이자 인터넷에서 가장 인기 있는 프로토콜 중 하나로, 전통적인 인터넷 모래시계 그림에서 "두 번째 허리"라고 불리는 구조를 이루고 있습니다.
HTTP는 왜 성공했을까요? 한 가지 해답은 애플리케이션 프로토콜을 필요로 하는 대부분의 애플리케이션에서 "가장 좋은 지점"이 되어준다는 점입니다. “HTTP를 이용한 프로토콜 구축”(2022년, HTTP 실무 그룹에서 현재의 RFC 모범 사례로 발행)에서는 다음의 요인이 HTTP의 성공에 기여했다고 주장합니다.
- 구현자, 지정자, 관리자, 개발자, 사용자에게 익숙함- 다양한 클라이언트, 서버, 프록시 구현 가능- 사용 용이성- 웹 브라우저 이용 가능- 인증 및 암호화와 같은 기존 메커니즘 다시 사용- 대상으로 하는 배포 환경에 HTTP 서버와 클라이언트가 있음- 방화벽을 통과하는 능력
또 다른 중요한 요소는 HTTP를 사용, 구현, 표준화하는 사람들의 커뮤니티입니다. Cloudflare는 프로토콜을 상호 운용할 수 있고 현재의 요구를 충족할 수 있도록, 적극적으로 협력해 프로토콜을 유지하고 개발합니다. HTTP의 발전이 정체되면 (당연히) 다른 프로토콜이 이를 대체할 것이고 커뮤니티의 모든 투자, 공동의 이해, 상호 운용성도 사라질 것입니다.
Cloudflare와 여러 회사는 IETF에 참여하도록 엔지니어를 파견하여 협력하는데, IETF에서는 인터넷 프로토콜 대부분을 논의하고 표준화합니다. 또한 HTTP 워크숍과 같은 커뮤니티 행사에 참석하고 후원하여 어떤 문제가 있고 무엇이 필요한지 논의하며, 어떤 변화로 도울 수 있는지 파악하고 있습니다.
그러면 2022년 실무 그룹 회의, 규격 문서, 부대 행사에서 무슨 일이 있었을까요? 웹 프로토콜 구현자와 배포자는 무엇을 하고 있을까요? 그리고 다음에는 어떻게 될까요?
새로운 규격: HTTP/3
규격 측면에서 2022년에 일어났던 가장 큰 일은 HTTP/3 발표였습니다. 네트워크를 보다 효율적으로 사용해 웹 성능에 날개를 달아줌으로써, 최신 애플리케이션과 사이트의 요구 사항에 발 맞추었던 엄청난 진전이었기 때문입니다.
90년대의 HTTP/0.9와 HTTP/1.0은 각 요청마다 새로운 TCP를 연결하는 방법을 썼습니다. 놀라울 정도로 비효율적인 네트워크 사용 방식이었습니다. HTTP/1.1에서는 영구 연결(`Connection: Keep-Alive` 헤더와 함께 HTTP/1.0으로 백포팅)이 도입되었습니다. 이러한 개선으로 서버와 네트워크가 웹의 폭발적인 인기에 대처하는 데 도움이 되었지만, 그 당시 커뮤니티에서도 여기에 상당한 제약이 있다는 점, 특히 HOL 블로킹(Head-Of-Line Blocking, 연결 시 처리되지 않은 요청이 하나가 다른 요청의 완료를 막음)의 제약을 잘 알고 있었습니다.
90년대와 2000년대 초에는 큰 문제가 아니었지만, 오늘날의 웹 페이지와 애플리케이션은 제약 사항이 성능에 아주 중요할 만큼 네트워크 수요가 많습니다. 페이지에는 네트워크 리소스를 두고 경쟁하는 자산이 수백 개인 경우가 많고 HTTP/1.1은 이를 감당할 수 없었습니다. 커뮤니티는 시작 단계에서 몇 번을 실패한 이후 결국 2015년에 HTTP/2로 문제를 해결했습니다.
하지만 HTTP에서 HOL 블로킹을 없앴더니 한 계층 아래인 TCP에서 같은 문제가 발생했습니다. TCP는 정상적이며 신뢰할 수 있는 전송 프로토콜이므로, 흐름에서 패킷이 하나만 손실되더라도 이후 패킷에 대한 액세스가 차단될 수 있습니다. 운영 체제의 버퍼에 있더라도 마찬가지입니다. 결국 이 점은 특히 최적화되지 않은 네트워크에서 HTTP/2 배포 시 실제적인 문제가 되었습니다.
물론 해답은 아주 오래되어 인터넷의 많은 부분의 기반이 된 전송 프로토콜인 TCP를 대체하는 것이었습니다. QUIC 실무 그룹에서의 많은 논의와 초안을 거쳐서 QUIC 버전 1이 그 대안으로 2021년에 발표되었습니다.
HTTP/3은 QUIC를 사용하는 HTTP 버전입니다. 실무 그룹은 QUIC와 함께 2021년에 사실상 이 버전을 마무리했지만, 다른 문서의 발표와 맞추기 위해 2022년까지 발표를 보류했습니다(아래 참조). 2022년 또한 HTTP/3 배포에서 중요한 해였습니다. Cloudflare는 새 프로토콜의 도입이 늘어나고 신뢰성이 증가하는 것을 확인할 수 있었습니다.
HTTP/2와 HTTP/3 사이의 간격은 짧았던 반면, 커뮤니티 내에서 HTTP/4에 바로 착수해야 한다는 의견은 많지 않았습니다. QUIC과 HTTP/3은 둘 다 새롭습니다. 전 세계에서는 프로토콜을 구현하고, 작동하며, 이를 사용해 사이트와 애플리케이션을 구축하는 최선의 방법이 무엇인지 아직 알아보고 있습니다. 제한점 때문에 새 버전을 강구하게 될 미래를 배제할 수는 없지만 IETF는 최신 네트워크에 대한 광범위한 업계 경험을 기반으로 이러한 프로토콜을 구축했으며 필요할 때 쉽게 변경할 수 있는 상당한 확장성을 갖추고 있습니다.
새로운 규격: HTTP “코어”
2022년, HTTP 규격과 관련된 또 다른 주요 사건은 HTTP 규격의 핵심인 "코어" 문서의 발표였습니다. 코어는 메서드, 헤더, 상태 코드, 메시지 형식인 HTTP 시맨틱, HTTP가 작업을 캐싱하는 방법인 HTTP 캐싱, 모두가 알고 즐겨 사용하는 형식을 사용하여 시맨틱을 와이어에 매핑하는 HTTP/1.1로 구성됩니다.
추가적으로 시맨틱 문서와 적절히 통합하고, 해결되지 않은 몇 가지 문제를 해결하기 위해 HTTP/2가 다시 발표되었습니다.
이는 이러한 문서에 대한 여러 개정판 중에서 가장 최신 버전입니다. 과거에는 RFC 723x 시리즈, (아마 가장 유명한) RFC 2616, RFC 2068, 이 모든 버전의 조상이라 볼 수 있는 RFC 1945가 있었습니다. 가독성을 높이고, 오류를 수정하고, 개념을 더 잘 설명하고, 프로토콜 작동을 명확히 하기 위해 각 개정판이 작성되었습니다. 잘못 지정(또는 구현)된 기능은 제외되었고 프로토콜 작동을 개선하는 새로운 기능이 추가되었습니다. 자세한 내용은 각 문서의 '...다음에서 변경' 부록을 확인하세요. 중요한 점은 항상 위에 링크된 최신 개정판을 참조하는 것입니다. 이전 RFC는 더 이상 사용되지 않습니다.
Early Hints 배포
HTTP/2에는 _서버 푸시_가 포함되어 있었습니다. 클라이언트가 무언가를 필요로 한다는 것을 알았을 때 서버가 요청/응답 쌍을 클라이언트에 "푸시"하도록 설계된 기능으로, 요청하고 응답을 기다리는 대기 시간 페널티를 방지할 수 있습니다.
2015년에 HTTP/2가 마무리된 후, Cloudflare와 여러 HTTP 구현팀은 성능이 대폭 향상될 것이라는 기대를 갖고 바로 서버 푸시를 출시했습니다. 안타깝게도 실제로는 더 어려웠습니다. 서버 푸시가 작동하려면 클라이언트가 무슨 요청을 보낼지 뿐만 아니라 네트워크 상태가 어떨지, 사실상 서버에서 미래를 예측해야 합니다. 그리고 서버가 잘못 예측했다면("오버 푸시") 푸시된 요청은 브라우저가 만든 실제 요청과 직접 경쟁하게 되는데, 성능에 도움이 되기 보다 성능이 저하될 실제 가능성이 있어 기회 비용이 큽니다. 브라우저가 이미 캐시에 사본을 가지고 있어 푸시가 전혀 필요하지 않다면 더 나쁜 영향을 미칩니다.
그래서 2022년에 Chrome은 HTTP/2 서버 푸시를 없앴습니다. 다른 브라우저와 서버에서는 아직 지원할 수도 있지만 커뮤니티에서는 브라우저 알림별 웹 푸시 프로토콜과 같은 특수 용도에만 현재 적합하다는 데 동의하는 것으로 보입니다.
그렇다고 Cloudflare가 포기한다는 의미는 아닙니다. 2017년에 HTTP 실무 그룹은 103(Early Hints) 상태 코드를 실험 RFC로 발표했습니다. 이를 통해 서버는 "실제" 최종 응답 전에 최종 이외의 응답으로 브라우저에 _힌트_를 보낼 수 있습니다. 브라우저가 가져올 리소스에 대한 몇 가지 링크가 콘텐츠에 포함되지만, 클라이언트에 대한 응답을 받는 데 시간이 더 필요한 경우(생성하는 데 시간이 더 걸리거나, CDN처럼 서버가 다른 곳에서 가져와야 하기 때문)에 유용합니다.
Early Hints는 서버 푸시가 목표로 했던 여러 상황에서 사용할 수 있습니다. 페이지를 로드해야 하는 CSS 및 JavaScript가 있는 경우가 그 예입니다. 이론적으로는 서버 푸시만큼 최적화되어 있지 않습니다. 해결되지 않은 요청이 있을 때만 힌트를 보낼 수 있고, 클라이언트에 대한 힌트를 받고 조치를 취할 때 대기 시간이 약간 늘어나기 때문입니다.
하지만 실제로 Cloudflare와 파트너(Shopify 및 Google 등)는 2022년에 Early Hints를 실험해봤고 핵심 웹 성능 메트릭이 상당히 절감되는 등, 장래성이 있는 성능상의 이점이 있으며 훨씬 더 안전하게 사용할 수 있다는 점을 알게 되었습니다.
Early Hints가 잠재력을 보여주어 매우 기쁩니다. Cloudflare Pages에 통합하게 되어 더욱 기쁩니다. Cloudflare는 프로토콜의 새로운 이 기능을 활용해 성능을 개선할 새로운 방법까지도 평가하고 있습니다.
개인정보 보호 중심 중개
2022년의 HTTP 프로토콜 확장 중에서 많은 이들에게 가장 흥미로운 점은 프록시, 게이트웨이, 유사한 구성 요소를 프로토콜에 삽입하여 특정한 목표를 달성하는 기능인 중개에 초점이 맞춰져 있는데, 목표는 주로 개인정보 보호 개선이었습니다.
예를 들어 MASQUE 실무 그룹은 중개자가 터널링된 트래픽을 다른 서버로 전달할 수 있도록 HTTP에 새로운 터널링 기능을 추가하려는 활동입니다.
CONNECT로 TCP 터널을 오랜 시간 동안 사용할 수 있었던 반면, MASQUE를 통해서는 QUIC 및 HTTP/3 등 더 많은 프로토콜을 더 효율적으로 터널링할 수 있는 UDP 터널을 사용할 수 있게 되었습니다.
Cloudflare는 Apple과 함께 MASQUE를 이용해 iCloud 비공개 릴레이를 구현하고, 한 회사에만 의존하지 않고 고객의 개인정보 보호를 강화하기 위해 노력하고 있습니다. MASQUE 기반 VPN을 가능하게 할 IP 터널링을 포함한 실무 그룹의 향후 작업에도 관심이 많습니다.
중개 중심의 또 다른 규격은 OHTTP(Oblivious HTTP)입니다. OHTTP는 중개 집합을 사용하여 서버가 연결이나 IP 주소를 사용해 클라이언트를 추적하지 못하도록 막아, 원격 측정이나 기타 중요한 데이터를 수집하는 데 개인정보를 더욱 강력히 보호합니다. 이 규격은 이제 막 표준 프로세스를 마무리하고 있으며, Cloudflare에서는 중요한 신제품인 Privacy Gateway를 구축하는 데 이 규격을 사용해 고객의 고객 개인 정보를 보호하고 있습니다.
중개는 커뮤니케이션을 분할할 수 있으므로, Cloudflare와 인터넷 커뮤니티의 다수는 개인정보 보호를 개선하는 귀중한 도구가 이제 시작되었을 뿐이라고 생각합니다.
프로토콜 보안
마지막으로 2022년에는 HTTP의 보안 관련 측면에서 많은 작업이 있었습니다. Digest Fields 규격은 무결성 다이제스트를 메시지에 추가할 수 있도록 오래된 '다이제스트' 헤더 필드를 업데이트했습니다. HTTP Message Signatures 규격으로 요청 및 응답에서는 암호화 서명이 가능합니다. 임시로 널리 배포되어 있었지만 지금까지는 표준이 없었던 부분입니다. 두 규격 모두 마지막 표준화 단계에 있습니다.
2022년에는 쿠키 규격 개정도 많이 진전되어 곧 마무리될 것입니다. 빠른 시일 내로 쿠키를 완전히 없애기란 불가능하기 때문에 새로운 `SameSite` 속성 등 쿠키가 작동하는 방식을 제한해 개인정보 보호와 보안을 개선하려고 다양한 작업이 이루어졌습니다.
Cloudflare가 수년 동안 투자한 또 다른 보안 관련 규격 세트는 "Private Access Tokens"라고도 하는 Privacy Pass입니다. 성가신 캡차를 사용하지 않고, 사용자의 온라인 활동을 추적하지 않고도 봇이 아닌 실제 사람 클라이언트를 확인할 수 있는 암호화 토큰입니다. HTTP에서 이러한 규격은 새로운 인증 체계가 되었습니다.
Privacy Pass는 아직 표준 프로세스를 거치지 않았지만 2022년에 Apple이 광범위하게 배포하여 큰 발전을 이루었습니다. 그리고 Cloudflare가 캡차의 대안인 Turnstile에서 사용하기 때문에 이제 사용자에게 더 나은 경험을 제공할 수 있습니다.
2023년은 어떨까요?
그렇다면 그다음은 무엇일까요? HTTP 실무 그룹에서는 아직 마무리되지 않은 위의 규격 외에도 QUERY 메서드(바디가 있는 GET으로 생각하세요), Resumable Uploads(tus기반), Variants(캐싱 목적으로 개선된 Vary 헤더), Structured Fields 개선 사항(새로운 날짜 유형 포함), 기존 헤더를 Structured Fields로 개조하는 방법 등, 다른 작업도 몇 가지 진행하고 있습니다. 2023년에 진행되는 대로 자세히 다루겠습니다.
2022년 HTTP 워크숍에서 커뮤니티는 프로토콜을 개선하기 위해 어떤 작업을 새로 시작할 수 있는지도 논의했습니다. 논의되었던 몇 가지 아이디어로는 공유 프로토콜 테스트 인프라 개선(지금은 약간의 리소스가 있으나 훨씬 더 개선할 수 있음), 더욱 지능적이고 올바르게 연결을 관리할 수 있도록 Alternative Services 개선(또는 대체), 대안인 헤더의 이진 직렬화와 같이 급진적인 변경이 있습니다.
커뮤니티는 HTTP가 pub/sub를 수용해야 하는지, 또는 WebSocket(이와 더불어, 곧 WebTransport)에서 작동하도록 표준화해야 하는지 여부까지 지속적으로 논의했습니다. 지금 말하기는 어렵지만, 이제 막 시작된 QUIC를 통한 미디어와 관련이 높은 작업으로 이를 진전시킬 기회가 생길 수도 있습니다.
당연히 이게 전부는 아니고, 2023년(및 그 후)에 HTTP가 어떻게 될 지는 두고 봐야 합니다. HTTP는 사상 최대 규모의 분산형 하이퍼텍스트 시스템인 World Wide Web과 계속 호환성을 유지하면서 아직도 진화하고 있습니다.