[HTTP] 모든 것이 HTTP인 시대, 웹 통신의 근간 이해하기

1. 도입부 

현대 인터넷에서 주고받는 거의 모든 형태의 데이터—HTML, 텍스트, 이미지, 영상, JSON—는 HTTP(HyperText Transfer Protocol)라는 통로를 통해 흐른다. 과거에는 단순히 하이퍼텍스트를 전송하는 용도였지만, 이제는 서버 간의 통신조차 HTTP를 기반으로 이루어지는 '모든 것이 HTTP인 시대'가 되었다.

웹 개발자에게 HTTP를 이해한다는 것은 단순히 통신 방식을 아는 것을 넘어, 서버의 확장성을 어떻게 확보하고 대용량 트래픽을 어떻게 제어할 것인지에 대한 설계 철학을 배우는 것과 같다. 오늘은 HTTP를 지탱하는 핵심 원칙인 클라이언트-서버 구조, 무상태성, 그리고 메시지 구조를 깊이 있게 살펴본다.

[Infra] URI, URL, URN의 차이와 웹의 요청 메커니즘

 

 

 

2. 주요 특징: 클라이언트 서버 구조와 기반 프로토콜

HTTP는 기본적으로 Request-Response(요청-응답) 구조를 가진다. 클라이언트는 서버에 요청을 보내고 응답을 대기하며, 서버는 그에 대한 결과를 만들어 응답하는 독립적인 구조다. 이러한 분리는 클라이언트와 서버가 각자의 로직에만 집중할 수 있게 하여 웹의 비약적인 발전을 이끌었다.

HTTP 버전별 기반 프로토콜

현재는 HTTP/1.1을 주로 사용하지만, 성능이 개선된 2와 3의 비중도 급증하고 있다.

• HTTP/1.1, HTTP/2: 신뢰성 중심의 TCP 기반.
• HTTP/3: 성능과 속도 중심의 UDP 기반.

 

 

3. 무상태 프로토콜 (Stateless)

서버 개발자들이 가장 까다로워하는 업무 중 하나가 '찰나에 발생하는 대용량 트래픽'이다. 수강신청이나 선착순 이벤트가 대표적이다. 이를 해결하는 열쇠가 바로 Stateless(무상태) 설계다.

Stateful vs Stateless 비교

• 장점: 서버 확장성이 매우 높다(Scale-out). 어떤 서버가 요청을 받아도 처리가 가능하므로 무한한 서버 증설이 가능하다.
• 단점: 클라이언트가 매번 추가 데이터를 전송해야 하므로 데이터 양이 조금 더 많아진다.

Note: 로그인 상태 유지와 같이 어쩔 수 없이 상태를 유지해야 하는 경우는 브라우저 쿠키나 서버 세션 등을 활용해 최소한으로만 사용해야 한다.

 

 

4. 비연결성 (Connectionless)

HTTP는 기본적으로 연결을 유지하지 않는 모델이다. 수천 명의 사용자가 서비스를 이용해도, 실제로 동시에 요청을 처리하는 순간은 매우 짧기 때문에 서버 자원을 극도로 효율적으로 사용할 수 있다.

한계와 극복: 지속 연결 (Persistent Connections)

비연결성은 매번 TCP/IP 3-way handshake를 새로 맺어야 한다는 시간적 손실이 있다. 특히 웹 페이지 하나를 불러올 때 HTML, CSS, JS, 이미지 등 수많은 자원을 따로 요청하면 성능이 저하된다.

 

 

5. HTTP 메시지 구조 (Message Structure)

HTTP 메시지는 크게 시작 라인, 헤더, 바디 세 부분으로 나뉜다.

(1) 요청 메시지 (Request Message)

• 시작 라인: GET /search?q=hello&hl=ko HTTP/1.1
  • HTTP 메서드 (GET: 조회, POST: 처리, PUT, DELETE 등)
  • 요청 대상 (절대경로와 쿼리 파라미터)
  • HTTP 버전

(2) 응답 메시지 (Response Message)

• 시작 라인: HTTP/1.1 200 OK
  • HTTP 버전
  • 상태 코드 (200: 성공, 400: 클라이언트 오류, 500: 서버 오류)
  • 이유 문구 (사람이 읽는 설명)

(3) HTTP 헤더와 바디

• 헤더(Header): 메시지 바디의 크기, 압축 방식, 인증 정보, 브라우저 정보 등 전송에 필요한 모든 부가 정보를 담는다. 필요시 helloworld: hihi와 같이 임의의 헤더를 추가할 수도 있다.
• 바디(Body): 실제 전송할 데이터다. HTML, 이미지, JSON 등 바이트로 표현 가능한 모든 데이터가 이곳에 담긴다.

 

 

 

6. 실무 팁 및 주의사항

• 서버 확장의 핵심: 서버가 클라이언트의 이전 요청 상태를 저장하고 있다면, 특정 서버에 장애가 났을 때 다른 서버가 대신하기 어렵다. 대규모 트래픽을 감당해야 한다면 최대한 Stateless하게 설계하여 스케일 아웃이 가능하게 만들어야 한다.
• 상태 코드의 의미: 200만 안다고 끝이 아니다. 400(잘못된 요청)과 500(서버 터짐)을 정확히 구분하여 프론트엔드에 전달해야 디버깅 시간이 비약적으로 단축된다.