2021년 2월 24일 수요일

[HTTP] HTTP 1.0 과 HTTP 1.1 의 큰 차이점

최근 HTTP 강좌라는 주제로 블로그에 포스팅 한 내용을 좀 살펴봤는데 HTTP 1.0 과 HTTP 1.1 의 차이에 대해 정리해 놓은 게 없음을 알았다. 

필자가 생각보다 현업에서 신입 또는 대리급의 경력직을 인터뷰할 때 즐겨 묻는 주제이기도 하고 HTTP/2 에 대해서 포스팅 하려고 준비 중에 있는데 내용을 이해하고 있는게 좋을 것 같기도 하고 해서 포스팅 해 본다.

과거 사회에 첫발을 내딛고 웹 캐시(Web Cache) 서버를 기술 지원 하는 엔지니어가 되어 가는 과정에서 수학의 정석처럼 읽어 보았던 자료에 의하면 HTTP 1.1 의 가장 큰 특징은 다음 3가지로 표현하고 있다. 

  1. 커넥션 유지 (Persistent Connection)
  2. 호스트 헤더 (Host Header)
  3. 강력한 인증 절차 (Improved Authentication Procedure)


위 3가지에 대해 정리해 보자. 

1. 커넥션 유지 (Persistent Connection)

HTTP 프로토콜은 클라이언트-서버 간 데이터를 주고 받는 응용 계층의 프로토콜이다. 
HTTP 를 이용한 데이터 전달은 TCP 세션 기반에서 이루어 진다. 

HTTP 1.0 과 1.1 의 차이는 TCP 세션을 지속적으로 유지할 수 있느냐? 없느냐에 차이를 둔다. 
아래 그림을 참고하면 이해가 쉽다. 




위 그림과 같이 HTTP 1.0 은 요청 컨텐츠마다 TCP 세션을 맺어야 한다. 
(1 GET / 1 Connection)
이와 다르게 HTTP 1.1 은 Persistent 기능을 이용하여 한개의 TCP 세션을 통해 여러개의 컨텐츠 요청이 가능하다. 
(N GET / 1 Connection)

이 차이점으로 통해 서버는 TCP 세션 처리 부하를 줄일수 있기에 좋고, 그만큼 클라이언트는 응답속도가 개선되어 좋다. 

1-1. 파이프라이닝 (Pipelining)

Persistent 기능을 통한 커넥션 유지와 함께 HTTP 1.1 에서 지원되는 기능이 하나 더 있다. 
바로 "파이프라이닝(Pipelining)" 이다. 

해당 기능은 먼저 아래 그림을 보면 이해가 쉽다. 


HTTP 요청은 순차적으로 이루어진다. 
위 그림(왼쪽)과 같이 3개의 컨텐츠를 요청한다고 가정하면 파이프라이닝 기능이 없는 경우.. 
요청#1 -> 응답#1 -> 요청#2 -> 응답#2 -> 요청#3 -> 응답#3 
과 같이 진행된다. 

즉, 요청#1에 대한 응답#1을 정상적으로 받아야만 다음 요청#2가 진행되고, 마찬가지로 응답#2를 받아야 요청#3이 진행된다. 

어떠한 이유로 응답#1이 없는 경우라면 요청#2, 요청#3은 진행되지 못하게 되어 문제가 된다. 
설사 문제가 없더라도 상식적으로 비효율 적이란 것을 느낄 수 있을 것이다. 

파이프라이닝은 이를 개선한 기능이다. 
위 그림(오른쪽)과 같이 동시에 요청#1,요청#2,요청#3을 보내고 이에 대한 각각의 응답을 받아 처리한다. 

이는 응답 속도를 높혀 페이지 뷰의 속도를 빠르게 할 수 있는 기능이다. 



2. 호스트 헤더 (Host Header)

버츄얼 호스팅이라고 들어봤으리라 생각한다. 
HTTP 1.1로의 발전이 없었다면 불가능한 서비스이다. 
HTTP 1.0 환경에서는 하나의 IP에 여러 개의 도메인을 운영할 수 없다. 
도메인 마다 IP를 구분해서 준비해야 한다. 도메인만큼 서버의 개수도 늘어날 수 밖에 없는 구조이다. 

HTTP 1.1 에서 Host 헤더의 추가를 통해 비로소 버츄얼 호스팅이 가능해졌다. 
버츄얼 호스팅은 아래 그림과 같으니 참고하면 좋겠다. 



3. 강력한 인증 절차 (Improved Authentication Procedure)

HTTP 1.1 에서 다음 2개의 헤더가 추가되었다. 
  • proxy-authentication
  • proxy-authorization
실제 서버에서 클라이언트 인증을 요구하는 www-authentication 헤더는 HTTP 1.0 에서부터 지원 되어 왔으나, 클라이언트와 서버 사이에 프록시가 위치하는 경우 프록시가 사용자의 인증을 요구할 수 있는 방법이 없었다. 

위 헤더에 대한 상세 내용은 기존 강좌를 참고하면 좋겠다. 

인증 관련 헤더 내용 : [여기]를 클릭하세요


-끝-

댓글 1개: