안녕하세요! 이번에는 프론트엔드 개발자 기술 면접의 '단골 손님'이자, 웹의 근간이 되는 HTTP의 진화 과정에 대한 문서를 번역해 드릴게요.
이 문서는 단순히 역사를 나열한 것이 아니라, 웹이 발전하면서 마주한 성능 문제들을 어떻게 해결해 왔는지(예: 멀티플렉싱, QUIC 등)를 보여줍니다. 면접에서 "HTTP/1.1과 HTTP/2의 차이점은 무엇인가요?" 또는 "HTTP/3는 왜 TCP 대신 UDP를 사용하나요?" 같은 질문을 받았을 때 멋지게 답변할 수 있는 훌륭한 무기가 될 거예요. 자, 시작해 볼까요?
HTTP의 진화 (Evolution of HTTP)
HTTP(HyperText Transfer Protocol)는 월드 와이드 웹(World Wide Web)의 기반이 되는 프로토콜이에요. 팀 버너스리(Tim Berners-Lee)와 그의 팀에 의해 1989년에서 1991년 사이에 개발된 HTTP는, 특유의 단순함을 유지하면서도 유연성을 갖추기 위해 수많은 변화를 겪어왔습니다. 반신반의하던 연구실 환경에서 파일을 교환하기 위해 설계되었던 이 프로토콜이, 어떻게 고해상도 이미지와 3D 비디오까지 실어 나르는 오늘날의 복잡한 인터넷 미로 속으로 진화했는지 계속해서 읽어보세요.
이 문서의 내용 (In this article)
- 월드 와이드 웹의 발명 (Invention of the World Wide Web)
- HTTP/0.9 – 한 줄짜리 프로토콜 (HTTP/0.9 – The one-line protocol)
- HTTP/1.0 – 확장성 구축하기 (HTTP/1.0 – Building extensibility)
- HTTP/1.1 – 표준화된 프로토콜 (HTTP/1.1 – The standardized protocol)
- 20년 이상의 개발 기간 (More than two decades of development)
- HTTP/2 – 더 나은 성능을 위한 프로토콜 (HTTP/2 – A protocol for greater performance)
- HTTP/2 이후의 진화 (Post-HTTP/2 evolution)
- HTTP/3 - QUIC 위에서 동작하는 HTTP (HTTP/3 - HTTP over QUIC)
- 같이 보기 (See also)
월드 와이드 웹의 발명 (Invention of the World Wide Web)
1989년, 유럽 입자 물리 연구소(CERN)에서 일하던 팀 버너스리는 인터넷 위에 하이퍼텍스트 시스템을 구축하자는 제안서를 작성했어요. 처음에는 Mesh라고 불렸지만, 1990년 구현 과정에서 World Wide Web으로 이름이 바뀌었죠. 기존의 TCP와 IP 프로토콜 위에 구축된 이 시스템은 4가지의 구성 요소로 이루어져 있었습니다:
- 하이퍼텍스트 문서를 표현하기 위한 텍스트 포맷, HyperText Markup Language (HTML).
- 이러한 문서들을 교환하기 위한 프로토콜, HyperText Transfer Protocol (HTTP).
- 이 문서들을 표시하고(그리고 편집할 수 있는) 클라이언트, 최초의 웹 브라우저인 WorldWideWeb.
- 문서에 접근할 수 있게 해주는 서버, httpd의 초기 버전.
이 네 가지 구성 요소는 1990년 말에 완성되었고, 1991년 초에는 CERN 외부에서도 첫 서버들이 가동되기 시작했어요. 그리고 1991년 8월 6일, 팀 버너스리가 공개 alt.hypertext 뉴스그룹에 글을 게시했습니다. 이 시점을 현재 월드 와이드 웹이 공개 프로젝트로서 공식적으로 시작된 날로 봅니다.
초기 단계에서 사용된 HTTP 프로토콜은 매우 단순했어요. 나중에 HTTP/0.9라는 이름이 붙었으며, 종종 '한 줄짜리 프로토콜(one-line protocol)'이라고 불리기도 합니다.
HTTP/0.9 – 한 줄짜리 프로토콜 (HTTP/0.9 – The one-line protocol)
초기 버전의 HTTP에는 버전 번호가 아예 없었어요. 나중에 나온 버전들과 구분하기 위해 0.9라고 부르게 된 것이죠. HTTP/0.9는 극도로 단순했습니다. 요청(request)은 단 한 줄로 구성되었고, 사용 가능한 유일한 메서드인 GET으로 시작한 뒤 리소스의 경로가 이어지는 형태였어요. 이미 서버에 연결된 상태였기 때문에 프로토콜, 서버, 포트 같은 전체 URL은 포함되지 않았습니다.
GET /my-page.html응답(response) 또한 매우 단순해서, 파일 자체로만 구성되어 있었습니다.
<html>
A text-only web page
</html>이후의 발전된 버전들과 달리, 이때는 HTTP 헤더(headers)라는 게 없었어요. 이는 곧 오직 HTML 파일만 전송할 수 있었다는 뜻이죠. 상태 코드나 에러 코드도 없었습니다. 만약 문제가 생기면, 사람이 읽고 문제를 파악할 수 있도록 에러 설명을 담은 특정 HTML 파일이 생성되어 전송되었습니다.
HTTP/1.0 – 확장성 구축하기 (HTTP/1.0 – Building extensibility)
HTTP/0.9는 기능이 너무 제한적이었지만, 브라우저와 서버들은 빠르게 이 프로토콜을 더 다재다능하게 만들었어요:
- 매 요청마다 버전 정보가 함께 전송되었습니다 (
GET라인 끝에HTTP/1.0이 추가되었죠). - 응답의 맨 앞부분에 상태 코드(status code) 라인도 전송되기 시작했어요. 덕분에 브라우저가 요청의 성공 또는 실패 여부를 스스로 인식하고, 그에 맞춰 로컬 캐시를 업데이트하거나 사용하는 등 적절하게 동작을 바꿀 수 있게 되었습니다.
- 요청과 응답 모두에 HTTP 헤더(HTTP headers)라는 개념이 도입되었어요. 메타데이터를 전송할 수 있게 되면서, 프로토콜이 극도로 유연하고 확장 가능해졌습니다.
Content-Type헤더 덕분에 일반 텍스트 HTML 파일이 아닌 다른 종류의 문서들도 전송할 수 있게 되었습니다.
💡 강사의 팁: HTTP/1.0에서 헤더가 생기고 다양한 타입(이미지, CSS 등)을 주고받을 수 있게 된 것은 혁명이었습니다. 우리가 지금 프론트엔드에서 다루는 JSON 데이터를 주고받을 수 있게 된 근간도 바로 이 확장성 덕분이죠!
이 시점의 전형적인 요청과 응답의 모습은 다음과 같았습니다:
GET /my-page.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
HTTP/1.0 200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/my-image.gif">
</HTML>이 요청이 끝나면 두 번째 연결이 이어지고, 이미지를 가져오기 위한 요청(그리고 그에 상응하는 응답)이 발생했어요:
GET /my-image.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
HTTP/1.0 200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)1991년에서 1995년 사이, 이러한 기능들은 "일단 시도해 보고 지켜보자(try-and-see)"는 방식으로 도입되었어요. 특정 서버나 브라우저가 새 기능을 추가해 보고 사람들의 반응이 좋으면 널리 쓰이는 식이었죠. 그러다 보니 시스템 간 상호 운용성(interoperability) 문제가 흔하게 발생했습니다. 이런 문제들을 해결하기 위해 1996년 11월, 공통된 관행들을 문서화한 정보 제공용 문서가 발행되었어요. 이것이 RFC 1945로 알려져 있으며, 이 문서가 HTTP/1.0을 정의하게 됩니다.
HTTP/1.1 – 표준화된 프로토콜 (HTTP/1.1 – The standardized protocol)
다양한 HTTP/1.0 구현체들이 난립하는 상황과 병행하여, 제대로 된 표준화 작업도 진행되고 있었어요. HTTP의 첫 번째 표준화 버전인 HTTP/1.1은 HTTP/1.0이 문서화된 지 불과 몇 달 후인 1997년 초에 발표되었습니다.
HTTP/1.1은 모호한 점들을 명확히 하고 수많은 개선 사항을 도입했어요:
- 연결 재사용(Connection Reuse): 연결을 재사용할 수 있게 되어 시간을 절약할 수 있게 되었습니다. 원본 문서 하나에 포함된 여러 개의 리소스(이미지 등)를 표시하기 위해 연결을 매번 새로 열 필요가 없어졌죠.
- 파이프라이닝(Pipelining): 첫 번째 요청에 대한 응답이 완전히 전송되기 전에 두 번째 요청을 보낼 수 있게 되었습니다. 이를 통해 통신의 대기 시간(latency)을 낮출 수 있었어요.
- 청크 응답(Chunked responses): 응답을 여러 조각으로 나누어 보내는 것도 지원하게 되었습니다.
- 추가적인 캐시 제어 메커니즘(cache control mechanisms)이 도입되었습니다.
- 콘텐츠 협상(Content negotiation): 언어, 인코딩, 타입을 포함한 콘텐츠 협상 기능이 도입되었어요. 이제 클라이언트와 서버가 어떤 콘텐츠를 교환할지 서로 합의할 수 있게 되었습니다.
Host헤더:Host헤더 덕분에, 동일한 IP 주소에서 서로 다른 도메인을 호스팅할 수 있는 서버 코로케이션(server collocation)이 가능해졌습니다.
다음 예시는 하나의 지속적인 TCP 연결을 통해 전송되는 전형적인 HTTP/1.1 요청의 흐름을 보여줍니다. 클라이언트가 리소스를 더 효율적으로 로드하기 위해 연결을 어떻게 재사용하는지 잘 나타나 있죠.
첫 번째 요청에서 웹 페이지를 가져오면, 서버는 HTML 문서로 응답합니다.
그런 다음 클라이언트는 HTML 내부에서 CSS와 JavaScript 리소스를 발견할 때마다 순차적으로 추가 요청을 보냅니다:
GET /en-US/docs/ HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:141.0) Gecko/20100101 Firefox/141.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
HTTP/1.1 200 OK
accept-ranges: none
content-encoding: br
date: Tue, 01 Jul 2025 08:32:50 GMT
expires: Tue, 01 Jul 2025 09:26:50 GMT
cache-control: public, max-age=3600
age: 1926
last-modified: Sat, 28 Jun 2025 00:47:12 GMT
etag: W/"b55394ed2f274eea5d528cf6c91e1dcf"
content-type: text/html
vary: Accept-Encoding
content-length: 26178
[26178 bytes of HTML]
GET /static/css/main.9e7d1ce5.css HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:141.0) Gecko/20100101 Firefox/141.0
Accept: text/css,*/*;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
HTTP/1.1 200 OK
content-encoding: br
content-length: 43694
date: Mon, 30 Jun 2025 21:13:12 GMT
expires: Mon, 30 Jun 2025 21:47:29 GMT
cache-control: public, max-age=31536000
age: 42704
last-modified: Mon, 30 Jun 2025 00:33:45 GMT
etag: W/"d4f4d0955482844ad842986a9bcb7e8a"
content-type: text/css
vary: Accept-Encoding
[43694 bytes of CSS]
GET /static/js/main.a918a4e7.js HTTP/1.1
Host: developer.mozilla.org
…TCP 연결을 설정하는 것은 클라이언트-서버 간 통신에서 꽤 비용이 많이 드는(느린) 작업입니다. 게다가 TCP slow start (TCP 혼잡 제어의 일종) 특성 때문에, 새로 만들어진 연결보다 오랫동안 유지된 연결이 더 빠르죠.
HTTP/1.1은 여러 번의 요청과 응답에 하나의 TCP 연결을 재사용할 수 있게 해주기 때문에, 매 요청마다 새로운 연결을 만들어야 하는 수고를 덜어줍니다.
하지만 여전히 클라이언트는 다음 리소스를 요청하기 위해 이전 리소스의 다운로드가 끝날 때까지 기다려야 했어요 (Head-of-line blocking, HOL 블로킹).
이 문제를 우회하기 위해, 대부분의 브라우저는 웹사이트(또는 origin) 하나당 최대 6개의 TCP 연결을 동시에 맺을 수 있도록 허용합니다.
이렇게 6개의 병렬 연결을 사용하면 브라우저는 HTTP/1.1 모델을 사용하면서도 리소스를 동시에 가져올 수 있었고, 이는 성능 향상에 큰 기여를 했습니다.
💡 강사의 팁: 기술 면접에서 매우 중요한 파트입니다! HTTP/1.1의 "Keep-Alive(연결 재사용)" 기능 덕분에 성능이 좋아졌지만, 앞의 요청이 늦어지면 뒤의 요청도 병목에 걸리는 "Head-of-Line Blocking(HOL 블로킹)" 문제가 발생했어요. 과거에 프론트엔드 개발자들이 이미지를 하나로 합치는 CSS 스프라이트(Sprite) 기법을 쓰거나, JS 파일을 하나로 번들링(Bundling)했던 이유가 바로 이 브라우저의 '연결 개수 제한'과 'HOL 블로킹'을 피하기 위해서였답니다!
HTTP/1.1은 1997년 1월에 RFC 2068로 처음 발행되었습니다.
20년 이상의 개발 기간 (More than two decades of development)
HTTP의 확장성 덕분에 새로운 헤더나 메서드를 만드는 것은 무척 쉬운 일이었어요. 비록 HTTP/1.1 프로토콜이 1999년 6월에 발표된 RFC 2616과, HTTP/2 출시 전인 2014년 6월에 발표된 RFC 7230-RFC 7235 두 번의 개정을 거치며 다듬어졌지만, 무려 15년이 넘는 시간 동안 극도로 안정적으로 사용되었습니다.
HTTP/1.1은 2022년 RFC 9110을 통해 다시 한번 업데이트되었어요. 단순히 HTTP/1.1만 업데이트된 것이 아니라 HTTP 전체가 재정비되어, 현재는 의미론(semantics, RFC 9110), 모든 버전에 적용되는 캐싱(caching, RFC 9111), 그리고 각 버전별 문서인 HTTP/1.1 (RFC 9112), HTTP/2 (RFC 9113), HTTP/3 (RFC 9114)로 나뉘게 되었습니다. 또한 그동안 항상 '제안/초안' 표준에 머물렀던 사양이 마침내 공식적인 인터넷 표준(STD 97)의 지위를 얻게 되었죠.
보안 전송을 위한 HTTP 사용 (Using HTTP for secure transmissions)
HTTP에 일어난 가장 큰 변화는 1994년 말에 이루어졌습니다. 기본 TCP/IP 스택 위에서 HTTP를 보내는 대신, 넷스케이프 커뮤니케이션즈(Netscape Communications)라는 회사가 그 위에 추가적인 암호화 전송 계층인 SSL을 만들었어요. SSL 1.0은 대중에게 공개되지 않았지만, SSL 2.0과 그 후속작인 SSL 3.0은 전자상거래(e-commerce) 웹사이트의 탄생을 가능하게 했습니다. 서버와 클라이언트 간에 주고받는 메시지를 암호화하고 진위성을 보장함으로써 말이죠. SSL은 결국 표준화 과정을 거쳐 오늘날의 TLS가 되었습니다.
같은 시기에, 암호화된 전송 계층이 필수적이라는 사실이 점차 분명해졌습니다. 웹은 더 이상 학술적인 네트워크가 아니라, 광고주, 익명의 개인, 심지어 범죄자들까지 최대한 많은 개인 데이터를 빼내기 위해 경쟁하는 정글로 변해버렸으니까요. HTTP 위에서 만들어지는 애플리케이션들이 강력해지고 주소록, 이메일, 사용자 위치 같은 개인 정보에 접근하게 되면서, 전자상거래뿐만 아니라 웹 전반에 걸쳐 TLS가 필수가 되었습니다.
복잡한 애플리케이션을 위한 HTTP 사용 (Using HTTP for complex applications)
팀 버너스리는 원래 HTTP를 읽기 전용 매체로만 상상한 게 아니었습니다. 그는 사람들이 원격으로 문서를 추가하고 이동할 수 있는, 일종의 분산 파일 시스템 같은 웹을 만들고 싶어 했죠. 1996년경, HTTP는 문서 작성이 가능하도록 확장되었고 WebDAV라는 표준이 만들어졌어요. 이 표준은 주소록 데이터를 다루기 위한 CardDAV, 캘린더를 위한 CalDAV 같은 특정 애플리케이션들로 확장되었습니다. 하지만 이러한 *DAV 확장 기능들에는 치명적인 결함이 있었어요. 바로 서버에서 기능을 구현해 주어야만 사용할 수 있다는 점이었죠.
2000년에는 HTTP를 사용하는 새로운 패턴인 REST(representational state transfer)가 설계되었습니다. 이 API 방식은 새로운 HTTP 메서드에 의존하는 대신, 기본적인 HTTP/1.1 메서드를 사용하여 특정 URI에 접근하는 방식을 채택했어요. 덕분에 웹 애플리케이션들은 브라우저나 서버를 따로 업데이트할 필요 없이 API를 통해 데이터를 조회하고 수정할 수 있게 되었습니다. 필요한 모든 정보는 표준 HTTP/1.1을 통해 서비스되는 파일 안에 내포되어 있었으니까요. 다만 REST 모델의 단점은, 각각의 웹사이트가 자기들만의 비표준 RESTful API를 정의하고 그것을 통제했다는 점입니다. 클라이언트와 서버가 서로 상호운용이 가능했던 *DAV 확장 기능과는 다른 점이었죠. 하지만 그럼에도 불구하고 RESTful API는 2010년대에 들어와 매우 보편화되었습니다.
💡 강사의 팁: 프론트엔드 실무에서는 정말 숨 쉬듯이 마주칠 개념입니다. 우리가 Next.js나 React 프로젝트에서 백엔드 서버로
GET /users/1이나POST /users처럼 데이터를 요청하는 구조가 바로 이 RESTful API 아키텍처를 따르고 있는 것이랍니다.
2005년 이후로는 웹 페이지에서 사용할 수 있는 API가 더욱 많아졌습니다. 그중 몇몇 API들은 특정 목적을 위해 HTTP 프로토콜의 확장 기능을 만들어냈어요:
- Server-sent events: 서버가 브라우저로 간헐적인 메시지를 푸시(push)할 수 있게 해주는 기능입니다.
- WebSocket: 기존의 HTTP 연결을 업그레이드하여 설정할 수 있는 양방향 통신용 새로운 프로토콜입니다.
웹 보안 모델 완화하기 (Relaxing the security-model of the web)
HTTP는 동일 출처 정책(same-origin policy)이라고 알려진 웹 보안 모델과는 독립적입니다. 사실, 현재의 웹 보안 모델은 HTTP가 만들어진 이후에 개발되었어요! 세월이 흐르면서, 특정한 제약 조건 하에서는 이 정책의 엄격한 제한을 조금 풀어주는 것이 유용하다는 사실이 입증되었습니다. 서버는 새로운 HTTP 헤더 세트를 사용하여 클라이언트에게 "이 제한을 언제, 어느 정도까지 풀어줄 것인지"를 전달합니다. 이러한 메커니즘은 교차 출처 리소스 공유 (CORS, Cross-Origin Resource Sharing)나 콘텐츠 보안 정책 (CSP, Content Security Policy) 같은 명세에 잘 정의되어 있죠.
💡 강사의 팁: CORS 에러, 프론트엔드 개발자라면 누구나 겪는 통과의례죠? 기본적으로 브라우저는 보안을 위해 다른 출처(도메인, 포트 다름)의 데이터 접근을 막는데(동일 출처 정책), 백엔드 서버에서 HTTP 응답 헤더에
Access-Control-Allow-Origin을 넣어주면 브라우저가 "아, 이 서버는 허락해 줬구나!" 하고 데이터를 통과시켜 주는 원리입니다.
이러한 큰 확장 기능들 외에도 수많은 헤더들이 추가되었고, 때로는 실험적으로만 사용되기도 했어요. 대표적으로 개인정보 보호를 제어하는 Do Not Track (DNT) 헤더, X-Frame-Options, 그리고 Upgrade-Insecure-Requests 등이 있으며 이 밖에도 훨씬 많은 헤더들이 존재합니다.
HTTP/2 – 더 나은 성능을 위한 프로토콜 (HTTP/2 – A protocol for greater performance)
시간이 지나면서 웹 페이지들은 훨씬 복잡해졌습니다. 일부 웹 페이지들은 아예 그 자체로 거대한 애플리케이션이 되기도 했죠(SPA 시대의 도래). 더 많은 시각 미디어가 표시되었고, 상호작용(interactivity)을 더하기 위한 스크립트의 볼륨과 크기도 커졌습니다. 훨씬 더 많은 데이터가 셀 수 없이 많은 HTTP 요청을 통해 전송되어야 했고, 이는 기존 HTTP/1.1 연결 방식에 엄청난 복잡성과 오버헤드(부하)를 야기했습니다.
이를 해결하기 위해, 2010년대 초 구글은 'SPDY'라는 실험적인 프로토콜을 구현했습니다. 클라이언트와 서버가 데이터를 주고받는 이 대안적인 방식은 브라우저와 서버를 개발하는 많은 개발자들의 관심을 모았습니다. SPDY는 응답성을 획기적으로 향상하고 데이터 중복 전송 문제를 해결했으며, 훗날 HTTP/2 프로토콜의 훌륭한 기반이 되었습니다.
HTTP/2 프로토콜은 HTTP/1.1과 비교해 다음과 같은 차이점이 있어요:
- 텍스트 프로토콜이 아닌 바이너리(이진) 프로토콜입니다. 사람이 직접 읽거나 수동으로 작성할 수는 없지만, 이러한 장벽을 감수하고서라도 휠씬 더 향상된 최적화 기술들을 구현할 수 있게 되었습니다.
- 멀티플렉싱(Multiplexing) 프로토콜입니다. 동일한 연결 안에서 여러 개의 요청을 병렬로 처리할 수 있게 되어, 앞서 요청한 파일이 뒤의 파일을 가로막는 HTTP/1.x 프로토콜의 고질적 한계(HOL 블로킹)를 마침내 제거했습니다.
- 헤더를 압축합니다. 일련의 요청들 사이에서 헤더는 종종 내용이 중복되기 때문에, 압축을 통해 전송되는 데이터의 중복과 오버헤드를 크게 줄였습니다.
2015년 5월에 공식 표준화된 HTTP/2의 사용량은 꾸준히 증가하여, 2022년 1월에는 전체 웹사이트의 46.9%가 사용할 정도로 정점에 달했습니다 (통계 참조). 트래픽이 많은 대형 웹사이트들이 데이터 전송 오버헤드를 줄이고 예산을 절감하기 위해 가장 발 빠르게 도입에 앞장섰습니다.
이토록 빠르게 채택될 수 있었던 이유는, HTTP/2를 사용하기 위해 웹사이트 코드나 애플리케이션을 수정할 필요가 없었기 때문일 것입니다. 그저 최신 브라우저와 통신할 수 있는 최신 버전의 서버 환경만 구축하면 되었거든요. 소수의 그룹만이 초기 도입을 주도했고, 구형 브라우저와 서버 버전들이 자연스럽게 교체되면서 웹 개발자들의 큰 추가 작업 없이도 HTTP/2의 사용률이 쑥쑥 올라갔습니다.
HTTP/2 이후의 진화 (Post-HTTP/2 evolution)
HTTP의 확장성은 여전히 새로운 기능을 추가하는 데 활발히 사용되고 있습니다. 특히 2016년에 등장한 HTTP 프로토콜의 새로운 확장 기능들을 언급해 볼 수 있어요:
Alt-Svc지원은 주어진 리소스의 식별(identification)과 위치(location)를 분리할 수 있게 해 주었습니다. 이를 통해 더욱 스마트한 CDN 캐싱 메커니즘을 구현할 수 있게 되었죠.- 클라이언트 힌트(Client hints)의 도입으로, 브라우저나 클라이언트가 서버에게 자신의 요구 사항과 하드웨어 제약 조건(예: 화면 크기, 네트워크 상태)에 대한 정보를 선제적으로 통신할 수 있게 되었습니다.
Cookie헤더에 보안 관련 접두사(prefixes)가 도입되어, 안전한 쿠키가 변조되지 않도록 보장하는 데 큰 도움이 되었습니다.
HTTP/3 - QUIC 위에서 동작하는 HTTP (HTTP/3 - HTTP over QUIC)
HTTP의 다음 메이저 버전인 HTTP/3는 이전 버전의 HTTP와 의미론(semantics, 헤더나 메서드 등)은 똑같지만, 전송 계층(transport layer)에서 TCP 대신 QUIC이라는 프로토콜을 사용합니다. 2022년 10월 기준으로, 전체 웹사이트의 26%가 HTTP/3를 사용하고 있었습니다.
QUIC은 HTTP 연결에 있어 대기 시간(latency)을 훨씬 더 낮게 제공하도록 설계되었어요. HTTP/2와 마찬가지로 멀티플렉싱 프로토콜이지만, HTTP/2는 단일 TCP 연결 위에서 실행되기 때문에, TCP 계층에서 처리되는 패킷 손실 감지 및 재전송이 발생하면 연결된 모든 스트림이 멈춰버리는 현상(TCP 계층의 HOL 블로킹)이 여전히 존재했습니다.
반면 QUIC은 UDP 위에서 여러 스트림을 실행하며, 패킷 손실 감지와 재전송을 각 스트림별로 독립적으로 구현했어요. 그래서 에러가 발생하더라도 해당 패킷의 데이터를 담고 있는 특정 스트림만 차단되고, 나머지 정상적인 스트림들은 영향을 받지 않고 쌩쌩 돌아갑니다.
RFC 9114에 정의된 HTTP/3는 대부분의 주요 브라우저에서 지원되고 있습니다. 크로미움 기반 브라우저(Chrome, Edge 등)와 Firefox 모두에서 사용 가능해요.
💡 강사의 팁: 면접관이 "HTTP/3의 가장 큰 특징은 무엇인가요?"라고 묻는다면, 두 가지 키워드 'UDP 기반'과 'QUIC 프로토콜 적용으로 인한 TCP 헤드 오브 라인 블로킹 해결'을 명확하게 답변해 주시면 됩니다.
같이 보기 (See also)
