그림으로 쉽게 보는 HTTP 변천사
웹과 함께 시작된 0.9부터 따끈하게 등장한 3.0까지
시리즈 초기에 우린 인터넷 상에서 컴퓨터와 컴퓨터가 서로 데이터를 주고받기 위한 규약인 HTTP에 대해 알아봤습니다. 그리고 다른 네트워크 요소들이 그러하듯 HTTP도 처음부터 짜잔 하고 지금의 완성된 형태로 등장한 것은 아닙니다. WWW, 웹이 탄생한 1989년부터 시작해 오늘날에 이르기까지 많은 시도와 변화가 있었죠.
그래서 이번 포스팅에선 이런 HTTP에 대해 한 단계 더 깊게 들어가 초창기엔 어떤 모습이었고, 어떤 단계를 거쳐 지금에 이르렀는지 그 일대기를 간략하고 실속 있게 담아봤습니다.
태초에 HTTP가 있었으니
가장 초기, 그러니까 WWW(World Wide Web)이 만들어지면서 함께 등장한 HTTP는 정말 통신에 필요한 최소한의 기능만 갖췄습니다.
어떤 데이터를 요청한다는 본문을 보내면 요청한 메시지에 대한 결과를 본문에 담아 응답했습니다. 가령 붕어빵집에서 붕어빵 천 원어치를 주문하면 붕어빵을 받는 것처럼요.
붕어빵집은 보통 주문서라던가 영수증이 따로 없으니까요. 이때 만약 붕어빵이 다 떨어졌다면 구두로 다 떨어졌다는 답변을 받듯 0.9 버전 또한 에러가 발생했을 경우 응답 메시지의 본문에 에러를 적어 보냈습니다.
약간의 사족을 덧붙이자면 당시의 HTTP를 HTTP/0.9라고 부르는데 이는 버전 1.0이 나온 이후에 이전 HTTP를 부르기 위한 방안으로 뒤늦게 붙여진 이름입니다. 더 이상 원 앤 온리가 아니었기 때문이죠.
여하튼 이렇게 처음에는 실제 데이터의 전송만을 위해 쓰인 HTTP는 웹의 발전과 덩달아 점차 다양한 기능이 추가되기 시작했습니다. 다만 제대로 정리되지 않은 상태로 이것저것 추가되다 보니 다양한 프로토콜이 마구잡이로 만들어졌으며, 이를 하나로 정리하고자 소위 말하는 '각 잡고' 문서화를 하게 되는데 이것이 바로 HTTP/1.0입니다.
각 잡고 문서화, 1.0
1996년 만들어진 HTTP/1.0부터는 우리가 익히 알고 있는 형태의 HTTP가 나타납니다. 한 번 예시를 볼까요?
우선 요청 메시지와 응답 메시지 모두 본문 이외에 위아래로 이런저런 텍스트가 추가되었는데, 이것이 HTTP/1.0부터 새롭게 등장한 헤더(Header)입니다.
헤더는 해당 메시지의 정보를 담고 있는 역할로. 이것만 읽어도 우리는 지금 이 메시지의 개괄적인 의미를 파악할 수 있죠. 예시에서는 버전 정보(HTTP/1.0)와 상태 코드(200 OK), 또 문서의 타입인 Content-Type(text/html)이 추가된 것을 볼 수 있습니다. 이를 통해 우리는 메시지가 정상적으로 데이터를 받아왔는지, 또 지금 받은 문서의 타입은 어떤지 등을 확인하고 이에 대응할 수 있게 되었습니다.
그러나 놀랍게도 1.0은 이리저리 분산된 기능들을 하나로 정리했을 뿐 X맨 공식 표준은 아니었습니다.
그럼 표준은 언제부터 생겼을까요?
진짜_표준.http/1.1
바로 1.0이 나온 지 몇 달 채 지나지 않은 1997년 초에 HTTP/1.1이라는 이름으로 공개되었습니다. 큰 맥락은 1.0과 동일하되 일부 모호했던 기능들이 개선되며 진정한 표준으로 자리매김하게 되었죠.
당시 1.0 버전에선 모든 요청마다 새로운 연결을 맺어야 했습니다. 요청하는 컴퓨터와 응답하는 컴퓨터가 데이터를 통신하기 위해 연결을 하고 요청과 응답을 한 번씩 주고받고 나면 그 연결을 끊고 다시 새 연결을 하는 식이었죠.
문제는 동일한 컴퓨터 사이에서 여러 개의 콘텐츠를 요청할 때에도 매 번 새 연결을 맺어야 했다는 점이에요. 특히 한 번 연결을 할 때마다 TCP에선 3-way-handshake가 이루어졌는데 (3-way-handshake가 궁금하신 분들은 이전 포스팅인 그림으로 쉽게 보는 TCP를 참고해주세요.) 아시다시피 한 번의 3-way-handshake만으로도 시간을 어느 정도 잡아먹는데, 이걸 데이터를 여러 번 주고받느라 몇 번을 반복하다 보니 속도가 눈에 띄게 느려지게 된거죠. 초창기 웹에선 이용하는 콘텐츠가 적다 보니 큰 문제가 되지 않았지만 점차 웹이 고도화되자 불편함은 더욱 커졌습니다.
그리고 이러한 문제점을 해결하기 위해 탄생한 HTTP/1.1에서는 아래와 같은 방법을 통해 효과적으로 통신 속도를 개선하게 됩니다.
우선 각 요청마다 TCP 연결을 반복했던 HTTP/1.0과 달리 HTTP/1.1에서는 한 번 TCP 연결을 맺으면 끊지 않고 계속 유지할 수 있게 했습니다(persist connection). 반복되는 3-way-handshake를 단 한 번으로 줄여 메모리 자원을 절약하고 성능을 개선할 수 있게 되었지요.
거기에 덧붙여 1.0에서는 이전 요청에 대한 응답이 도착해야만 다음 요청을 보낼 수 있었기에 앞선 요청에 대한 응답이 늦거나 돌아오지 않으면 뒤의 요청들은 막연히 기다려야만 하는 문제가 있었는데, 1.1에선 이전 응답과 상관없이 한 번에 여러 개의 요청을 보낼 수 있게 해 통신 속도를 더욱 높였습니다(Pipelining).
비유하자면 레스토랑에서 와인과 피자를 주문할 때 HTTP/1.0에선 문을 열고 - 와인을 주문하고 - 와인을 받고 - 문을 닫고 - 다시 문을 열고 - 피자를 주문하는 형태였다면, HTTP/1.1에선 문을 열고 - 와인과 피자를 각각 주문하면 - 메뉴들이 순서대로 하나씩 나오는 식으로 바뀐 거죠.
이렇게 표준화된 HTTP는 15년이 넘도록 자잘한 기능을 확장하며 계속 1.1 버전을 유지하고 있었습니다.
그러던 어느 날, 2009년에 Google에서 SPDY(스피디라고 읽습니다.)라는 새 프로토콜을 발표합니다.
'speedy'라는 단어를 기반으로 만들어진 이 기술은 이름에서 유추할 수 있듯 HTTP/1.1의 성능 제한을 해결하고 웹 페이지의 로드 지연 시간을 줄이기 위해 만들어졌죠. 그리고 이 SPDY의 발표를 흥미롭게 본 HTTP관계자 (HTTP Working Group)는 흥미로운 제안을 합니다. 바로 SPDY를 기반으로 새 HTTP 버전을 만들어보지 않겠냐는 거였죠. 이 제안은 성사되었고 두 팀이 몇 년간 긴밀하게 협업한 결과, 2015년 5월에 SPDY를 기반으로 HTTP/1.1의 단점을 개선한 HTTP/2가 세상에 나타납니다.
더 빠르게 HTTP/2
그럼 HTTP/2는 HTTP/1.1과 어떤 것이 다를까요? 다양한 기능들이 추가되었지만 한 마디로 요약하자면 '성능, 속도 개선'입니다. 이쯤 되면 눈치채셨겠지만 모든 새 HTTP 버전의 가장 주된 목적은 빠른 속도랍니다.
여하튼 HTTP/1.1의 경우 서로 간의 연결은 계속 유지되었지만, 그 안에서는 아직도 하나의 요청은 하나의 응답이라는 1:1 대응을 이루고 있었죠. 거기에 더불어 요청이 들어간 순서대로 처리되다 보니, 앞의 요청 시간이 길어질 경우 뒤에 있는 요청들도 덩달아 지연되는 문제가 있었습니다.
이러한 문제들을 해결하기 위해 HTTP/2에서는 이전의 요청에 대한 응답을 대기하지 않고도 뒤의 응답을 받을 수 있도록 모든 요청과 응답을 병렬적으로 처리했습니다.
더불어 한 번의 요청만으로도 여러 개의 응답을 받을 수 있었고 (Multiplexed Streams), 또 클라이언트가 요청하지 않아도 서버에서 미리 필요한 리소스들을 푸시하는 등 (Server Push) 더 높은 성능과 빠른 속도를 보장할 수 있게 되었습니다.
아까의 레스토랑에 다시 비유하자면 이제는 굳이 와인, 피자를 따로따로 주문하지 않아도 '피자 세트메뉴' 같은걸 시켜 한 번에 주문할 수 있게 되었고, 세트메뉴에 필요한 자잘한 디쉬들 (가령 피클이나 식전 빵 같은) 도 굳이 주문하지 않아도 함께 나오게 된 거죠.
그렇다면 HTTP/2는 어떻게 이런 새로운 변화를 불러올 수 있었을까요?
이를 가능케 한 기능이 바로 바이너리 프레이밍(binary framing)입니다.
바이너리 프레이밍이란 HTTP/2의 핵심으로, 우리가 읽을 수 있는 텍스트 형식이었던 HTTP 메시지를 더 작은 단위로 쪼개 010101 같은 바이너리 형태로 캡슐화한 것을 뜻합니다. 같은 메시지라도 더 크기가 작아지고 효율적으로 전달할 수 있게 된 것이죠.
이 바이너리 프레이밍을 통해 위의 기능들을 가능케 함으로써 HTTP/2는 HTTP의 새로운 메커니즘을 만들어냈습니다.
따끈한 새 버전, HTTP/3
이 정도까지만 해도 우리가 봤을 땐 괜찮아 보이는데, 갑자기 2020년에 HTTP/3이 발표됩니다. 2가 세상에 나온 지 불과 4년 만이죠. 어떤 차이가 있길래 이토록 빠른 시일 내에 새 버전이 나올 수 있게 된 걸까요?
사실 HTTP/2에겐 고질적인 문제가 있었습니다. 바로 여전히 오래된 프로토콜인 TCP 위에서 동작하고 있었다는 거죠. 이 부분에 대해선 많은 관계자들이 고민을 했고 특히 2를 만드는 데 큰 역할을 한 Google도 마찬가지였습니다.
그리고 TCP의 한계를 극복할만한 새 프로토콜을 만들게 되는데 그게 바로 QUIC입니다.
2013년에 발표한 QUIC은 'Quick UDP Internet Connection'의 약자로, 이름에서 알 수 있듯 TCP가 아닌 UDP 위에서 작동한다는 점이 포인트입니다.
TCP는 데이터가 정상적으로 들어갔는지, 순서는 맞는지 일일이 확인하기 때문에 속도가 느린데, UDP는 이렇게 지속적으로 통신하지 않아 훨씬 가볍고 속도도 빠르기 때문이죠. 다만 UDP는 TCP처럼 확인을 하지 않아 데이터가 중간에 손실되는 경우가 종종 있었는데 QUIC에서는 중간에 데이터 손실이 발생해도 이를 개별적으로 재전송할 수 있게 함으로써 신뢰성까지 개선할 수 있게 되었습니다.
그리고 이러한 QUIC을 사용한 차세대 프로토콜을 HTTP/3이라고 부르게 된 것이고요. 참고로 HTTP/3은 아직 표준은 아니며 현재 draft 상태이지만, Google이나 Facebook을 비롯해 2022년 1월 기준 전체 웹사이트의 24.5%가 사용하고 있는 등 여러 서비스에서 시범적으로 사용하고 있습니다.
마무리
여기까지 해서 오늘 HTTP의 역사와 각 버전 별 차이에 대해 간략히 알아봤습니다. 근 30여 년의 역사를 한 페이지에 담다 보니 상대적으로 분량이 길어졌는데 여기까지 읽어주신 분들께 경외와 감사의 인사를 드립니다(__).
프로그래밍은 생겨난 지 얼마 안 된 분야다 보니 역사도 다른 학문에 비해 짧지만, 그만큼 단기간에 폭발적으로 많은 성장을 거두어서 그 안의 응축된 변화를 보는 재미가 쏠쏠한 것 같아요. 그럼 오늘 포스팅은 여기서 마무리하겠습니다.
* 사실과 다르거나 수정이 필요한 부분이 있다면 말씀해주시길 바랍니다.
레퍼런스
HTTP/2 소개 | Web Fundamentals | Google Developers
