HTTP 개관 및 버전별 특징 [webserv 개념 1-1]

HTTP의 정의

HTTP는 HTML 문서와 같은 리소스를 가져올 수 있도록 해주는 프로토콜입니다.
여기서 HTTP 요청의 대상을 "리소스"라고 하며, HTTP는 리소스의 특성을 제한하지 않습니다.
다만, 리소스와 상호 작용하는 데 사용할 수 있는 인터페이스를 정의할 뿐입니다.
대부분의 리소스는 URI(Uniform Resource Identifier)로 식별됩니다.
클라이언트-서버 프로토콜 : 수신자(거의 웹브라우저)에 의해 요청이 초기화 되는 프로토콜을 말합니다.

HTTP의 특징 : 요청(Request)과 응답(response)으로 통신 한다.

• 요청은 일반적으로 브라우저지만, 검색엔진 인덱스 채우는 로봇인 경우도 존재합니다.
• 요청과 응답 사이에는 여러 개체들이 있습니다.( 예 : 게이트웨이 또는 캐시 역할을 하는 프록시 )
• 브라우저는 항상 요청을 보내는 개체입니다.
• HTTP는 애플리케이션 계층의 프로토콜입니다. → 아래 계층의 TCP연결(또는 TLS)을 활용해서 전송
• HTTP는 TCP 표준에 의존합니다.(신뢰할 수 있는 연결을 의미합니다.)

HTTP 동작 흐름

1. TCP연결을 엽니다. (요청을 보내거나 받기 위해서) - 기존 연결 재사용 또는 서버에 대한 여러 TCP연결 가능
2. HTTP메세지 전송
3. 서버에 의해 전송된 응답을 읽어들입니다.
4. 연결을 닫거나 다른 요청들을 위해 재사용 합니다.

HTTP 사용하여 제어 가능한 일반적인 기능

1. 캐싱

서버는 (캐시 대상과 기간)을 (프록시와 클라이언트)에게 지시할 수 있고, 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에 지시할 수 있습니다.

2. origin 제약사항을 완화하기

브라우저는 보안을 위해 동일한 origin으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근할 수 있습니다. 단, 이런 제약은 서버에게 부담되나 HTTP 헤더를 통해서 해당 제약을 완화할 수 있습니다.

3. 세션

쿠키 사용은 서버 상태를 요청과 연결하도록 해줍니다. 쿠키를 이용해서 세션 만들기 가능합니다.

4. 그외

인증 , 프록시와 터널링 (en-US) 등의 기능을 지원합니다. 이번 게시물에서는 이 내용들을 하나씩 자세히 다루진 않겠습니다. 각각의 주제로 필요하다면 추후 게시물로 다루도록하겠습니다.

버전별 특징

이 글 아래 내용은 TCP 통신 방식과 HTTP 쪽의 이해가 필요합니다. TCP/IP 네트워크 프토토콜의 개념이 부족하면 아래 글이 이해가 가지 않을 수 있습니다. 이해가 가지 않아도 이런게 있구나 하는 편안한 마음으로 읽어주시길 바랍니다. 추후에 네트워크 프로그래밍 관련 게시물도 다루도록 하겠습니다.

HTTP/1.0

각 요청/응답에 대해 별도의 TCP 연결을 여는 것이 HTTP 1.0의 기본 동작입니다.
TCP Connection당 하나의 URL만 fetch하며, 매번 request/response가 끝나면 연결이 끊기므로 필요할 때마다 다시 연결해야하는 단점이 있어 속도가 매우 느립니다.
그러므로 여러 요청을 연속해서 보내는 경우에는 단일 TCP연결을 공유하는 것보다 효율적이지 못하다는 단점이 있습니다.
또한, URL의 크기가 작고 한번에 가져올 수 있는 데이터의 양이 제한되어있습니다.
서버의 입장에서도 부담이 커져서, 과부하가 걸리고 성능이 떨어져서 해결하기 위해서 HTTP1.1 이 등장했습니다.

HTTP/1.1

1997년에 만들어졌습니다. 현재까지 웹에서 사용 되고 있는 방식입니다.

출처 : https://en.wikipedia.org/wiki/HTTP_pipelining

파이프라이닝

• HTTP/1.1은 파이프라이닝 개념과 지속적인 연결의 개념을 도입해서 HTTP 1.0의 단점을 개선했습니다.
• 기본적인 TCP 연결은 [Connection](<https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Connection>) 헤더를 사용해 부분적으로 제어할 수 있습니다.
• HTTP 파이프라이닝이 활성화되면, 첫번째 응답을 완전히 수신할 때까지 기다리지 않고 여러 요청을 보낼 수 있습니다. (단, 현재는 파이프라이닝은 거의 소실된 기술 입니다.)

HTTP 파이프라이닝은 HTTP/1.1에 도입되었지만, 여러 문제로 인해 점차 사용이 줄었습니다. 특히, 요청 및 응답의 순서가 어긋나는 경우가 발생할 수 있으며, 이로 인해 지연 및 불안정성이 생길 수 있습니다. 이러한 문제로 인해, 대부분의 웹 서버 및 클라이언트는 HTTP 파이프라이닝을 사용하지 않습니다.
대신 HTTP/2와 HTTP/3는 멀티플렉싱을 도입하여, 파이프라이닝 없이도 여러 요청과 응답을 동시에 처리할 수 있도록 개선했습니다. 이 기술은 요청 및 응답의 순서를 유지하면서도 지연을 최소화할 수 있어, 파이프라이닝보다 더 안정적이고 효율적입니다.

 

호스트 헤더(Host Header)

HTTP 1.0은 하나의 IP 주소에 여러 개의 도메인을 운영 할 수 없었습니다. 따라서 도메인 별로 IP를 구분해서 준비해야 하기 때문에 서버의 개수가 늘어나야 했습니다. 하지만 HTTP 1.1은 가상 호스팅(Virtual Hosting)이 가능해졌기 때문에 하나의 IP 주소에 여러 개의 도메인을 적용시킬 수 있습니다.

• HTTP 1.1은 다음과 같은 2개의 header가 추가되었습니다.
  • proxy-authorization
  • proxy-authentication

단, 실제 서버에서 클라이언트 인증을 요구하는 www-authentication 헤더는 HTTP 1.0부터 지원 됐으나, 서버와 클라이언트 사이에 프록시가 위치하는 경우 프록시가 사용자의 인증을 요구할 수 있는 방법이 없어서 HTTP/1.1 부터 제대로 적용 됐습니다.
 

HTTP 파이프라인의 한계

HTTP/1.1은 HTTP파이프라인 구조를 이용해서 이전요청의 완료를 기다리지 않고 다음 요청을 전송할 수 있습니다.
그러나, HTTP 파이프라인에는 "서버는 요청 순서대로 리스폰스를 반환해야 한다" 라는 제한이 있습니다.
예를 들어, 5개 요청 중 첫 번째 요청 처리가 느린 경우, 두 번째 요청은 대기 상태(헤드오브라인 블로킹)가 되어서 결과적으로 전체의 속도가 느려지는 상황이 생깁니다.
상황이 이렇다 보니 파이프라인은 오페라 브라우저를 제외하고 대부분의 모던 브라우저가 기본으로 OFF 되어 있어 안타깝게도 거의 이용되고 있지 않은 실정입니다.

HTTP/2

출처 : https://www.wallarm.com/what/what-is-http-2-and-how-is-it-different-from-http-1

HTTP/2 는 2015년에 만들어졌습니다. HTTP/2는 HTTP/1.1 제작자가 예상하지 못한 몇 가지 문제를 해결하고자 만들어졌습니다.
HTTP/2가 더 빠른 이유는 로드 프로세스 중에 콘텐츠의 우선순위를 지정하는 기능 덕분입니다.

우선순위 지정(Prioritization)이란?

HTTP/2에서는 가중치 우선순위 지정이라는 기능이 제공됩니다. 이를 통해 개발자는 매번 먼저 로드할 페이지 리소스를 결정할 수 있습니다.
웹 성능의 맥락에서 우선순위는 콘텐츠가 로드되는 순서를 나타냅니다.
예를 들어, 사용자가 뉴스 웹 사이트를 방문하여 기사로 이동한다고 가정해 보겠습니다. 기사 상단의 사진이 먼저 로드되어야 할까요?기사의 텍스트가 먼저 로드되어야 할까요?배너 광고가 먼저 로드되어야 할까요?
이런 상황에서 HTTP/2에서 개발자는 우선순위 지정을 직접 세부적으로 제어할 수 있습니다. 실제 페이지 로드 속도를 HTTP/1.1에서는 불가능했던 수준까지 최대화할 수 있습니다. 개발자는 더 중요하고 작은 데이터를 먼저 로드해서, 사용자의 페이지 사용 경험을 향상 시킵니다.

멀티 플렉싱

HTTP/2는 하나의 TCP 연결을 통해 여러 요청(데이터 스트림)과 응답을 동시에 전송할 수 있는 멀티플렉싱 기능을 제공합니다. 이를 통해 지연이 줄어들고 대역폭이 효율적으로 사용됩니다.
개발자는 이러한 각 데이터 스트림에 서로 다른 가중치 값을 할당할 수 있으며, 이 값은 클라이언트에 먼저 렌더링할 데이터 스트림을 알려줍니다. (이 기능이 위에 말했던 우선순위 지정 기능입니다.)
 

그 외 기능

• 헤더 압축: HTTP/2는 헤더 필드를 압축하는 HPACK 알고리즘을 사용하여 요청과 응답의 크기를 줄입니다. 이로써 네트워크 전송이 더 빠르고 효율적으로 이루어집니다.
• 서버 푸시: 서버는 클라이언트의 요청에 대해 응답하는 것 외에, 클라이언트가 필요할 것 같은 추가 리소스를 미리 푸시할 수 있습니다. 이는 클라이언트가 추가 요청을 하지 않아도 필요한 리소스를 받을 수 있어 성능을 향상시킵니다.
• 이진 프레이밍: HTTP/2는 이진 프레이밍을 사용하여 데이터를 효율적으로 전송합니다. 이진 형식은 텍스트 기반 형식보다 더 안정적이고 효율적입니다.
• HTTP 메시지(HTTP/2 이전)는 인간이 읽을 수 있습니다. (2부터 암호화)

HTTP/3

HTTP/3의 중요한 차이점은 새로운 전송 프로토콜인 QUIC에서 실행된다는 것입니다.
QUIC은 사람들이 하루 종일 이동하면서 끊임없이 네트워크를 전환하는 모바일 중심의 인터넷 사용을 위해 설계되었습니다.
최초의 인터넷 프로토콜이 개발될 당시에는 기기의 휴대성이 떨어지고 네트워크를 자주 전환하지 않았기 때문에 현대의 개념에 맞게 설계된 프로토콜입니다.
QUIC을 사용한다는 것은 HTTP/3가 전송 제어 프로토콜(TCP)이 아닌 사용자 데이터그램 프로토콜(UDP)에 의존합니다.
HTTP/2가 2015년에 나왔기때문에 아직 불안정하고 많이 안 쓸것이라고 생각했었지만, 국내에서는 네이버가 2022년에 처음으로 도입하고 구글, 토스 등 빅테크 기업들은 진작에 도입해서 실제 프로덕트에서도 사용하고 있습니다.

• QUIC 프로토콜: HTTP/3는 TCP 대신 QUIC 프로토콜을 사용합니다. QUIC는 UDP를 기반으로 하며, TCP의 전송 지연 문제를 해결하기 위해 개발되었습니다.
• 스트림 분리: HTTP/3는 QUIC의 멀티플렉싱 기능을 활용하여 각 요청과 응답을 독립된 스트림으로 처리합니다. 이를 통해 하나의 스트림에서 문제가 발생하더라도 다른 스트림은 영향을 받지 않습니다.
• 연결 재사용: QUIC는 재연결 시 빠르게 재사용할 수 있는 기능을 제공하여 연결 설정 시간을 단축하고 안정성을 향상시킵니다.
• TLS 통합: HTTP/3는 보안을 위해 TLS를 기본적으로 사용하며, QUIC 프로토콜과 통합되어 보안 연결을 더 빠르게 설정할 수 있습니다.

 
https://www.cloudflare.com/ko-kr/learning/performance/what-is-http3/
https://www.wallarm.com/what/what-is-http-2-and-how-is-it-different-from-http-1