CHAPTER1 - HTTP의 진화

1930년대, MIT 공대에 재직 중이던 미국 출신 전기공학자 바네바 부시는 사람들이 생산하는 정보량은 그 정보를 소비하는 사회의 능력에 비례한다고 생각했다. 1945년, 월간 애틀랜틱에 등재된 '생각하는 대로'라는 기고문에서 그는 다음과 같이 기술했다.

연구 결과를 전문적으로 전달하고 검토하는 방식은 오래전부터 이어져 내려오고 있으며, 지금은 그 목적을 달성하기에 매우 부적절하다. 학술 저작물을 쓰는 데 소요되는 전체 시간과 읽는 데 소요되는 전체 시간을 측정할 수 있다면, 이 둘 사이에는 엄청난 차이가 있다는 사실을 알게 될것이다.

그는 지식을 마이크로필름으로 저장하여, '엄청난 속도와 유연성으로 참조'할 수 있는 시스템을 상상했다. 또한 이러한 정보는 관련 주제들과 문맥적 상관관계가 있으며, 이는 인간의 마음이 데이터를 서로 연결하는 방식과 유사하다고 말했다. 그의 메멕스시스템이 현실화되지는 않았찌만 개념은 후세에 많은 영향을 미쳤다.

지금은 당연한 것으로 받아들이는 하이퍼텍스트라는 용어는 소프트웨어 설계자이자 철학자인 테드넬슨이 1963년 즈음에 대념을 고안하여 1965년 처음 발표했다. 그는 하이퍼텍스트의 개념을 다음과 같이 제시했다.

종이 위에서는 쉽게 표현할 수 없는 복잡한 방식으로 상호 연결된 글이나 그림 자료의 모음. 요약을 포함할 수 있고, 내용과 상호 관계의 지도를 포함할 수도 있다. 검토자들의 주석, 부연설명, 각주를 포함할 수 있다.

넬슨은 정보가 상호 연결되어 지워지지 않으면서 누구나 쉽게 사용할 수 있는 '문서위주'를 만들기를 원했다. 그는 부시의 아이디어를 토대로 1970년에 제너두 프로젝트에서 하이퍼텍슽트 시스템의 시제품을 주현했다. 불행히도 제너두 프로젝트는 빛을 보지 못했지만, 후대에 많은 영향을 미쳤다.

HTTP는 1989년에 처음 등장했다. CERN에서 일하던 팀 버너스 리는 연구소에서 '가속기(미완성 상태였던 대형 강입자 충동기를 의미)'와 각종 실험을 통해 얻은 정보를 관리하는 데 도움을 주는 새 시스템을 제안했다. 그는 넬슨이 주창한 개념 두 가지를 채택했는데, 텃째는 '제약이 없는 방식으로 서로 연결되어 사람이 읽을 수 있는 정보'를 의미하는 하이퍼텍스트며, 둘째는 정보가 반드시 텍스트 형태일 필요는 없다'는 의미인 하이퍼미디어다. 그는 수많은 기계에서 서버와 브라우저를 구동해 '범세계적인 시스템'을 제공하자고 제안했다.

1.1 HTTP/0.9와 1.0

HTTP/0.9는 매우 단순한 프로토콜이었다. 단 하나의 메서드(GET)만 있었고, 어떠한 헤더도 없었으며, (이미지는 처리할 수 없고 텍스트만 다룰 수 있는)HTML만 가져오도록 설계되었다.

이후 몇 년간, HTTP의 사용이 계속 증가했다. 1995년에는 80번 포트에서 HTTP 트래픽을 처리하는 서버가 전 세계적으로 18,000대를 넘어섰다. 이 프로토콜은 0.9 버전 원형에서 대폭 개선되어 1996년에 HTTP/1.0이 RFC 1945로 발표되었다.

1.0 버전은 모든 것이 시작된 0.9 버전에 어마어마한 변화를 가져왔다. 0.9 버전의 규격은 한 페이지 정도 분량이었지만, 1.0 버전은 60페이지에 달했다. 가히 장난감 수준에서 쓸 만한 도구 수준으로 발전했다고 할 수 있었다. 1.0 버전은 오늘날 매우 친숙한 다음과 같은 개념을 도입했다.

• 헤더
  
• 응답코드
  
• 리다이렉트
  
• 오휴
  
• 조건부 요청
  
• 콘텐츠 인코딩
  
• 더 다양한 요청 메서드

0.9 버전보단 비약적으로 개선되었지만, HTTP/1.0에도 해결해야 할 결함이 많았다. 여러 요청 사이에 연결을 유지하는 기능이 없었고, Host 헤더가 필수가 아니었스며, 캐싱 옵션이 빈약했다. 이 세 항목은 향후 웹의 발전에 큰 영향을 미쳤으며, 반드시 해결해야만 하는 문제였다.

1.2. HTTP/1.1

1.0이 나온 지 얼마 되지 않아 1.1 버전이 발표되었고, 이 프로토콜은 지금까지 20년 넘게 명맥을 유지해오고 있다. 1.1. 버전에서는 앞서 언급한 많은 문제점이 고쳐졌다. Host 헤더를 필수 항목으로 지정한 덕분에 가상 호스팅, 즉 하나의 IP 주소로 다수의 웹프로퍼티를 제동할 수 있게 되었다. 새 연결 지시자를 사용하면 웹 서버는 응답 후에 연결을 끊을 필요가 없다. 브라우저는 더 이상 모든 요청마다 TCP 연결을 재수립하지 않아도 돼 성능과 효율이 대폭 개선되었다.

이 외에도 다음과 같은 변경이 추가로 이루어졌다.

• cachebility 헤더의 확장
• OPTION 메서드
• Upgrade 헤더
• Range 요청
• Transfer-Encoding 압축
• 파이프라이닝

NOTE_ 파이프라이닝은 클라이언트가 모든 요청을 동시에 전송할 수 있는 기능이다. 하지만 파이프라이닝은 몇 가지 문제점이 있어 잘 사용되지 않는다. 서버는 요청을 동시에 받더라도 여전히 순서대로 응답한다. 이는 어떤 한 요청을 처리하는 데 시간이 오래 걸리는 경우, 이 HOL 블로킹 현상으로 인해 다른 요청들에 대한 응답도 함께 지연됨을 의미한다. 게다가 인터넷상의 서버와 프락시 중 파이프라이닝을 제대로 구현한 곳은 거의 없으며, 있더라도 제대로 종작하지 않는 경우가 많다.

HTTP/1.1은 HTTP/1.0의 성공의 결과이자, 수년간 1.0 프로토콜을 적용해 얻은 경험의 산물이었따.

HTTP/1.1 RFC IETF는 위원회가 작성한 RFC라는 초안으로 프로토콜 규격을 방행한다. 이 위원회는 시간과 의지만 있다면 누구든 참여할 수 있다. HTTP/1.1은 RFC 2068에 처음 정의되었고, 이후 RFC 2616으로 대체되었다가, 최종적으로 RFC 7230~7235로 개정되었다.

1.3 HTTP/1.1 이후

1999년, HTTP/1.1을 기술한 RFC 2616에서 현대 웹의 토대가 된 표준이 정의되었다. 마치 바위에 새겨 굳어진 것처럼 HTTP/1.1은 진화하지도 변하지도 않았다. 하지만 웹과 그 사용방식은 창시자가 상상하지도 못한 방식으로 계속 변해왔다. 일반적인 상거래 사이트의 상호작용과 효용성은 복잡하게 연결된 문서위주라는 기대를 뛰어넘어 우리가 세상에 참여하는 방식을 근복적으로 바꿔놓았다. 현재까지도 존재하는 프로토콜상의 여러 제약에도 이러한 발전은 끊임없이 이루어졌다.

단언할 수 있는 가장 가시적인 변화는 웹 페이지의 구성에 있다. HTTP 아카이브는 2010년 이후의 자료만 보유하고 있지만 그 비교적 짧은 기간에도 엄청난 변화가 이루어졌음을 보여준다. 웹 페이지에 개체가 추가될 때마다 페이지는 더 복잡해지고, 한 번에 한 개체만 요청하도록 설계된 이 프로토콜은 갈수록 더 혹사당하고 있다.

1.4 SPDY

2009년, 구글의 마이크 벨시와 로베르토 페온은 HTTP의 대안으로 SPDY를 제시했다. SPDY가 HTTP를 대체하려는 최초 제안은 아니었지만 체감 성능을 실질적으로 개선했기 때문에 가장 중요한 프로토콜이 되엇따. SPDY 이전에는 HTTP/1.1을 훼손하거나 호환성을 포기해서라도 개선하려는 업계의 의지가 부족했다. 브라우저, 서버, 프락시, 다양한 네트워크 장비들 모두에 변경을 적용하는 데 매우 많은 노력이 필요해 보였다.

하지만 SPDY가 모든 걸 바꿔놓았다. SPDY는 더 효율적인 것에 대한 욕구와 변경에 대한 의지가 업계에 존재한다는 사실을 증명했다. SPDY는 HTTP/2의 기틀을 마련했으며 무엇보다도 다중화, 프레이밍, 헤더 압축과 같은 몇 가지 핵심 기능이 성공적임을 증명했다. 크롬과 파이어폭스는 재빨리 SPDY를 지원해쏙, 결국에는 주요 브라우저 대부분이 SPDY를 채택했다. 또한, 많은 서버와 프락시도 이에 보조를 맞추어 SPDY를 지원해야만 했다.

1.5. HTTP/2

2012년 초, 차세대 HTTP 프로토콜을 재정할 HTTP 워킹 그룹(HTTP 규격을 담당하는 IETF(그룹)을 재구성했다. 워킹 그룹 활동 계획안 중 다음과 같은 핵심 부분이 새 프로토콜에 대한 그들의 기대감을 잘 보여준다.

HTTP/2.0은 다음을 목표로 한다.

• 대부분의 경우에서 최종 사용자의 체감 지연 시간을 TCP를 사용하는 HTTP/1.1보다 실질적으로 현저히 개선한다.
• HTTP의 'HOL 블로킹' 문제를 해결한다.
• 병렬 처리를 위해 서버에 다중 연결할 필요가 없다. TCP의 사용, 특히 혼잡 제어와 관련한 동작을 개선한다.
• HTTP/1.1의 의미 체계를 유지한다. HTTP 메서드, 상태코드, URI, 헤더 필드 외에도 기존에 문서화된 것을 최대한 활용한다.
• HTTP/2.0이 HTTP/1.x와 호환성을 유지하는 방법, 특히 중재자를 명확히 정의한다.(1→2 및 2→1 양방향).
• 새로운 확장 기능과 정책을 적절히 사용할 수 있도록 명확하게 한다.

HTTP/2.0의 제안 요청서가 송부되었고, SPDY를 HTTP/2.0의 시작점으로 사용하기로 결정되었다. 2015년 5월 14일, 마침내 RFC 7540이 발행되어 HTTP/2가 공식화되었다.