하이퍼텍스트 전송 프로토콜 (r1)

HTTP는 기본적으로 클라이언트-서버 모델을 따르는 프로토콜이다. 이 모델에서 통신은 항상 요청을 보내는 클라이언트와 그 요청에 대한 응답을 제공하는 서버라는 두 개의 구별된 역할로 구성된다. 일반적으로 웹 브라우저나 모바일 앱과 같은 소프트웨어가 클라이언트 역할을 하며, 웹 서버 소프트웨어가 서버 역할을 담당한다.

클라이언트는 사용자의 동작(예: 링크 클릭, 폼 제출)이나 프로그램 로직에 따라 특정 자원(예: HTML 문서, 이미지, 데이터)에 대한 요청을 서버에 보낸다. 서버는 해당 요청을 받아 해석한 후, 요청된 자원을 찾거나 생성하여 적절한 응답 메시지와 함께 클라이언트에게 돌려보낸다. 이 과정에서 서버는 클라이언트의 상태를 유지하지 않는 상태 비저장성을 기본 원칙으로 한다.

이 모델의 주요 특징은 통신이 항상 클라이언트의 요청으로 시작된다는 점이다. 서버는 클라이언트의 요청 없이 자발적으로 데이터를 보낼 수 없다. 이러한 단방향적인 요청-응답 구조는 웹의 기본 동작 방식을 정의하며, 실시간 양방향 통신이 필요한 경우에는 WebSocket과 같은 다른 프로토콜이 사용된다.

클라이언트-서버 모델은 시스템을 논리적으로 분리하여 확장성과 유지보수성을 높인다. 서버는 비즈니스 로직과 데이터 저장을 중앙에서 관리하고, 클라이언트는 사용자 인터페이스와 상호작용을 담당한다. 이 분리는 다양한 종류의 클라이언트(데스크톱 브라우저, 모바일 앱, IoT 기기)가 동일한 서버와 통신할 수 있는 기반을 제공한다.

HTTP 통신의 핵심은 클라이언트가 서버로 보내는 HTTP 요청과 서버가 클라이언트로 되돌려주는 HTTP 응답으로 구성된다. 이 두 구조는 모두 시작 줄, 헤더, 본문의 세 부분으로 나뉜다.

요청 메시지의 시작 줄은 HTTP 메서드, 요청 대상(일반적으로 URL의 경로 부분), 사용 중인 HTTP 버전을 포함한다. 예를 들어 GET /index.html HTTP/1.1은 /index.html 리소스를 HTTP/1.1 버전으로 가져오라는 GET 요청이다. 응답 메시지의 시작 줄은 프로토콜 버전, HTTP 상태 코드, 상태 코드를 설명하는 텍스트인 상태 메시지로 구성된다. HTTP/1.1 200 OK는 요청이 성공했음을 의미한다.

헤더는 요청이나 응답에 대한 부가 정보를 키-값 쌍 형태로 제공한다. 요청 헤더는 클라이언트의 정보(User-Agent), 선호하는 응답 형식(Accept), 쿠키(Cookie) 등을 담는다. 응답 헤더는 서버 정보(Server), 응답의 콘텐츠 타입(Content-Type), 캐시 지시사항(Cache-Control) 등을 포함한다. 헤더는 빈 줄로 끝난다. 본문은 실제 전송되는 데이터로, HTML 문서, JSON 데이터, 이미지 파일 등이 될 수 있다. GET 요청처럼 데이터를 가져오기만 하는 경우 본문이 없을 수 있다.

HTTP는 기본적으로 상태 비저장(Stateless) 프로토콜이다. 이는 각각의 HTTP 요청이 독립적이며, 서버가 이전 요청의 컨텍스트나 상태를 유지하지 않는다는 것을 의미한다. 서버는 클라이언트가 보낸 요청을 받으면, 그 요청 자체에 포함된 정보만으로 처리를 수행하고 응답을 반환한다. 이후 동일한 클라이언트에서 오는 다음 요청은 이전 요청과 아무런 연관성이 없는 것으로 간주된다.

이러한 설계는 서버의 구현을 단순화하고 확장성을 높이는 데 기여한다. 서버가 클라이언트의 상태를 저장할 필요가 없으므로, 시스템 리소스(메모리, 스토리지)를 절약할 수 있다. 또한, 여러 대의 서버로 구성된 분산 환경에서 특정 클라이언트의 요청을 어떤 서버로든 자유롭게 라우팅할 수 있어 로드 밸런싱과 장애 복구가 용이해진다.

그러나 실제 웹 애플리케이션에서는 사용자 로그인 상태, 장바구니 정보 등과 같은 상태 유지가 필수적이다. 이러한 필요성을 해결하기 위해 쿠키(Cookie), 세션(Session), 토큰(Token) 기반 인증 등의 기술이 도입되었다. 예를 들어, 서버는 로그인 성공 시 클라이언트에게 세션 ID를 담은 쿠키를 전송하고, 클라이언트는 이후 요청마다 이 쿠키를 포함시켜 자신을 식별한다. 서버는 이 ID를 키로 사용하여 외부 저장소(데이터베이스, 메모리 캐시)에서 해당 사용자의 상태 정보를 조회한다. 이는 HTTP 프로토콜 자체의 상태 비저장성을 보완하는 애플리케이션 레벨의 해결책이다.

따라서 HTTP의 상태 비저장성은 프로토콜의 근본적인 특성이지만, 현대 웹은 이 위에 구축된 다양한 상태 관리 메커니즘을 통해 풍부한 상호작용을 제공한다.

HTTP에서 자원에 대한 행동을 정의하는 주요 HTTP 메서드는 GET, POST, PUT, DELETE이다. 이 네 가지 메서드는 CRUD (Create, Read, Update, Delete) 작업과 대응되는 경우가 많으며, RESTful API 설계의 근간을 이룬다.

GET 메서드는 지정된 리소스의 표현을 요청한다. 서버의 데이터를 변경하지 않고 정보를 조회하는 데 사용되며, 요청 파라미터는 URL의 쿼리 문자열에 포함된다. 반면, POST 메서드는 서버에 데이터를 제출할 때 사용된다. 주로 새로운 리소스를 생성하거나, 기존 리소스에 데이터를 추가하는 데 활용된다. 요청 본문에 전송할 데이터를 담아 보낸다.

리소스의 전체적인 교체나 생성에 PUT 메서드가 사용된다. 클라이언트가 제공한 리소스로 지정된 URI의 리소스를 완전히 대체한다. 해당 URI에 리소스가 없으면 새로 생성하고, 있으면 덮어쓴다. DELETE 메서드는 지정된 리소스를 서버에서 삭제하도록 요청한다.

안전한 메서드는 서버의 상태를 변경하지 않아야 한다. 멱등한 메서드는 동일한 요청을 한 번 보내는 것과 여러 번 보내는 것이 서버에 동일한 효과를 가져야 한다[1].

HTTP GET과 POST 외에도, 웹 통신을 위한 여러 보조적인 메서드가 존재한다. 이 메서드들은 주로 정보를 얻거나, 서버의 기능을 확인하거나, 리소스의 일부만을 수정하는 데 사용된다.

HTTP HEAD 메서드는 GET 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않는다. 즉, 서버는 HTTP 헤더만을 반환해야 한다. 이 메서드는 주로 리소스의 존재 여부를 확인하거나(예: HTTP 상태 코드 404 확인), 리소스를 다운로드하지 않고도 Last-Modified 헤더를 통해 변경 시간을 확인하는 등의 용도로 사용된다. 이를 통해 불필요한 데이터 전송을 줄이고 네트워크 대역폭을 절약할 수 있다. HTTP OPTIONS 메서드는 특정 URL에 대해 서버가 지원하는 통신 옵션을 묻는 데 사용된다. 주로 CORS(Cross-Origin Resource Sharing) 사전 요청에서 특정 도메인과 메서드에 대한 접근 권한을 확인할 때 활용된다. 서버는 Allow 헤더를 통해 지원하는 메서드 목록(예: GET, POST, OPTIONS)을 응답한다.

HTTP PATCH 메서드는 리소스의 부분적인 수정을 위해 사용된다. PUT 메서드가 리소스를 전체적으로 교체하는 것과 달리, PATCH는 리소스의 특정 필드나 속성만을 변경하는 데 적합하다. 예를 들어, 사용자 프로필에서 이메일 주소만 업데이트할 때 전체 프로필 데이터를 다시 보내는 대신 변경된 필드만 전송할 수 있다. PATCH 요청의 본문 형식은 JSON Patch나 JSON Merge Patch와 같은 표준 포맷을 따르는 것이 일반적이다. 이 메서드는 효율적인 데이터 전송과 동시성 제어에 유용하다.

HTTP 상태 코드 1xx 범주는 정보 제공을 목적으로 하는 임시 응답이다. 이 코드는 요청이 수신되어 처리 중임을 알리며, 클라이언트는 요청을 계속하거나 서버의 응답을 기다려야 한다. 1xx 응답은 최종 응답이 아니므로 별도의 본문을 포함하지 않는다[4].

주요 1xx 상태 코드는 다음과 같다.

이러한 정보 응답은 주로 HTTP/1.1 프로토콜에서 효율적인 통신을 위해 사용된다. 예를 들어, 클라이언트가 큰 본문 데이터를 보내기 전에 Expect: 100-continue 헤더와 함께 요청을 보내면, 서버가 100 Continue로 응답한 후에 본문 전송을 시작할 수 있다. 이는 네트워크 자원을 절약하는 데 도움이 된다.

HTTP 상태 코드 2xx 범위는 클라이언트의 요청이 성공적으로 수신되고, 이해되고, 처리되었음을 나타낸다. 가장 일반적으로 사용되는 코드는 200 OK이다. 이 코드는 요청이 성공했으며, 응답 본문에 요청된 리소스(예: HTML 문서, JSON 데이터)가 포함되어 있음을 의미한다.

다른 주요 2xx 상태 코드로는 다음과 같은 것들이 있다.

• 201 Created: 요청이 성공적으로 처리되어 새로운 리소스가 생성되었다. 이 응답은 일반적으로 POST 또는 PUT 요청 이후에 반환되며, 새로 생성된 리소스의 위치는 Location 헤더에 포함되는 경우가 많다.

• 202 Accepted: 요청은 수락되었지만, 처리가 아직 완료되지 않았다. 이는 비동기적으로 처리되는 작업에 사용된다.

• 204 No Content: 요청은 성공했지만, 클라이언트에 돌려줄 콘텐츠가 없다. 응답 본문은 비어 있다. 이 코드는 성공 여부만이 중요할 때, 예를 들어 DELETE 요청이나 폼 제출 후 페이지를 새로 고치지 않는 경우에 사용된다.

• 206 Partial Content: 클라이언트가 Range 헤더를 사용해 리소스의 일부만 요청했을 때 반환된다. 이는 대용량 파일을 청크로 나누어 다운로드하거나, 비디오 스트리밍 시에 유용하다.

2xx 상태 코드는 모두 성공을 의미하지만, 그 의미와 사용되는 상황은 미묘하게 다르다. 올바른 상태 코드를 선택하는 것은 API 설계의 명확성과 클라이언트의 정확한 동작을 보장하는 데 중요하다.

3xx 상태 코드는 클라이언트가 요청을 완료하기 위해 추가적인 조치(일반적으로 다른 URI로의 리다이렉션)를 취해야 함을 나타낸다. 이 코드들은 사용자를 새로운 위치로 안내하거나, 요청의 대안을 제시하는 데 사용된다.

대표적인 3xx 상태 코드는 다음과 같다.

리다이렉션은 웹사이트 구조 변경, 콘텐츠 통합, 보안 강화(HTTP에서 HTTPS로 전환) 등 다양한 상황에서 활용된다. 클라이언트(주로 웹 브라우저)는 이 상태 코드를 받으면 대부분 자동으로 Location 헤더에 지정된 새 주소로 요청을 재시도한다.

4xx 상태 코드는 클라이언트의 요청에 오류가 있어 서버가 요청을 처리할 수 없음을 나타낸다. 서버는 요청의 구문이 잘못되었거나, 요청을 이해할 수 없거나, 요청을 이행할 수 없는 상황에서 이 코드를 반환한다. 이 오류는 일반적으로 클라이언트 측에서 요청을 수정해야 함을 의미한다.

가장 흔한 4xx 오류 코드는 다음과 같다.

이 외에도 402(Payment Required), 406(Not Acceptable), 409(Conflict), 410(Gone), 411(Length Required), 413(Payload Too Large), 414(URI Too Long), 415(Unsupported Media Type), 422(Unprocessable Entity), 426(Upgrade Required) 등 다양한 상황에 맞는 클라이언트 오류 코드가 존재한다. 이러한 코드들은 클라이언트가 정확한 문제를 파악하고 요청을 수정하는 데 도움을 준다.

5xx 상태 코드는 서버 측에서 요청을 처리하는 과정에서 오류가 발생했음을 나타낸다. 클라이언트의 요청 자체는 유효했지만, 서버가 그 요청을 이행하지 못한 상황을 의미한다. 이는 서버의 내부 로직 결함, 과부하, 게이트웨이 문제 등 다양한 원인에서 발생한다. 클라이언트는 동일한 요청을 다시 시도할 수 있지만, 서버 측 문제가 해결되지 않으면 동일한 오류가 반복된다.

가장 대표적인 5xx 오류는 500 Internal Server Error이다. 이는 서버가 요청을 처리하는 중에 예상치 못한 상황을 맞아 구체적인 오류 상태 코드를 반환할 수 없을 때 사용되는 일반적인 서버 오류 응답이다. 서버의 애플리케이션 로직 오류, 설정 오류, 예외 처리 실패 등이 원인이 될 수 있다.

다른 주요 5xx 상태 코드로는 다음과 같은 것들이 있다.

이러한 오류는 주로 서버 관리자의 조치가 필요하다. 클라이언트 개발자는 5xx 오류를 받았을 때, 사용자에게 서버 문제를 알리고 일정 시간 후 재시도하도록 유도하는 것이 일반적이다. 특히 503 Service Unavailable의 경우, 응답 헤더에 제공된 Retry-After 지시자를 참고하여 재시도 타이밍을 조절할 수 있다.

일반 헤더는 HTTP 요청과 HTTP 응답 모두에서 사용될 수 있는 헤더 필드이다. 이 헤더들은 메시지의 전송 자체와 관련된 정보를 담고 있으며, 특정 요청이나 응답의 콘텐츠와는 직접적인 연관이 없다. 주로 연결 관리, 캐싱 제어, 메시지 전송 시간 등의 통신 과정에 필요한 메타데이터를 제공하는 역할을 한다.

주요 일반 헤더의 예는 다음과 같다.

이러한 헤더들은 클라이언트와 서버 간의 효율적인 통신을 조율하는 데 기여한다. 예를 들어, Cache-Control 헤더는 네트워크 트래픽을 줄이고 응답 속도를 높이는 캐싱 동작을 제어하며, Connection 헤더는 TCP 연결의 생명주기를 관리하여 연결 설정 오버헤드를 최소화한다. 일반 헤더는 애플리케이션 데이터를 운반하는 메시지의 "운송 수단"에 대한 설정을 담당한다고 볼 수 있다.

요청 헤더는 클라이언트가 서버로 보내는 HTTP 요청 메시지의 일부로, 요청에 대한 추가 정보를 제공한다. 이 헤더들은 요청하는 리소스나 클라이언트 자체에 대한 메타데이터를 포함한다. 주요 기능은 요청의 컨텍스트를 정의하고, 서버가 적절한 응답을 생성할 수 있도록 필요한 조건을 전달하는 것이다.

주요 요청 헤더는 다음과 같이 분류하여 설명할 수 있다.

이 외에도 If-Modified-Since, If-None-Match와 같은 조건부 요청 헤더나, Cache-Control을 요청에 사용하여 캐싱 동작을 지시할 수 있다. 요청 헤더를 효과적으로 사용하면 콘텐츠 협상, 효율적인 캐싱, 인증, 세션 관리 등이 가능해진다.

응답 헤더는 서버가 클라이언트에게 보내는 HTTP 응답 메시지의 일부로, 응답에 대한 부가 정보를 담고 있다. 이 헤더들은 응답의 상태, 서버 정보, 리소스에 대한 메타데이터, 그리고 클라이언트가 응답을 어떻게 처리해야 하는지에 대한 지시 사항을 포함한다.

주요 응답 헤더는 다음과 같은 범주로 나눌 수 있다.

또한, 캐싱 정책을 제어하거나 보안 관련 지시를 내리는 헤더들도 중요하다. 예를 들어, Cache-Control 헤더는 응답된 리소스를 클라이언트나 중간 프록시 서버가 얼마나 오래 캐시할 수 있는지 정의한다. Strict-Transport-Security 헤더는 브라우저가 해당 사이트에 향후 접속 시 HTTPS를 통해서만 연결하도록 강제하는 보안 정책을 전달한다. 이러한 헤더들은 웹 애플리케이션의 성능과 보안을 구성하는 데 핵심적인 역할을 한다.

엔터티 헤더는 HTTP 요청이나 응답의 본문(메시지 바디)에 포함된 리소스 자체에 대한 메타데이터를 설명한다. 이 헤더들은 전송되는 데이터의 콘텐츠 유형, 길이, 인코딩 방식, 최종 수정 시간 등을 나타내어, 클라이언트와 서버가 리소스를 어떻게 해석하고 처리해야 하는지에 대한 정보를 제공한다.

주요 엔터티 헤더로는 다음과 같은 것들이 있다.

이 헤더들은 특히 캐싱과 조건부 요청에서 중요한 역할을 한다. 예를 들어, Last-Modified 헤더는 클라이언트가 이후 요청 시 If-Modified-Since 헤더를 함께 보내어 리소스가 변경되었는지 확인하는 조건부 요청의 기준이 된다. 또한 Content-Encoding 헤더는 데이터가 압축되어 전송되었음을 알려, 클라이언트가 적절하게 압축을 해제하도록 한다.

HTTP/1.1 이후, 일부 엔터티 헤더는 "표현 헤더(Representation Header)"라는 범주로 재분류되기도 한다. 이는 동일한 리소스가 서로 다른 표현(예: 다른 언어나 인코딩)으로 제공될 수 있음을 더 명확히 반영하기 위함이다. 그러나 엔터티 헤더라는 용어는 여전히 본문과 관련된 메타데이터를 지칭하는 데 널리 사용된다.

HTTP/0.9는 1991년 팀 버너스리가 제안한 최초의 HTTP 프로토콜 버전이다. 매우 단순한 설계를 가지고 있어, 오직 GET 메서드만을 지원했고, 응답은 HTML 문서 본문만으로 구성되었다. 상태 코드나 HTTP 헤더의 개념이 존재하지 않았으며, 연결은 단일 요청과 응답 이후에 즉시 종료되었다. 이는 단순히 하이퍼텍스트 문서를 가져오는 데만 초점을 맞춘 프로토타입에 가까운 프로토콜이었다.

HTTP/1.0은 1996년 RFC 1945로 공식화되면서 프로토콜이 크게 확장되었다. 주요 개선 사항은 다음과 같다.

HTTP/1.0은 현대 웹의 기초를 마련했지만, 성능상의 한계가 명확했다. 각 요청에 대해 별도의 TCP 연결을 설정해야 하는 오버헤드가 컸으며, 파이프라이닝과 같은 고급 기능은 표준화되지 않았다. 이러한 한계점은 이후 HTTP/1.1의 등장으로 이어지는 주요 동기가 되었다.

HTTP/1.1은 1997년 [6]에 처음 정의되었으며, 1999년 [7]으로 개정되어 2014년까지 공식 표준으로 유지되었다. 이 버전은 HTTP/1.0의 주요 한계를 해결하고 웹의 폭발적 성장을 뒷받침하는 핵심 기능들을 도입하였다.

가장 중요한 개선점은 지속 연결(Persistent Connection)과 파이프라이닝(Pipelining)이다. 지속 연결은 하나의 TCP 연결을 통해 여러 개의 요청과 응답을 순차적으로 처리할 수 있게 하여, 매번 연결을 설정하고 종료하는 데 드는 오버헤드를 크게 줄였다. 파이프라이닝은 클라이언트가 첫 번째 요청에 대한 응답을 기다리지 않고 연속적으로 여러 요청을 보낼 수 있는 기능이었으나, 실제 구현과 사용에서의 복잡성으로 인해 널리 채택되지는 못했다. 또한, 호스트 헤더(Host header)의 필수화로 하나의 서버 IP 주소에서 여러 도메인을 호스팅하는 가상 호스팅(Virtual Hosting)이 가능해졌다.

다음 표는 HTTP/1.1에서 새로 도입되거나 강화된 주요 기능을 정리한 것이다.

이러한 개선에도 불구하고 HTTP/1.1은 본질적으로 텍스트 기반의 프로토콜이며, 요청-응답이 순차적으로 처리되어야 하는 구조적 한계를 가지고 있었다. 이로 인해 다수의 리소스를 로드하는 현대적인 웹 페이지에서는 HOL 블로킹(Head-of-Line Blocking) 문제가 발생하여 성능 병목 현상을 일으켰다. 이러한 한계는 이후 HTTP/2와 HTTP/3의 개발을 촉진하는 주요 동기가 되었다.

HTTP/2는 2015년에 공식 표준으로 채택된 HTTP 프로토콜의 주요 개정판이다. 이 버전의 주요 목표는 HTTP/1.1의 성능 한계, 특히 레이턴시(latency) 문제를 해결하여 웹 페이지 로딩 속도를 높이는 것이었다. 핵심적인 변화는 텍스트 기반의 프로토콜에서 이진(binary) 프레이밍 계층을 도입한 것이다. 이 변경으로 프레이밍과 파싱이 효율적이고 오류 가능성이 낮아졌으며, 텍스트 처리에 따른 오버헤드가 제거되었다.

가장 중요한 기능은 단일 TCP 연결 내에서 다중 요청과 응답을 동시에 처리할 수 있는 멀티플렉싱이다. HTTP/1.1에서는 파이프라이닝이 제한적으로 지원되었지만, 헤드 오브 라인 블로킹 문제가 있었다. HTTP/2에서는 여러 HTTP 스트림이 병렬로 전송되고 인터리빙(interleaving)되며, 수신 측에서 재조립되기 때문에 이 문제가 해결되었다. 또한 서버가 클라이언트의 요청 없이도 필요한 리소스를 사전에 푸시할 수 있는 서버 푸시 기능을 도입했다. 이를 통해 서버는 예상되는 추가 리소스(예: HTML 문서에 연결된 CSS나 JavaScript 파일)를 클라이언트의 캐시에 먼저 보낼 수 있어 추가적인 왕복 시간을 줄인다.

프로토콜 효율성을 높이기 위한 다른 기능들도 포함되었다. 헤더 압축을 위해 HPACK 알고리즘을 사용하여 반복되는 헤더 필드의 전송 오버헤드를 크게 줄였다. 또한 스트림에 우선순위를 부여할 수 있어, 클라이언트가 중요한 리소스(예: 페이지 렌더링을 블록하는 CSS)에 더 높은 대역폭과 빠른 응답을 요청할 수 있게 했다.

HTTP/2는 하위 호환성을 유지하면서 설계되었다. 애플리케이션 계층의 HTTP 의미 체계(메서드, 상태 코드, 헤더 필드 등)는 변경되지 않았으며, 주로 전송 방식이 개선되었다. 따라서 기존 웹 애플리케이션과 API는 수정 없이도 HTTP/2의 이점을 누릴 수 있다. 이 버전은 빠르게 주요 브라우저와 서버(예: Apache, Nginx, Node.js)에 구현되어 광범위하게 채택되었다.

HTTP/3은 월드 와이드 웹에서 정보를 교환하기 위해 사용되는 하이퍼텍스트 전송 프로토콜의 세 번째 주요 버전이다. 이전 버전인 HTTP/2와 달리, 전송 계층 프로토콜로 TCP 대신 QUIC을 사용하는 것이 가장 큰 특징이다. QUIC은 UDP 위에 구축된 프로토콜로, TCP의 핸드셰이크 지연과 HOL 블로킹 문제를 해결하기 위해 설계되었다. HTTP/3의 표준은 IETF에 의해 2022년 6월에 RFC 9114로 공식 발표되었다.

HTTP/3의 핵심 장점은 연결 설정 시간의 단축과 멀티플렉싱 성능 향상이다. TCP와 TLS를 결합한 기존 방식은 연결을 설정하는 데 여러 번의 왕복이 필요했지만, QUIC은 암호화와 전송 계층 연결 설정을 단일 핸드셰이크로 통합하여 지연을 크게 줄인다. 또한, QUIC은 패킷 손실이 발생하더라도 다른 스트림의 데이터 전송을 막지 않는 독립적인 스트림을 제공하여, HTTP/2에서 여전히 존재했던 TCP 수준의 HOL 블로킹 문제를 근본적으로 해결한다.

주요 구성 요소와 동작 방식은 다음과 같다.

이러한 변화로 인해 HTTP/3는 특히 불안정한 모바일 네트워크 환경에서 페이지 로드 시간을 개선하는 데 효과적이다. 모든 주요 웹 브라우저(크롬, 파이어폭스, 사파리, 엣지)와 클라우드플레어, 구글, 페이스북과 같은 주요 콘텐츠 전송 네트워크 및 서비스 제공업체들이 HTTP/3를 지원한다. 그러나 네트워크 중간 장비(방화벽, 로드 밸런서 등)가 UDP 트래픽을 제대로 인식하고 허용하지 않을 경우 연결 문제가 발생할 수 있다는 실무적인 과제도 남아 있다.

HTTPS는 HTTP 프로토콜에 보안 계층을 추가한 것이다. 이 보안 계층은 주로 TLS 또는 그 전신인 SSL 프로토콜을 사용하여 구현된다. HTTPS를 사용하면 클라이언트와 서버 간에 교환되는 모든 데이터가 암호화되므로, 제3자가 통신 내용을 도청하거나 변조하는 것을 방지할 수 있다. 이는 특히 로그인 정보, 결제 정보, 개인 데이터 등 민감한 정보를 전송할 때 필수적이다.

HTTPS 연결은 핸드셰이크(handshake) 과정으로 시작된다. 클라이언트가 서버에 연결을 요청하면, 서버는 자신의 디지털 인증서를 클라이언트에게 전송한다. 이 인증서는 신뢰할 수 있는 인증 기관에 의해 발급되며, 서버의 공개 키와 신원 정보를 포함한다. 클라이언트는 이 인증서의 유효성을 검증한 후, 서버의 공개 키를 사용하여 대칭 암호화에 사용될 세션 키를 암호화하여 서버로 보낸다. 이후의 모든 통신은 이 세션 키로 암호화된다.

현대 웹에서는 보안과 개인 정보 보호 강화, 검색 엔진 최적화(SEO) 이점, 그리고 최신 웹 플랫폼 기능(예: Geolocation API) 사용 요구 등으로 인해 HTTPS 사용이 사실상 표준이 되었다. 대부분의 주요 브라우저는 HTTPS가 아닌 사이트에 대해 '안전하지 않음' 경고를 표시한다[8]. 따라서 모든 종류의 웹사이트, 단순 정보 제공 사이트조차도 HTTPS를 채택하는 것이 권장된다.

HTTP는 기본적으로 인증 메커니즘을 제공하지 않는다. 따라서 보호된 자원에 접근하기 위해서는 클라이언트가 자신의 신원을 증명해야 하며, 이를 위해 기본 인증과 토큰 기반 인증 등 다양한 방식이 사용된다.

기본 인증은 가장 단순한 형태의 HTTP 인증 방식이다. 클라이언트가 보호된 자원을 요청하면, 서버는 401 Unauthorized 상태 코드와 함께 WWW-Authenticate 헤더를 응답한다. 클라이언트는 사용자 이름과 비밀번호를 콜론(:)으로 연결한 후 Base64로 인코딩하여 Authorization 헤더에 담아 다시 요청을 보낸다[9]. 이 방식은 구현이 간단하지만, 자격 증명이 암호화되지 않은 채로 전송되기 때문에 반드시 HTTPS와 함께 사용해야 안전하다. 또한 매 요청마다 자격 증명을 전송해야 하고, 서버에서 세션 상태를 관리하지 않는다는 점이 특징이다.

보다 현대적이고 확장성 있는 방식은 토큰 기반 인증이다. 대표적으로 JWT가 널리 사용된다. 이 방식에서는 사용자가 처음으로 자격 증명(예: 아이디/비밀번호)을 서버에 제출하면, 서버는 해당 정보를 검증하고 서명된 토큰을 생성하여 응답한다. 클라이언트는 이후 요청의 Authorization 헤더에 이 토큰을 담아 전송한다[10]. 서버는 토큰의 서명을 검증하여 요청의 유효성을 확인한다. 토큰 자체가 필요한 정보(클레임)를 포함할 수 있어 서버 측 세션 저장이 불필요한 상태 비저장성을 유지할 수 있으며, OAuth 2.0 같은 위임 인증 표준과의 호환성도 좋다.

HTTP 캐싱의 동작을 제어하기 위해 사용되는 주요 헤더는 Cache-Control, Expires, ETag, Last-Modified 등이 있다. 이 헤더들은 서버가 응답에 포함시키거나, 클라이언트가 요청에 포함시켜 캐시의 저장, 유효성 재확인, 만료 정책을 관리한다.

Cache-Control 헤더는 가장 강력하고 유연한 캐시 제어 메커니즘을 제공한다. 이 헤더는 공백으로 구분된 여러 지시어(directive)를 통해 캐시 동작을 세밀하게 조정한다. 주요 지시어로는 캐시 저장을 금지하는 no-store, 매번 서버에 유효성 검사를 요구하는 no-cache, 공유 캐시(예: 프록시 서버)에 저장하지 않도록 하는 private, 특정 시간 동안 캐시를 신선한 상태로 유지하는 max-age(초 단위) 등이 있다. 예를 들어, Cache-Control: public, max-age=3600은 응답을 공유 캐시에 저장할 수 있으며 1시간 동안 신선하다고 간주함을 의미한다.

Expires 헤더는 HTTP/1.0에서 도입된 절대적인 만료 날짜와 시간을 지정하는 방식이다. Expires: Wed, 21 Oct 2025 07:28:00 GMT와 같이 표시한다. 이 방식은 서버와 클라이언트의 시계가 동기화되어 있어야 정확하게 동작한다는 단점이 있다. 현대적인 캐싱에서는 상대적인 시간을 지정하는 Cache-Control: max-age 지시어를 우선적으로 사용하는 것이 권장된다.

조건부 요청을 위한 헤더로는 ETag(엔터티 태그)와 Last-Modified가 있다. ETag는 리소스의 특정 버전을 식별하는 불투명한 식별자 문자열이다. 서버는 응답에 ETag: "33a64df5"와 같은 값을 제공한다. 클라이언트는 이후 요청 시 If-None-Match 헤더에 이 값을 담아 보내어 리소스가 변경되었는지 확인한다. Last-Modified는 리소스가 마지막으로 수정된 날짜를 나타내며, 클라이언트는 If-Modified-Since 헤더를 사용하여 유효성 재확인을 수행한다. ETag는 Last-Modified보다 더 정확한 변경 감지가 가능하다는 장점이 있다.

조건부 요청은 클라이언트가 서버에 특정 조건이 만족될 때만 자원을 전송하도록 요청하는 HTTP 메커니즘이다. 이는 캐시의 유효성을 검사하거나, 자원의 업데이트를 안전하게 수행하는 데 사용된다. 클라이언트는 요청에 특별한 헤더를 포함시켜 조건을 명시하며, 서버는 해당 조건을 평가한 후 조건이 충족되면 일반적인 응답을, 충족되지 않으면 상태 코드 304 Not Modified와 같은 간단한 응답을 반환한다.

주요 조건부 요청 헤더는 If-Modified-Since, If-None-Match, If-Match, If-Unmodified-Since 등이 있다. If-Modified-Since는 주어진 날짜 이후에 자원이 변경되었을 경우에만 전송을 요청하며, 주로 캐시 갱신에 사용된다. If-None-Match는 서버가 부여한 ETag 값과 클라이언트가 가진 값이 일치하지 않을 때만 자원을 요청한다. 이는 Last-Modified 날짜보다 더 정확한 변경 감지 수단으로 간주된다.

조건부 요청의 일반적인 동작 흐름은 다음과 같다.

이 메커니즘은 특히 대역폭을 절약하고 서버 부하를 줄이는 데 효과적이다. 변경되지 않은 자원에 대해 전체 본문을 다시 전송할 필요가 없어지기 때문이다. 또한 If-Match 헤더를 사용하면 낙관적 잠금을 구현하여 동시 편집 충돌을 방지하는 등, RESTful API에서 자원의 무결성을 유지하는 데도 활용된다.

RESTful API는 HTTP 프로토콜의 설계 원칙과 제약 조건을 준수하여 웹 서비스를 구축하는 아키텍처 스타일이다. 이 용어는 로이 필딩의 박사 논문에서 소개된 REST(Representational State Transfer) 원칙을 따르는 API를 지칭한다. RESTful API는 자원을 URI(Uniform Resource Identifier)로 식별하고, 해당 자원에 대한 조작을 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 표현한다. 이는 웹의 기본적인 동작 방식을 그대로 활용하여 간결하고 예측 가능한 인터페이스를 제공하는 것이 핵심 목표이다.

RESTful API는 몇 가지 핵심 제약 조건을 따른다. 첫째, 클라이언트-서버 아키텍처를 통해 관심사를 분리한다. 둘째, 상태 비저장성(Statelessness)을 유지하여 각 요청이 필요한 모든 정보를 자체적으로 포함하도록 한다. 셋째, 캐시 가능성(Cacheability)을 명시하여 네트워크 효율성을 높인다. 넷째, 계층화된 시스템(Layered System)을 지원한다. 다섯째, 필요에 따라 코드 온 디맨드(Code on Demand)를 선택적으로 적용할 수 있다. 가장 중요한 여섯 번째 원칙은 Uniform Interface(일관된 인터페이스)로, 자원의 식별, 표현을 통한 조작, 자기 서술적 메시지, 그리고 애플리케이션 상태의 엔진으로서의 하이퍼미디어(HATEOAS)를 포함한다.

실제 구현에서 RESTful API는 일반적으로 JSON 또는 XML 형식을 사용하여 데이터를 교환한다. 자원은 명사형 URI로 표현되며, 동작은 HTTP 메서드에 의해 정의된다. 예를 들어, /users라는 URI에 GET 요청을 보내면 사용자 목록을 조회하고, POST 요청을 보내면 새로운 사용자를 생성한다. /users/123에 GET 요청을 보내면 ID가 123인 사용자 정보를 조회하며, PUT 요청을 보내면 해당 사용자 정보를 갱신한다.

RESTful 아키텍처는 단순성, 확장성, 독립성 등의 장점으로 인해 모바일 애플리케이션, 마이크로서비스, 공공 오픈 API 등 다양한 분야에서 널리 채택되었다. 그러나 HATEOAS의 엄격한 적용이나 표준화된 오류 처리 방식의 부재 등은 실무에서 논의의 대상이 되기도 한다. 이러한 점을 보완하기 위해 JSON API(https://jsonapi.org/)나 OData(https://www.odata.org/)와 같은 표준 사양이 제안되기도 하였다.

WebSocket은 TCP 연결 위에서 작동하는 양방향 통신 프로토콜이다. HTTP의 단방향 요청-응답 모델을 보완하여, 한 번 연결을 수립한 후에는 서버와 클라이언트가 자유롭게 데이터를 주고받을 수 있는 전이중(full-duplex) 통신 채널을 제공한다.

WebSocket 연결은 일반적인 HTTP 요청으로 시작된다. 클라이언트는 Upgrade: websocket 헤더를 포함한 특별한 HTTP 요청을 보낸다. 서버가 이를 승인하면, TCP 연결은 HTTP 프로토콜에서 WebSocket 프로토콜로 "업그레이드"된다. 이후부터는 HTTP의 오버헤드가 없는 경량의 데이터 프레임을 사용하여 효율적으로 통신한다.

이 프로토콜은 실시간 기능이 필요한 다양한 애플리케이션에 널리 사용된다. 대표적인 예로는 실시간 채팅, 주식 시세 표시, 온라인 게임, 협업 편집 도구, 그리고 실시간 알림 시스템 등이 있다. 기존의 폴링(polling)이나 Comet 같은 기술에 비해 서버 부하가 적고 지연 시간이 짧다는 장점이 있다.

관련 문서:

• MDN Web Docs - WebSocket

• IETF RFC 6455 - The WebSocket Protocol

HTTP/2 Server Push는 서버가 클라이언트의 명시적인 요청 없이도 클라이언트에 필요한 리소스를 사전에 전송할 수 있는 기능이다. 이는 웹 페이지 로딩 성능을 개선하기 위해 설계되었다. 기존의 HTTP/1.1에서는 클라이언트가 HTML 문서를 수신하고 파싱한 후, 문서 내에 참조된 CSS, JavaScript, 이미지 파일 등을 발견해야만 해당 리소스에 대한 추가 요청을 보낼 수 있었다. 이로 인해 여러 번의 왕복 지연이 발생하여 페이지 로딩 시간이 길어지는 원인이 되었다. HTTP/2 Server Push는 서버가 클라이언트가 아직 요청하지도 않은 리소스를 미리 예측하여 푸시 스트림을 통해 함께 전송함으로써 이러한 지연을 줄인다.

동작 원리는 다음과 같다. 클라이언트가 초기 HTML 페이지를 요청하면, 서버는 해당 페이지를 응답하면서 동시에 해당 페이지에서 필요로 할 것으로 예상되는 추가 리소스(예: 주요 스타일시트나 스크립트 파일)에 대한 가상의 "요청"을 서버 내부에서 생성한다. 그런 후, 이 리소스들을 클라이언트에게 푸시한다. 클라이언트는 푸시된 리소스를 받아 캐시에 저장한다. 이후 클라이언트가 페이지를 파싱하고 해당 리소스가 필요해지면, 이미 캐시에 저장되어 있기 때문에 네트워크 요청을 다시 보낼 필요가 없어진다.

이 기술의 효과와 주의점은 아래 표와 같다.

Server Push는 강력한 최적화 도구이지만, 남용하면 오히려 성능을 해칠 수 있다. 따라서 리소스 간의 의존성을 정확히 분석하고, 캐시 가능성이 높은 정적 리소스에 선택적으로 적용하며, 클라이언트의 캐시 상태를 고려하는 것이 중요하다. 현대적인 웹 개발에서는 Server Push보다는 리소스 우선순위 힌트(Priority Hint)나 프리로드(Preload)와 같은 다른 HTTP/2 또는 HTML 기능과 조합하여 사용하는 경우가 많다.