HTTP 1.1

HTTP (Hyper Text Transfor Protocol) 1.1에 대해 알아보자

• HTTP 1.1은 왜 생겼을까
• HTTP 1.1의 장점과 단점은 무엇일까

 

HTTP란 무엇인가?

• WWW (World Wide Web)의 기반역할을 하는 데이터 통신 프로토콜

HTML 기반의 문서를 주고 받기 위해 WWW가  탄생하면서, 연결 지향적인 특징과 TCP/IP  프로토콜 기반의 신뢰성있는 통신 규약이 만들어졌다.

HTTP 0.9

초기 HTTP/0.9버전으로 만들어졌으며, 하이퍼텍스트만을 통신하기 위해 고안됐다.
이때는 복잡한 기능은 제공하지 않고, GET 메서드만 존재했다.
기본적으로 포트를 정의하지 않으면 80포트를 사용하여 연결이 되도록 지원했다.
별도의 HTTP 헤더나 상태 코드가 존재하지 않았으며, 응답은 HTML 파일만 보내줬다.
전체 문서가 전송이 되면 서버에서 TCP-IP 연결을 끊어벼렸다.

참고: HTTP 0.9

즉, 초기 HTTP는 HTML 파일을 주고 받기 위한 단순한 프로토콜이었다.

HTTP 1.0

HTML을 받아오는 기능만 존재하던 HTTP 0.9를 개선하여 HTTP 1.0이 생겼다.
이때부터 사용하는 protocol의 버전을 서버에 전송할 필요가 생겼다.
HTTP 1.0에서는 HEAD와 POST method가 추가됐다.
POST method가 추가되면서, client로부터 server로 메시지를 전송 할 수단이 생겼다.
HTTP result에 status가 추가됐다.
HTTP에 헤더도 추가가 되면서 요청과 응답의 메시지가 더 풍부하고 유연해졌다.
Content-Type이 헤더에 추가되며, HTML이 아닌 파일도 전송이 가능해졌다.

참고: HTTP 1.0

꽤나 쓸만해진 프로토콜이었지만, HTTP/1.0이 나오고 얼마되지 않아 HTTP/1.1 버전이 발표됐다.

이 글은 HTTP 1.1을 다루기 때문에, 이제부터 좀 더 자세히 알아보도록 한다.

HTTP 1.1은 왜 나왔을까?

가장 큰 이유 중 하나는 커넥션 연결의 수명이 너무 짧았던 점(short-lived connections)이며, 이 점을 일부나마 개선하여 재사용 가능하게 변경됐다.
HTTP 1.0에서는 리소스를 다운로드 하는데 많은 연결이 필요했다. 하나의 연결이 하나의 리소스만을 전송했기 때문에, 많은 리소스를 가지는 웹페이지라면 그 만큼 많은 연결을 필요로 하게 됐다.
각 연결은 병렬 처리가 아니었으며, 이전 연결이 끝날때까지 다음 리소스를 가져오지 못했다.

이 문제를 개선하여 keep-alive 연결이라는 형태의 지속적인 HTTP 연결이 되도록 개선됐다. 
이를 Persistent HTTP라고도 부른다.
HTTP/1.1 에서는 한 번 연결이 되면, 지정한 timeout동안 지속적으로 연결을 유지한다. 
이 연결이 된 시간동안은 여러 개의 요청과 응답을 주고 받을 수 있다.

Persistent HTTP

 

이 외에도 Pipelining이 추가됐다.
이 요청은 한 번에 여러개의 요청을 보내 응답을 받아 대기 시간을 줄이는 기술이다.
HTTP가 닫히기 전에 사용할 수 있다는 점에서 Persistent HTTP와 유사하다.

Pipelining

파이프라이닝은 GET, HEAD, PUT ,DELETE를 포함한 멱등 HTTP 메서드로 제한된다. 메시지가 손실 될 경우 부작용에 대한 걱정을 하지 않고, 전체 HTTP 요청을 새로 보낼 수 있기 때문이다.

하지만, 구현의 복잡성 및 고려해야 할 점들이 너무 많아 최신 웹 브라우저에서는 더 이상 사용되지 않는다.
특히, 어떤 하나의 요청의 처리시간이 오래걸리는 경우 다른 요청들도 지연이 되는 문제인 HOL(Head of Line) Blocking 현상이 발생하였으며, 이는 이후 버전에서 다른 기술로 대체되며 해결이 되었다.

HOL Blocking

 

GET, HEAD, POST만 지원하던 HTTP 1.0에서 PUT, DELETE, OPTIONS, TRACE가 추가되었다.
여전히 가장 많이 사용되는 method는 GET과 POST지만, method를 다양하게 사용할 수 있게 되면서 REST API의 기반이 되기도 했다.

Host Header가 필수화가 되었다.
HTTP/1.0에서는 동일 IP에 대해 여러 도메인을 호스팅하기 어려웠으나, HTTP/1.1로 넘어오면서, Host 헤더를 필수로 지정하여 하나의 IP주소로 여러 도메인을 식별할 수 있게 되었다.
이는 가상 호스팅의 핵심이 되었으며, IP 주소 낭비를 감소 시키고 여러 도메인을 운영할 수 있게 됐다.

캐시 처리에 대한 보완도 이뤄졌다.
다양한 지시어를 토해 캐시 동작을 제어하게 되었고, 가장 중요한 캐시 제어 헤더로 Cache-Control이 추가되었다.
Cache-Control은 여러 지시어를 통해 캐시를 어떻게, 얼마나, 저장할지에 대한 동작을 제어한다.

 

인증 관련된 메커니즘도 개선이 되었으며, 특히 SSL/TLS의 표준화가 지원됐다.
즉, HTTPS가 지원되기 시작한 시점 역시 HTTP/1.1 부터다.

HTTP/1.1은 충분히 개선이 많이 된 프로토콜이며, 20년이 넘는 현재까지도 가장 많이 사용되는 방식이다.
다만, HOL Blocking 같은 문제가 있었고, 요청마다 반복적인 긴 헤더 정보를 필요로 했다.
그 외에도 클라이언트가 요청하지 않으면, 서버에서 리소스를 전달 할 수 없는 단점도 있었다.
이러한 점을 개선하여 HTTP/2가 생겼으며, 성능과 보안을 더욱 더 개선할 수 있게 되었다.

HTTP/2는 TCP에 의존적이다보니, 계층적 레벨에서의 HOL Blocking 이슈가 여전히 남아있었고, 이를 개선하여 HTTP/3가 나오기도 했다.

기술의 발전은 결국 기존 기술의 단점을 보완하며 성능을 개선하여 나온 결과물이다.

즉, HTTP/1.1은 HTTP/1.0에 비해 성능과 효율성을 높였으며, Host Header를 지원하며 가상 호스팅을 통해 확장성을 높였고, 보안을 더 강화 시켰으며, 다양한 HTTP method를 지원하여 유연함을 높였다.

정리