HTTP의 버전으로 보는 변천사

 

우리가 웹에서 요청과 응답에서 사용하는 프로토콜은 HTTP 프로토콜위에서 작동한다

Header에는 상태코드와 함께 HTTP 버전, 컨텐츠 타입 등 여러 정보가담기며 바디에는 정보를 담아 전송할수있다

또한 HTTP에서 지원하는 여러 메소드(Get, Post, Delete, Put, Patch)를 통해 Restful한 URL을 설계할수있다

 

하지만 과연 과거에서부터 지금까지 이르러서 처음부터 이런기능을 모두 지원한것일까?

우리는 과거의 HTTP와 현재, 그리고 미래에 개발되고있는 HTTP프로토콜에 대한 정보를 알아볼것이다

 

 

HTTP 0.9

---

초기에 HTTP는 1991년에 나온 0.9버전으로써 현재와는 매우다르게 아주 간단한 기능만 가지고있었다

리소스에 대한 경로로 가능한 Http 메서드는 Get방식 밖에지원하지 않았으며응답은 아주간단하게 내용자체로 구성되어있었다

이는 헤더도 없이 그냥 HTML 파일만 전송할수있으며 다른유형의 문서는 전송이될수없었다 그저 그냥 파일을 전송하기위한 내용자체로만 구성되어있었다는 특징을 가지고있다

 

 

이처럼 그냥 html파일 하나만 전송된다는 것을 확인할수있다 또한 상태코드 또한 없어서 클라이언트 문제인지 아니면 서버문제인지 알수없었으며 보통 html 파일내부에 오류에 대한 설명과 함께 같이 전송하곤했다

 

그리고 다음 http 1.0버전에서는 좀더 브라우저에서 사용하기 편하게 보다 더많은 정보를 보내기위해 훗날 우리가 지금도 사용하고있는 헤더(Header) 라는 개념이 생겼다

 

 

 

 

 

 

HTTP 1.0

---

1.0 버전은 기존 0.9버전에서 여러가지 변화되었는데 첫번째로 HTTP 헤더라는 개념이 도입되어서 사용자가 요청 및 응답을 하게되면 헤더에 버전정보, method, 상태코드 등 여러가지 정보를 넣어서 보낼수 있게되었다

이에 따른 결과로 브라우저가 요청을 보내고 해당 요청이 성공했는지 실패했는지 직간접적으로 알수있게되었으며 이에따른 처리를 할수있게 되었다

 

또한 기존 html 파일만 보낼수있었던 프로토콜을 확장가능하고 유연하게 바꾸게 되었는데

이는 Content-Type에 도입으로인해 HTML 파일 이

외에 다른 문서도 전송이 가능해지게되었다

 

 

 

위에 요청이 들어오면 헤더부분에는 프로토콜에 버전과함께 상태타입, 서버정보, 컨텐츠타입이 같이 전송되는것을 확인할수있다

하지만 1.0버전에는 여러문제가 있었는데 대표적으로 커넥션 하나당 요청, 응답한개씩 처리가 가능했는데

이는 곧 서버에 많은 커넥션이 걸리게되고 이는 매우 비효율적이게 돌아간다는것을 알수있었다

이것을 개선하기위해서 우리가 현재 가장많이 쓰이고있는 웹프로토콜 Http1.1버전이 나오게된다

 

 

 

 

HTTP 1.1

---

1997년에 등장한 Http 1.1버전은 커넥션을 재사용할수있게 바꾸었는데

우선 파이프라이닝을 통해 요청을 보내고 해당요청이 끝나기전에 다음데이터를 미리 요청할수있게 되었다

이로인해 높은 레이턴시를 개선할수있었으며 좀더 효율적인 통신이 가능하게되었다

 

다만 하나의 커넥션에 여러개의 요청이 들어있을뿐이고 동시에 많은양의 요청을 처리해서 응답으로 보내주는것은 아니였다

하지만 1.1버전또한 한계가있었는데 결국에는 요청이 많고 응답이 너무 늦을경우에는 뒤에있는 요청이 전부 블락킹 처리되어버리고, Header에 요청이 계속해서 들어가기떄문에 반복되는 데이터가 계속해서 들어가게되었다

 

 

 

 

 

 

 

 

HTTP 2.0

---

1.1버전의 한계로 인해 Http프로토콜은 성능향상을 위해서 여러가지 조치를 취하게되는데

여기서 동작방식에 많은 변화가 오게되며 Http 1.1이 웹표준 프로토콜이지만 여기에서 1.1을 대체하는것이 아니고 좀더 확장한 개념으로 나온 버전이다

 

Http/1.1 버전에서는 요청에 대한 응답을 받은후에 다시 요청을 보낼수있는 형태이며, 만약 요청의 응답을 늦게 수신할경우에는 뒤에오던 응답도 그에따라 늦게 처리가 될수밖에없다는 문제가있는데 이를 해결하기위해 파이프라인 커넥션을 통해 요청을 보내고 다음요청을 기다리는게아니라 병렬커넥션으로 기다리지않고 보낼수있었다

 

하지만 파이프라인 커넥션 구현이 복잡함과 동시에 만들수있는 개수가 한정되어있었는데 이를 해결하기위해서 SPDY(스피디)에 기반한 Http 2.0 버전이 등장하게 된것이다

 

간단하게 말하자면 스피디에 등장으로 헤더를 압축하여 대역폭을 절약하며, 하나의 커넥션에 여러 요청을 동시에 보낼수있게되었다

 

 

 

위에서 언급됬듯이 핵심적인 개념인 Http 메서드, 상태코드, 헤더 같은 구조는 변경되지 않았기때문에 어플리케이션 개발자는 사실 1.* 버전이나 2.*버전이나 사용에 차이점은 없다는 것이특징이다

2.0버전에서는 메세지를 프레임단위로 분할하여 바이너리로 인코딩하며 이로인해 파싱속도와 전송속도가 빠르며 오류발생할 가능성이 적다

 

하지만 2.0에서도 한계가 있었는데 위에서 설명하진않았지만 각요청을 Stream으로 구분해서 병렬처리하지만 결국 TCP의 문제일수도 있는 블락킹문제가 존재한다

TCP 태생적인 문제를 해결하기 위해서 HTTP 3.0이 등장하게된다

 

 

 

 

 

HTTP 3.0

---

3.0 버전은 정확히 QUIC / HTTP 3.0 이라고 분류되며 Google에서 개발한 UDP기반의 전송 프로토콜이다

위에서 나온 Http는 TCP를 사용하는데 반해 3.0는 UDP를 기반으로 전송하게되며 이로인해 3-way handshake과정을 최적화 하는것을 목적으로 개발되었다 이는 Stream을 하나의 chain으로 연결하는 TCP와는 다르게 독립적인 chain을 구성하여 블락킹 문제를 해결하게 되었다 

 

그덕분에 Http 1.*, 2.*버전의 TCP의 고유의 성능문제를 해결하게되었는다

 

 

 

 

 

 

번외

---

 

그렇다면 번외편으로 크롬 관리자 도구를 통해 현재 사이트의 Http 버전을 알수있는 방법에대해서 알아보도록 하자

우선 자신이 알고싶은 사이트에 접속후 관리자도구(F12)를 열어주도록 한다

 

그다음 Network탭으로 이동후 아무것도 뜨지않는다면 Ctrl + R 을통해 새롭게 리로드 해준다

 

 

 

 

 

그렇다면 대충 이런식으로 화면이 뜰텐데 이는 서버에서 우리에게 요청결과를 내려준것이다

우리가 볼것은 Protocol 탭인데 h2, h3라고 써져있는 부분이 현재 Http 프로토콜의 버전을 의미한다

h2는 Http/2.0을 의미하며 h3는 Http/3.0 을 사용하고있다는 뜻이다

본래에는 h2가 많았지만 요새 점점 h3도 많아지는 추세이다

 

 

여기까지가 Http 버전의 역사이며, 도움이 되었길 바란다