HTTP의 진화

월드 와이드 웹의 발명

1990년에 팀 버너스 리에 의해 만들어졌다. TCP/IP 프로토콜 상에서 만들어진 월드 와이드 웹은 HTML, HTTP, 월드 와이드 웹이라고 불리는 브라우저, 문서에 접근하게 해주는 httpd의 초기 버전으로 구성되어 있다.

HTTP/0.9: 원-라인 프로토콜

HTTP 초기 버전은 매우 단순했다. GET이 유일한 메서드였고, 요청은 단일 라인으로 구성되어 있었다. 응답은 오로지 파일 내용으로 구성되었다. HTML 문서만이 전송 가능했다(HTTP 헤더 없음)

GET /mypage.html

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

HTTP/1.0

요청 시 버전 정보 기재
응답 시 상태 코드 기재: 브라우저가 요청한 결과에 대한 대처할 수 있게 됨
HTTP 헤더 도입
- 메타데이터 전송 허용
- 프로토콜을 유연하고 확장 가능하게 만듦
- Content-Type 헤더: HTML 외 다른 문서 전송 가능

HTTP/1.1: 표준 프로토콜

커넥션 재사용 가능
- 탐색된 단일 원본 문서에 임베디드된 리소스를 보여주기 위해 사용된 커넥션을 재사용하여 시간 절약
파이프라이닝 추가
- 첫번째 요청에 대한 응답이 완전히 전송되기 전에 두번재 요청 전송을 가능하게 함
청크된 응답 지원
캐시 제어 메커니즘 도입
컨텐츠 협상 도입(언어, 인코딩, 타입 포함)
- 클라이언트와 서버가 교환하려는 적합한 컨텐츠를 동의할 수 있게 함
Host 헤더: 동일 IP 주소에 다른 도메인을 호스트 하는 기능이 서버 colocation 가능하게 함

HTTP/1.1 이후 확장

15년 동안 확장을 거듭해왔다.

보안 전송을 위한 HTTP 사용

이에 기본적인 TCP/IP 스택을 통해 HTTP를 전송하는 것을 넘어 그 토대 위에 추가적인된 전송 계층인 SSL가 자리잡게 되었다. SSL 2.0과 3.0, 3.1은 서버와 클라이언트 간 교환된 메시지 인증을 암호화하고 보장해서 e-commerce 웹 사이트의 등장을 가능하게 했다. SSL은 TLS가 되었고, 1.0, 1.1, 1.2 버전이 나와 있다. 암호화된 전송 계층은 e-commerce 외의 상황에도 반드시 필요하다. 광고주, 불특정 개인, 범죄자가 다른 사람인 척 가장하거나 전송된 데이터를 수정된 데이터로 대치시키려고 개인 정보를 빼내려 하기 때문이다.

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

초기 HTTP는 읽기 전용(GET)이었지만, 팀 버너스 리는 이를 넘어 문서를 원격으로 추가하거나 이동시킬 수 있는 분산된 파일 시스템의 일종으로 웹을 상상했다. 그러나 2000년 이전까지 웹 영역에서 이러한 사용은 불가능했다. 2000년에 REST API는 웹 애플리케이션이 브라우저나 서버의 갱신 없이 데이터 탐색과 수정을 허용하게 하였다. REST 모델은 표준이 있는 게 아니라 각각의 웹사이트가 자신의 비표준 RESTful API를 정의하고 그에 대한 전권을 가진다는 것이다. 2005년부터 웹 페이지에서 사용 가능한 API 집합들이 급격히 늘어나게 되었고, 서버 전송 이벤트, 웹 소켓 같은 몇몇은 특성화된 HTTP 헤더로 특정한 목적을 위해 HTTP 프로토콜에 확장을 만들어냈다.

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍어의 한 형식이다. 클라이언트/서버 구조, Stateless, Cachable, Layered System, Code on demand, 인터페이스 일관성의 6가지 제한 조건이 적용된다.

서버 전송 이벤트: 서버가 브라우저로 이따금씩 보내는 메시지를 푸쉬할 수 있는 곳

웹 소켓: 기존 HTTP 커넥션을 업그레이드하여 만들 수 있는 새로운 프로토콜

웹의 보안 모델 강화

HTTP는 웹 보안 모델인 same-origin 정책에서 독립되어 있다. same-origin 정책은 제약사항 아래 허용된다. 제약사항이 얼마나 그리고 언제 리프트될 지는 HTTP 헤더를 사용하는 서버로부터 클라이언트에 의해 전도된다

HTTP/2: 더 나은 성능을 위한 프로토콜

HTTP/1.1의 단점

웹 페이지가 복잡해지면서 디스플레이되는 시각 미디어의 양과 함께 상호작용을 추가하기 위한 스크립트는 더 커졌다. 따라서 더 많은 데이터들이 더 많은 요청 너머로 전송되고 있다. 그그러나 HTTP/1.1 커넥션에서 요청은 순차적이어야 한다. 병렬 커넥션이 이론적으로 사용 가능하다 하여도 여전히 많은 양의 오버헤드와 복잡도라는 문제가 남아 있다. 이에 Google은 SPDY 프로토콜을 구현해 클라이언트와 서버 간의 데이터 교환을 대체할 수단을 증명하였다. 이것은 HTTP/2 프로토콜의 기초가 된다.

HTTP/2의 차별성

텍스트 프로토콜이라기보다는 이진 프로토콜이다. 읽을 수도 수작업을 만들 수 도 없다. 그러나 이로 인해 새로운 최적화 기술이 구현될 수 있다는 장점이 있다.
병렬 요청이 동일한 커넥션 상에서 다루어질 수 있는 다중화 프로토콜이다.
전송된 데이터의 분명한 중복과 그런 데이터로부터 유발된 오버헤더를 제거한다
- 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축시킨다.
서버로 하여금 사전에 클라이언트 캐시를 서버 푸쉬라고 불리는 매커니즘에 의해 필요하게 될 데이터로 채워넣게 한다.

오버헤드란? 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간, 메모리 등을 말한다.

파이프라인이란? 데이터 처리 단계의 출력이 다음 단계의 입력으로 이어지는 형태로 연결된 구조를 말한다. 이렇게 연결된 데이터 처리 단계는 여러 단계가 서로 동시에, 또는 병렬적으로 수행될 수 있어 효율성의 향상을 꾀할 수 있다.

Alt-Svc 지원: 더 나은 CDN 메커니즘을 따라 신분 증명의 개념과 주어진 자원의 위치를 분리하도록 해준다.
Client-Hints: 브라우저 혹은 클라이언트가 요구사항이나 서버의 하드웨어 제약사항에 대한 정보를 사전에 미리 주고받을 수 있게 되었다.
Cookie 내 보안 관련 접두사 도입

참조

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP

💻 HTTP #5: HTTP의 진화

HTTP의 진화

월드 와이드 웹의 발명

HTTP/0.9: 원-라인 프로토콜

HTTP/1.0

HTTP/1.1: 표준 프로토콜

HTTP/1.1 이후 확장

보안 전송을 위한 HTTP 사용

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

웹의 보안 모델 강화

HTTP/2: 더 나은 성능을 위한 프로토콜

HTTP/1.1의 단점

HTTP/2의 차별성

참조

Trending Tags

💻 HTTP #5: HTTP의 진화

HTTP의 진화

월드 와이드 웹의 발명

HTTP/0.9: 원-라인 프로토콜

HTTP/1.0

HTTP/1.1: 표준 프로토콜

HTTP/1.1 이후 확장

보안 전송을 위한 HTTP 사용

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

웹의 보안 모델 강화

HTTP/2: 더 나은 성능을 위한 프로토콜

HTTP/1.1의 단점

HTTP/2의 차별성

참조

Further Reading

💻 HTTP #4: 교차 출처 리소스 공유(CORS)

💻 HTTP #6: HTTP 메시지

💻 HTTP #7: HTTP 압축

Trending Tags