개요
HTTP는 클라이언트와 서버 간에 이루어지는 요청/응답(request/response) 프로토콜이다. TEXT, IMAGE, FILE, HTML, JSON 등 다양한 형태의 데이터가 HTTP를 통해 전송된다.
HTTP에는 여러 버전이 존재하며, 현재 가장 널리 사용되는 버전은 HTTP/1.1(TCP) 이다. 최근에는 HTTP/2와 HTTP/3(UDP) 의 사용량이 증가하고 있다. 이 글에서는 HTTP의 가장 중요한 버전인 1.1을 중심으로 정리해 보려고 한다.
HTTP의 특징
1. 클라이언트-서버 구조
초기에는 클라이언트와 서버의 구분이 명확하지 않았다. 그러나 HTTP를 사용하면서 클라이언트와 서버가 명확히 분리되었고, 클라이언트는 UI와 사용자 경험(UX) 에 집중하고, 서버는 데이터 처리 및 비즈니스 로직 을 담당하도록 발전하였다. 이를 통해 클라이언트와 서버가 각각 독립적으로 개선될 수 있는 구조가 되었다.
2. 무상태(Stateless)
서버는 클라이언트의 상태를 유지하지 않는 특징이 있다.
장점
- 수평 확장(Scale Out) 이 용이하다.
- 요청량이 갑자기 증가하더라도 서버를 쉽게 증설할 수 있다.
단점
- 클라이언트가 매 요청마다 필요한 데이터를 추가로 전송해야 한다.
한계점
- 모든 시스템이 무상태로 설계될 수는 없다.
- 로그인과 같이 상태 유지를 필요로 하는 경우에는 쿠키, 세션, 토큰 등을 활용해야 한다.
3. 비연결 (Connectionless)
HTTP는 기본적으로 연결을 유지하지 않는 모델이다. 즉, 클라이언트와 서버는 요청을 보낸 후 연결을 끊는다.
장점
- 서버 자원을 효율적으로 사용할 수 있다. 각 요청마다 새로운 연결을 만들지 않으므로 서버 자원이 낭비되지 않는다.
단점
- 요청이 새로 발생할 때마다 새로운 TCP 연결을 설정해야 하므로 연결 과정(3-way handshake)으로 인해 응답 시간이 증가할 수 있다.
- 웹 사이트의 정적 자원(HTML, CSS, JS, 이미지 등)을 다시 다운로드해야 할 수도 있다.
- 이를 해결하기 위해 캐시(Caching) 및 브라우저 캐싱 기법이 활용된다.
4. HTTP 지속 연결(Persistent Connections)
기본적인 HTTP는 단기 연결 방식이지만, HTTP/1.1부터는 지속 연결(Persistent Connection) 을 지원하여 단점을 보완하였다.
- 하나의 연결을 유지하면서 여러 요청과 응답을 주고받을 수 있다.
- 연결을 한 번만 맺고 유지하므로 성능이 향상된다.
- HTTP/1.1에서는 기본적으로
Connection: keep-alive가 활성화 되어 있다.- 명시적으로
Connection: close를 설정하지 않는 한 동일한 TCP 연결이 유지된다.
- 명시적으로
- 예시:
HTML요청 →CSS요청 →JS요청 →IMAGE요청을 하나의 연결에서 처리.
HTTP 메시지 구조
HTTP 메시지는 Start Line(시작 줄), Message Header(메시지 헤더), Message Body(메시지 본문) 의 세 부분으로 구성된다. 이 구조는 클라이언트의 요청과 서버의 응답에 동일하게 적용된다.
| 구성 요소 | 설명 | 예시 |
|---|---|---|
| Start Line (시작 줄) | 요청 메서드 및 URL 또는 상태 코드 포함 | GET /index.html HTTP/1.1 HTTP/1.1 200 OK |
| Message Header (메시지 헤더) | 요청/응답에 대한 추가 정보 제공 | Content-Type: text/html User-Agent: Mozilla/5.0 |
| Message Body (메시지 본문) | 요청 또는 응답 데이터를 포함 | { "name": "John" } |
HTTP 메서드(Method)
HTTP는 클라이언트가 서버에 요청을 보낼 때 사용하는 다양한 메서드를 제공한다.
주요 메서드
| 메서드 | 설명 |
|---|---|
| GET | 리소스 조회 |
| POST | 리소스 생성 |
| PUT | 리소스 전체 수정 |
| PATCH | 리소스 일부 수정 |
| DELETE | 리소스 삭제 |
기타 메서드
| 메서드 | 설명 |
|---|---|
| HEAD | GET과 동일하지만 응답 본문 제외 |
| OPTIONS | 서버가 지원하는 메서드 조회 |
| CONNECT | 프록시 터널링 요청 |
| TRACE | 요청이 서버를 통해 어떻게 전달되는지 추적 |
HTTP 메서드의 속성
1. 안전성 (Safety)
- GET, HEAD는 서버의 상태를 변경하지 않으므로 안전한 메서드이다.
2. 멱등성 (Idempotency)
- 여러 번 실행해도 같은 결과를 보장하는지 여부.
- GET, PUT, DELETE는 동일한 요청을 여러 번 전송해도 같은 결과를 보장하지만, POST는 서버의 상태를 변경할 수 있어 멱등하지 않다.
3. 캐시 가능성 (Cacheability)
- GET, HEAD는 캐싱이 가능하지만, POST는 기본적으로 캐싱되지 않는다.
HTTP 상태 코드(Status Code)
HTTP 응답은 상태 코드(Status Code) 를 포함하여 클라이언트에게 요청 처리 결과를 전달한다.
| 상태 코드 | 설명 |
|---|---|
| 1xx | 정보 응답 (Informational) |
| 2xx | 성공 (Success) |
| 3xx | 리다이렉션 (Redirection) |
| 4xx | 클라이언트 오류 (Client Error) |
| 5xx | 서버 오류 (Server Error) |
주요 상태 코드 예시
- 200 OK: 요청이 성공적으로 처리됨.
- 301 Moved Permanently: 리소스가 영구적으로 이동됨.
- 400 Bad Request: 잘못된 요청.
- 401 Unauthorized: 인증이 필요함.
- 403 Forbidden: 접근 권한 없음.
- 404 Not Found: 요청한 리소스를 찾을 수 없음.
- 500 Internal Server Error: 서버 내부 오류.
(💡+자주 보이는 코드 보충 설명)
400 Bad Request:
클라이언트가 보낸 요청이 잘못되었거나 서버에서 이해할 수 없는 상태를 나타낸다.
예를 들어, 요청 형식이 잘못되었거나 필수 파라미터가 누락된 경우 발생한다.
클라이언트는 요청을 수정하여 다시 보내야 한다.
404 Not Found:
클라이언트가 요청한 리소스를 서버에서 찾을 수 없는 상태를 나타낸다.
예를 들어, URL이 잘못되었거나 리소스가 삭제된 경우 발생한다.
클라이언트는 올바른 경로를 확인해야 한다.
500 Internal Server Error:
서버 내부의 오류로 인해 요청을 처리할 수 없는 상태를 나타낸다.
예를 들어, 서버의 설정 오류나 예기치 못한 서버 상태로 인해 응답을 처리할 수 없을 때 발생한다.
이는 서버 개발자나 시스템 관리자에게 문제가 있음을 알려주는 중요한 상태 코드다.
마무리
HTTP는 웹 통신의 핵심 프로토콜로, 요청/응답 구조를 기반으로 동작하며 다양한 특징과 메서드를 갖고 있다. HTTP/1.1에서 등장한 지속 연결을 통해 성능이 개선되었으며, HTTP/2와 HTTP/3에서는 더 나은 최적화가 이루어지고 있다. HTTP의 특징과 구조를 이해하면 웹 개발 및 네트워크 설계에 큰 도움이 될 뿐만 아니라, RESTful API 설계에도 필수적인 개념으로 활용된다.
