HTTP 버전 별 차이의 필요성

HTTP가 모든 버전이 동일한 기능을 갖는 것은 아니다.

 

예를 들어서 WebSocket 등에 사용되는 장기 연결은 HTTP 1.1부터 지원되는 기능이기도 하다.

또한 모든 HTTP 버전이 GET, POST 등등 모든 HTTP 메서드를 지원하는 것도 아니다.

 

즉 각 HTTP 버전에는 명확한 차이가 있고 통신 및 연결 유지 등에도 명확한 차이가 있다.

따라서 이번에는 각 HTTP 버전의 특징들에 대해서 알아볼 예정이다.

 

HTTP/0.9 - 원 라인 프로토콜

해당 버전에는 버전 번호가 부여되어 있지 않다.

0.9라는 숫자는 이후 버전과 구분하기 위해 붙은 구분자일 뿐이다.

단순한 요청을 지원

우선 명확한 특징들을 이처럼 나타낼 수 있다.

  • 지원 메서드 : GET
  • HTTP 버전 : HTTP 버전 번호가 없기 때문에 버전 명시 불필요
  • HTTP 헤더 : HTTP 헤더를 지원하지 않는다

따라서 이처럼 요청을 보내면 된다.

GET /test.html

단순한 응답을 지원

응답도 요청과 마찬가지로 단순하다.

  • 응답 코드 : 응답 코드가 없고 오직 html 파일만 전송함
  • 응답 헤더 : 요청과 마찬가지로 응답 헤더가 없음
  • 통신 중 문제 발생시 문제에 대한 설명을 담은 html 전송

따라서 다음과 같은 응답이 전송된다.

<html>
  HTML Page
</html>

 

HTTP/1.0 - 확장성 GOAT

기존 버전은 단순한 데이터 처리에는 문제가 없지만, 확장성이 부족했다.

따라서 HTTP/1.0은 이전 버전에 비해서 확장성 측면에서 높은 성취를 이룬다.

기존 버전의 HTTP 요청 / 응답에 비해 확장된 기능

우선 아래와 같이 기존 버전에 비해서 더 많은 기능들을 지원한다.

  • 지원 메서드 : GET, HEAD, POST
  • HTTP 버전 : HTTP 버전 정보를 명시함
  • HTTP 헤더 : HTTP 헤더를 지원함

따라서 요청 시 다음과 같이 전송할 수 있게 된다.

GET /test.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

 

또한 아래와 같이 기존 버전의 응답 메세지의 문제를 해소한다.

  • 응답 코드 : 응답 상태에 따라 시작 부분에 응답 코드를 붙여서 전송
  • 응답 헤더 : Content-Type와 같은 응답 헤더 덕분에 다양한 종류의 문서 전송이 가능해짐 
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

Connection 방식과 한계

HTTP 1.0은 short-lived Connection 방식을 사용한다.

 

즉 connection은 응답 직후에 종료된다.

따라서 아래 그림과 같이 각 요청마다 새로운 연결을 생성해야 한다.

즉 위 그림과 같이 HTTP/1.0은 매 요청마다 3-way-handshake를 통해서 세션을 수립하고, 응답을 수신한 후 4-way-handshake를 통해 세션을 종료하는 구조이기 때문에 오버헤드가 크다.

 

HTTP/1.1 - 표준성 GOAT

HTTP/1.1은 1.0에 비해서 보다 확장되고 안정적인 기능들을 제공한다.

HTTP/1.1의 주요 특징들

기존 버전에 비해서 HTTP 메서드 지원이 확대됨

  • GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE

청크 전송 인코딩을 지원함

  • Content-Length 없이 동적 데이터 전송이 가능하고 스트리밍과 비동기 응답 처리에 유용

Upgrade 헤더 지원

  • WebSocket 등의 다른 프로토콜로 전환 가능

정교한 캐시 제어 매커니즘 도입

  • Cache-Control, Etag 등이 도입됨

언어, 타입, 인코딩 등의 콘텐츠 협상

  • Accept, Accept-Encoding, Accept-Language 헤더 지원

Host 헤더를 통해 가상 호스팅 지원

  • 하나의 IP 주소로 여러 도메인 처리 가능

따라서 다음과 같은 보다 정교한 요청-응답이 가능하다.

GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

Persistent Connection 지원

다음으로 기존 버전과 달리 지속적인 connection을 지원한다.

해당 connection은 keep-alive에서 설정한 시간동안 지속된다.

 

아래 그림은 Persistent Connection의 통신 방식을 나타낸다.

이처럼 기존 방식과 달리 3-way-handshake와 4-way-handshake가 각 요청-응답마다 나타나는 것이 아닌 Connection 종료 후 나타나기에 오버헤드가 상당히 감소했다.

HTTP Pipelining 지원

다음으로 HTTP/1.1부터 파이프라이닝을 지원한다.

파이프라이닝은 요청에 대한 응답을 받기 전에 새로운 요청을 전달할 수 있는 기술이기에 통신 지연 단축에 큰 도움이 된다.

 

아래 그림은 HTTP Pipelining에 대한 통신 방식이다.

이처럼 요청에 대한 응답이 오기 전에 새로운 요청을 전송하는 것을 볼 수 있다.

HTTP/2 - 향상된 성능

HTTP/2는 구글의 실험적 프로토콜인 SPDY의 영향을 많이 받았다.

이에 따라서 응답성 증가 및 중복 데이터 전송을 해결한 보다 향상된 성능을 지원하는 버전이다.

HTTP/2의 주요 특징

바이너리 프로토콜

  • 텍스트 기반 프로토콜이 아닌 바이너리 프로토콜이기에 파싱 및 처리가 빠르고 효율적이다

multiplexed stream

  • 하나의 연결로 병렬 요청 수행이 가능하기에 HOL Blocking을 해결함
  • HTTP/1.1의 파이프라이닝은 요청은 병렬 전송이 가능하지만 응답은 순서대로 받아야하기 때문에 HOL Blocking이 자유롭지 못했지만, HTTP/2는 해당 문제를 해결한다.

stream priortization

  • 리소스 간 우선순위를 설정하여 필요한 리소스부터 전송한다

향상된 압축 지원

  • autometic compressing을 통해서 gzip 압축을 자동으로 지원
  • 헤더 압축(HPACK)을 지원하여 전송 데이터의 중복과 오버헤드를 최소화함

Server Push

  • 서버 푸시를 통해 클라이언트 캐시에 데이터 저장이 가능하다
  • 서버는 요청하지 않은 리소스도 클라이언트에 보내줄 수 있음

Alt-Svc

  • CDN 연결 최적화
  • 클라이언트가 동일한 컨텐츠를 다른 프로토콜 및 서버로 요청 가능

보안 및 쿠키 개선

  • 쿠키 헤더 접두사를 통해 보안 속성 강화

 

HTTP/3 - QUIC을 통한 확장

HTTP/3의 주요 특징

quic 사용

  • transport layer에서 tcp가 아닌 UDP 기반의 quic를 사용함

quic는 UDP 기반이기에 여러 스트림을 동시 실행 및 독립적 패킷 손실 감지 및 재전송이 가능하다

=> 오류 패킷의 데이터 스트림만 차단된다.

 

마무리

마지막으로 HTTP 버전은 높을수록 좋은 것 같은데 왜 굳이 낮은 버전을 사용하는 경우도 있는지가 궁금해졌고 이에 대해 조사했다.

 

조사 결과 해당 부분은 호환성과 관련이 있었다.

 

모든 클라이언트가 높은 버전의 HTTP를 지원하는 것이 아니기 때문에 상황에 따라서 맞춰서 사용해야 할 것이다.

이런 상황에서 적절한 HTTP 버전과 그에 호환되는 기술 선정은 필수적이다.

예를 들어서 HTTP/1.0만 지원하는 클라이언트에서 웹소켓을 사용하기로 했다면, 이는 심각한 설계 문제로 이어질 수 있다.

또한, HTTP/3는 UDP 기반인데 이는 TCP 기반의 시스템에서 사용이 제한될 수 있다.

 

즉 오히려 상황에 맞는 적절한 HTTP 버전 설정이 중요할 것이고 서비스의 호환성 및 성능등을 고려하여 최적의 HTTP 버전을 선택하는 것이 중요할 것이다

 

 

'CS 및 기본 개념' 카테고리의 다른 글

[ Java 공식문서 ] Java 동시성 프로그래밍 2 : Synchronized  (4) 2025.08.06
[ Java 공식문서 ] Java 동시성 프로그래밍 1 : Thread  (3) 2025.08.04
[ NGINX ] NGINX를 리버스 프록시로 사용하는 WebSocket 시스템 구축  (6) 2025.07.30
[ AWS ] CDN (CloudFront) 으로 S3 정적 파일 관리하기  (3) 2025.07.23
[ CS ] 네트워크 주요 포트번호와 그 사용처  (3) 2025.07.22

티스토리툴바