[HTTP] 1. HTTP 의 역사

HTTP 역사

네트워크의 애플리케이션 계층에서 동작하는 애플리케이션 프로토콜 중 가장 잘 알려진 것이 HTTP (Hypertext Transfer Protocol) 이다. 웹 브라우저는 URL의 'http' 부분을 보고 액세스한다. HTTP 는 원래 텍스트 파일을 다운로드 하기위한 간소한 프로토콜이었다. 현재는 메시지뿐만 아니라 사진, 영상, 음성등의 파일 및 실시간 동영상 송출에 이르기 까지 수 많은 용도로 사용하고 있다.

1. HTTP/0.9

HTML (Hypertext Markup Language) 로 된 텍스트 파일을 서버로부터 다운로드를 하기위한 단순한 목적이었다.

2. HTTP/1.0

1996년에 RFC1945 Hypertext Transfer Protocol - HTTP/1.0 으로 표준화되었다. 텍스트 파일 외에도 동영상, 이미지 등 다양한 파일을 다룰 수 있게 되었고 다운로드뿐만 아니라 업로드나 삭제도 가능해졌다.

HTTP 메시지의 포맷이나 요청(Request), 응답(Response) 의 기본적인 구조도 이때 시작되었다.

다만, HTTP/0.9 와 HTTP/1.0은 요청마다 TCP 커넥션을 만들고 부수는 작업을 반복했다. 5개의 요청이 있으면 1번째 요청으로 TCP 커넥션을 만들어 응답을 받으면, 커넥션을 종료하고 다음 2번째 요청을위해 TCP 커넥션을 새로 만들었다. 이러한 방식은 작은 서비스에는 문제가 없겠지만 처리가 많아지면 서버에 막대한 부하가 걸리게 된다.

또한, 웹브라우저는 하나에 서버에 동시에 오픈가능한 TCP 커넥션 수가 정해져 있다.

3. HTTP 1.1

1997년에 RFC 2068 Hypertext Transfer Protocol - HTTP/1.1 으로 표준화 되어 1999년에 RFC 2616 으로 업데이트 되었다. keep-alive (지속적 연결), pipeline (파이프라인) 등 TCP 에서의 성능 향상을 목표로 하는 기능이 추가되었다.

현재 가장 많이 사용되고 있다.

keep-alive (지속적 연결)
한 번 만들어진 TCP 커넥션을 재사용하는 것이다.
5개의 요청이 있을때 1개의 TCP 커넥션으로 5개의 요청을 처리하는 것이다.
pipeline (파이프라인)
요청에 대한 응답을 기다리지 않고 다음 요청을 하는 기능이다.
그러나 현실에서는 기대한만큼 성능이 나오지 못했다. TCP 커넥션 안에서 요청과 응답을 병렬처리 할 수 없는 사양이어서 서버는 요청 받은 순서로 응답해야 했다. 구체적으로 5개의 요청을 연속해서 보낼때, 첫번째 요청 처리가 길어지면 병렬처리가 되지않아 두번째 요청에대한 응답도 반환되지 않았다. 이를 HoL 블로킹 (Head of Lock Blocking) 이라 하는데, 이것을 원인으로 크롬, 파이어폭스등 파이프라인이 비활성화되어 있다.

4. HTTP/2

구글이 개발한 SPDY(스피디) 라는 프로토콜을 기반으로 2015년 RFC7540 Hypertext Tranfer Protocol Version 2 로 표준화되었다. 이제까지 텍스트 형식으로 교환하는 데이터를 프레임(frame) 이라는 바이너리 형식 단위로 교환하여 오버헤드 감소와 성능 향상을 목표로 한다. 멀티플렉싱 이나 헤더 압축(HPACK), 서버푸시 등 TCP 뿐만 아니라 애플리케이션 에서도 성능향상을 목표로 한다.

점차 사용이 증가하고있다.

멀티플렉싱 (multiplexing)
HoL 블로킹 문제를 안고있던 HTTP/1.1 의 파이프라인을 대신해 추가된 기능
1개의 TCP 커넥션안에 스트림(stream) 이라는 가상 채널을 만들고, 스트림별로 요청과 응답을 교환하게 한다.
헤더 압축 HPACK
HTTP 헤더를 압축하는 기능
HTTP/1.1은 같은 내용의 헤더를 반복하여 교환하므로 낭비가 많아 헤더 전송량을 줄이는 것을 목표로 한다.
서버 푸시 (server push)
HTTP/1.1 까지 HTTP 는 하나의 요청에 대해 하나의 응답을 반환하는 풀 타입 프로토콜이다. 하나의 요청에 대해 여러 응답을 반환하는 푸시 타입 기능을 추가했다.
HTTP/2 서버는 클라이언트가 최초로 요청한 콘텐츠를 해석하고 다음에 올 요청에 대한 응답을 요청이 오기 전에 반환한다. 웹브라우는 그 응답을 캐시해두고 다음 요청이 오면 캐시영역에서 호출하여 속도 향상을 목표로 한다.
예를들어 index.html 이 abc.js 와 xyz.css 를 로딩하는 HTML이라고 하자. index.html 에 대한 요청 뒤에 abc.js 와 xyz.css 에대한 요청이 올 것을 예상할 수 있다. 서버는 abc.js, xyz.css 에대한 요청이 오기 전에 이를 응답한다. 웹브라우저는 그 응답을 캐시해두고 abc.js, xyz.css 의 요청에 대한 응답을 캐시영역에서 가져온다.

5. HTTP/3

구글이 개발한 QUIC(Quick UDP Internet Connections) 를 기반으로 IETF에서 RFC 표준화를 진행중이다. 애플리케이션 데이터를 보내지 않는 시간을 극단적으로 줄인 것으로 뛰어난 성능 향상을 목표로 한다.