Skip to main content

HTTP Versions

HTTP 1.0​

HTTP 1.0은 RFC 1945에서 IETF 표준이 되었다. 저자 중 REST로 유명한 Roy T. Fielding도 있다. HTTP 1.0은, 클라이언트와 서버 간 요청에 대한 기본 규칙을 정의했다.


HTTP 1.0의 특징​

  • Non-Persistent Connection
    • 즉, 매 연결마다 새로운 TCP 연결 수립 과정이 필요하다.
  • Stateless
    • HTTP는 Statless한 프로토콜이기 때문에, 서버가 클라이언트의 상태를 추적하지 않으며, 각 요청은 독립된 요청이다.
  • Simple Method Set
  • Header Fields
    • HTTP 요청 및 응답에는 모두 헤더 필드가 존재하며, 이는 각 요청 및 응답의 메타 데이터를 제공한다.

HTTP 1.0의 문제점​

  • HTTP 1.0의 경우, 네트워크 연결이 지속되지 않아 오버헤드가 발생한다.
  • chunked transfer encoding과 같은 기능이 제공되지 않아 웹 효율이 떨어진다.

유명한 오타 "Referer"​

RFC 1945 Section 10.13 Referer에 보면 "Referrer"이 "Referer"로 잘못 작성 돼 있다. 때문에 다음과 같이 "Referer"로 헤더를 파싱해야 한다.

import express, { Request, Response } from "express";

const app = express();

app.get("/", (req: Request, res: Response) => {
  const referer = req.headers.referer;
  if (referer) {
    console.log(`Navigated from ${referer}`);
  } else {
    console.log("No navigation history available");
  }
  res.send("Hello World!");
});

app.listen(3000, () => {
  console.log("Server is listening on port 3000");
});

나도 오타 발견​

RFC 1945 Section 1.1 Purpose에서 referred "too" 오타를 발견했다.

This specification reflects common usage of the protocol referred too as "HTTP/1.0".


HTTP 1.1​

HTTP 1.1은 RFC 2616에서 IETF 표준이 되었다. 마찬가지로 저자 중, REST로 유명한 Roy T. Fielding이 있다. HTTP 1.1은 기존의 HTTP 1.0의 문제점을 크게 개선했다.


HTTP 1.1의 특징​

  • Persistent Connection
    • 하나의 TCP 연결을 통해 여러 개의 HTTP 요청을 주고받을 수 있게 되어, 기존에 매 연결마다 수립과 해제를 반복함으로써 발생하는 오버헤드를 줄여, 자원의 효율과 성능을 향상시켰다.
  • Pipelining
    • 클라이언트가 한 번에 여러 요청을 보낼 수 있으며, 서버는 순차적으로 응답을 보낼 수 있다.
  • Additional Methods
    • PUT, DELETE, TRACE, CONNECT 메서드가 추가되었다.
  • Host Header
  • Chunked Transfer-Encoding
    • 응답의 크기를 미리 알 수 없을 때 사용하는 청크 전송 기능이 추가되었다.
    • 기존의 Content-Length 헤더를 사용할 때는 동적으로 생성되는 콘텐츠를 전송할 경우 응답 시간이 지연된다. 하지만 청크를 통해 응답 본문을 여러 개의 청크로 나누어서 전송할 수 있는데, 청크는 청크의 길이, 데이터, 그리고 끝을 나타내는 마커로 구성 된다. 마지막 청크의 경우, 길이가 0으로, 이로써 클라이언트는 모든 응답을 받았다는 것을 알 수 있다.
  • Cache Control
    • 캐시를 보다 구체적으로 제어할 수 있게 되었다.
  • Maintaining States
    • HTTP의 Stateless한 특징으로 인한 문제를 Cookie를 통해 해결했다. 이로써 사용자가 매번 로그인하지 않아도 된다. 하지만 HTTP 프로토콜 자체는 여전히 Stateless하다.

HTTP 1.1의 문제점​

  • Head-of-Line Blocking
    • Pipelining기능은 순차적으로 요청을 처리하게 되는데, 만약 첫 번째 요청이 지연되면, 한 번에 하나의 요청만 처리할 수 있기 때문에 그 다음 요청도 모두 지연되는 문제가 발생한다.
  • Network Latency
    • 하나의 TCP 연결에서 한 번에 하나의 요청을 처리하게 되는데, 여러 요청을 보낼 수 있게 돼, 네트워크 지연 문제가 발생한다.

HTTP 2.0​

HTTP 2.0은 RFC 7540에서 IETF 표준이 되었으나, 이후 RFC 9113에서 개정되었다. 이번에는 재미있게도 Apple Inc.이 저자에 포함 돼 있다. HTTP 2.0은 HTTP 1.1의 성능 문제를 개선했다.


HTTP 2.0의 특징​

  • Multiplexing
    • 하나의 TCP 연결에서 여러 요청 메시지를 동시에 보낼 수 있다. 이때 메시지는 Stream으로 구분되며, 이로 인해 Head-of-Line Blocking 문제를 조금 해소시켰다.
    • Stream이란, 동시에 여러 메시지를 주고 받을 수 있는 양방향 시퀀스이다.
    • Stream은 각 요청 메시지를 분할한 프레임들로 구성되는데, 이러한 프레임은 서로 다른 Stream 간에 뒤섞여 전달 될 수 있게 돼, Head-of-Line Blocking 문제를 해소할 수 있다.
  • Stream Prioritization
    • 요청 메시지에 해당하는 각 Stream에 대해 우선순위를 둘 수 있으며, 서버는 우선순위가 높은 요청에 먼저 응답할 수 있다.
  • Binary Protocol
    • Text 기반의 HTTP 1.1에 비해 작은 오버헤드를 가지게 된다.
  • HTTP/2를 사용하기 위해서는 서버 말고도 브라우저 역시 이를 지원해야 하는데, 현재는 대부분의 브라우저에서 지원한다.
    • 서버의 경우, HTTP/2를 지원한다면, 클라이언트에 HTTP/2.0을 응답 프로토콜로 전달한다. 또는 $ curl -I <URL>로 확인이 가능하다.
    • 또한 필수는 아니지만, HTTP/2를 지원하는 대부분의 서버는 TLS(HTTPS)를 사용한다.

HTTP 2.0의 문제점​

  • Head-of-Line Blocking
    • 비록 HTTP 1.1에서의 문제를 일부 완화시키긴 했지만, TCP 자체로 인한 문제가 남아 있다. 가령, TCP 패킷 중 하나가 손실되면, 이후의 모든 패킷이 Blocking 될 수 있다.
Related Links
  • No related links