HTTP(Hyper Text Transfer Protocol)는 우리가 아는 현재의 인터넷 환경을 만들었다 라고 해도 전혀 부족함이 없을 것이다.
아니 HTTP가 있었기에 현재의 인터넷 환경이 탄생하고 발전하게 되었다고 하는 게 맞을 것이다.
애플리케이션 프로토콜인 HTTP는 1989년 WWW(World Wide Web)의 창시자 팀버너에 의해 제안 되었다.
인터넷 발전에 대한 요구가 증가하면서, HTTP는 최상의 성능을 제공하기 위해 지속적으로 발전해야만 했다.
초창기 HTTP는 수 많은 개편 과정을 거쳤으며, 1997년에 HTTP/1.1이 첫 번째 표준이 되었다.
1997년 HTTP/1.1은 표준으로 선정되면서 HTTP/2가 등장하기까지 무려 18년동안 꾸준히 사용되어 왔다.
현재 웹을 이용하는 많은 사용자들은 좀 더 화려하고, 멋진 홈페이지 서비스를 기대한다. 웹이 이미 생활의 대부분을 차지하게 된 요즘 이러한 사용자의 요구는 시간이 흐를수록 증가할 것이라는 건 너무도 자명한 일이다.
HTTP/1.1은 이러한 시대적 요구를 수용하기에는 현재 너무 버거운 상태이다.
18년 동안의 큰 사랑을 받아온 HTTP/1.1 이 HTTP/2에게 바톤을 넘겨야 할 시점이 온 것이다.
여기서는 HTTP/1.1 의 제약사항이 무엇이며 이를 극복하기 위해 HTTP/2 가 어떻게 바뀌었는지? 앞으로 HTTP/2가 풀어야 할 숙제는 무엇인지 등을 살펴보기로 한다.
# 1991年 - HTTP/0.9
HTTP 의 첫 번째 프로토콜인 HTTP/0.9 는 단일 라인(One-line) 프로토콜로 불렸다.
사실 HTTP 초기 버전에는 버전 넘버가 부여되지 않았다. HTTP/1.0 이후 초기 버전을 구분하기 위해 0.9로 표시하고 있다.
단일 라인 프로토콜인 HTTP/0.9 는 다음과 같은 특징이 있다.
- 요청만으로 구성되며 요청 Method 는 오직 GET 만 지원
- 요청은 오직 단일 라인으로 되어 있으며, Method 다음에 요청 URL이 따른다.
- 응답은 엄청 심플하며, 응답 바디로만 구성됨
- 오로지 HTML 문서만 전송 가능
- HTTP 헤더 및 상태/에러 코드는 존재 하지 않음.
지금의 인터넷 환경을 기준으로 HTTP/0.9를 바라보면 매우 초라해 보이지만, WWW를 탄생 시켰다는 점에서 보면 가장 훌륭한 프로토콜로 평가할 수도 있겠다.
무(無)에서 유(有)를 창조하기가 정말 어려운 것처럼...
# 1996年 - HTTP/1.0
HTTP/0.9 는 단순 HTML 문서만 열람하기 위한 프로토콜이어서, 이에 대한 지원 범위를 확장할 필요성이 생겼다.
초기 HTTP 프로토콜의 지원 범위를 확장하고, 실제 인터넷 서비스를 가능케 하기 위해 다음과 같이 몇가지의 주요 내용이 변경된다.
- 요청과 응답에 필요한 정보를 담은 HTTP 헤더를 추가함
- 다중 헤더 정보를 식별하기 위해 헤더와 헤더 사이는 줄바꿈(CRLF)으로 구분함.
- 버전 정보가 요청과 응답에 포함됨.
- 응답에 상태/에러 코드를 추가함.
- Content-Type의 헤더를 통해 HTML 외 다양한 컨텐츠를 지원하게 됨.
HTTP/1.0 의 요청과 응답은 다음과 같다.
HTTP/1.0 의 내용이 결정되기 까지 여러 논의가 진행되었으나, 뭔가 과정이 체계적이진 못했다고 한다.
논의 주체들간의 이견들이 분명 있었을테고 이를 조율해 가는 과정이 순탄치 않았던 것으로 보인다.
이런 문제점을 해소하기 위해 "HTTP 워킹 그룹"이 만들어졌고, RFC 1945 가 잘 정리되면서 1996년 5월 HTTP/1.0 이 릴리즈 되었다.
다만, HTTP/1.0 (RFC 1945) 은 논의되었던 내용들의 정보를 제공하는 목적의 문서이며, 그래서 공식적으로 HTTP 인터넷 표준(Internet Standard)은 아니었다.
표준 재정 여부와 무관하게 HTTP/1.0 의 등장으로 이때부터 브라우저를 통한 웹이 본격적으로 시작되었다고 할 수 있다.
# 1997年 - HTTP/1.1
HTTP/1.0 이 발표되고 불가 1년이 지나지 않았는데, HTTP/1.1(RFC 2068) 이 공식적으로 릴리즈 되었고, 이것이 HTTP 의 공식적인 첫 번째 인터넷 표준이다.
HTTP/1.0 의 발표가 1996년 5월 이었고, HTTP/1.1 이 1997년 1월이니 HTTP/1.0의 수명은 7개월이었던 셈이다.
좀 더 정확히 이야기 하면 HTTP/1.1은 1997년 1월 발표 후 성능적 향상을 많이 개선하면서 1999년 1월 RFC 2616 으로 업그레이드 되었다.
우리가 현재 사용중인 HTTP/1.1은 RFC 2616 에 기본을 두고 있다고 하겠다.
그렇다면 왜 HTTP/1.0 발표 후 HTTP/1.1 을 급하게 추진하였을까?
HTTP/1.0 의 제약 사항이 많이 복잡화 되고, 다양한 컨텐츠 기반의 웹서비스를 제공하기에 좀 부족한 부분이 있기 때문이다.
그 내용은 아래와 같다.
- 하나의 TCP 커넥션 당 1개의 컨텐츠만 요청이 가능
- 하나의 IP 에 여러 도메인 서비스가 불가능
위 2가지 사항이 핵심적인 내용인데 이 중에서 TCP 커넥션 당 1개의 컨텐츠만 요청할 수 있는것이 가장 큰것으로 보인다.
이 이야기는 하나의 페이지에 20개의 컨텐츠가 있다면 브라우저는 이를 화면에 보여주기 위해 20개의 TCP 커넥션을 필요하다는 이야기가 된다.
서버와 클라이언트에게 모두 부담이 되는 사항인것이다.
그리하여 릴리즈된 HTTP/1.1을 보면 아래 내용들을 지원하고 있다.
- 세션 유지(Persist) 와 파이프라이닝(Pipelining)
- Host 헤더 지원을 통한 Virtual Hosting
- 청크(Chunked) 전송, 압축과 해제, 캐싱 관련 directives 추가
- 클라이언트 식별과 쿠키 등..
아래는 HTTP/1.1 의 요청과 응답이다.
HTTP/1.0 과는 달리 연결 유지 (Persistence) 를 통해 하나의 TCP 세션에 2개의 컨텐츠를 요청하여 받은 경우이다.
# HTTP/1.1의 문제점
인터넷이 발전함에 따라 지금까지 웹사이트는 점점 커졌고 복잡해졌다.
아래 그래프는 2010년 11월 ~ 2021 5월까지의 페이지의 전체 사이즈 추이를 나타낸 것인데..
데스크톱 이용자를 위한 페이지는 4.5배 늘었고, 모바일 이용자를 위한 페이지는 13.4 배 커진것을 볼 수 있다.
최근 홈페이지의 FCP (first contentful paint)는 데스크톱 이용자의 경우 2.2초, 모바일 이용자의 경우 5초가 소요되는 것으로 조사된다.
FCP는 웹페이지의 접속 시 첫번째 컨텐츠가 뜨기까지 소요되는 시간을 의미한다.
이용자들은 FCP 가 긴 경우 페이지 접속을 멈추고 다른 웹사이트로 방문할 가능성이 커진다고 한다.
알려져 있기를 웹사이트에 사용자들이 오래 머물게 하려면 컨텐츠의 질도 중요하겠지만 FCP 가 1초 미만이 되어야 한다고 한다.
FCP를 낮추기 위해서는 HTTP/1.1 로는 더 이상 힘들어졌다.
HTTP/1.1 이 가지고 있는 아래 제약사항들 때문이다.
- 프로토콜 자체의 부하
- TCP 프로토콜의 한계 (slow start)
- PIPELINING 의 비현실적 적용 환경 및 HOLB 문제점
- 순차적인 요청/응답 환경
위 내용에 대해서는 다음 포스팅에서 상세히 다뤄보겠다.
# 2015年 - HTTP/2
위 내용에서 다룬 HTTP/1.1 의 문제점을 획기적으로 개선한 프로토콜이 2015년에 등장했다.
HTTP/2는 2009년 구글이 HTTP/1.1 의 문제점을 해결하고자 먼저 시작한 SPDY 를 모태로 한다.
SPDY 는 다음 내용을 담고 있다.
- 페이지 로딩 타임 50% 감소
- 구축 복잡성 최소화
- 웹사이트 컨텐트 변경 불필요
2009년 구글에 따르면 SPDY를 통해 페이지 로딩 타임을 55% 개선하였다고 한다. 2012년 SPDY는 크롬, 파이어폭스, 오페라에서 공식적으로 최초 지원하기 시작했다.
HTTP 워킹 그룹은 SPDY 를 근간으로 한 HTTP/2 를 명세화하기 시작했고 2015년에 공식적으로 RFC 7540으로 표준화 하였음을 릴리즈하였다.
HTTP/2는 아래 대표적인 4가지 기능을 통해 HTTP/1.1에서 가지고 있는 제약 사항을 극복했다.
- Binary Frame & Multiplexing
- Server Push
- Header Compression
- Stream Prioritization
다음 포스팅에서는 HTTP/2 의 등장 배경인 HTTP/1.1 의 제약 사항들에 대해 상세히 정리해본다.
끝~
댓글 없음:
댓글 쓰기