HTTP/1.1

HTTP/1.0은 각 요청-응답 사이클마다 새로운 TCP 연결을 열고 닫는 비지속 연결 방식을 사용했다. 이 방식은 매번 3-way 핸드셰이크와 TCP 느린 시작을 반복해야 하므로, 웹 페이지에 여러 리소스(이미지, 스타일시트, 스크립트 등)가 포함된 경우 심각한 지연과 네트워크 오버헤드를 초래했다.

HTTP/1.1의 가장 중요한 발전은 지속 연결의 도입이다. 기본적으로 단일 TCP 연결을 통해 여러 개의 요청과 응답을 순차적으로 교환할 수 있게 되어, 연결 설정 및 해제에 따른 반복적인 오버헤드를 크게 줄였다. 이는 특히 여러 작은 리소스를 로드하는 현대적인 웹 페이지의 성능을 획기적으로 향상시켰다.

또한, 호스트 헤더가 필수화되어 가상 호스팅이 가능해졌다. HTTP/1.0에서는 하나의 IP 주소가 하나의 도메인에만 매핑되었지만, HTTP/1.1에서는 요청 헤더에 호스트명을 명시함으로써 동일한 서버와 IP 주소에서 여러 웹사이트를 호스팅할 수 있게 되었다. 이는 인터넷 인프라의 효율성을 극대화하는 핵심 변화였다.

다음 표는 HTTP/1.0과 HTTP/1.1의 주요 차이점을 요약한다.

이 외에도 청크 전송 인코딩을 통한 스트리밍 응답 지원, 보다 풍부한 캐시 제어 헤더, 그리고 새로운 HTTP 메서드와 상태 코드의 추가 등이 HTTP/1.1의 핵심 발전 사항이다.

HTTP/1.0의 제한을 극복하고 웹의 폭발적 성장을 지원하기 위한 공식 표준으로, HTTP/1.1은 IETF의 HTTP 워킹 그룹에 의해 표준화되었다. 첫 번째 표준안은 1997년 1월에 RFC 2068로 공개되었다. 이 초안은 지속 연결, 호스트 헤더, 청크 전송 인코딩과 같은 핵심 기능을 정의했으나, 일부 모호한 점과 구현상의 문제가 지적되었다.

이를 수정하고 보완한 최종 표준안은 1999년 6월에 RFC 2616으로 공개되었다. 이 문서는 "Hypertext Transfer Protocol -- HTTP/1.1"이라는 제목으로, 1990년대 후반 웹의 폭넓은 사용 사례를 반영한 명세가 되었다. RFC 2616은 다음 표와 같이 주요 개정 사항을 포함했다.

RFC 2616은 이후 약 15년 동안 HTTP/1.1의 공식 표준 문서 역할을 했다. 그러나 시간이 지나면서 명세의 복잡성과 일부 모호한 표현이 문제로 지적되었다. 이에 따라 IETF는 2014년 6월에 단일 문서였던 RFC 2616을 여섯 개의 더 명확하고 집중된 문서로 분할하여 개정했다[1]. 이 개정판들은 기술적 내용을 크게 변경하지 않으면서 명세의 가독성과 구현 정확성을 높이는 데 목적을 두었다.

HTTP/1.0에서는 각 HTTP 요청마다 새로운 TCP 연결을 열고, 응답을 받은 후 즉시 연결을 닫는 방식이 기본이었다. 이 방식은 단순하지만, 하나의 웹 페이지를 구성하는 HTML, CSS, 자바스크립트, 이미지 파일 등 여러 리소스를 각각 별도의 연결로 가져와야 하므로 매번 TCP 3방향 핸드셰이크와 느린 시작(Slow Start) 과정을 반복해야 했다. 이는 네트워크 지연과 서버 부하를 크게 증가시키는 원인이 되었다.

HTTP/1.1에서 도입된 지속 연결은 이러한 비효율성을 해결하기 위한 핵심 기능이다. 지속 연결은 하나의 TCP 연결을 열어 두고, 여러 개의 요청과 응답을 연속적으로 주고받을 수 있도록 한다. 기본적으로 연결은 일정 시간 동안 유지되며, Connection: keep-alive 헤더를 명시적으로 사용하여 관리할 수도 있다. 이를 통해 연결 설정과 해제에 드는 오버헤드를 줄이고, 네트워크 대역폭을 더 효율적으로 사용할 수 있게 되었다.

지속 연결의 동작은 클라이언트와 서버의 협력에 의해 이루어진다. 클라이언트가 지속 연결을 지원하고자 할 경우 요청에 Connection: keep-alive 헤더를 포함시킬 수 있다. 서버도 이를 지원하면 응답에 동일한 헤더를 포함시켜 연결을 유지하겠다는 의사를 표시한다. 연결이 유지되는 시간은 서버 설정에 따라 다르며, 일정 시간 동안 새로운 요청이 없으면 서버 측에서 연결을 닫게 된다. 이 기능은 HTTP/1.1의 기본 동작이므로, 명시적으로 연결을 종료하려면 Connection: close 헤더를 사용해야 한다.

지속 연결의 도입은 웹 성능에 지대한 영향을 미쳤다. 특히 여러 개의 작은 리소스(예: 아이콘, 스크립트 조각)를 많이 요청하는 현대적인 웹 페이지의 로딩 시간을 획기적으로 단축시켰다. 그러나 지속 연결은 연결을 장시간 유지한다는 특성상 서버의 동시 연결 수 제한과 결합될 경우 새로운 형태의 병목 현상을 만들기도 했다. 또한, 잘못 구현된 클라이언트나 서버로 인해 연결이 제때 닫히지 않아 리소스가 낭비되는 문제도 발생할 수 있었다.

파이프라이닝은 HTTP/1.1에서 도입된 성능 최적화 기법이다. 이 기술은 클라이언트가 첫 번째 요청에 대한 응답을 기다리지 않고, 동일한 TCP 연결 상에서 여러 개의 HTTP 요청을 연속적으로 보낼 수 있게 한다. 이론적으로는 지속 연결만 사용하는 경우보다 네트워크 지연 시간을 더욱 줄이고 처리량을 향상시킬 수 있다.

작동 방식은 다음과 같다. 클라이언트는 서버에 첫 번째 요청을 보낸 후, 해당 요청에 대한 응답이 도착하기 전에 두 번째, 세 번째 요청을 바로 이어서 보낸다. 서버는 요청을 받은 순서대로 처리하여 응답을 생성하며, 이 응답들도 요청이 들어온 순서와 동일하게 클라이언트에게 반환해야 한다. 이는 FIFO 큐와 유사한 방식으로 관리된다.

그러나 파이프라이닝에는 심각한 실용적 한계가 존재한다. 가장 큰 문제는 HOL 블로킹이다. 파이프라인에서 먼저 보낸 요청의 처리가 지연되면, 그 뒤에 있는 모든 요청의 응답도 차단되는 현상이 발생한다. 또한, 프록시 서버나 오래된 서버 중에서 파이프라이닝을 제대로 지원하지 않는 경우가 많아 호환성 문제를 일으켰다.

이러한 복잡성과 구현상의 문제들로 인해, 대부분의 현대 웹 브라우저에서는 기본적으로 파이프라이닝 기능이 비활성화되어 있다. 결국 파이프라이닝은 이론상의 이점에도 불구하고 널리 채택되지 못했으며, 이러한 한계를 근본적으로 해결하기 위해 설계된 HTTP/2의 멀티플렉싱이 그 대안으로 자리 잡게 되었다.

HTTP/1.0에서는 하나의 IP 주소가 하나의 도메인에만 매핑된다는 가정 하에 동작했다. 그러나 웹 호스팅 서비스의 발전으로, 단일 서버(하나의 IP 주소)에서 여러 개의 독립적인 웹사이트(예: site1.example.com, site2.example.com)를 운영하는 가상 호스팅이 보편화되었다. 이 경우, 클라이언트가 요청을 보낼 때 서버는 요청이 어느 도메인을 위한 것인지 구분할 방법이 없었다.

이 문제를 해결하기 위해 HTTP/1.1에서는 반드시 포함되어야 하는 필수 헤더인 Host 헤더를 도입했다. 클라이언트는 HTTP 요청을 보낼 때 Host: site1.example.com과 같이 목적지 도메인 이름을 헤더에 명시해야 한다. 서버는 이 헤더 값을 확인하여 동일한 IP 주소와 포트 번호로 들어오는 요청이라도, 각각 다른 웹사이트의 콘텐츠를 정확히 제공할 수 있게 된다.

Host 헤더의 도입은 웹 인프라의 효율성을 크게 높였다. 서버 자원을 더 효율적으로 공유할 수 있게 되었고, 이는 공유 호스팅 비즈니스 모델의 기반이 되었다. 또한, 이 헤더는 TLS/SSL 인증서를 통한 HTTPS 연결에서도 중요한 역할을 한다. 서버는 클라이언트가 초기 핸드셰이크 단계에서 보내는 SNI 정보와 Host 헤더를 통해, 하나의 IP 주소에서 여러 개의 서로 다른 보안 인증서를 사용하는 것이 가능해졌다.

Host 헤더는 HTTP/1.1 요청에서 유일하게 필수적인 헤더 필드이며, 이를 생략하면 서버는 대개 400 Bad Request 상태 코드로 응답한다. 이 메커니즘은 현대 웹의 기본 구조를 이루는 핵심 요소 중 하나이다.

청크 전송 인코딩(Chunked Transfer Encoding)은 HTTP/1.1에서 도입된 데이터 전송 방식이다. 이 방식은 서버가 응답 본문의 전체 크기를 미리 알지 못하는 상황에서도 데이터를 스트리밍 방식으로 클라이언트에 점진적으로 전송할 수 있게 해준다. 이는 동적으로 생성되는 콘텐츠나 큰 파일을 전송할 때 특히 유용하다.

전송 과정은 각각의 "청크" 단위로 이루어진다. 각 청크는 자신의 크기(16진수 바이트 수)와 실제 데이터, 그리고 줄바꿈으로 구성된다. 마지막으로 크기가 0인 청크가 전송되어 응답의 종료를 알린다. 이 방식을 사용할 때는 응답 헤더에 Transfer-Encoding: chunked 필드가 포함되고, Content-Length 헤더는 생략된다.

이 방식의 주요 장점은 서버가 전체 응답을 생성하고 메모리에 버퍼링할 필요 없이 데이터를 생성하는 즉시 전송을 시작할 수 있다는 점이다. 이를 통해 대기 시간을 줄이고 서버의 메모리 사용량을 최적화할 수 있다. 또한, 전송 중간에 연결이 끊어져도 이미 수신된 청크까지의 데이터는 유효하게 처리될 수 있다.

HTTP 요청 메시지는 클라이언트가 서버에게 자원에 대한 동작을 지시하기 위해 보내는 메시지이다. 기본 구조는 시작 줄, 헤더, 빈 줄, 메시지 본문으로 구성된다. 시작 줄은 다시 HTTP 메서드, 요청 대상(URI), 사용 중인 HTTP 버전으로 이루어져 있으며, 각 요소는 공백으로 구분된다. 예를 들어, GET /index.html HTTP/1.1은 서버의 /index.html 자원을 가져오라는 요청이다.

헤더는 요청에 대한 부가 정보를 필드-이름: 값 형식의 줄로 제공한다. 필수 헤더는 Host 헤더로, HTTP/1.1의 가상 호스팅을 지원하기 위해 도입되어 하나의 서버 IP 주소가 여러 도메인을 서비스할 수 있게 한다. 그 외에도 클라이언트 정보(User-Agent), 선호하는 응답 형식(Accept), 쿠키(Cookie) 등 다양한 헤더가 사용된다. 헤더의 끝은 빈 줄(CRLF)로 표시한다.

메시지 본문은 선택 사항이며, POST나 PUT 메서드처럼 서버로 데이터를 전송할 때 사용된다. 본문이 있을 경우, Content-Type과 Content-Length 헤더를 통해 데이터의 형식과 크기를 명시하는 것이 일반적이다. 본문이 없는 GET이나 DELETE 요청에서는 빈 줄 이후에 아무 내용도 오지 않는다.

다음은 로그인을 시도하는 POST 요청 메시지의 예시이다.

응답 메시지는 클라이언트가 보낸 HTTP 요청에 대한 서버의 처리 결과를 담은 구조이다. 기본적으로 상태 라인, 헤더, 빈 줄, 메시지 본문(엔티티 본문)의 순서로 구성된다. 상태 라인은 응답의 첫 번째 줄로, 사용 중인 HTTP 버전, 상태 코드, 그리고 해당 상태 코드를 설명하는 짧은 문구인 상태 텍스트로 이루어진다. 예를 들어 HTTP/1.1 200 OK는 요청이 성공했음을 의미한다.

헤더 부분은 응답에 대한 부가 정보를 키-값 쌍 형태로 제공한다. 중요한 헤더로는 콘텐츠의 유형을 나타내는 Content-Type(예: text/html; charset=UTF-8), 본문의 길이를 바이트 단위로 알려주는 Content-Length, 그리고 캐시 제어와 관련된 Cache-Control 등이 있다. 상태 라인과 모든 헤더는 캐리지 리턴과 라인 피드(CRLF)로 끝나야 한다.

헤더 이후에는 반드시 빈 줄(CRLF만 있는 줄)이 와야 하며, 이는 헤더의 끝과 메시지 본문의 시작을 구분하는 역할을 한다. 메시지 본문은 요청된 리소스의 실제 데이터를 포함한다. 예를 들어 HTML 문서, 이미지 파일, 또는 JSON 데이터 등이 여기에 해당한다. 본문의 존재 여부와 길이는 상태 코드와 요청 메서드에 따라 달라질 수 있다. 204 No Content와 같은 응답에는 본문이 존재하지 않는다.

본문의 전송 방식은 Transfer-Encoding 헤더에 따라 달라질 수 있다. chunked 인코딩이 지정된 경우, 본문은 여러 개의 덩어리로 나누어져 전송된다[3]]이라고 한다]. 이는 동적으로 생성되는 콘텐츠를 스트리밍하거나 전체 콘텐츠 길이를 미리 알 수 없을 때 유용하다.

HTTP 헤더 필드는 클라이언트와 서버 간에 교환되는 메타데이터를 전달하는 데 사용된다. 각 헤더 필드는 이름과 값으로 구성되며, 콜론(:)으로 구분된다. 헤더 필드는 요청과 응답 모두에 존재하며, 메시지의 본문(body)이 시작되기 전에 한 줄씩 나열된다.

헤더 필드는 그 목적과 사용처에 따라 크게 네 가지 범주로 나눌 수 있다.

* 일반 헤더(General Header): 요청과 응답 메시지 모두에서 사용될 수 있는 헤더이다. 메시지 전체에 적용되는 정보를 담는다. 대표적으로 메시지의 날짜와 시간을 나타내는 Date, 연결 관리를 위한 Connection 등이 있다.

* 요청 헤더(Request Header): 클라이언트가 서버에게 보내는 요청 메시지에서만 사용되는 헤더이다. 클라이언트의 정보, 선호하는 응답 형식, 조건부 요청 등을 서버에 알린다. 예를 들어 User-Agent는 클라이언트 소프트웨어(브라우저) 정보를, Accept는 클라이언트가 처리할 수 있는 콘텐츠 유형을 나타낸다.

* 응답 헤더(Response Header): 서버가 클라이언트에게 보내는 응답 메시지에서만 사용되는 헤더이다. 서버에 대한 정보와 요청된 리소스에 대한 추가 정보를 제공한다. Server 헤더는 서버 소프트웨어 정보를, Location은 리다이렉션할 URL을 나타낸다.

* 엔터티 헤더(Entity Header): 메시지 본문(엔터티)에 대한 메타데이터를 설명하는 헤더이다. 본문의 콘텐츠 유형, 길이, 마지막 수정 시간 등을 기술한다. Content-Type은 본문의 미디어 타입(예: text/html), Content-Length는 본문의 크기를 바이트 단위로 표시한다.

몇 가지 주요 헤더 필드의 역할을 구체적으로 살펴보면 다음과 같다.

이러한 헤더 필드들을 조합하여 클라이언트와 서버는 통신의 세부 사항을 정교하게 제어할 수 있다. 예를 들어 If-Modified-Since 같은 조건부 요청 헤더를 사용하면 리소스가 변경되었을 때만 데이터를 전송받을 수 있어 대역폭을 절약한다.

HTTP 메서드는 클라이언트가 서버에 요청하는 동작의 종류를 지정하는 명령어이다. HTTP/1.1은 여러 메서드를 정의하며, 그 중 일부는 안전하거나 멱등성을 가진다. 안전 메서드는 서버의 상태를 변경하지 않는 읽기 전용 작업이며, 멱등 메서드는 동일한 요청을 여러 번 반복해도 한 번 실행한 효과와 동일한 결과를 보장한다.

가장 일반적으로 사용되는 메서드는 다음과 같다.

이 외에도 HTTP/1.1은 다른 메서드들을 정의한다. HEAD 메서드는 GET 요청과 동일한 응답을 요구하지만, 응답 본문을 반환하지 않고 헤더만 반환한다. 이는 리소스의 존재 유무나 메타데이터를 확인하는 데 유용하다. OPTIONS 메서드는 대상 리소스에 대해 지원되는 통신 옵션을 설명한다. PATCH 메서드는 리소스의 부분적인 수정을 위해 사용되지만, 원래 RFC 2616에는 포함되지 않았고 이후 별도 RFC로 표준화되었다[5]. TRACE 메서드는 요청의 루프백 테스트를 수행하며, CONNECT 메서드는 프록시 서버에 터널 연결을 설정하는 데 사용된다.

상태 코드는 세 자리 숫자로 구성되며, 응답의 첫 번째 줄에 위치합니다. 코드의 첫 번째 숫자는 응답의 클래스를 정의하며, 나머지 두 숫자는 구체적인 상황을 나타냅니다. 이 체계는 HTTP 클라이언트가 서버 응답의 성공, 실패, 추가 조치 필요 여부 등을 빠르게 이해할 수 있도록 합니다.

각 클래스의 대표적인 상태 코드는 다음과 같습니다. 2xx 성공 클래스에서는 200 OK가 가장 일반적이며, 요청이 성공했음을 나타냅니다. 3xx 리다이렉션 클래스에서는 301 Moved Permanently (영구 이동)와 302 Found (임시 이동)가 자주 사용됩니다. 4xx 클라이언트 오류에서는 404 Not Found (리소스를 찾을 수 없음)와 400 Bad Request (잘못된 요청)가 흔합니다. 5xx 서버 오류에서는 500 Internal Server Error (내부 서버 오류)와 503 Service Unavailable (서비스를 사용할 수 없음)이 대표적입니다.

1xx 정보 응답은 상대적으로 덜 사용되지만, 100 Continue는 클라이언트가 요청 본문을 계속 보내도 된다는 신호로 활용됩니다. 이러한 상태 코드 체계는 HTTP/1.1의 명확성과 상호운용성을 크게 향상시킨 핵심 요소 중 하나입니다.

HOL 블로킹은 HTTP/1.1의 핵심 성능 한계 중 하나로, 특히 파이프라이닝이 활성화된 상황에서 두드러지게 나타난다. 이 용어는 네트워크 큐에서 선두에 있는 패킷이 지연될 때 뒤따르는 모든 패킷이 대기해야 하는 현상을 가리킨다. HTTP/1.1의 파이프라이닝에서는 단일 TCP 연결을 통해 여러 HTTP 요청을 순차적으로 보낼 수 있지만, 응답은 반드시 요청이 보내진 순서대로 클라이언트에 도착해야 한다.

이로 인해 첫 번째 요청에 대한 응답이 느리게 생성되거나 대용량 데이터를 포함하면, 뒤이어 보낸 요청들의 응답은 첫 번째 응답이 완전히 전송될 때까지 대기열에서 차단된다. 예를 들어, 첫 번째 요청이 복잡한 데이터베이스 쿼리를 필요로 하는 동적 페이지를 요청하고, 두 번째 요청이 간단한 스타일시트 파일을 요청한 경우, 스타일시트 파일의 응답은 첫 번째 동적 페이지의 응답이 완전히 준비되어 전송되기 전까지 전달될 수 없다. 이는 네트워크 대역폭이 충분하더라도 발생하는 논리적 차단 현상이다.

이 문제를 완화하기 위해 현대 웹 브라우저는 단일 도메인에 대해 여러 개의 병렬 TCP 연결을 동시에 열어 요청을 분산시킨다. 그러나 이 방법은 연결 설정 및 종료에 따른 오버헤드를 증가시키고, 서버 부하를 가중시킬 수 있다. HTTP/1.1의 HOL 블로킅 문제는 프로토콜 설계의 근본적인 한계였으며, 이는 후속 버전인 HTTP/2에서 멀티플렉싱을 도입하여 해결하고자 하는 주요 동기가 되었다.

HTTP/1.1의 지속 연결은 매 요청마다 TCP 연결을 새로 설정하는 오버헤드를 줄였지만, 동시에 처리할 수 있는 연결 수에 제한이 생겼다. 대부분의 웹 브라우저는 동일한 도메인에 대해 동시에 유지할 수 있는 지속 연결의 최대 개수를 6개에서 8개 정도로 제한한다[8]. 이는 과도한 연결로 인해 클라이언트와 서버의 리소스가 고갈되는 것을 방지하기 위한 조치이다.

이 제한은 현대 웹 페이지가 수십 개에서 수백 개의 리소스(이미지, 스타일시트, 자바스크립트 파일 등)로 구성되는 경우에 심각한 병목 현상을 유발한다. 브라우저는 페이지를 빠르게 렌더링하기 위해 가능한 한 많은 리소스를 병렬로 다운로드하려 하지만, 연결 수 제한으로 인해 실제로는 대기열이 형성된다. 6개의 연결이 모두 사용 중이라면, 7번째 리소스에 대한 요청은 앞선 요청 중 하나가 완료되어 연결이 해제될 때까지 큐에서 대기해야 한다.

이 병목 현상은 HOL 블로킹 문제와 결합되어 성능 저상을 악화시킨다. 단일 연결 내에서 파이프라이닝이 활성화되더라도, 응답이 순차적으로 처리되어야 하므로 앞선 요청의 응답이 지연되면 뒤의 요청들도 함께 블로킹된다. 여러 연결을 사용하면 이 문제를 일부 완화할 수 있지만, 연결 수 제한이라는 새로운 한계에 부딪히게 된다. 결과적으로, 리소스가 많은 복잡한 웹 페이지를 로드할 때는 연결 풀이 가득 차 리소스 다운로드가 순차적으로 진행되는 것과 유사한 현상이 발생하여 전체 페이지 로드 시간이 길어지게 된다.

이 문제를 완화하기 위한 일반적인 방법은 도메인 샤딩이다. 이는 서브도메인을 여러 개 만들어 리소스를 분산시키는 기법으로, 브라우저의 도메인별 연결 제한을 우회하기 위한 것이다. 예를 들어, static1.example.com, static2.example.com과 같은 서브도메인에 리소스를 호스팅하면, 브라우저는 각 도메인에 대해 별도의 연결 풀을 할당하여 동시 연결 총수를 늘릴 수 있다. 그러나 이 방법은 추가적인 DNS 조회와 연결 설정 오버헤드를 유발하며, HTTP/2와 같은 후속 프로토콜에서는 오히려 성능을 해칠 수 있는 최적화로 간주된다.

HTTPS는 HTTP/1.1 프로토콜에 보안 계층을 추가한 것이다. 정확히는, HTTP 메시지의 전송을 담당하는 전송 계층에 TLS(또는 그 전신인 SSL) 암호화 프로토콜을 적용한 형태이다. 이 조합은 HTTP over TLS, 또는 HTTP over SSL이라고 불린다. HTTPS를 사용하면 클라이언트와 서버 간에 교환되는 모든 HTTP 요청과 응답 메시지가 암호화되어, 네트워크 상에서 도청이나 중간자 공격으로부터 내용을 보호한다.

HTTP/1.1 명세 자체는 암호화 메커니즘을 정의하지 않는다. 대신, HTTPS는 별도의 표준(RFC 2818 등)으로 정의되며, 기본적으로 TCP 포트 443을 사용한다. 연결 설정 과정에서 TLS 핸드셰이크가 먼저 수행되어 암호화된 터널을 구축한 후, 그 안에서 평문 HTTP/1.1 프로토콜이 동작한다. 따라서 애플리케이션 관점에서의 메시지 형식, 메서드, 상태 코드는 HTTP/1.1과 완전히 동일하다.

보안의 필요성이 증가하면서 HTTPS는 로그인, 결제, 개인정보 조회 등 민감한 트랜잭션을 넘어 웹 전반의 표준이 되었다. 현대의 웹 브라우저들은 HTTP 사이트에 대해 '안전하지 않음' 경고를 표시하며, 검색 엔진 또한 HTTPS 사용을 SEO 랭킹 요소로 삼는다. HTTP/1.1은 여전히 내부 프로토콜로 널리 사용되지만, 외부 네트워크를 통한 전송 시에는 거의 항상 HTTPS의 보호를 받는다.

HTTP/1.1은 설계상의 특성과 텍스트 기반의 명확한 메시지 형식으로 인해 여러 보안 취약점에 노출될 수 있다. 가장 대표적인 문제는 메시지가 평문으로 전송된다는 점이다. 이로 인해 네트워크 상에서 패킷을 감청하는 중간자 공격이 가능해지며, 민감한 정보가 그대로 노출될 위험이 있다. 또한, 메시지의 무결성을 검증할 수 없어 전송 중 변조가 발생할 수도 있다.

특정 헤더를 악용한 공격도 빈번하게 발생한다. 예를 들어, Host 헤더를 조작하여 서버 측 라우팅 로직을 우회하거나, HTTP 요청 스머글링 공격을 통해 프론트엔드 서버와 백엔드 서버 간의 요청 해석 차이를 이용하는 경우가 있다. CRLF 인젝션은 헤더를 종료하는 캐리지 리턴과 라인 피드 문자를 삽입하여 응답을 분할하거나 악성 헤더를 추가하는 공격 방식이다.

연결 관리와 관련된 공격도 존재한다. Slowloris 공격은 매우 느린 속도로 요청 헤더를 조금씩 전송하여 서버의 연결 자원을 고의로 소진시키는 서비스 거부 공격의 일종이다. 또한, 메시지 본문의 크기를 나타내는 Content-Length 헤더와 청크 전송 인코딩을 혼용하거나 조작하여 서버의 요청 처리 로직을 혼란시키는 공격이 가능하다[10].

이러한 취약점들을 완화하기 위해 HTTPS를 사용하여 통신 구간을 암호화하는 것이 필수적이다. 또한, 웹 애플리케이션 방화벽을 도입하고, 서버 소프트웨어를 최신 상태로 유지하며, 불필요한 헤더를 제거하고 사용자 입력값을 철저히 검증하는 등의 보안 조치가 필요하다.

HTTP/1.1은 텍스트 기반의 프로토콜로, 각 요청과 응답이 평문으로 구성되어 헤더가 반복되고 압축되지 않는다. 반면 HTTP/2는 바이너리 프로토콜을 채택하여 메시지를 바이너리 프레임으로 분할하고 전송 효율을 높였다. 이는 구문 분석을 빠르게 하고 오류 가능성을 줄인다.

HTTP/1.1에서는 단일 연결 내에서 여러 요청을 순차적으로 보낼 수 있는 파이프라이닝이 있지만, 응답은 요청 순서대로 반드시 도착해야 하는 HOL 블로킹 문제가 있다. HTTP/2는 멀티플렉싱을 도입하여 단일 TCP 연결 상에서 여러 요청과 응답을 병렬로 주고받을 수 있게 하여 이 문제를 해결했다. 또한 서버 푸시 기능을 통해 클라이언트의 추가 요청 없이도 필요한 리소스를 사전에 전송할 수 있다.

헤더 처리 방식에도 차이가 있다. HTTP/1.1은 매 요청마다 중복된 헤더 필드를 전송해야 한다. HTTP/2는 HPACK 압축 방식을 사용하여 헤더를 압축하고, 정적/동적 테이블을 통해 중복된 필드를 효율적으로 제거하여 대역폭을 절약한다.

이러한 개선에도 불구하고 HTTP/2의 핵심 전송 계층은 여전히 TCP를 사용한다. 이로 인한 TCP의 핸드셰이크 지연과 혼잡 제어 메커니즘의 한계는 여전히 남아있었으며, 이는 이후 HTTP/3과 QUIC 프로토콜의 등장으로 이어지는 배경이 되었다.

HTTP/2가 TCP 위에서 동작하며 멀티플렉싱과 헤더 압축으로 성능을 개선했다면, HTTP/3는 전송 계층 프로토콜 자체를 교체하는 근본적인 변화를 가져왔다. HTTP/3의 핵심은 QUIC(Quick UDP Internet Connections) 프로토콜을 사용한다는 점이다. QUIC는 UDP를 기반으로 설계되었으며, TCP의 신뢰성과 TLS의 보안 기능을 통합했다.

HTTP/3와 QUIC의 도입으로 해결된 가장 중요한 문제는 HOL 블로킹(Head-of-Line Blocking)이다. TCP에서는 패킷 하나가 손실되면 그 뒤의 모든 패킷의 전달이 지연되는 현상이 발생한다. 반면, QUIC는 독립적인 스트림을 통해 데이터를 전송하므로, 한 스트림에서의 패킷 손실이 다른 스트림에 영향을 미치지 않는다. 또한 연결 설정 시 TCP 핸드셰이크와 TLS 핸드셰이크를 결합하여 대기 시간을 크게 줄였으며, 연결 마이그레이션 기능으로 네트워크가 변경되어도(예: Wi-Fi에서 셀룰러로 전환) 기존 연결을 유지할 수 있다.

HTTP/3의 표준화는 IETF에서 진행되었으며, 2022년 6월 RFC 9114로 공식 발표되었다[11]. 이 진화는 웹의 성능과 보안, 신뢰성을 한 단계 높이는 동시에, 수십 년간 인터넷의 근간을 이루었던 TCP 중심의 패러다임을 변화시키는 중요한 이정표가 되었다. 현재 많은 주요 CDN 제공업체와 웹 브라우저, 서버 소프트웨어가 HTTP/3를 지원하고 있다.