HTTP/1.0이란?

Sep 14, 2024

Contents

HTTP HTTP/1.1이란?기본적인 HTTP/1.1 작동 과정 네트워크 계층과 HTTP/1.1 HTTP/1.0의 문제점 HTTP/1.1의 문제점 - HoL HTTP/1.1의 문제점 - Not Encrypted 결론 참고 자료

HTTP

HTTP/1.0이란?
기본적인 HTTP/1.1 작동 과정
네트워크 계층과 HTTP/1.1
HTTP/1.0의 문제점
HTTP/1.1의 문제점 - HoL
HTTP/1.1의 문제점 - Not Encrypted
참고 자료

HTTP/1.1이란?

HTTP는 Hypertest Transfer Protocol의 약자로 클라이언트*와 서버*가 정보를 요청하고 보내는 데 사용하는 방법 중 하나입니다.

클라이언트(Client)* : 웹 사이트에 접속하는 사용자를 의미하며, 이 글을 보고 있는 당신(의 컴퓨터) 이라고 이해하여도 무방할 것 같습니다.
서버(Server)* : 웹 사이트에 접속할 때, 그 사이트에 대한 정보를 반환해주는 주체라고 이해하여도 무방할 것 같습니다.,

기본적인 HTTP/1.1 작동 과정

예를 들어, www.example.com이라는 웹 사이트를 방문한다고 생각해봅시다.
당신은 브라우저에 www.example.com을 입력하여 잠시 후에 예쁘게 꾸며진 웹사이트를 볼 것입니다.

이 경우에 웹사이트는 HTML, CSS, JavaScript로 구성되어 있습니다.

또한 웹사이트에 포함된 아이콘, 이미지, 동영상, 소리 등이 추가로 불러와지기도 할 것입니다.
이 경우 F12 등의 단축키로 개발자 모드를 활성화하여 불러오는 데이터들을 확인 가능합니다.

당신이 실제로 www.example.com에 접속을 하면 다음과 같은 통신이 이루어집니다.

GET /index.html HTTP/1.1
Host: www.example.com

위 통신으로 클라이언트는 서버로부터 HTML을 전달 받으며,
추가적으로 HTML에서 요청된 CSS, JavaScript, 이미지 등을 클라이언트에게 반환합니다.
즉, 서버는 여러 차례에 걸쳐서 클라이언트에게 데이터를 반환한다는 점입니다.

네트워크 계층과 HTTP/1.1

모두 알고 있듯이 네트워크 통신은 OSI 7 계층을 오가며 진행되게 됩니다.
각 계층은 본인이 필요한 정보와 다음 계층이 필요한 정보로 구성되어 있습니다.
1계층인 물리적 계층에서부터 7계층인 응용 계층까지 점점 더 적은 정보를 담고 있으며 이 과정을 디캡슐레이션(Decapsulation)으로 부르며 그 반대를 캡슐레이션(Capsulation)이라 부릅니다.

구체적으로 네트워크 통신을 하게 되면
클라이언트가 서버로 요청을 보낼때 7계층에서 2계층까지 인켑슐레이션이 이루어집니다.
이후 공용 인터넷을 통해서 서버로 도착하여 2계층부터 7계층까지 디캡슐레이션을 합니다.

아래 그림을 보면 조금 더 쉽게 이해할 수 있을 것입니다. — [Ref]
Data Link, Network, Transport는 각각 2, 3, 4 계층이며 Application이 7계층입니다.

HTTP/1.0의 문제점

앞서 기본적인 HTTP/1.1 작동 과정에서
클라이언트는 서버로부터 여러 차례에 나누어서 HTML, CSS 등을 받음을 배웠습니다.

최초에 나온 HTTP/1.0은 모든 새 요청에 대해서
TCP 연결을 끊고 새롭게 연결하므로 시간 및 비용 측면에서 비효율적이었습니다.

HTTP/1.1에서는 Persistent Connection과 Pipelining을 사용하여 이 문제를 해결하였습니다.

Persistent Connection : TCP Connection이 직접적으로 닫힐 것(closed)을 말하지 않는다면, TCP Connection이 유지 됩니다.
Pipelining : 복수의 HTTP Request가 Pipeline을 통해서 병렬적으로 요청이 전달됩니다.
- A, B, C Request → A, B, C Response
  (응답 순서는 매번 다름)

HTTP/1.1의 문제점 - HoL

HTTP/1.1 Pipeline은 HoL(Head of Line) 문제가 있습니다.
Pipeline은 서로 독립적인 N개의 요청을 큐를 통해서 제어하기 때문에, 단 1개의 요청이라도 필요한 리소스를 검색할 수 있으면 그 뒤의 모든 요청이 차단되는 상황이 있습니다.

예를 들어 A → B → C 순으로 요청을 보내지만
A 요청이 무한 Pending 상태에 빠진다면 B, C도 마찬가지로 Pending에 빠지게 됩니다.

이러한 문제점은 HTTP/2.0에서 해결되었습니다.