[WEB] HTTP의 진화 1. HTTP/0.9~HTTP/1.1

 

HTTP (HyperText Transfer Protocol)은 월드 와이드 웹의 기반이 되는 프로토콜이다. 

 

 

 

HTTP/0.9

HTTP의 시작은 1989년 팀 버너 리(Tim Berners-LEE)에 의해 제안된 인터넷의 하이퍼 텍스트 시스템이다. 

초기 버전인 HTTP/0.9는 매우 단순한 프로토콜이었다.

요청은 단일 라인으로 구성되어 가능한 메서드는 `GET`이 유일했으며, 헤더(header)도 없어 요청과 응답이 극히 단순명료했다. 또한 상태 코드(status code)도 없었기 때문에 문제가 발생할 경우 특정 html 파일을 오류에 대한 설명과 함께 보냈다.

 

▷ Request

 

▷ Response

 

HTTP/0.9 스펙을 요약하면 다음과 같다.

• TCP/IP 링크 위에서 동작하는 ASCII 프로토콜
• GET 메서드만 지원
• HTTP 헤더 X, 상태 코드 X
• 응답도 HTML 파일 자체만 보내줌
• 서버와 클라이언트 간의 연결은 모두 요청 후에 닫힘 

---

 HTTP/1.0 

인터넷의 성장이 날이 갈수록 거대히지며, 이제는 단순히 하이퍼텍스트 문서 뿐만 아니라 멀티미디어 데이터나 메타데이터 등 다양하고 상세한 컨텐츠가 필요해짐으로써, 기존의 HTTP/0.9로는 다양한 요구사항들을 채울 수 없는 한계에 봉착하게 되었다.

문제는 HTTP에서 명시한스펙이 없었으므로 이들 간엔 다양한 혼란이 존재했다. 

이때 이러한 다양한 요구사항을 만족시키며 스펙을 표준화하기 위한 HTTP-WG(HTTP Working Group) 이라는 조직이 탄생했으며, 1996년 HTTP/1.0 구현의 일반적인 사용을 문서화한  RFC1945가 발표되었다.

 

 

이는 다음과 같은 익숙한 형태의 요청과 응답 포맷으로 구성되었다.

Request 메시지에는 GET 요청이 시작되는 줄에 path와 HTTP 버전, 그리고 다음 줄로 이어지는 헤더값을 가지며,

Response 메시지에는 200 OK 이후 응답 상태로 이어지는 헤더값을 가지는 걸 볼 수 있다.

 

▷ Request

 

▷ Response

 

이렇게 발표된 HTTP/1.0 스펙을 요약하면 다음과 같다. 

• 기본적인 HTTP 메서드와 요청/응답 헤더 추가 
• HTTP 버전 정보와 각 요청 사이내로 전송되기 시작 (HTTP/1.0이 GET 라인에 붙은 형태로)
• 상태 코드(status code)가 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작을 할 수 있게 됨 
• 응답 헤더의 Content-Type 덕분에 HTML 파일 형식 외에 다른 문서들을 전송하는 기능이 추가됨 

 

HTTP/1.0 문제점

Short-lived Connection 

HTTP/1.0의 문제점은 비연결성(connectionless)로 인한 단기 커넥션이다.

즉, 커넥션 하나당 하나의 요청 하나의 응답 처리가 가능한 것을 말하는데, 서버에 자원을 요청할 때마다 매번 새로운 연결을 해줘야 했다. 

• 1 Request & 1 Response
• 매번 새로운 연결로 성능 저하
• 매번 새로운 연결로 서버 부하 비용 증가

예를 들어 웹페이지를 요청하면 html과 그에 딸린 css나 js 및 이미지 등등 수많은 자원들이 다운로드되어 화면에 띄울텐데, 각 자원들을 따로따로 매번 TCP 연결하고 다운받고 연결 끊고 다시 연결하고 다운받고 연결을 끊는 것이다. 

 

그래서 HTTP 초기에는 모든 자료에 대해서 비연결성으로 각각의 자원에 대해 연결 -> 응답 -> 종료를 반복하다보니 느렸다.

---

HTTP/1.1

HTTP/1.0의 몇가지 단점을 커버하기 위해 HTTP/1.0이 출시된지 6개월만에 1997년 1월 에공식적으로 HTTP/1.1이 릴리즈되게 된다.

HTTP/1.1은 현재 가장 많이 쓰이는 프로토콜 버전이며, 우리가 HTTP를 학습할때 배우는 기본 베이스 지식이기도 하다. 

 

HTTP/1.1 표준은 이전 버전에서 발견된 많은 프로토콜 모호성을 해결하고 몇가지 크리티컬한 성능 개선을 도입했다.

• Persistent Connection: 지정한 timeout동안 연속적인 요청 사이에 커넥션을 닫지 않음. 기존 연결에 대해서 handshake 생략 가능
• Pipelining: 이전 요청에 대한 응답이 완전히 전송되기 전에 다음 전송을 가능하게 하여, 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방식
• HOST 헤더 추가: 동일 IP 주소에 다른 도메인을 호스트하는 기능 
• Chunk Encoding 전송
• 바이트 범위 요청
• 캐시 제어 메커니즘 도입 

 

Persistent Connection (keep-alive)

HTTP는 TCP 연결 기반 위에서 동작하는 프로토콜로, 신뢰성 확보를 위해 연결을 맺고 끊는데 있어서 3-way Handshake가 이루어진다.

그런데 HTTP는 기본적으로 비연결성 프로토콜이기 때문에 한번의 요청과 응답을 하고 응답이 끝나면 연결을 끊어버리는데, 자원을 요청할때마다 연결을 맺고 끊어버려 오버헤드(overhead)가 생기게 된다. 

 

그래서 HTTP/1.1에서 Persistent Connection 기능이 추가됨으로써, 한번 맺어졌던 연결을 끊지 않고 지속적으로 유지하여 불필요한 Handshake를 줄여 성능을 개선하였다. 

• 연결을 유지함으로써 Handshake 과정을 생략해 빠르게 지원을 받아올 수 있다.
• 불필요한 연결의 맺고 끊음을 최소화시켜 네트워크 부하를 줄일 수 있다.
• 클라이언트 측에서 요청에 keep-alive 헤더를 담아 보내야 한다.
• 정확한 Content-Length 헤더를 사용해야 한다. 하나의 connection을 계속해서 재사용해야 하는데, 특정 요청의 종료를 판단할 수 없기 때문이다.
• Connection 헤더를 지원하지 않는 proxy 에는 사용할 수 없다.

Pipelining

파이프라이닝은 여러개의 요청을 보낼때 처음 요청이 응답될 때까지 기다리지 않고 요청을 한꺼번에 보내는 것을 의미한다. 즉, 여러개의 요청을 한꺼번에 보내서 응답을 받음으로써 대기시간을 줄이는 기술이다. 

• keep-alive를 전제로 하며, 서버 간 요청의 응답속도를 개선시키기 위해 적용
• 서버는 요청이 들어온 순서대로(FIFO) 응답을 반환한다.
• 하지만 응답 순서를 지키기 위해 응답 처리를 미루기 때문에 HOLB(Head Of Line Blocking) 문제가 발생했다. 그래서 모던 브라우저들은 대부분 파이프라이닝을 사용하지 못하게 막아놨다. 
• HTTP/2.0 에서는 멀티플렉싱 알고리즘을 대체되었다. 

 

HTTP/1.1 문제점

HOLB (Head Of Line Blocking)

위에서 소개한 Pipelining은 어찌보면 정말 혁신적인 기술이지만, 보낸 요청 순서내돌 응답을 받아야하는 규칙 부분에서 문제가 생기게 된다. 

마치 FIFO(선입선출)처럼 생각하면 되는데, 문제는 요청하는 데이터의 크기가 제각각이기 때문에, 우선순위 원칙에 따라 첫번째 데이터의 응답 속도가 늦어지면 후순위에 있는 데이터의 응답속도도 덩달아 늦어지게 되는 것이다.

 

RTT (Round Trip Time)

RTT란 요청(SYN)을 보낼 때부터 요청에 대한 응답(SYN+ACK)을 받을 때까지의 왕복 시간을 의미한다.

즉, 아무리 keep-alive 라고 하지만 결국 TCP 상에서 동작하는 HTTP의 특성상 Handshake가 반복적으로 일어나게 되어 불필요한 RTT 증가로 인해 네트워크 지연을 초래하여 성능이 저하되게 된다.

예전에는 컨텐츠가 지금처럼 많지 않았기에 큰 부담은 아니었지만, 점점 컨텐츠가 증가함에 따라 이러한 레이턴시도 부담스러워졌다.

 

무거운 헤더 구조와 중복

HTTP/1.1의 헤더에는 많은 메타정보들이 저장되어 있다. 또한 해당 도메인에 설정된 쿠키 정보도 매 요청시마다 헤더의 포함되어 전송되기 때문에 오히려 전송하려는 값보다 헤더 값이 더 큰 경우가 비일비재하였다.

그리고 Persistent Connection 속에서 주고받는 연속된 요청 데이터가 중복된 헤더값을 가지고 있는 경우가 많아 메모리 자원도 쓸데없이 낭비하게 되는 꼴이 되었다. 

 

 

References 

https://inpa.tistory.com/entry/WEB-🌐-HTTP-09-HTTP-30-까지-알아보는-통신-기술

https://mark-kim.blog/HTTP_0_9_to_1_1/