HTTP의 진화

작성일 | In

[Network] HTTP의 진화

본 내용은 MDN HTTP 진화를 보고 공부, 정리한 내용입니다.

HTTP는 팀 버너스리에 의해 1989년 - 1991년에 발명되었다. 초기에는 Mesh 라고 불렸으며, 이후 개발 과정중에 World Wide Web (WWW) 으로 이름을 바꾸었다.

TCP/IP 프로토콜을 기본으로 총 4개의 기본 블럭으로 구성되어있다.

  • HTML
  • HTTP
  • 클라이언트 월드 와이드 웹 (브라우저)
  • httpd (서버)

초기에는 별다른 버전을 사용하지 않았지만, 후에 이와 같은 초기 HTTP를 HTTP /0.9 버전, 혹은 원-라인 프로토콜이라 명명했다.

HTTP /0.9 - 원 라인 프로토콜

초기 HTTP는 굉장히 단순하다. 단일 라인으로 연결되고 사용 가능한 메서드는 GET이 유일했다. HTTP request/response 메세지에는 헤더가 없고 내용만 존재했다. 아래는 HTTP /0.9의 HTTP request/response 메세지의 예시 형태이다.

1
2
3
4
5
6
7
// HTTP request
GET /mypage.html

// HTTP response
<html>
Simple HTML Page
</html>

현대 HTTP와는 다르게 요청 메세지에 버전 정보가 없고, 응답 메세지도 HTML 파일 내용 그 자체였다. 즉, HTML 파일 외에 다른 파일 전송을 지원하지 않았다는 이야기이다. 통신 시 에러가 발생해도 상태코드는 따로 정의되지 않았으며, 특정 HTML 파일이 사람이 이해할 수 있도록 해당 파일 내부에 문제에 대한 설명과 함께 클라이언트에게 전달되었다.

HTTP /1.0

HTTP /0.9가 굉장히 제한적이었으므로, 확장성을 높이기 위한 여러 개발자들의 시도가 빠르게 이루어졌고 이에 HTTP /1.0이 등장했다. HTTP /1.0이 HTTP /0.9와 달라진 점들은 아래와 같다.

  • 버전 정보가 각 요청에 포함된다.
  • 상태 코드가 각 응답의 시작 부분에 포함되어 브라우저가 해당 내용을 보고 대처할 수 있게 되었다.
  • HTTP 헤더 개념이 등장했다. 이는 서버, 브라우저의 메타데이터 전송을 허용하며 프로토콜을 유연, 확장 가능하게 만들었다.
  • 새로운 HTTP 헤더의 등장 (Content-Type) 으로 HTML 파일 이외의 다른 파일도 전송할 수 있게 되었다.

HTTP /1.0은 정식으로 출시되었다기보단, 일단 적용해보고 상황을 지켜보는 형태로 사람들 사이에 사용되기 시작했다. 여기서 상호 운용성의 문제가 많이 일어났다.

(*상호 운용성은 하나의 시스템이 동일 혹은 이종의 시스템과 아무 문제없이 잘 상호작용함을 뜻한다.)

HTTP /1.1

HTTP /1.0이 구현 중에 있을 때, 이 내용을 토대로 HTTP에 대한 표준화가 진행되고 있었다. HTTP /1.0이 나온지 몇 달 뒤 HTTP 표준인 HTTP /1.1이 등장했다. (1997년 1월 RFC 2068)

HTTP /1.1에선 HTTP /1.0 까지의 내용들 중 모호한 기능을 명확하게 하고 많은 개선사항들을 적용했다.

(자세한 개선 내용은 여기에서 확인할 수 있다.)

HTTP /1.1은 극도의 안정성으로 긴 시간동안 새 버전의 출시 없이 확장되어왔다. 어떤 부분에서 발전이 이루어졌는지를 살펴보자.

HTTP의 보안

HTTP는 기본적으로 TCP/IP를 이용한 프로토콜이므로 취약성 문제가 존재했다. 이에 넷스케이프 커뮤니케이션즈에서 SSL(Secure Sockets Layer)이라는 암호화된 전송 계층을 만들어냈다.

SSL 2.0과 3.0, 3.1을 통해 e커머스 웹 사이트들이 등장하고 성장할 수 있었다. SSL의 차세대 프로토콜이 TLS(Transport Layer Security) 란 이름으로 등장했고, 현재 1.2 버전까지 상용화 되어 있으며 1.3 버전이 개발중에 있다.

  • 참고로 https 프로토콜이 TLS 계층이 추가된 http 프로토콜이다.

복잡한 웹 애플리케이션의 HTTP

1996년 즈음, HTTP가 authoring이 가능해지면서 WebDAV (Web-based Distributed Authoring and Versioning) 표준이 등장했다. WebDAV란 웹서버에 HTML파일 말고도 다른 파일들을 조회, 수정, 저장, 삭제 할 수 있는 확장된 HTTP 를 말한다. 대표적으로 웹하드디스크, CardDAV (전화번호부 개체), CalDAV (달력 개체) 등이 있다.

WebDAV의 단점은 서버 측에서 모든 구현이 이루어졌는데, 매우 복잡한 구현 과정이 필요했다. 아울러 해당 내용은 기밀이 되어 다른 사람들은 그 기술에 접근하지 못했다.

2000년에 HTTP를 이용한 새로운 패턴인 REST (Representational State Transfer) 가 등장했다. 이 패턴은 HTTP의 새로운 커스텀 헤더가 필요하지 않고, 그저 REST 형식에 맞는 URI에 접근하기만 하면 HTTP /1.1에서도 원활하게 적용 가능했다. 이에 웹 애플리케이션은 서버 혹은 브라우저의 갱신 없이 데이터 탐색, 수정을 허용하는 API 제공이 가능했다. 또한 *DAV 패턴과 다르게 REST API는 서버와 클라이언트의 상호작용이 가능했다. REST 모델의 단점은 각 서버마다 자기만의 RESTful API를 정의하고 서버가 그에대한 전권을 갖는다는 점이다.

HTTP /2

HTTP /1.1이 굉장히 유연하고 확장성이 좋지만, TCP/IP 프로토콜을 기반으로 하면서 기본적으로 연결 당 하나의 요청을 처리하도록 설계되었기 때문에 여러 단점이 존재한다.

  • HTTP /1.x는 3가지 연결 모델을 지원한다. 자세한 내용은 여기를 통해 확인할 수 있다.

HTTP /1.1의 단점

1. HTTP HOL(Head Of Line) Blocking

HTTP는 한 연결 당 하나의 요청을 처리하도록 설계되어 있어서, 여러 요청을 처리하는데 단점이 있다. 이를 해결하기 위한 방법으로 파이프라이닝이 존재하지만, 기본적으로 요청과 응답을 동기화하기 위해 FIFO로 응답이 전송되어야 한다. 즉, 서버로 먼저 온 요청의 응답이 지연되면, 뒤이은 요청들의 응답도 덩달아 지연된다. 이를 HTTP의 HOL Blocking이라 한다.

  • 참고로 HOL Blocking은 컴퓨터 네트워크에서 두루 사용되는 용어로 첫 번째 패킷에 의해 패킷 라인이 유지되고, 이 때문에 벌어지는 뒤이은 패킷들의 지연 현상을 일컫는다. TCP HOL Blocking도 존재하며 이는 HTTP /2의 단점 중에 하나이다.

2. 불필요한 RTT(Round Trip Time)

HTTP는 기본적으로 한 연결 당 하나의 요청을 처리하고, 연결을 끊는다. 위에서 언급한 파이프라이닝 말고도 HTTP /1.x는 클라이언트와 서버 간 영속적인 연결을 지원하지만, 이러한 연결 모델들의 사용이 어려울 경우 요청 하나당 하나의 연결이 계속해서 만들어지고 끊어진다. 즉, 요청 하나 당 3-way hand shaking이 계속된다는 뜻이고, 이는 많은 자원적 낭비를 야기한다.

SPDY, HTTP /2의 등장

이와 같은 문제점들로 인해 구글에서 2010년 전반기에 SPDY (Speedy의 약자) 프로토콜을 구현하여 공개했다. 이는 HTTP /1.1의 통신 지연 등의 단점을 보완했고, SPDY를 기반으로 2015년 HTTP /2가 공개되었다. HTTP /2가 HTTP /1.1과 달라진 점은 아래와 같다.

  • 텍스트 프로토콜이 아닌 이진 프로토콜이 되었다. 즉, 수동적으로 조작될 수 없지만 처리 속도가 더 빠르므로 이와 관련한 최신 기술의 등장을 기대할 수 있다.
  • HTTP /1.1에서 걸림돌이 되었던 요청, 응답간의 동기화를 위한 제약을 없애 각각의 요청, 응답을 동시에 처리할 수 있다.
  • 연속된 요청에는 중복된 헤더 내용이 많다. 이를 압축하여 데이터 중복에 의한 전송 오버헤드를 줄였다.
  • 클라이언트의 요청을 예상하여 클라이언트 캐쉬에 클라이언트가 요청할 것 같은 데이터를 넣어두는 서버 푸쉬 기술이 등장했다.
0%