HTTP란 무엇인가?

HTTP는 클라이언트와 서버가 서로 통신하는 방법을 표준화하는 TCP/IP 기반 애플리케이션 계층 통신 프로토콜이다.

HTTP는 인터넷에서 데이터를 주고받기 위해 사용되는 프로토콜이다. 클라이언트와 서버 간의 통신을 담당하며, 웹 브라우저와 웹 서버 간의 데이터 전송을 위해 주로 사용된다.

HTTP는 요청(Request)과 응답(Response)의 형태로 이루어져 있다. 클라이언트는 HTTP 요청 메시지를 서버에 전송하고, 서버는 이 요청에 대한 응답 메시지를 클라이언트에게 전송한다. 요청과 응답은 각각 헤더와 바디로 구성된다. 헤더는 요청이나 응답에 대한 메타데이터를 포함하고, 바디는 요청이나 응답에 대한 실제 데이터를 포함한다.

여담으로 HTTP는 잘못된 이름이라고 한다!!😮
하이퍼 텍스트라는 용어는 잘못되었고 HMTP 또는 Hypermedia 전송 프로토콜이 합리적이라고 한다.
하지만 이미 HTTP라는 이름으로 굳어버린지 오래되었다고..

HTTP의 특징

1. Stateless(무상태): HTTP는 상태를 유지하지 않는 프로토콜이다. 각각의 요청은 독립적으로 처리되며, 이전 요청과의 연결이나 상태를 기억하지 않는다.

2. Connectionless(비연결성): HTTP는 요청과 응답이 한 번 이루어지면 연결이 종료된다. 각각의 요청은 독립적으로 처리되기 때문에 연결을 유지할 필요가 없다.

3. Request-Response 모델: HTTP는 클라이언트가 요청을 보내고 서버가 응답을 반환하는 형태의 모델을 따른다. 클라이언트는 요청 메서드(GET, POST, PUT, DELETE 등)를 사용하여 원하는 동작을 서버에 전달하고, 서버는 상태 코드와 데이터를 포함한 응답을 반환한다.

4. URI(Uniform Resource Identifier): HTTP는 리소스를 식별하기 위해 URI를 사용한다. 클라이언트는 URI를 통해 서버에 요청할 리소스를 지정한다. URI는 URL(Uniform Resource Locator)이라는 특정한 형태의 식별자로 표현된다.

HTTP/0.9 - 원 라이너

HTTP의 첫 번째 문서화된 버전은 1991년에 제시된 HTTP/0.9였다. 이것은 가장 단순한 프로토콜이었고 GET이라는 단일 메서드가 존재한다. 클라이언트가 서버의 일부 웹 페이지에 접근해야 하는 경우 아래와 같은 단순한 요청을 수행했을 것이다.

GET /index.html

서버의 응답은 다음과 같다.

(response body)
(connection closed)

즉, 서버는 요청을 받고 응답으로 HTML을 응답하며 콘텐츠가 전송되는 즉시 연결을 끊는다.

• 헤더 없음

• "GET"이 유일한 방법

• 응답은 HTML로 고정

HTTP/1.0 - 확장성 만들기

HTTP/1.0은 초기 버전의 HTTP 프로토콜로, 1996년에 처음 소개되었다. HTTP/1.0은 웹 브라우저와 웹 서버 간의 기본적인 데이터 전송을 처리하는 데 중점을 두고 있다.

HTTP/1.0 특징

1. 비지속적 연결(Non-Persistent Connection): 요청과 응답 후에 연결을 닫는 비지속적 연결 방식을 사용한다. 클라이언트는 각각의 요청마다 새로운 연결을 맺어야 한다. 이로 인해 연결 설정/해제에 대한 오버헤드가 발생해 성능상의 문제가 있다.

2. 요청 메시지의 단순성: 요청 메시지는 단순한 구조를 가지고 있다. 요청 메시지에는 요청 메서드, 헤더, 바디 등의 정보가 포함된다. 하지만 헤더의 기능이 제한적이고, 다양한 요청 형태와 추가 기능에 대한 확장성이 부족하다.

3. 상태 코드: 상태 코드를 사용하여 요청의 성공, 실패, 리다이렉션 등의 상태를 나타낸다. 일반적으로 2xx는 성공, 3xx는 리다이렉션, 4xx는 클라이언트 오류, 5xx는 서버 오류를 나타내는 상태 코드를 사용한다.

4. 캐싱: 캐싱 기능을 지원한다. 서버는 응답에 캐시 지시자(Cache-Control, Exires 등)를 포함하여 클라이언트 측에서 콘텐츠를 캐시할 수 있도록 한다. 이를 통해 동일한 요청에 대한 응답을 반복적으로 전송하지 않고 캐시된 데이터를 사용할 수 있다.

5. 보안: 보안 기능에 대한 내장 지원이 제한적이다. HTTPS와 같은 보안 프로토콜이나 암호화 기능은 추가로 구현해야 한다.

HTTP/1.0은 초기의 웹 통신을 위한 기본적인 프로토콜이었지만, 비효율적인 연결 관리와 확장성의 한계 등의 제한사항이 있었다. 이후 HTTP/1.1과 HTTP/2.0의 등장으로 이러한 제한사항을 극복하고 효율적인 웹 통신을 위한 개선이 이루어졌다.

HTTP/1.0의 단점

HTTP/1.0의 단점 중 하나는 연결당 여러 요청을 가질 수 없다는 것이다. 즉, 클라이언트가 서버로부터 무언가를 필요로 할 때마다 새로운 TCP연결을 열어야 하며 단일 요청이 이행된 후 연결이 닫힌다. 그리고 다음 요구 사항을 위해 새 연결이 필요하다.

만약 10개의 이미지, 5개의 스타일시트, 5개의 자바스크립트 파일이 있는 웹 페이지를 방문하여 해당 웹페이지에 대한 요청이 있을 때 서버는 요청이 완료되는 즉시 연결을 종료하므로 총 20개의 개별 연결이 필요하다.

3 way handshake

단순한 형태의 3 way handshake는 모든 TCP 연결이 3 way handshake로 시작하여 클라이언트와 서버가 애플리케이션 데이터 공유를 시작하기 전에 일련의 패킷을 공유하는 것이다.

• SYN - 클라이언트가 임의의 숫자(예: x)를 선택하여 서버로 보낸다.

• SYN ACK - 서버는 임의의 숫자로 구성된 ACK 패킷을 클라이언트로 다시 전송하여 요청을 확인한다. 서버에서 선택한 y와 숫자 x+1(x는 클라이언트에서 보낸 숫자)

• ACK - 클라이언트는 서버에서 받은 숫자 y를 증가시키고 숫자 y+1과 함께 ACK 패킷을 다시 보낸다.

3 way handshake가 완료되면 클라이언트와 서버 간의 데이터 공유가 시작된다. 클라이언트는 마지막 ACK 패킷을 발송하자마자 애플리케이션 데이터 전송을 시작할 수 있지만 서버는 요청을 이행하기 위해 ACK 패킷이 수신될 때까지 기다려야 한다.

3 way handshake의 단점

HTTP는 상태 비저장 프로토콜이다. 즉, 서버는 클라이언트에 대한 정보를 저장하지 않기 때문에 각 요청은 서버가 이전 요청과는 관계 없이 자체적으로 요청을 수행하는데 필요해서 매번 요청이 필요하다. 그 결과 클라이언트가 필요로 하는 많은 수의 연결 외에도 중복 데이터를 전송해야 하므로 대역폭 사용량이 증가한다.

간단하게 말하자면 매번 연결할 때마다 3 way handshake를 해야하기에 시간이 오래걸리고 단 1개의 데이터 손실이 나더라도 재전송이 필요하다.

HTTP/1.1 - 표준 프로토콜

HTTP/1.1은 HTTP 프로토콜의 주요 업데이트 버전으로, 1997년에 소개되었다. HTTP/1.1은 이전 버전인 HTTP/1.0의 단점을 보완하고, 성능 확장성을 개선하기 위해 다양한 기능을 도입하였다.

HTTP/1.1 특징

1. Keep-Alive 연결: 기본적으로 Keep-Alive 연결을 지원하여 한 번의 TCP 연결로 여러 요청과 응답을 처리할 수 있다. 이를 통해 연결을 설정하고 해제하는 오버헤드를 줄여 네트워크 지연 시간을 감소시킨다.

2. 지속적 연결(Persistent Connection): 비지속적 연결 방식이 아닌, 지속적 연결 방식을 도입하여 클라이언트와 서버 간의 연결을 유지한다. 이를 통해 한 번의 연결로 여러 요청과 응답을 처리할 수 있으며, 연결 설정/해제에 따른 오버헤드를 줄여 성능을 향상시킨다.

3. 파이프라이닝(Pipelining): 파이프라이닝 기능을 제공하여 여러 요청을 동시에 전송하고 응답을 순차적으로 받을 수 있다. 이를 통해 한 번의 연결로 여러 요청과 응답을 처리하여 네트워크 지연을 감소시키고 효율성을 향상시킨다. 하지만 파이프라이닝은 모든 서버와 클라이언트에서 지원되지 않아 일부 호환성 문제가 있다.

지속적인 연결 또는 파이프라이닝의 이점을 얻기 위해서는 응답에서 Content-Length 헤더를 사용해야 하는데, 이 방식에는 여전히 문제가 존재한다. 데이터가 동적이고 서버가 사전에 콘텐츠 길이를 찾을 수 없는 경우에는 지속적인 연결의 이점을 얻을 수 없다. 이를 해결하기 위해 HTTP/1.1은 청크 분할 인코딩을 도입했다. 이러한 경우에 서버는 Content-Length를 생략할 수 있게 되었다.

4. 청크 전송 인코딩 (Chunked Transfer Encoding): 청크 전송 인코딩을 지원하여 대용량 데이터를 작은 청크로 분할하여 전송할 수 있다. 이를 통해 데이터 전송을 빠르고 효율적으로 처리할 수 있다.

5. 가상 호스팅(Virtual Hosting): 하나의 웹 서버에서 여러 개의 도메인을 호스팅할 수 있는 가상 호스팅 기능을 지원한다. 이를 통해 동일한 서버에서 여러 웹 사이트를 운영할 수 있다.

6. 압축 전송(Content Compression): 압축 전송을 지원하여 서버에서 클라이언트로 전송되는 데이터를 압축하여 전송할 수 있다. 이를 통해 네트워크 대역폭을 절약하고 데이터 전송 속도를 향상시킨다.

7. Range 요청(Range Requests): Range 요청을 지원하여 클라이언트가 원하는 범위의 데이터만 요청할 수 있다. 이를 통해 대용량 파일의 일부만 전송 받을 수 있으며, 다운로드 속도를 개선시킨다.

8. 호스트 헤더 필드(Host Header Field): 호스트 헤더 필드를 도입하여 하나의 서버가 여러 개의 도메인을 호스팅할 수 있도록 지원한다. 이를 통해 가상 호스팅이 가능해지며, 하나의 IP 주소로 여러 개의 웹사이트를 운영할 수 있다.

9. 추가적인 요청 메서드(Additional Request Methods): 이전의 GET과 POST 메서드 외에도 다양한 추가적인 요청 메서드(PUT, DELETE, PATCH, OPTIONS)를 도입했다.

그 외에도 다이제스트 및 프록시 인증이 추가되었다.

이러한 기능들은 HTTP/1.1을 통해 웹 애플리케이션의 성능과 효율성을 향상시키고 개발자들에게 더 많은 유연성을 제공한다. 하지만 HTTP/1.1은 여전히 파이프라이닝의 한계와 성능 문제를 가지고 있어, 이후에 HTTP/2와 HTTP/3의 등장을 이끌게 되었다.

HTTP/1.1의 단점

1. 성능 제한: 동시에 여러 요청을 처리하지 못하고, 요청과 응답을 순차적으로 처리한다. 이로 인해 동시에 많은 리소스를 요청하는 경우 성능이 저하될 수 있다. 또한, 각 요청에는 오버헤드가 발생하며, 요청마다 새로운 TCP 연결을 설정해야 한다.

2. 불필요한 데이터 전송: 요청과 응답의 헤더에 중복된 정보를 포함하고 있다. 이로 인해 네트워크 대역폭을 낭비하고, 데이터 전송 속도를 늦출 수 있다.

3. 블로킹 현상: 한 번에 하나의 요청만 처리할 수 있기 때문에, 하나의 요청이 느린 응답을 가지고 있는 경우 다른 요청도 블로킹되어 대기해야 한다.

4. 서버 부하: 동시에 많은 연결을 유지해야 하므로, 서버 부하가 증가할 수 있다. 많은 연결을 처리하는 데에는 추가적인 리소스가 필요하고, 서버의 확장성이 제한될 수 있다.

5. 무거운 헤더 압축: 헤더 정보를 압축하지 않기 때문에, 많은 양의 헤더 정보를 저송해야 할 때 불필요한 데이터 전송이 발생할 수 있다.

HTTP/2 - 더 나은 성능

HTTP/2는 HTTP 프로토콜의 다음 세대로서, HTTP/1.1의 단점을 개선하고 성능을 향상시키기 위해 설계된 프로토콜이다.

HTTP/2 특징

1. 이진 프레임 형식: 이진 프레임 형식을 사용하여 데이터를 전송한다. HTTP/1.1의 텍스트 기반 프로토콜보다 더 효율적으로 데이터를 인코딩하고 압축할 수 있다.

2. 다중화와 스트림: HTTP/2는 단일 TCP 연결에서 여러 개의 동시 스트림을 지원한다. 이는 동시에 여러 요청과 응답을 처리할 수 있음을 의미한다. HTTP/1.1의 순차적인 요청-응답 모델과 비교하여 성능을 크게 향상시킨다.

3. 헤더 압축: 헤더 필드를 압축하여 데이터 전송량을 줄인다. 이는 네트워크 대역폭을 절약하고 전송 속도를 향상시킨다. HPACK 압축 알고리즘을 사용하여 효율적인 헤더 압축을 수행한다.

4. 서버 푸시: 서버 푸시 기능을 제공하여 서버가 클라이언트 요청에 대한 응답으로 추가적인 리소스를 미리 전송할 수 있다. 이는 클라이언트가 추가적인 요청을 보내지 않아도 되므로 웹 페이지 로딩 시간을 단축시킬 수 있다.

5. 스트림 우선순위: 스트림에 우선순위를 할당하여 중요한 리소스에 대한 전송을 우선적으로 처리할 수 있다.

서버 푸시 및 헤더 압축을 비롯한 기능들은 모두 성능 향상을 위해 설계되었으며, 웹 페이지의 로딩 속도를 크게 개선할수 있다.

HTTP/2는 이러한 특징들을 통해 HTTP/1.1에 비해 더 빠르고 효율적인 웹 통신을 제공한다. 이를 통해 웹 애플리케이션의 성능과 사용자 경험을 향상시킬 수 있다.

HTTP/3 - HTTP over QUIC

HTTP/3는 최신 버전의 HTTP 프로토콜로, 기존의 TCP(Transmission Control Protocol) 대신에 QUIC(Quick UDP Internet Connections) 프로토콜을 사용합니다. QUIC는 UDP(User Datagram Protocol)를 기반으로 한 전송 계층 프로토콜로, 네트워크 연결을 보다 빠르고 안정적으로 만들기 위해 설계되었습니다.

HTTP/3 특징

1. 성능 개선: QUIC 프로토콜은 다중화(Multiplexing)와 연결 상태의 유지(Maintaining Connection State)를 통해 여러 개의 요청과 응답을 동시에 처리할 수 있다. 이를 통해 네트워크 지연을 줄이고 더 빠른 페이지 로딩을 제공한다.

2. 연결 설정 및 핸드쉐이크 감소: QUIC는 특별한 초기 연결 설정과 핸드쉐이크 프로세스를 사용하여 연결을 빠르게 설정하고 유지한다. 이로써 초기 연결 지연을 줄이고 네트워크 환경의 변동에 더 빠르게 적응할 수 있다.

3. 강력한 보안: HTTP/3는 기본적으로 TLS 암호화를 사용하여 데이터의 기밀성과 무결성을 보호한다. QUIC 프로토콜은 보안을 강화하기 위해 최신 암호화 알고리즘을 사용하고, 중간자 공격과 패킷 조작과 같은 보안 위협을 줄이는 기능을 제공한다.

4. 이동성과 신뢰성: QUIC은 네트워크의 변화에 더 잘 적응할 수 있도록 설계되었다. 이동성이 높은 환경(예: 모바일 네트워크)에서도 빠른 연결 설정과 연결 유지를 제공하며, 패킷 손실이나 네트워크 혼잡으로 인한 성능 저하에 대한 내성을 갖는다.

HTTP/3는 현재까지는 실험적인 단계이며, 일부 웹 서버와 브라우저에서 지원되고 있다. QUIC 기반의 프로토콜을 사용하기 때문에 이전 버전의 HTTP와는 호환되지 않는다. 그러나 HTTP/3의 장점과 성능 향상을 위해 점점 더 많은 웹 서비스와 클라이언트가 이를 채택하고 있다.

참고
HTTP에 대해 알아야 할 모든 것
HTTP 기반 시스템의 구성 요소 [MDN]
HTTP/2로의 여정
A to Z HTTP/3 핵심 개념
[MDN] HTTP의 진화