프로토콜의 버전

SuweonPark·2024년 5월 16일

프로토콜 버전

오늘날 쓰이고 있는 HTTP 프로토콜은 버전이 여러 가지다. HTTP 프로토콜의 여러 변형을 모두 잘 다루려면 HTTP 애플리케이션이 일을 열심히 해야 한다. 그 버전들이란 다음과 같다.

1. HTTP/0.9

1991년의 HTTP 프로토타임은 HTTP/0.9로 알려져 있다. 이 프로토콜은 심각한 디자인 결함이 다수 있고 구식 클라이언트하고만 같이 사용할 수 있다. HTTP/0.9는 오직 GET 메서드만 지원하고, 멀티미디어 콘텐츠에 대한 MIME 타입이나, HTTP헤더, 버전 번호는 지원하지 않는다. HTTP/0.9는 원래 간단한 HTML 객체를 받아 오기 위해 만들어진 것이다. HTTP/0.9는 금방 HTTP/1.0으로 대체되었다.

HTTP 초기 버전에는 버전 번호가 없었습니다. HTTP/0.9는 이후 버전과 구별하기 위해 0.9로 불리게 됐습니다. HTTP/0.9는 극히 단순합니다. 요청은 단일 라인으로 구성되며 리소스에 대한 경로로 가능한 메서드는 GET이 유일했습니다. 서버에 연결되면 프로토콜, 서버 및 포트가 필요하지 않으므로 전체 URL은 포함되지 않았습니다.

GET /mypage.html

응답 또한 극도로 단순합니다. 오로지 파일 내용 자체로 구성됩니다.

<html>
  A very simple HTML page
</html>

2. HTTP/1.0

1.0은 처음으로 널리 쓰이기 시작한 HTTP 버전이다. HTTP/1.0은 버전 번호, HTTP헤더, 추가 메서드, 멀티미디어 객체 처리를 추가했다. HTTP/1.0은 시각적으로 매력적인 웹페이지와 상호작용하는 폼을 실현했고 이는 월드 와이드 웹을 대세로 만들었다. HTTP/1.0은 결코 잘 정의된 명세가 아니다. HTTP가 상업적, 학술적으로 급성장하던 시기에 만들어진, 잘 동작하는 용례들의 모음에 가깝다.

각 요청 안에 버전 정보가 포함되어 전송되었습니다(HTTP/1.0 이 GET 라인에 붙은 형태).
상태 코드 라인 또한 응답의 시작 부분에 붙어 전송되었습니다. 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작(예, 특정 방법으로 로컬 캐시를 갱신하거나 사용)을 할 수 있게 되었습니다.
HTTP 헤더 개념은 요청과 응답 둘 다 도입되어, 메타데이터 전송이 가능해졌고, 프로토콜이 극도로 유연하고 확장성이 높아졌습니다.
Content-Type 덕분에, 일반 HTML 파일들 외에 다른 문서들을 전송할 수 있었습니다.

다음은 일반적인 요청과 응답입니다:

GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

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)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

3. HTTP/1.0+

1990년대 중반, 월드 와이드 웹이 급격히 팽창하고 상업적으로도 성공하면서 여러 유명 웹 클라이언트와 서버 들은 그에 따른 요구를 만족시키기 위해 발 빠르게 HTTP에 기능을 추가해갔다. 오래 지속되는 "keep-alive" 커넥션, 가상 호스팅 지원, 프락시 연결 지원을 포함해 많은 기능이 공식적이진 않지만 사실상의 표준으로 HTTP에 추가되었다. 이 규격 외의 학장된 HTTP 버전을 흔히 HTTP/1.0+라고 부른다.

여기서 "keep-alive"란 persistent connection을 맺는 기법 중 하나로, HTTP/1.0+부터 지원하고 있다. 하나의 TCP connection을 활용해서 여러개의 HTTP request/response를 주고 받을 수 있도록 해준다. keep-alive옵션은 설게쌍 여러 문제점(proxy 문제)이 생기면서 HTTP/1.1부터 사용되고 있지 않지만 여전히 많은 웹 어플리케이션에서 사용하고 있기 때문에 있다.
기본적으로 HTTP/1.1은 persistent connection을 지원하는 반면에 HTTP/1.0 connection은 하나의 request에 응답할 때마다 connection을 close하도록 설정돼있다.

4. HTTP/1.1

HTTP/1.1은 HTTP 설계의 구조적 결함 교정, 두드러진 성능 최적화, 잘못된 기능 제거에 집중했다. 뿐만 아니라 HTTP/1.1은 더 복잡해진 웹 어플리케이션과 배포(1990년대 후반에 이미 쓰이고 있었다)를 지원한다. HTTP/1.1은 현재의 HTTP 버전이다.

HTTP/1.1은 모호함을 명확하게 하고 많은 개선 사항들을 도입했습니다.

연결을 재사용할 수 있어 시간이 절약됩니다. 단일 원본 문서 내로 포함된 리소스들을 표시하기 위해 더 이상 여러 번 연결을 열 필요가 없기 때문입니다.
파이프라이닝을 추가하여, 첫번째 요청에 대한 응답이 완전히 전송되기 전에 두번째 요청 전송을 가능케 하여, 통신 지연 시간이 단축되었습니다.
청크된 응답도 지원되었습니다.
추가적인 캐시 제어 메커니즘이 도입되었습니다.
언어, 인코딩 혹은 타입을 포함한 컨텐츠 협상이 도입되어, 클라이언트와 서버로 하여금 교환하려는 가장 적합한 컨텐츠에 대한 합의를 할 수 있습니다.
Host 헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 기능이 서버 배치가 가능해졌습니다.

다음은 하나의 단일 커넥션을 통한 요청의 전형적인 전체 흐름의 예시입니다.

GET /en-US/docs/Glossary/Simple_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/Simple_header

200 OK
Connection: Keep-Alive
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/Simple_header

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 사용

HTTP에 일어났던 가장 큰 변화는 1994년 말에 이루어졌습니다. 컴퓨터 서비스 회사인 Netscape Communications는 기본 TCP/IP 스택을 통해 HTTP를 전송하는 대신에, TCP/IP 스택 위에 추가적인 암호화된 전송 계층인 SSL을 만들어냈습니다. SSL 1.0은 대중에게 비공개였고, SSL 2.0과 후속 버전인 SSL 3.0을 통해 전자 상거래 웹사이트를 만들 수 있었습니다. 이를 위해서 서버와 클라이언트 간에 교환되는 메시지의 신뢰성을 암호화하고 보장했습니다. SSL은 결국 표준화되어 TLS가 되었습니다.

같은 기간에, 암호화된 전송 계층에 대한 필요하다는 것이 분명해졌습니다. 웹은 더 이상 학문적인 네트워크가 아니라, 광고주, 불특정 개인 혹은 범죄자가 가능한 한 많은 개인정보 데이터를 놓고 경쟁하는 정글이 되었습니다. HTTP를 통해 구축된 애플리케이션이 더욱 강력해지고 주소록, 이메일 혹은 사용자의 지리적 위치와 같은 수 많은 개인 정보에 접근하는 부분이 필요해짐에 따라, 전자 상거래 이외의 경우에서도 TLS에서 필요해졌습니다.

복잡한 애플리케이션을 위한 HTTP 사용

Tim Berners-Lee는 원래 HTTP를 읽기 전용 도구로 생각하지 않았습니다. 그는 사람들이 문서를 원격으로 추가하거나 이동시킬 수 있는, 분산된 파일 시스템의 한 종류로 웹을 만들고 싶었습니다. 1996년경에 HTTP는 저작을 허용하도록 확장되었으며 WebDAV(Web Distributed Authoring and Versioning, 웹 분산 저작 및 버전 관리)라고 불리는 표준이 만들어졌습니다. WebDAV는 주소록 항목들을 다루기 위한 CardDAV 및 달력을 다루기 위한 CalDav와 같은 특정 애플리케이션들로 더 확장되었습니다. 그러나 이런 모든 *DAV 확장들은 한 가지 결함이 있었는데, 서버에서 구현된 경우에만 사용할 수 있었습니다.

2000년에, HTTP 사용에 대한 새로운 패턴인 representational state transfer (또는 REST)가 설계가 되었습니다. API는 새로운 HTTP 메서드를 기반으로 하지 않았지만, 대신 기본 HTTP/1.1 메서드를 사용하여 특정 URI에 대한 접근에 의존했습니다. 이를 통해 모든 웹 애플리케이션에서 API가 브라우저나 서버를 업데이트하지 않고도 데이터를 검색하고 수정할 수 있게 되었습니다. 필요한 모든 정보는 웹 사이트가 표준 HTTP/1.1을 통해 제공되는 파일에 포함되었습니다. REST 모델의 단점은 각 웹사이트가 자체 비표준 RESTful API를 정의하고 이를 완전히 제어할 수 있다는 것입니다. 이는 클라이언트와 서버가 상호 운용 가능한 *DAV 확장과 차이가 있습니다. RESTful API들은 2010년에 들어 매우 보편화되었습니다.

RESTful 이란

HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스이다. 기본적으로 개발자는 HTTP 메소드와 URI 만으로 인터넷에 자료를 CRUD 할 수 있다.
'REST API'를 제공하는 웹 서비스를 'RESTful' 하다고 할 수 있다.
RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것은 아니다.

RESTful API 개발 원칙

a. 자원을 식별할 수 있어야 한다.

URL (Uniform Resource Locator) 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다. 자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미이다.
Server가 제공하는 정보는 JSON 이나 XML 형태로 HTTP body에 포함되어 전송 시킨다.

b. 행위는 명시적이어야 한다.

REST는 아키텍쳐 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제적이지 않다. 기존의 웹 서비스 처럼, * GET을 이용해서 UPDATE와 DELETE를 해도 된다.
다만 REST 아키텍쳐에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.

c. 자기 서술적이어야 한다.

데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 어플리케이션을 실행 해야 하는지를 알 수 있어야 한다.
즉, 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다

d. HATEOS (Hypermedia as the Engine of Application State)

클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.
REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어줄 것이 필요하다.
이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼 링크를 제공한다.
클라이언트는 이 하이퍼 링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리 할 수 있게 한다.

2005년 이후 웹 페이지에서 사용 가능한 API를 사용할 수 있게 되었습니다. 이 API 중 일부는 특정한 목적을 위해 HTTP 프로토콜에 확장을 생성합니다.

서버 전송 이벤트, 서버가 브라우저로 가끔 메시지를 푸쉬할 수 있습니다.
웹소켓은 기존 HTTP 연결을 업그레이드하여 만들 수 있는 새로운 프로토콜입니다.

웹의 보안 모델 완화

HTTP는 동일 출처 정책으로 알려진 웹 보안 모델과는 독립되어 있습니다. 사실, 현재의 웹 보안 모델은 HTTP이 만들어진 이후에 개발되었습니다! 몇 년에 걸쳐, 특정 제약 조건을 두고, 이 정책의 일부 제한 사항을 해제하는 것이 유용한 것으로 입증되었습니다. 서버는 새로운 HTTP 헤더 세트를 사용하여 이러한 제한을 언제, 얼마나 해제해야 하는지 클라이언트에 전송했습니다. 교차 출처 리소스 공유 (CORS) 및 컨텐츠 보안 정책 (CSP)과 같은 명세 안에 정의되었습니다.

큰 확장 외에, 다른 많은 헤더들이, 때로는 실험적으로만, 추가되었습니다. 주목할 만한 헤더는 프라이버시를 제어하기 위한 Do Not Track (DNT) 헤더, X-Frame-Options, 혹은 Upgrade-Insecure-Requests이 있지만, 더 많은 헤더들이 존재합니다.

5. HTTP/2.0

HTTP/2.0은, HTTP/1.1 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜을 기반으로 설계가 진행 중인 프로토콜이다.

몇 년에 걸쳐, 웹 페이지는 더욱 복잡해졌습니다. 일부는 그 자체로 애플리케이션이기도 했습니다. 더 많은 시각적 미디어가 표시되고 상호작용을 위한 스크립트 코드의 양과 크기도 증가했습니다. 훨씬 더 많은 HTTP 요청을 통해, 많은 데이터가 전송되었고, 이를 통해 HTTP/1.1 연결에 복잡성과 오버헤드가 많이 발생했습니다. 이를 설명하기 위해, Google은 2010년 초반에 실험적인 프로토콜 SPDY를 구현했습니다. 클라이언트와 서버 간 데이터를 교환하는 이 대체 방법은 브라우저와 서버 모두에서 작업하는 개발자들의 관심을 끌었습니다. SPDY는 응답성 증가를 정의하고 중복 데이터 전송 문제를 해결하여 HTTP/2 프로토콜의 기반이 됩니다.

HTTP/2 프로토콜은 HTTP/1.1과 몇가지 특징이 다릅니다.

텍스트 프로토콜이 아닌 이진 프로토콜입니다. 읽을 수도 없고 수동으로 만들 수 없습니다. 이러한 장애물에도 불구하고, 향상된 최적화 기술을 구현할 수 있습니다.
다중화 프로토콜입니다. 동일한 연결을 통해 병렬 요청을 수행할 수 있어, HTTP/1.x 프로토콜의 제약을 없애줍니다.
헤더를 압축합니다. 요청 집합 간에 유사한 경우가 많으므로, 전송된 데이터의 중복과 오버헤드가 제거됩니다.
서버가 서버 푸시라는 메커니즘으로 클라이언트 캐시에 데이터를 저장할 수 있습니다.

2015년 5월에 공식적으로 표준화된 HTTP/2는 2022년 1월 전체 웹 사이트의 46.9%로 사용량 정점에 도달했습니다(these stats 참조). 트래픽이 많은 웹사이트는 데이터 전송 오버헤드와 그에 따른 예산을 절약하기 위한 노력의 일환으로 가장 빠르게 채택되었습니다.

HTTP/2가 웹사이트와 애플리케이션을 변경할 필요가 없었기 때문에 빠른 채택이 가능했을 확률이 높습니다. 이를 사용하려면, 최신 브라우저와 통신하는 최신 서버만 필요했습니다. HTTP/2 채택을 높이기 위해서는 제한된 그룹 집합만 필요했고, 레거시 브라우저와 서버 버전이 갱신되면서 웹 개발자의 큰 노력 없이도 자연스럽게 사용량이 늘어났습니다.