[HTTP] HTTP 정의와 HTTP스펙

대부분의 내용은 인프런 김영한 강사님의 모든 개발자를 위한 HTTP 웹 기본 지식을 참고했습니다.

---

 

 

HTTP란 ?

HTTP(HyperText Transfer Protocol)는 웹상에서 이루어지는 모든 데이터 교환의 기초이며,

HTML, TEXT, IMAGE, JSON, XML 등 거의 모든 것을 주고 받을 때 지켜야되는 규칙을 말합니다.

 

 

---

HTTP 스펙

---

 

HTTP의 등장

1989년, 팀 버너스리(Tim Berners-Lee)와 그의 팀원들이 CERN(유럽 입자 물리학 연구소)에서 일하면서 WWW(World Wide Web)을 제안하면서 등장했습니다.

당시 여러기관에 흩어져있는 문서들을 체계화하여 전 세계의 대학 및 연구소들끼리의 상호 연구를 위해 인터넷을 통한 하이퍼텍스트 시스템을 제안했는데,

초기 Mesh라고 불리던 그것은 1990년 '월드 와이드 웹'으로 이름을 바꿨습니다.

 

기존의 TCP, IP 프로토콜을 기반으로 만들어졌고, 4개의 기본 구성요소로 이루어져있습니다. 

1. 하이퍼텍스트 문서를 표현하기 위한 텍스트 형식의 "하이퍼텍스트 마크업 언어(HTML)"

2. 하이퍼텍스트 문서를 교환하기 위한 프로토콜인 "하이퍼텍스트 전송 프로토콜(HTTP)"

3. 문서를 보여주기 위한 클라이언트인 "월드 와이드 웹"이라고 불리는 첫번째 브라우저

4. 문서에 접근하도록 해주는 서버인 "httpd의 초기 버전"

---

 

HTTP/0.9

1991년에 나온 최초의 HTTP 명세로 기본 포트로 80번 사용하며 GET요청만 사용할 수 있는 아주 단순한 프로토콜입니다.

해당 명세에서는 요청은 멱등(idempotent)한 특성을 가지며, 연결이 종료된 이후에 서버는 요청에 관한 어떠한 정보도 저장하지 말 것을 명시하고 있습니다.

 

이것이 HTTP가 무상태(stateless) 프로토콜이라 불리는 이유입니다.

---

 

HTTP/1.0

HTTP/0.9에서는 기능이 매우 제한적이었기 때문에 대부분의 웹 서버들은 0.9스펙에서 명시되지 않은 여러 기능들을 자체적으로 구현하여 사용했습니다.

명시적인 약속이 없었기 때문에 각 서버와 클라이언트의 기능이 일관성 있게 구현되지 않았습니다.

그래서 HTTP의 기본적인 구조는 그대로 유지하면서 다양한 요구사항을 충족시키기 위해 HTTP Working Group이라는 조직이 등장합니다.

HTTP WG는 1996년에 이러한 사양을 정리하여 발표했는데 이게 HTTP/1.0입니다.

 

사실 HTTP/0.9에는 버전 번호가 없었는데 HTTP/1.0이 나오면서 버전을 구분하기위해 HTTP/0.9라고 나중에 이름이 붙게됩니다.

 

HTTP/1.0에서 추가된 기능을 간단히 살펴보면 아래와 같습니다.

 

⋅ HTTP 헤더의 추가

⋅ 요청메서드가 GET, HEAD, POST 세 가지로 확장

⋅ HTTP 요청에 버전 정보를 포함할 수 있도록 변경

⋅ HTTP 상태 코드의 추가

⋅ Content-Type가 추가되어 HTML파일들 외에 다른 문서들을 전송할 수 있게됨

---

 

HTTP/1.1

HTTP/1.1은 1997년 1월에 최초 공개되어 이후 여러차례 개정 되었습니다.

HTTP/1.1에서 추가된 내용을 간단히 살펴보면 아래와 같습니다.

 

⋅ HOST 요청 헤드를 반드시 포함

⋅ 지속 연결 기능 추가

⋅ 파이프라이닝 기능 추가

⋅ PUT, OPTIONS, DELETE 등의 메서드 추가

⋅ 캐시 제어 메커니즘 추가

⋅ HTTP 쿠키 추가

 

이 외에도 많은 기능이 추가되었습니다.

추가된 기능중 가장 큰 차이점 3가지만 좀 더 자세히 알아보겠습니다.

 

1. HOST 요청 헤드

HTTP/1.0에서는 서버 하나당 오직 하나의 웹사이트만 호스팅하고 있었기 때문에 HOST헤더가 필요하지 않았습니다.

하지만 가상 호스팅으로 인해서 하나의 서버가 여러 개의 도메인을 호스팅할 수 있게되어 서버에서 어떤 도메인에 대한 요청인지를 구별하기 위해 HTTP/1.1에서는 HOST 요청 헤더를 사용하게 되었습니다.

 

2. 지속 연결 기능(Persisted connection)

 

HTTP/1.0에서는 클라이언트의 요청을 처리하고 TCP 연결을 바로 종료합니다.

이렇게 요청을 처리하고 TCP 연결을 바로 종료한다면, 웹 페이지에서 다수의 HTTP 요청이 발생하는경우 매번 TCP handshake 과정을

거쳐야 하기때문에 속도가 매우 느려진다는 문제점이 있습니다.

 

그래서 HTTP/1.1에서는 기본적으로 한 번 TCP 연결을 수립하면 그 연결을 재사용하게 설정되어 있습니다.

이렇게 한다면, 연결을 맺고 끊는 과정이 줄어들어 네트워크 지연이 개선될 수 있습니다.

 

이 기능은 Connection 요청 헤더에 keep-alive 값을 넣어 사용할 수 있습니다.

Connection: keep-alive

(HTTP/1.1에선 이 기능이 디폴트값이기 때문에 명시하지 않아도 됩니다.)

연결을 해제하고 싶다면 close라는 값을 넣어 요청을 보냅니다.

Connection: close

 

그럼 여기서 궁금증이 하나 생깁니다.

'연결을 계속 유지하고 있다면 서버의 자원을 잡아먹고 있는건데, 사용자가 많아지면 서버가 과부하되는게 아닐까 ?'

서버의 자원은 무한대가 아니므로, timeout을 설정하여 연결에서의 요청이 마지막으로 종료된 시점으로부터

설정한 timeout 시간 동안만 연결을 유지합니다.

 

(다른 이야기이지만 현재 사이드 프로젝트에서 Spring 프레임워크를 사용하고 있어서 설정하는 방법을 찾아봤는데,

application.yml 또는 application.properties 파일에 server.tomcat.connection-timeout=60000 이런식으로 설정하면 됩니다.)

 

3. 파이프라이닝(Pipelining)

기본적으로 HTTP 요청은 순차적으로 전송되고, 이전 요청에 대한 응답을 받아야 다음번 요청을 보낼 수 있습니다.

이러한 방식은 네트워크 지연과 대역폭 제한으로 인해 다음 요청을 보내는데 상당한 딜레이가 발생할 수 있습니다.

 

위의 그림에서 지속연결에 대한 그림을 보면 여러요청이 있을 때 하나의 요청과 응답을 세트로 묶어 처리되는 것을 볼 수 있습니다.

이 것이 딜레이가 발생할 수 있는 원인입니다.

 

그래서 HTTP/1.1에서는 파이프라이닝이 기법이 추가되었습니다.

파이프라이닝은 세번째 그림처럼 여러 HTTP 요청을 보내야할 때 발생한 요청은 일단 전송하는 방식입니다.

클라이언트 측에서 여러 HTTP 요청을 순차적으로 보내면 서버는 받은 순서대로 응답을 주는 방식으로 딜레이를 개선한 것입니다.

 

하지만, HTTP 파이프라이닝은 모던 브라우저에서 기본적으로 활성화되어 있지 않습니다.

버그가 있는 프록시 서버들이 많이 있고,

파이프라이닝은 정확히 구현하기 어렵습니다.

그리고 파이프라이닝은 HOL 문제에 영향을 받기 때문에 파이프라이닝은 HTTP/2.0에서 멀티플렉싱으로 대체되었습니다.

 

 

 

 

 

 

우리가 사용하고 있는 HTTP/1.1에 대부분의 기능이 있기 때문에 글은 여기서 마치겠습니다.

추후에 HTTP/2.0과 HTTP/3.0에 대해서도 글을 작성하여 링크를 걸어놓겠습니다.

 

 

---

Evolution of HTTP

HTTP persistent connection

 

HTTP pipelining

HTTP/1.x의 커넥션 관리