[HTTP 완전 정복 시리즈] 4편 - HTTP의 동작 원리와 메시지 구조

HTTP는 클라이언트와 서버가 데이터를 주고받기 위해 사용하는 프로토콜이다.
지금까지는 HTTP 요청이 네트워크를 어떻게 타고 흘러가는지 살펴봤다면,
이번에는 HTTP 자체가 어떻게 동작하는지,
그리고 요청과 응답 메시지의 구조는 어떻게 생겼는지를 정리해본다.

---

HTTP는 어떻게 동작하는가?

HTTP는 기본적으로 클라이언트-서버 구조로 작동한다.

• 클라이언트가 HTTP 요청을 보낸다.
• 서버는 요청을 처리한 후 응답을 보낸다.
• 응답을 받은 클라이언트는 이를 렌더링하거나 사용자에게 표시한다.

이 흐름은 단방향이며, 클라이언트가 요청을 보내지 않으면 서버는 응답하지 않는다.

---

무상태(Stateless) 구조

HTTP는 Stateless Protocol이다.
즉, 서버는 클라이언트의 이전 요청 상태를 기억하지 않는다.

• 요청마다 독립적으로 처리됨
• 서버 확장(Scale-Out)이 쉬움
• 로드밸런싱에 유리함

문제는 로그인 상태 유지 같은 기능이다.
이런 경우는 쿠키(Cookie), 세션(Session), 토큰(Token) 등의 기술을 활용해
HTTP의 Stateless 특성을 보완하게 된다.

---

비연결성(Connectionless)

HTTP는 요청이 끝나면 TCP 연결을 끊는 구조였다.
매 요청마다 새롭게 TCP 연결을 생성하는 방식이다.

이 방식은 서버 자원을 아낄 수 있는 장점이 있지만,
매번 연결/해제하는 비용이 발생해 비효율적일 수 있다.

이를 해결하기 위해 지속 연결(Persistent Connection)이라는 방식이 도입되었다.
HTTP/1.1에서는 기본적으로 지속 연결을 사용하며,
하나의 TCP 연결로 여러 요청/응답을 처리할 수 있다.

---

HTTP 메시지 구조

HTTP는 텍스트 기반 메시지로 동작하며,
요청 메시지(Request)와 응답 메시지(Response)의 구조가 각각 존재한다.

---

요청 메시지 구조

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
(공백 라인)
(요청 바디 - POST, PUT 등에만 존재)

 

GET /index.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: text/html (공백 라인) (요청 바디 - POST, PUT 등에만 존재)

• 요청 라인: 메서드(GET), 경로, HTTP 버전
• 헤더(Header): 요청에 필요한 부가 정보
• 공백 라인: 헤더 종료를 표시
• 바디(Body): 폼 데이터, JSON 등 전송할 실제 데이터 (필요할 경우)

 

응답 메시지 구조

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 305
(공백 라인)
(HTML 콘텐츠 등 응답 바디)

 

• 상태 라인: HTTP 버전, 상태 코드(200), 상태 메시지(OK)
• 헤더(Header): 응답 관련 정보
• 공백 라인
• 바디(Body): 실제 응답 데이터

---

요약

• HTTP는 클라이언트-서버 구조에서 텍스트 메시지를 주고받는 방식으로 동작한다.
• Stateless 특성 덕분에 서버 확장에 유리하지만, 로그인 상태 유지 등을 위해 별도 기술이 필요하다.
• 지속 연결(Persistent Connection)을 통해 성능을 개선할 수 있다.
• 요청/응답 메시지의 구조를 알면 디버깅이나 API 설계가 훨씬 쉬워진다.

---

이제 HTTP의 전체 흐름과 구조를 이해했으니,
이후에는 REST API 설계나 인증/인가, 쿠키/세션 같은 주제로 확장해서 공부할 수 있을 것 같다.