HTTP란 무엇인가? (HTTP 개관)

HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트와 서버가 데이터를 주고받기 위한 통신 규약이다. 웹 브라우저가 웹 서버에 HTML 문서를 요청하고, 서버가 응답을 반환하는 모든 과정이 HTTP를 통해 이루어진다.

HTTP의 특징

HTTP는 클라이언트-서버 구조로 동작한다. 클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 반환하는 단방향 통신 모델이다. 서버는 클라이언트의 요청 없이 먼저 데이터를 보낼 수 없다.

각 요청은 완전히 독립적이며, 서버는 이전 요청을 기억하지 않는다. 첫 번째 요청에서 로그인했더라도, 두 번째 요청에서 서버는 그 사실을 알지 못한다.

이 제약을 해결하기 위해 쿠키(Cookie)나 세션(Session), JWT 토큰을 사용한다. 클라이언트가 매 요청마다 인증 정보를 함께 보내면, 서버는 요청마다 사용자를 식별할 수 있다. 이러한 특징은 특정 서버에 종속되지 않아 수평적 확장이 용이하다.

HTTP는 텍스트 기반 프로토콜로 요청과 응답 메시지가 사람이 읽을 수 있는 텍스트 형식으로 작성되며 헤더와 본문을 명확히 구분해 디버깅과 분석이 쉽다.

GET /api/users HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: application/json

위 요청은 모두 텍스트로 구성되어 있어 네트워크 패킷을 분석하면 내용을 바로 확인할 수 있다. 하지만 텍스트 기반이라 바이너리보다 크기가 크고, HTTP/2부터는 성능을 위해 바이너리 프레이밍을 도입했다.

HTTP와 TCP/IP

HTTP는 애플리케이션 계층 프로토콜로, 실제 데이터 전송은 하위 계층인 TCP/IP가 담당한다.

TCP(Transmission Control Protocol)는 전송 계층 프로토콜로, 신뢰성 있는 데이터 전송을 보장한다. 패킷이 순서대로 도착하도록 관리하고, 손실된 패킷을 재전송하며, 흐름 제어와 혼잡 제어를 수행한다.

HTTP 요청을 보내기 전에 먼저 TCP 연결을 맺어야 한다. 이를 3-Way Handshake라고 하며, 클라이언트와 서버가 서로 통신 준비가 되었는지 확인하는 과정이다.

1. 클라이언트 → 서버: SYN (연결 요청)
2. 서버 → 클라이언트: SYN-ACK (연결 수락)
3. 클라이언트 → 서버: ACK (확인)

이후 HTTP 요청과 응답이 오가고, 연결을 종료할 때는 4-Way Handshake를 수행한다. 이러한 연결 설정 과정이 성능에 영향을 주기 때문에, HTTP/1.1부터는 Keep-Alive로 연결을 재사용하고, HTTP/2는 하나의 연결로 여러 요청을 동시에 처리한다.

IP(Internet Protocol)는 네트워크 계층 프로토콜로, 데이터를 패킷 단위로 나누어 목적지까지 전달한다. IP 주소를 통해 라우팅하며, 신뢰성은 보장하지 않는다.

HTTP는 TCP 위에서 동작하므로, TCP의 신뢰성과 순서 보장 특성을 활용한다. 하지만 TCP의 연결 설정 비용과 헤드 오브 라인 블로킹 문제도 존재하며, 이를 해결하기 위해 HTTP/3는 TCP 대신 QUIC(UDP 기반)을 사용한다.

HTTP 버전의 역사

HTTP는 웹의 발전과 함께 계속 진화해왔다. 각 버전은 이전 버전의 문제를 해결하고 성능을 개선했다.

HTTP/0.9 (1991)는 최초의 HTTP 버전으로, 매우 단순했다. GET 메서드만 지원하고, 헤더가 없으며, HTML만 전송할 수 있었다. 요청은 GET /index.html과 같은 방식으로 단 한 줄이었다.

HTTP/1.0 (1996)는 헤더를 도입하여 메타데이터를 전송할 수 있게 되었다. POST, HEAD 메서드가 추가되었고, 상태 코드로 결과를 구분했다. 이미지, 비디오 등 다양한 콘텐츠 타입을 지원했다. 하지만 요청마다 TCP 연결을 새로 맺어야 해서 비효율적이었다.

HTTP/1.1 (1997)는 가장 오래 사용된 버전으로, 현재도 널리 쓰인다. Keep-Alive가 기본값이 되어 연결을 재사용할 수 있게 되었다. 파이프라이닝으로 여러 요청을 한 번에 보낼 수 있게 되었지만, 응답은 순서대로 받아야 했다. PUT, DELETE, OPTIONS 등 메서드가 추가되었고, Host 헤더가 필수가 되어 가상 호스팅이 가능해졌다. 하지만 헤드 오브 라인 블로킹으로 첫 번째 응답이 지연되면 뒤의 모든 응답이 대기해야 했다. 헤더가 중복되어 전송되고, 텍스트 기반이라 파싱 오버헤드가 존재한다.

HTTP/2 (2015)는 성능 향상에 집중했다. 바이너리 프레이밍으로 파싱 속도가 빨라졌고, 멀티플렉싱으로 하나의 연결에서 여러 요청을 병렬 처리할 수 있게 되었다. 헤더 압축(HPACK)으로 중복 헤더를 줄였고, 서버 푸시로 클라이언트 요청 전에 리소스를 먼저 보낼 수 있게 되었다.

HTTP/3 (2022)는 TCP 대신 QUIC(UDP 기반)을 사용한다. TCP의 헤드 오브 라인 블로킹을 완전히 제거했고, 연결 설정이 더 빠르며, 패킷 손실에 강하다. 모바일 네트워크처럼 불안정한 환경에서 특히 유리하다.

HTTP의 구성 요소

• 클라이언트: 요청을 보내는 주체로, 웹 브라우저가 대표적이다. 클라이언트는 사용자의 행동에 따라 HTTP 요청을 생성하고, 응답을 받아 처리한다.

• 서버: 요청을 받아 응답을 반환하며 Nginx, Apache, Tomcat, Node.js 서버 등이 있다. 요청을 해석하여 적절한 리소스를 찾고, 비즈니스 로직을 수행한 뒤 응답을 생성한다.

• 프록시: 클라이언트와 서버 사이에서 중개 역할을 한다. 캐싱으로 응답 속도를 높이고, 로드 밸런싱으로 트래픽을 분산하며, 인증과 보안 검사를 수행한다. 로깅과 모니터링을 위해서도 사용된다.

• 캐시: 응답을 저장해두고 재사용한다. 브라우저 캐시, CDN 캐시, 서버 측 캐시가 있다. 같은 요청에 대해 서버까지 가지 않고 캐시에서 바로 응답하여 속도를 크게 개선한다.

백엔드 개발자에게 HTTP가 중요한 이유

백엔드 개발의 핵심은 HTTP API를 설계하고 구현하는 것이다. RESTful API는 HTTP 메서드와 상태 코드를 의미 있게 사용하여 직관적인 인터페이스를 제공한다. GET으로 조회하고, POST로 생성하며, PUT/PATCH로 수정하고, DELETE로 삭제한다. 상태 코드로 성공, 실패, 리다이렉션을 명확히 구분한다.

HTTP의 특성을 이해하면 성능을 최적화할 수 있다. Keep-Alive로 연결을 재사용하고, 캐싱으로 불필요한 요청을 줄이며, 압축으로 전송 크기를 줄인다. HTTP/2 멀티플렉싱을 활용하면 여러 요청을 병렬 처리할 수 있다.

무상태 프로토콜이므로 확장성 있는 아키텍처를 설계할 수 있다. 서버가 상태를 저장하지 않으면 여러 서버로 부하를 분산하기 쉽다. 로드 밸런서가 요청을 어떤 서버로 보내도 상관없다. 하지만 인증, 세션 관리는 별도로 고려해야 한다.

웹 서비스의 보안은 HTTP 레벨에서 시작된다. HTTPS로 통신을 암호화하고, CORS로 출처를 검증하며, CSP 헤더로 XSS를 방지한다. 인증 헤더(Authorization, Cookie)를 안전하게 관리해야 한다.