✅ 웹 브라우저와 서버 간의 통신을 위한 응용 계층 프로토콜
📌 특징
무상태성(Stateless)
각 요청이 독립적이고, 서버는 이전 상태를 기억하지 않는다.
🔹 장점
- 많은 요청을 효율적으로 처리 가능
- 구현 단순
🔹 단점
- 로그인 등 상태 유지가 필요한 경우 별도 구현 필요 ex) 쿠키, 세션, 토큰 등
클라이언트-서버 구조
- 요청자와 응답자가 명확하게 나뉘는 구조
텍스트 기반 프로토콜
사람이 직접 읽고 이해할 수 있는 텍스트 형식으로 구성
🔹 장점
- 디버깅이나 테스트 간편
🔹 단점
- binary 형식보다 비효율적 -> HTTP/2에서는 binary framing 도입
📌 기본 구조: 요청 - 응답
요청
클라이언트가 서버에 리소스를 요청할 때 보내는 메세지
🔹 구성 요소
- 요청 라인:
GET /page.html HTTP/1.1 - 헤더: 요청에 대한 추가 정보
- 본문: 주로 POST/PUT 요청에서 사용
요청 예시
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html응답
서버가 요청을 처리한 후 클라이언트에게 돌려주는 메세지
🔹 구성 요소
- 상태 라인:
HTTP/1.1 200 OK - 헤더: 응답에 대한 정보
- 본문: 요청한 데이터
응답 예시
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<html>
<body>Hello, world!</body>
</html>📌 버전별 비교
HTTP/1.0
🔹 특징
- 요청마다 새로운 TCP 연결 필요 -> 비효율적 (매번 3-way handshake) -> Keep-Alive
- 헤더 전송 시 중복이 많고 압축이 없어 비효율적
🔹 Keep-Alive
HTTP 연결을 끊지 않고 재사용해서 성능을 높이는 기술
- HTTP/1.0에서는 명시적으로 Keep-Alive를 사용할 수 있다.
- HTTP/1.1은 기본 지원
HTTP/1.1
🔹 주요 개선점
-
지속 연결
- 기본적으로 연결 유지(keep-alive 필요 없음)
-
파이프라인 지원
- 요청은 순차 전송, 응답도 순차 도착이 기본 원칙이라 브라우저들이 사용을 꺼림
❌ 한계
- 멀티 요청/응답 병렬 처리 불가능
-> 여전히 Head-of-Line Blocking 발생
HTTP/2
🔹 주요 개선점
- 멀티 플렉싱 -> 하나의 TCP 연결로 동시에 여러 요청과 응답 전송 가능
-
헤더 압축
- 중복 제거 + 압축 -> 대역폭 절약, 속도 향상
-
서버 푸시
- 클라이언트의 요청 없이 서버가 미리 리소스 전송 가능
-
바이너리 프레이밍
- 텍스트가 아닌 바이너리 기반
🔹 Head-of-Line Blocking
앞줄에 있는 하나의 요청이 지연되면, 그 뒤의 요청들까지 기다려야 하는 상황
📌 HTTP & REST
✅ HTTP는 프로토콜(통신 방법)이고, REST는 아키텍처 스타일(설계 원칙)이다.
| 항목 | HTTP | REST |
|---|---|---|
| 개념 | 프로토콜 (통신을 위한 약속) | 아키텍처 스타일 (설계 방식) |
| 목적 | 클라이언트 ↔ 서버 간 데이터 전송 | 웹 리소스를 명확하고 일관되게 설계 |
| 내용 | 요청/응답 포맷, 상태 코드, 메서드 등 | 자원 중심 URI 설계, 메서드에 따라 의미를 부여 |
| 관계 | REST는 HTTP 위에서 주로 사용됨 | HTTP를 기반으로 동작하는 경우가 많음 |
- 따라서 REST는 HTTP 뿐만 아니라 WebSocket, gRPC 등 다른 프로토콜 위에서도 적용 가능
REST(Representational State Transfer)
✅ 자원을 중심으로 설계하는 방식
✅ "자원의 표현(Representation)"을 이용해 상태(State)를 전달(Transfer)
🔹 핵심 설계 원칙
- Client-Server 구조: 클라이언트와 서버를 명확하게 분리해야 한다.
- Stateless: 각 요청은 독립적이며, 서버는 이전 요청의 상태를 저장하지 않는다.
- Cacheable: 응답은 캐시가 가능한지 여부를 명확히 나타내야 한다.
- Uniform Interface: 자원 접근은 표준 HTTP 메서드와 URI 사용을 지켜 일관된 인터페이스를 통해 이뤄져야 한다.
- Layered System: 클라이언트는 REST 서버와 상호작용할 뿐, 중간 서버에 대해서는 모른다.
- Code on Demand: 서버는 클라이언트로 실행 가능한 코드(JavaScript 등)를 전송할 수 있다