HTTP 프로토콜: 프론트엔드와 백엔드의 "통신 언어"
🎯 핵심 질문
HTTP는 어떻게 작동하는가? 이는 마치 "두 사람이 어떻게 대화하는가?"와 같은 질문입니다. 언어, 문법, 대화 규칙을 정해야 합니다. HTTP는 프론트엔드와 백엔드 사이의 "대화 프로토콜"입니다.
0. HTTP의 본질
HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 프로토콜)는 프론트엔드와 백엔드 간 통신의 기반이 되는 프로토콜입니다.
0.1 대화에 비유하기
| 대화 요소 | HTTP 대응 | 설명 |
|---|---|---|
| 언어 | HTTP 프로토콜 | 양측이 모두 이해할 수 있는 언어 |
| 문법 | 요청/응답 형식 | 어떻게 "말할" 것인가 |
| 흐름 | 요청-응답 모델 | 한 번 묻고 한 번 답하기 |
| 종료 | 연결 해제 | TCP 연결 종료 |
1. HTTP의 발전 과정
HTTP는 1991년 탄생 이후 여러 차례의 주요 업그레이드를 거쳤습니다.
HTTP Protocol Demo
HTTP request
GET/api/users/123HTTP/1.1
Host:api.example.com
User-Agent:Mozilla/5.0
Accept:application/json
Authorization:Bearer xxx
TCP connection
HTTP response
HTTP/1.1200OK
Content-Type:application/json
Content-Length:156
Cache-Control:max-age=3600
{
"id": 123,
"name": "Alice",
"email": "alice@example.com"
}
1.1 버전 비교
| 버전 | 연도 | 핵심 개선 사항 | 주요 특징 |
|---|---|---|---|
| HTTP/0.9 | 1991 | GET만 지원 | 순수 텍스트, 요청만 있고 응답 헤더 없음 |
| HTTP/1.0 | 1996 | POST/HEAD 추가 | 요청마다 TCP 연결 하나씩 |
| HTTP/1.1 | 1997 | 지속 연결 | Keep-Alive, 하나의 연결로 여러 요청 |
| HTTP/2 | 2015 | 멀티플렉싱 | 바이너리 프레임, 헤더 압축 |
| HTTP/3 | 2022 | QUIC 기반 | UDP 전송, HOL 블로킹 해결 |
💡 왜 HTTP/2가 필요한가?
HTTP/1.1은 지속 연결을 지원하지만 요청은 반드시 직렬로 전송해야 합니다(이전 요청의 응답이 반환된 후에야 다음 요청 전송 가능). HTTP/2는 멀티플렉싱을 통해 이 문제를 해결하여 여러 요청을 동시에 전송할 수 있습니다.
2. HTTP 요청의 구조
2.1 요청 라인
http
GET /api/users/123 HTTP/1.1세 부분으로 구성됩니다:
- 메서드: GET, POST, PUT, DELETE 등
- URL: 요청한 리소스 경로
- 버전: HTTP/1.1 또는 HTTP/2
2.2 요청 헤더
http
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Authorization: Bearer xxx
Content-Type: application/json
Content-Length: 45주요 요청 헤더:
| 헤더 | 설명 | 예시 |
|---|---|---|
| Host | 서버 도메인 | api.example.com |
| User-Agent | 클라이언트 정보 | Mozilla/5.0 |
| Accept | 허용되는 응답 유형 | application/json |
| Authorization | 인증 정보 | Bearer token |
| Content-Type | 요청 본문 유형 | application/json |
2.3 요청 본문
json
{
"name": "홍길동",
"email": "hong@example.com"
}POST, PUT, PATCH 등의 메서드만 요청 본문을 가집니다.
3. HTTP 응답의 구조
3.1 상태 라인
http
HTTP/1.1 200 OK세 부분으로 구성됩니다:
- 버전: HTTP/1.1
- 상태 코드: 200, 404, 500 등
- 상태 텍스트: OK, Not Found 등
3.2 응답 헤더
http
Content-Type: application/json
Content-Length: 156
Cache-Control: max-age=3600
Set-Cookie: session=xxx; HttpOnly주요 응답 헤더:
| 헤더 | 설명 | 예시 |
|---|---|---|
| Content-Type | 응답 본문 유형 | application/json |
| Content-Length | 응답 본문 크기 | 156 |
| Cache-Control | 캐시 정책 | max-age=3600 |
| Set-Cookie | 쿠키 설정 | session=xxx |
3.3 응답 본문
json
{
"code": 0,
"data": {
"id": 123,
"name": "홍길동"
}
}4. HTTP 메서드 상세
| 메서드 | 용도 | 요청 본문 | 멱등성 | 안전성 |
|---|---|---|---|---|
| GET | 리소스 조회 | 없음 | 있음 | 있음 |
| POST | 리소스 생성 | 있음 | 없음 | 없음 |
| PUT | 전체 업데이트 | 있음 | 있음 | 없음 |
| PATCH | 부분 업데이트 | 있음 | 없음 | 없음 |
| DELETE | 리소스 삭제 | 없음 | 있음 | 없음 |
| HEAD | 헤더 조회 | 없음 | 있음 | 있음 |
| OPTIONS | 지원 메서드 조회 | 없음 | 있음 | 있음 |
4.1 GET vs POST
| 특성 | GET | POST |
|---|---|---|
| 파라미터 위치 | URL 쿼리 파라미터 | 요청 본문 |
| 캐시 | 캐시 가능 | 기본값 캐시 안 함 |
| 북마크 | 북마크 추가 가능 | 불가 |
| 히스토리 | 브라우저 히스토리에 저장 | 저장 안 함 |
| 데이터 길이 | 제한 있음 (URL 길이) | 제한 없음 |
| 보안성 | 파라미터가 URL에 노출 | 파라미터가 요청 본문에 있음 |
💡 GET/POST 사용 시기
- GET: 조회, 데이터 가져오기
- POST: 생성, 데이터 제출
- PUT: 전체 업데이트 (리소스 전체 교체)
- PATCH: 부분 업데이트 (지정 필드만 수정)
- DELETE: 리소스 삭제
5. HTTP 상태 코드
5.1 상태 코드 분류
| 분류 | 설명 | 대표 상태 코드 |
|---|---|---|
| 2xx | 성공 | 200 OK, 201 Created, 204 No Content |
| 3xx | 리다이렉션 | 301 영구, 302 임시, 304 변경 없음 |
| 4xx | 클라이언트 오류 | 400 잘못된 파라미터, 401 미인증, 404 찾을 수 없음 |
| 5xx | 서버 오류 | 500 내부 오류, 503 서비스 불가 |
5.2 자주 사용하는 상태 코드
| 상태 코드 | 설명 | 사용场景 |
|---|---|---|
| 200 OK | 요청 성공 | GET, PUT 요청 성공 |
| 201 Created | 생성 성공 | POST 리소스 생성 성공 |
| 204 No Content | 내용 없음 | DELETE 삭제 성공 |
| 301 Moved Permanently | 영구 리다이렉션 | URL 영구 변경 |
| 302 Found | 임시 리다이렉션 | URL 임시 변경 |
| 304 Not Modified | 변경 없음 | 캐시 유효 |
| 400 Bad Request | 잘못된 파라미터 | 요청 파라미터 형식 오류 |
| 401 Unauthorized | 미인증 | 로그인 필요 |
| 403 Forbidden | 권한 없음 | 로그인했지만 권한 부족 |
| 404 Not Found | 찾을 수 없음 | 리소스 부재 |
| 500 Internal Server Error | 내부 오류 | 서버 예외 |
| 503 Service Unavailable | 서비스 불가 | 서버 유지보수 또는 과부하 |
6. HTTPS: 안전한 HTTP
6.1 HTTP vs HTTPS
| 특성 | HTTP | HTTPS |
|---|---|---|
| 프로토콜 | TCP | TCP + SSL/TLS |
| 포트 | 80 | 443 |
| 데이터 | 평문 전송 | 암호화 전송 |
| 인증서 | 불필요 | SSL 인증서 필요 |
| 성능 | 약간 빠름 | 약간 느림 (핸드셰이크 오버헤드) |
| SEO | 영향 없음 | 검색 엔진 우선 수집 |
6.2 HTTPS의 작동 흐름
- Client Hello: 클라이언트가 지원하는 암호 스위트 전송
- Server Hello: 서버가 인증서와 선택된 암호 스위트 반환
- 인증서 검증: 클라이언트가 서버 인증서의 유효성 확인
- 키 교환: 비대칭 암호화로 세션 키 교환
- 암호화 통신: 세션 키로 대칭 암호화 통신 진행
💡 HTTPS의 장점
- 도청 방지: 데이터 암호화로 제3자가 읽을 수 없음
- 변조 방지: 데이터 무결성 검증
- 위장 방지: SSL 인증서로 서버 신원 확인
7. HTTP 캐시 메커니즘
7.1 캐시 헤더
| 헤더 | 설명 | 예시 |
|---|---|---|
| Cache-Control | 캐시 정책 | max-age=3600 |
| ETag | 리소스 버전 번호 | "33a64df551425fcc" |
| Last-Modified | 마지막 수정 시간 | Wed, 21 Oct 2015 07:28:00 GMT |
7.2 캐시 전략
강한 캐시:
http
Cache-Control: max-age=36003600초 동안 브라우저는 캐시를 직접 사용하며 요청을 보내지 않습니다.
협상 캐시:
http
ETag: "33a64df551425fcc"브라우저가 If-None-Match를 전송하면 서버는 304(변경 없음) 또는 200(변경됨)을 반환합니다.
8. 자주 묻는 질문
8.1 GET과 POST의 본질적 차이
오해: GET과 POST의 차이는 단지 파라미터 위치뿐이다.
진실:
- GET은 멱등적이며, 여러 번 요청해도 결과가 같음
- POST는 비멱등적이며, 여러 번 요청 시 여러 리소스가 생성될 수 있음
- GET은 캐시 가능, POST는 기본적으로 캐시되지 않음
- GET은 북마크 저장 가능, POST는 불가
8.2 HTTP/1.1의 HOL 블로킹
문제: HTTP/1.1은 지속 연결을 지원하지만 요청은 반드시 직렬로 전송해야 합니다. 이전 요청의 응답이 느리면 이후 요청이 모두 대기해야 합니다.
해결책:
- HTTP/2 멀티플렉싱
- 도메인 샤딩 (여러 도메인으로 여러 연결 수립)
- 연결 풀 (동시성 제한)
8.3 HTTP/2의 장점
| 특성 | HTTP/1.1 | HTTP/2 |
|---|---|---|
| 전송 형식 | 텍스트 | 바이너리 프레임 |
| 멀티플렉싱 | 미지원 | 지원 |
| 헤더 압축 | 없음 | HPACK 알고리즘 |
| 서버 푸시 | 미지원 | 지원 |
용어 빠른 참조
| 용어 | 영어 | 설명 |
|---|---|---|
| HTTP | HyperText Transfer Protocol | 하이퍼텍스트 전송 프로토콜 |
| HTTPS | HTTP Secure | HTTP + SSL/TLS |
| TCP | Transmission Control Protocol | 전송 제어 프로토콜 |
| SSL/TLS | Secure Sockets Layer | 보안 소켓 계층 |
| 멱등성 | Idempotent | 여러 번 요청해도 결과 동일 |
| 지속 연결 | Keep-Alive | 하나의 TCP 연결로 여러 요청 전송 |
| 멀티플렉싱 | Multiplexing | 여러 요청 동시 전송 |
| HOL 블로킹 | Head-of-Line Blocking | 앞선 요청이 뒤 요청을 차단 |