[CS] HTTP 완전 정복 - 구조, 동작 원리, 특징, 버전 차이까지
HTTP(HyperText Transfer Protocol)은 웹에서 클라이언트와 서버가 데이터를 주고받기 위해 사용하는 통신 규약이다. 웹 브라우저가 어떤 웹 페이지를 요청하거나, 서버가 그에 대한 응답을 보낼 때 HTTP를 사용한다. 핵심적인 개념을 아래와 같이 구조적으로 정리할 수 있다.
1. HTTP의 기본 구조
- 클라이언트(예: 웹 브라우저)가 요청(Request)을 보내고
- 서버(예: 웹 서버)가 응답(Response)을 반환한다.
HTTP는 텍스트 기반의 프로토콜로, 사람이 읽을 수 있는 형식으로 통신한다.
2. HTTP 요청의 구성
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
요청은 크게 세 부분으로 나뉜다.
- 요청 라인: 어떤 동작을 할 것인지 명시 (
GET /index.html HTTP/1.1) - 헤더(Header): 추가 정보들 (예: 브라우저 정보, 인코딩 등)
- 본문(Body): POST, PUT 등에서 데이터를 보낼 때 사용
3. HTTP 응답의 구성
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<html> ... </html>
응답도 크게 세 부분으로 나뉜다.
- 상태 라인: 응답 코드와 메시지 (
200 OK) - 헤더(Header): 서버 정보, 컨텐츠 타입 등
- 본문(Body): 요청에 대한 실제 데이터 (HTML, JSON 등)
4. HTTP 메서드
| 메서드 | 의미 |
|---|---|
| GET | 리소스 조회 |
| POST | 리소스 생성 |
| PUT | 리소스 전체 수정 |
| PATCH | 리소스 일부 수정 |
| DELETE | 리소스 삭제 |
| HEAD | 헤더만 요청 (본문 없음) |
| OPTIONS | 지원하는 메서드 확인 |
5. HTTP 상태 코드
| 코드 | 의미 |
|---|---|
| 200 | OK – 정상 응답 |
| 201 | Created – 생성됨 |
| 204 | No Content – 응답 본문 없음 |
| 301 | Moved Permanently – 영구 이동 |
| 302 | Found – 임시 이동 |
| 400 | Bad Request – 잘못된 요청 |
| 401 | Unauthorized – 인증 필요 |
| 403 | Forbidden – 접근 금지 |
| 404 | Not Found – 존재하지 않음 |
| 500 | Internal Server Error – 서버 오류 |
6. HTTP의 특징
🔹 무상태성(Stateless) - 서버는 요청의 과거를 기억하지 않는다
HTTP는 기본적으로 상태를 유지하지 않는다. 서버는 이전 요청이나 응답에 대한 정보를 기억하지 않으며, 매 요청은 독립적으로 처리된다.
이 구조는 서버 확장에 매우 유리하며, 요청 간의 간섭 없이 처리할 수 있다는 점에서 분산 시스템에 적합하다. 그러나 로그인 상태 유지와 같은 기능을 구현하기 위해서는 세션, 쿠키, 또는 JWT 같은 별도의 상태 관리 기술이 필요하다.
🔹 유연한 데이터 처리 - 포맷에 제약이 없다
HTTP는 데이터 형식에 제한이 없다. HTML, JSON, XML, 이미지, 영상 등 어떤 데이터든 전송할 수 있으며, 클라이언트는 Accept 헤더를 통해 원하는 포맷을 지정할 수 있다.
서버는 이 요청을 바탕으로 적절한 Content-Type을 설정하여 응답을 반환한다. 이 유연성 덕분에 다양한 서비스 시나리오에서 HTTP를 그대로 활용할 수 있다.
🔹 확장성(Extensibility) - 구조를 유지한 채 기능 확장이 가능하다.
HTTP는 설계 자체가 확장을 염두에 두고 있다. 새로운 기능이 필요할 경우, 프로토콜을 변경하지 않고도 헤더를 추가하여 구현할 수 있다.
대표적인 예로 Authorization 헤더를 활용한 인증, X-Request-ID를 이용한 트래픽 추적 등이 있다. 이처럼 헤더를 통해 인증, 로깅, 로드 밸런싱, 캐싱 등 다양한 부가 기능을 유연하게 구성할 수 있다.
🔹 클라이언트-서버 구조 - 역할 분리가 명확하다
HTTP는 요청을 보내는 클라이언트와 응답을 처리하는 서버로 역할이 명확히 분리되어 있다. 이 구조 덕분에 프론트엔드와 백엔드의 완전한 분리 개발이 가능하다.
예를 들어 React 기반의 웹 프론트엔드가 Spring Boot API 서버와 통신하는 구조가 대표적이다. 이러한 아키텍처는 팀 간 협업과 유지보수 측면에서도 큰 장점을 제공한다.
🔹 요청/응답 기반 - 항상 클라이언트가 먼저 요청한다
HTTP는 요청이 있어야 응답이 가능한 구조다. 서버는 클라이언트로부터 요청이 들어오기 전까지는 아무런 동작도 하지 않는다.
이러한 구조는 단순하지만, 실시간성이 요구되는 환경(예: 채팅, 알림, 게임 등)에서는 제한이 발생한다. 이러한 경우에는 WebSocket, Server-Sent Events(SSE), 또는 Long Polling 같은 보완 기술이 함께 사용된다.
7. HTTP 버전
📍 HTTP/1.0 – 연결을 매 요청마다 새로 열고 닫는다
HTTP/1.0은 1996년에 RFC 1945로 제정된 초기 버전으로, 기본적으로 요청 하나당 TCP 연결을 새로 열고, 작업이 끝나면 곧바로 연결을 끊는다.
- 문제점: 하나의 웹 페이지에 여러 리소스(HTML, CSS, JS, 이미지 등)를 로드하려면 매번 새로 연결을 맺어야 하므로 지연 시간(latency)과 부하가 매우 크다.
- 헤더에 Host 필드가 없음: IP 기반 가상 호스팅이 불가능했다. 하나의 IP에 도메인 하나만 할당 가능했다.
📍 HTTP/1.1 – 연결 재사용(Keep-Alive), Host 헤더 도입
1997년에 발표된 HTTP/1.1은 현재까지도 광범위하게 사용되는 표준이다. 1.0의 구조적 한계를 보완하며 실용성을 높인 것이 특징이다.
- Persistent Connection(연결 재사용):
Connection: keep-alive를 통해 하나의 연결로 여러 요청을 처리할 수 있게 되어, 브라우저 성능이 크게 향상되었다. - Host 헤더 도입: 하나의 IP 주소에 여러 도메인 호스팅이 가능해졌다. 이는 가상 호스팅의 기반이 되었다.
- 파이프라이닝 지원: 여러 요청을 순차적으로 보내고 응답을 기다리는 구조이나, 순서가 보장되어야 해서 병목 가능성이 존재한다.
📍 HTTP/2.0 – 멀티플렉싱과 성능 최적화
2015년에 발표된 HTTP/2.0은 웹의 복잡성과 트래픽 증가에 대응하기 위해 나온 성능 개선 중심의 업데이트다. 프로토콜 자체는 여전히 텍스트 기반이 아닌 바이너리 형식으로 변경됐다.
- 멀티플렉싱(Multiplexing): 하나의 TCP 연결 안에서 여러 요청과 응답을 동시에 처리 가능하다. 순서와 독립성이 확보되었다.
- 헤더 압축: 반복되는 HTTP 헤더를 압축(Huffman Coding + HPACK)하여, 데이터 전송량이 감소되었다.
- 서버 푸시(Server Push): 클라이언트 요청이 없어도 서버가 예상되는 리소스를 선제적으로 전송하는 것이 가능해졌다. 리소스 로딩 속도가 향상되었다.
8. 보안 프로토콜: HTTPS
-> SSL/TLS란?
9. 실제 흐름 예시
📌 HTTP 요청 흐름 (http://example.com)
- 사용자가 브라우저에
http://example.com입력 - 브라우저가 DNS를 통해 도메인의 IP 주소를 확인
- 브라우저가 서버에 바로 HTTP 요청 전송 (예:
GET / HTTP/1.1) - 서버가 암호화 없이 평문(plain text) HTTP 응답 반환
- 브라우저가 응답 수신 -> HTML 파싱 및 화면 렌더링
특징: 암호화 없음, 요청/응답 내용이 그대로 네트워크에 노출됨
📌 HTTPS 요청 흐름 (https://example.com)
- 사용자가 브라우저에
https://example.com입력 - 브라우저가 DNS를 통해 도메인의 IP 주소를 확인
- 브라우저가 서버에 접속 -> 서버가 SSL 인증서 제공
- TLS 핸드셰이크를 통해 암호화 설정 및 공개키 교환 진행
- TLS 암호화된 상태에서 HTTP 요청 전송 (예:
GET /) - 서버가 암호화된 HTTP 응답 반환
- 브라우저가 응답 복호화 -> HTML 파싱 및 화면 렌더링
특징: 데이터 암호화, 무결성 검증, 인증서 기반 신뢰성 확보
댓글남기기