HTTP의 진화
HTTP는 월드 와이드 웹의 기본 프로토콜이다.
1989년부터 1991년까지 Tim Berners-Lee와 그의 팀이 개발한 HTTP는 유연성을 향상하는 동시에 단순성을 유지하는 데 도움이 되는 많은 변화를 거쳤다.
계속 읽어보면, HTTP가 반신뢰할 수 있는 실험실 환경에서 파일을 교환하기 위해 설계된 프로토콜에서 고해상도 및 3D로 이미지를 전송하는 현대 인터넷 미로까지 어떻게 발전했는지 알 수 있다.
월드 와이드 웹의 발명 Invention of the World Wide Web
1989년 CERN에서 근무하던 Tim Berners-Lee는 인터넷을 통한 하이퍼텍스트 시스템 구축 제안을 작성했다.
(1989년 이전에는 인터넷으로 전용 프로그램을 통해 이미지 파일, 문서 파일, 이메일 등을 주고 받았다.)
처음에는 메시라고 불렸지만 나중에 1990년 구현 중, World Wide Web으로 이름이 변경되었다.
기존 TCP 및 IP 프로토콜을 기반으로 구축되었으며 4가지 구성 요소로 이루어져 있다.
- 하이퍼텍스트 문서를 나타내는 텍스트 형식은 HTML(HyperText Markup Language)이다.
- 문서를 교환하기 위한 간단한 프로토콜은 HTTP이다.
- 문서를 표시하고 편집하는 클라이언트는 WorldWideWeb이라는 최초의 웹 브라우저다.
- 문서에 대한 액세스를 제공하는 서버는 httpd의 초기 버전이다.
이 4개의 구성 요소는 1990년 말에 완성되었으며 첫 번째 서버는 1991년 초에 CERN 외부에서 실행되었다.
1991년 8월 6일 Tim Berners-Lee는 alt.hypertext 공개 뉴스 그룹에 게시했다.
이는 이제 공개 프로젝트로서 World Wide Web의 공식적인 시작으로 간주된다.
초기 단계에서 사용된 HTTP 프로토콜은 매우 간단했다.
나중에 HTTP/0.9로 명명되었으며 때로는 한 줄(one-line) 프로토콜이라고도 불렸다.
World Wide Web이 생기기 전에는 서로 파일을 교환하는 방식만 가능했다.
하지만 World Wide Web의 도입과 함께 초기 버전의 httpd와 같은 웹 서버를 통해 사용자는 서버에 저장된 HTML 파일을 불러와서 웹 브라우저로 직접 볼 수 있게 되었다.
이로 인해 정보 접근 방식이 크게 향상되었고, 웹 페이지를 통해 정 보를 손쉽게 검색하고 탐색할 수 있게 되었다.
HTTP/0.9 한 줄 프로토콜 HTTP/0.9 The one-line protocol
초기 버전의 HTTP는 버전 번호가 없었으며, 이후 버전들과 구분하기 위해 0.9라고 불리게 되었다.
HTTP/0.9는 매우 단순했다.
요청은 한 줄로 구성되었으며 유일하게 사용할 수 있는 메서드인 GET으로 시작하고 그 뒤에 리소스의 경로가 이어졌다.
서버에 연결되면 프로토콜, 서버 및 포트가 필요하지 않으므로 전체 URL은 포함되지 않았다.
GET /mypage.html
응답도 매우 간단했다.
파일 자체로만 구성되어 있었다.
<html>
A very simple HTML page
</html>
이후의 진화와 달리 HTTP 헤더가 없었다.
즉, HTML 파일만 전송할 수 있었다.
상태나 오류 코드는 없었다.
문제가 있으면 특정 HTML 파일이 생성되고 인간이 사용할 수 있도록 문제에 대한 설명이 포함되어 있었다.
HTTP/1.0 확장성 구축 HTTP/1.0 Building extensibility
HTTP/0.9는 매우 제한적이었지만, 브라우저와 서버는 이를 더욱 다양하게 만들었다.
HTTP/0.9는 초기의 매우 제한적인 프로토콜이었지만, 브라우저와 서버가 이를 신속하고 더 다양한 기능을 제공하도록 발전시켰다.
즉, HTTP/0.9는 처음에는 간단하고 기본적인 기능만 제공했지만, 브라우저와 서버가 이를 개선하면서 점차 더 많은 기능을 수행할 수 있게 되었다.
- 버전 정보는 각 요청 내에 포함되어 전송되었다.(GET 라인에 "HTTP/1.0"이라는 문구가 추가되었다.)
GET /index.html HTTP/1.0
GET /mypage.html HTTP/1.0 - 응답 시작 부분에도 상태 코드 줄이 전송되었다.
이를 통해 브라우저 자체가 요청의 성공 또는 실패를 인식하고 그에 따라 동작을 조정할 수 있었다.
예를 들어, 특정 방식으로 로컬 캐시를 업데이트 하거나 사용한다. - 요청과 응답 모두에 HTTP 헤더 개념이 도입되었다.
메타데이터가 전송될 수 있었으며 프로토콜은 매우 유연해지고 확장 가능해졌다. - Content-Type 헤더 덕분에 일반 HTML 파일 이외의 문서도 전송할 수 있다.
이 시점에서 일반적인 요청과 응답은 다음과 같다.
GET /mypage.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="/myimage.gif">
</HTML>
그 다음에는 두 번째 연결이 이루어지고, 해당 응답과 함께 이미지를 가져오라는 요청이 이어졌다.
GET /myimage.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년 사이에 이러한 기능들은 시도해보기 방식으로 도입되었다.
서버와 브라우저가 기능을 추가하고 그 기능이 인기를 끌 수 있는지 보았다.
상호 운용성 문제는 흔했다.
이러한 문제를 해결하기 위해 공통적인 관행을 설명한 정보 문서가 1996년에 발표되었다.
이는 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를 표준화한다는 것은 웹에서 데이터를 주고받는 방법을 정해진 규칙으로 만드는 것을 의미한다.
이렇게 하면 모든 웹 브라우저와 서버가 같은 방법으로 통신할 수 있게 된다.
HTTP/1.0도 공식적으로 표준화된 버전이지만, HTTP/1.1이 여러 개선 사항과 추가 기능들이 포함되어 있어서 더 포괄적이고 실질적이고 완전한 표준으로 간주된다.
HTTP/1.1은 웹의 발전과 더불어 다양한 기능을 추가하고 성능을 개선하여 널리 채택되었다.
HTTP/1.1은 모호성을 명확히 하고 여러 가지 개선 사항을 도입했다.
- 연결을 재사용할 수 있게 되어, 시간을 절약할 수 있었다.
더 이상 단일 원본 문서에 포함된 리소스를 표시하기 위해 여러 번 연결을 열 필요가 없었다. - 파이프라이닝이 추가되었다.
첫 번째 요청에 대한 응답이 완전히 전송되기 전에 두 번째 요청을 보낼 수 있도록 하여 통신 지연 시간을 줄였다. - 청크된 응답도 지원되었다.
- 추가적인 캐시 제어 메커니즘이 도입되었다.
- 언어, 인코딩, 타입을 포함한 콘텐츠 협상이 도입되었다.
이제 클라이언트와 서버가 교환할 콘텐츠에 대해 협의할 수 있었다. - Host 헤더 덕분에 동일한 IP 주소에서 다른 도메인을 호스팅할 수 있는 기능이 가능해져, 서버 공동 배치(하나의 서버에서 동시에 여러 웹사이트를 호스팅)가 가능해졌다.
하나의 단일 연결을 통한 일반적인 요청 흐름은 다음과 같다.
GET /en-US/docs/Glossary/CORS-safelisted_request_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.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
Referer: https://developer.mozilla.org/en-US/docs/Glossary?CORS-safelisted_request_header
HTTP/1.1 200 OK
Connection: Keep-Alice
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
(content)
GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_request_header
HTTP/1.1 200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache
(image content of 3077 bytes)
HTTP/1.1은 1997년 RFC 2068로 처음 공개되었다.
20년이 넘는 개발 기간 More than two decades of development
HTTP의 확장성 덕분에 새로운 헤더와 메서드를 쉽게 만들 수 있다.
HTTP/1.1 프로토콜은 HTTP/2가 출시되기 전, 1999년에 게시된 RFC 2616과 2014년에 게시된 RFC 7230-RFC 7235라는 두 번의 개정을 거쳐 개선되었지만 15년이상 매우 안정적이었다.
HTTP/1.1은 2022년에 RFC 9110으로 다시 업데이트되었다.
HTTP/1.1이 업데이트된 것뿐만 아니라, 전체 HTTP가 개정되어 다음 문서로 분할되었다.
시맨틱스(RFC 9110), 모든 HTTP 버전에 적용되는 캐싱(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년에 이루어졌다.
컴퓨터 서비스 회사인 Netscape Communications는 기본 TCP/IP 스택을 통해 HTTP를 전송하는 대신, 그 위에 추가 암호화된 전송 계층인 SSL을 만들었다.
SSL 1.0은 대중에게 공개되지 않았지만 SSL 2.0과 후속 SSL 3.0은 전자상거래 웹사이트를 만들 수 있게 했다.
이렇게 만들기 위해, 서버와 클라이언트 간에 교환하는 메시지를 암호화하고 진위성을 보장했다.
SSL은 결국 표준화되어 TLS가 되었다.
같은 기간 동안 암호화된 전송 계층이 필요하다는 것이 분명해졌다.
웹은 더 이상 약술적(웹이 초기에는 단순하고 기초적인 정보를 교환하는 용도로 사용되었다) 네트워크가 아니였고 대신 광고주, 무작위 개인 및 범죄자가 가능한 한 많은 개인 데이터를 두고 경쟁하는 정글이 되었다.
HTTP를 통해 구축된 애플리케이션이 더욱 강력해지고 주소록, 이메일 및 사용자 위치와 같은 개인 정보에 대한 액세스가 필요함에 따라 TLS는 전자상거래 사용 사례 이외에서도 필요하게 되었다.
복잡한 애플리케이션에 HTTP 사용 Using HTTP for complex applications
Tim Berners-Lee는 원래 HTTP를 읽기 전용 매체로 생각하지 않았다.
그는 사람들이 원격으로 문서를 추가하고 이동할 수 있는 웹, 일종의 분산 파일 시스템을 만들고 싶어했다.
1996년경, HTTP가 확장되어 작성이 가능해졌고 WebDAV라는 표준이 만들어졌다.
주소록 항목을 처리하는 CalDAV와 같은 특정 애플리케이션을 포함하도록 확장되었다.
하지만 이 모든 *DAV확장에는 결함이 있었다.
서버에서 구현할 때만 사용할 수 있었다.
2000년에 HTTP를 사용하는 새로운 패턴인 표현적 상태 전송(또는 REST)이 고안되었다.
REST API는 새로운 HTTP 메서드를 기반으로 하지 않았다.
대신 기본 HTTP/1.1 메서드를 사용하여 특정 URI에 액세스 하는 데 의존했다.
예를 들어, 웹 브라우저에서 웹사이트에 접속할 때 사용하는 'GET'이나 데이터를 보내는 'POST' 같은 기본적인 HTTP 요청 방식을 사용하여, REST API는 특정 주소(URI)로부터 데이터를 가져오거나 수정하는 작업을 한다.
이 방식은 기존의 웹 기술을 그대로 사용하면서도, 추가적인 특별한 서버나 브라우저 기능을 요구하지 않는다는 장점이 있다.
이를 통해 모든 웹 애플리케이션은 브라우저나 서버를 업데이트하지 않고도 REST API가 데이터를 검색하고 수정할 수 있었다.
서버가 REST API를 제공하면 클라이언트(웹 애플리케이션)는 별도의 업데이트 없이 데이터를 공급받을 수 있다.
필요한 모든 정보는 웹사이트가 표준 HTTP/1.1을 통해 제공하는 파일에 포함되어 있다.
REST 모델의 단점은 각 웹사이트가 자신만의 비표준 RESTful API를 정의하고 이를 완전히 제어한다는 것이다.
이는 클라이언트와 서버가 상호 운용이 가능한 *DAV 확장과 달랐다.
RESTful API는 2010년대에 매우 일반화되었다.
2005년 이후로 웹 페이지에서 더 많은 API를 사용할 수 있게 되었다.
이러한 API 중 일부는 특정 목적을 위해 HTTP 프로토콜에 대한 확장을 생성한다.
- 서버에서 보낸 이벤트, 서버가 가끔씩 브라우저에 메시지를 푸시할 수 있다.
- 웹소켓(WebSocket), 기존 HTTP 연결을 업그레이드하여 설정하고 사용할 수 있는 새로운 프로토콜이다.
웹의 보안 모델 완화 Relaxing the security-model of the web
HTTP는 동일 출처 정책이라고 알려진 웹 보안 모델과 무관하다.
사실, 현제의 웹 보안 모델은 HTTP가 만들어진 후에 개발되었다.
수년에 걸쳐 특정 제약 하에서 이 정책의 일부 제한을 해제하는 것이 유용한 것으로 입증되었다.
서버는 새로운 HTTP 헤더 세트를 사용하여 이러한 제한을 얼마나, 언제 해제할 것인지 클라이언트에 전송했다.
이는 CORS(교차 원본 리소스 공유 Cross-Origin Resource Sharing) 및 CSP(콘텐츠 보안 정책 Content Security Policy)와 같은 사양에 정의되었다.
이러한 대규모 확장 외에도 많은 다른 헤더가 추가되었으며, 때로는 실험적으로만 추가되었다.
주목할 만한 헤더로는 개인 정보 보호를 제어하는 Do Not Track(DNT), X-Frame-Options, Upgrade-Insecure-Requests가 있지만 그 외에도 많은 헤더가 있다.
HTTP/2 더 나은 성능을 위한 프로토콜 HTTP/2 A protocol for greater performance
수년에 걸쳐 웹 페이지는 더욱 복잡해졌다.
일부는 그 자체로 애플리케이션이기도 했다.
더 많은 시각적 미디어가 표시되었고 상호 작용을 추가하는 스크립트의 양과 크기도 증가했다.
훨씬 더 많은 데이터가 상당히 많은 HTTP 요청을 통해 전송되었고 이로 인해 HTTP/1.1 연결에 대한 복잡성과 오버헤드가 증가했다.
이를 설명하기 위해 구글은 2010년대 초에 실험적 프로토콜 SPDY를 구현했다.
클라이언트와 서버 간에 데이터를 교환하는 이 대체 방식은 브라우저와 서버에서 작업하는 개발자의 관심을 모았다.
SPDY는 응답성을 높이고 중복 데이터 전송 문제를 해결하여 HTTP/2 프로토콜의 기반이 되었다.
HTTP/2 프로토콜은 몇 가지 면에서 HTTP/1.1과 다르다.
- 텍스트 프로토콜이 아닌 바이너리 프로토콜이다.
수동으로 읽고 만들 수 없다.
이러한 장애물에도 불구하고 개선된 최적화 기술을 구현할 수 있다. - 다중화된 프로토콜이다.
동일한 연결을 통해 병렬 요청을 할 수 있어 HTTP/1.x 프로토콜의 제약을 제거한다. - 헤더를 압축한다.
이는 종종 요청 집합에서 유사하기 때문에 전송되는 데이터의 중복 및 오버헤드를 제거한다. - 서버는 서버 푸시라는 메커니즘을 통해 클라이언트 캐시에 데이터를 채울 수 있다.
2015년 5월에 공식적으로 표준화된 HTTP/2 사용은 2022년 1월에 모든 웹사이트의 46.9%로 정점을 찍었다.
트래픽이 많은 웹사이트는 데이터 전송 오버헤드와 그에 따른 예산을 절약하기 위해 가장 빠르게 도입되었다.
이러한 빠른 도입은 HTTP/2가 웹사이트와 애플리케이션을 변경할 필요가 없기 때문일 가능성이 크다.
이를 사용하려면 최신 브라우저와 통신하는 최신 서버만 있으면 된다.
도입을 트리거하는 데 필요한 그룹은 제한적이었고, 레거시 브라우저와 서버 버전이 갱신됨에 따라 웹 개발자가 크게 작업하지 않아도 자연스럽게 사용량이 증가했다.
도입을 트리거하는 데 필요한 그룹은 제한적이였고, 최신 버전 기능이나 표준(HTTP/2)을 지원하지 않는 구형 브라우저와 서버 버전이 갱신됨에 따라 웹 개발자가 크게 작업하지 않아도 사용이 자연스럽게 증가했다.
HTTP/2를 사용하기 위해서는 특정한 몇몇 그룹(웹 브라우저를 만드는 회사들, 웹 서버를 운영하거나 소프트웨어를 제공하는 회사들)만 새로운 표준을 지원하면 됐었다.
이들이 웹 브라우저와 웹 서버 소프트웨어가 HTTP/2를 지원하도록 업그레이드를 해주면 사용자들은 자동으로 HTTP/2를 사용할 수 있다.
HTTP/2 이후 진화 Post-HTTP/2 evolution
HTTP의 확장성은 여전히 새로운 기능을 추가하는 데 사용되고 있다.
특히, 2016년에 등장한 HTTP 프로토콜의 새로운 확장을 예로 들 수 있다.
- Alt-Svc를 지원함으로써 식별과 특정 리소스의 위치를 분리할 수 있게 되었다.
이는 더 스마트한 CDN 캐싱 메커니즘을 의미했다. - 클라이언트 힌트가 도입되면서 브라우저나 클라이언트는 자신의 요구 사항과 하드웨어 제약에 대한 정보를 서버에 적극적으로 전달할 수 있게 되었다.
- 쿠키 헤더에 보안 관련 접두사를 도입한으로써 보안 쿠키가 변경되지 않도록 보장하는데 도움이 되었다.
Alt-Svc 기능은 리소스의 URL과 실제로 리소스가 저장된 서버 위치를 분리할 수 있도록 한다.
이렇게 하면 콘텐츠를 더 효율적으로 캐싱하고 제공할 수 있다.
클라이언트 힌트는 사용자의 브라우저나 기기에서 서버로 필요한 정보(예 : 화면 크기, 네트워크 상태)를 보내고 서버가 이를 기반으로 최적화된 콘텐츠를 제공할 수 있게 한다.
새로운 보안 접두사를 사용하면 중요한 쿠키가 안전하게 보호되며 중간에 가로채거나 변조할 수 없게 된다.
이러한 확장 기능들은 HTTP 프로토콜을 더 안전하고 효율적으로 만들기 위해 도입되었다.
HTTP/3 QUIC를 통한 HTTP HTTP/3 HTTP over QUIC
HTTP의 다음 주요 버전인 HTTP/3은 이전 버전의 HTTP와 동일한 의미 체계를 가지고 있지만, 전송 계층 부분에 TCP 대신 QUIC를 사용한다.
2022년 10월까지 전체 웹사이트의 26%가 HTTP/3를 사용했다.
QUIC는 HTTP 연결에 대한 대기 시간을 크게 낮추도록 설계되었다.
HTTP/2와 마찬가지로 다중화된 프로토콜이지만, HTTP/2는 단일 TCP 연결을 통해 실행되므로 TCP 계층에서 처리되는 패킷 손실 감지 및 재전송이 모든 스트림을 차단할 수 있다.
QUIC는 UDP를 통해 여러 스트림을 실행하고 각 스트림에 대해 패킷 손실 감지 및 재전송을 독립적으로 구현하므로 오류가 발생하는 경우, 데이터가 있는 해당 스트림만 차단된다.
RFC 9114에 정의된 HTTP/3은 Chromium(및 Chrome과 Edge와 같은 변형)과 Firefox를 포함한 대부분의 주요 브라우저에서 지원된다.
Evolution of HTTP - HTTP | MDN
HTTP (HyperText Transfer Protocol) is the underlying protocol of the World Wide Web. Developed by Tim Berners-Lee and his team between 1989-1991, HTTP has gone through many changes that have helped maintain its simplicity while shaping its flexibility. Kee
developer.mozilla.org
'프론트엔드 > HTTP - 전' 카테고리의 다른 글
| Protocol upgrade mechanism (0) | 2024.09.12 |
|---|---|
| Connection management in HTTP/1.x (0) | 2024.08.24 |
| Basics of HTTP (0) | 2024.07.15 |
| Choosing Between www and non-www URLs (0) | 2024.06.23 |
| Common MIME types (0) | 2024.06.16 |
