2-2 HTTP와 HTTPS · JUNSEOK CS study

웹의 기본 프로토콜. 요청/응답 구조, 상태 코드, 헤더, 버전별 차이, TLS까지. "상태 코드 410은 뭐예요?", "HTTP/2와 HTTP/3은 뭐가 달라요?" 같은 질문에 즉답할 수 있어야 한다.

1. 프로토콜이란 무엇인가

1-1. 정의

**"두 당사자가 데이터를 주고받기로 약속한 공통 규칙"**이 프로토콜이다.

일상 비유: 전화를 걸 때 "여보세요" → "네, 안녕하세요" → 용건 말하기 → 끊을 때 "네, 그럼 끊을게요". 이 순서가 정해져 있지 않으면 대화가 꼬인다. 컴퓨터끼리도 마찬가지로 정해진 메시지 형식과 순서가 필요하다. 이게 프로토콜이다.

1-2. HTTP는 어디에 있는 프로토콜인가

HTTP는 응용(Application) 계층의 프로토콜이다. 아래는 TCP가 받쳐주고, 그 아래는 IP가 받쳐준다.

HTTP           ← 앱이 보는 데이터 형식 (우리가 다루는 레이어)
TLS            ← HTTPS일 때 보안 계층
TCP            ← 순서·재전송 보장
IP             ← 라우팅
Ethernet/Wi-Fi ← 물리 전송

TCP가 "데이터가 반드시 도착하게 해 주는 파이프"라면, HTTP는 그 파이프 위에서 "데이터를 이런 형식으로 주고받자는 약속이다.

1-3. HTTP의 핵심 특성

요청/응답 모델: 클라이언트가 요청하고 서버가 응답하는 구조. 서버가 먼저 말을 걸지 않는다.
텍스트 기반 (HTTP/1.1까지. HTTP/2부터는 바이너리): 헤더는 사람이 읽을 수 있는 텍스트
무상태(Stateless): 각 요청은 독립적. 서버는 이전 요청을 기억할 의무가 없다

2. 요청/응답 모델 자세히 보기

2-1. 식당 비유

HTTP는 식당의 주문 같다.

손님 (클라이언트)                 주방 (서버)
  │──── "김치찌개 주세요" ────→│   (요청)
  │                            │
  │←── "여기 김치찌개요" ──────│   (응답)

손님이 먼저 말해야 주방이 움직인다 (서버가 먼저 보내지 않음)
주문과 음식은 1:1로 짝짓혀 있다 (요청 한 번 = 응답 한 번)
주방은 이전 손님이 뭘 주문했는지 기억하지 않는다 (무상태)

2-2. 왜 무상태로 설계했나

무상태(Stateless)의 이점:

수평 확장: 서버를 여러 대로 늘려도 아무 서버나 요청을 받을 수 있다. 세션을 공유할 필요 없음.
장애 복구: 서버가 죽어도 잃을 상태가 없다. 다른 서버로 요청을 다시 보내면 됨.
단순성: 서버 구현이 간단하다.

단점도 있다: 로그인 같은 "상태"가 필요하면 쿠키, 토큰 등으로 매번 정체를 증명해야 한다. 그래서 4-4 챕터(인증과 인가)가 따로 있다.

3. HTTP 메시지 구조

HTTP 요청과 응답은 사람이 읽을 수 있는 텍스트다. 구조는 간단하다: 첫 줄 + 헤더들 + 빈 줄 + (선택적) 본문.

3-1. 요청 메시지

GET /users/1 HTTP/1.1                      ← Request Line
Host: api.example.com                      ← Headers
Authorization: Bearer eyJhbGci...
Content-Type: application/json
Accept: application/json
                                           ← 빈 줄 (body와 구분)
{"filter": "active"}                       ← Body (선택)

Request Line = 메서드 경로 버전

메서드: GET, POST, PUT, ...
경로: /users/1 같은 리소스 경로
버전: HTTP/1.1, HTTP/2, HTTP/3

Headers: 키-값 쌍. 메타정보(인증, 타입, 캐시 정책 등) Body: 실제 데이터. POST/PUT 등에 있고, GET에는 보통 없다

3-2. 응답 메시지

HTTP/1.1 200 OK                            ← Status Line
Content-Type: application/json             ← Headers
Cache-Control: max-age=60
Content-Length: 42

{"id": 1, "name": "Alice"}                 ← Body

Status Line = 버전 상태코드 상태메시지

3-3. 개발자 도구로 직접 확인

브라우저 DevTools의 Network 탭에서 요청 하나를 클릭하면 실제 HTTP 메시지가 그대로 보인다. 한 번 눌러보는 게 책 한 장을 읽는 것보다 이해가 빠르다.

4. HTTP 메서드

4-1. 주요 메서드와 특성

메서드	용도	안전성	멱등성
`GET`	조회	O	O
`HEAD`	헤더만 조회	O	O
`OPTIONS`	허용 메서드 조회 (CORS preflight)	O	O
`POST`	생성, 액션	X	X
`PUT`	전체 교체	X	O
`PATCH`	부분 수정	X	X (설계에 따라)
`DELETE`	삭제	X	O

4-2. 안전성 (Safety)

서버 상태를 변경하지 않음. 다시 말해 "서버에 아무 영향 없는 조회만 하는" 메서드.

⚠️ GET으로 카운터를 증가시키거나 결제 처리를 하면 안 된다. 이유:

브라우저 프리페치 / 프리로드: 사용자가 클릭하기도 전에 미리 요청할 수 있다
크롤러: 링크를 GET으로 무작위 순회
캐시 프록시: 중간 서버가 응답을 저장해서 다음 사용자에게 내줄 수 있다
브라우저 재시도: 네트워크 오류 시 자동 재시도 가능

실제 사례: 옛날에 관리자 페이지를 GET /user/delete?id=5로 만들었다가, 구글 크롤러가 "재미있어 보이는 링크들"을 타면서 모든 사용자를 삭제해버린 사건이 있었다.

4-3. 멱등성 (Idempotency)

같은 요청을 여러 번 보내도 최종 결과가 같음.

PUT /users/1 {name:"A"} → 몇 번 보내도 최종 상태는 동일 (멱등)
POST /users {name:"A"} → 매번 새 사용자 생성, 멱등 아님
DELETE /users/1 → 첫 번째는 삭제, 두 번째는 이미 없음 → 결과적으로 "그 리소스가 없다"는 상태 동일 (멱등)

왜 중요한가: 네트워크 문제로 요청이 실패했을 때 재시도 가능 여부의 판단 기준이 된다. 멱등이면 그냥 다시 보내도 안전하다.

4-4. ⚠️ 함정: PATCH는 멱등일 수도 아닐 수도

멱등: PATCH /user/1 {age: 30} — 몇 번 보내도 age는 30
비멱등: PATCH /user/1 {$inc: {age: 1}} — 호출할 때마다 age가 1씩 증가

설계에 따라 다르다. API를 설계할 때 PATCH를 어떻게 해석할지 문서화해야 한다.

4-5. ⚠️ 함정: GET은 body가 있을 수 있지만 쓰지 않는다

HTTP 명세상 GET 요청에도 body를 실을 수 있지만, 대부분의 프록시/캐시/서버가 이를 무시하거나 거부한다. 조회에 복잡한 조건이 필요하면 쿼리 파라미터로 보내거나, 드물지만 POST로 대체한다 (Elasticsearch 등).

5. 상태 코드

5-1. 카테고리 (첫 자리 숫자가 대분류)

코드	의미
1xx	정보 (거의 안 씀)
2xx	성공
3xx	리다이렉트
4xx	클라이언트 오류
5xx	서버 오류

5-2. 2xx (성공)

200 OK: 정상. 가장 흔함.
201 Created: 생성됨. 응답 Location 헤더로 새 리소스 URL을 가리키는 게 관례.
204 No Content: 성공했지만 본문이 없음. DELETE 성공 시 자주 씀.

5-3. 3xx (리다이렉트)

301 Moved Permanently: 영구 이동. 브라우저와 검색엔진이 북마크와 인덱스를 갱신.
302 Found / 303 See Other / 307 Temporary Redirect: 임시 이동.
304 Not Modified: 조건부 요청 성공, 캐시된 버전이 아직 유효함. (자세한 내용은 2-9 캐싱 챕터)

5-4. 4xx (클라이언트 오류)

400 Bad Request: 요청 형식 오류 (JSON 파싱 실패 등)
401 Unauthorized: 인증 안 됨 — 이름과 달리 "인가"가 아님. "당신이 누구인지 모르겠다"
403 Forbidden: 인증은 됐는데 권한 없음. "당신인 건 알겠는데 이건 허락 안 됨"
404 Not Found: 리소스 없음
409 Conflict: 현재 상태와 충돌 (버전 불일치, 중복 등록 등)
410 Gone: 영구 삭제됨. 404와 달리 "다시는 없을 것"을 명시
422 Unprocessable Entity: 형식은 맞는데 내용이 잘못됨 (validation 실패)
429 Too Many Requests: 속도 제한 (Rate Limit). Retry-After 헤더로 대기 시간 알려주는 게 관례

5-5. 5xx (서버 오류)

500 Internal Server Error: 서버 일반 오류. 예외가 안 잡혔을 때 기본값
502 Bad Gateway: 게이트웨이/프록시가 업스트림으로부터 나쁜 응답 받음
503 Service Unavailable: 일시 불가 (점검, 과부하)
504 Gateway Timeout: 업스트림 응답 없음 (타임아웃)

5-6. ⚠️ 함정: 401 vs 403

가장 자주 헷갈리는 부분.

401: "누구인지 모르겠어" → 로그인해라
403: "누구인지는 알겠는데 권한이 없어" → 로그인해도 안 됨

FE에서의 분기 처리:

401 수신 → 로그인 페이지로 리다이렉트 (또는 토큰 갱신 시도)
403 수신 → "권한 없음" 페이지 또는 이전 페이지로 돌리기

5-7. ⚠️ 함정: 2xx인데 실패한 경우

서버가 실수로 **오류 상황에서도 200 OK**를 반환하고 body에 {success: false, error: "..."}만 넣는 경우가 있다. 이러면:

브라우저 캐시가 오류 응답을 "성공"으로 간주해 저장할 수 있음
중간 프록시도 "성공"으로 취급
모니터링 도구가 오류를 놓침

원칙: HTTP 상태 코드는 HTTP 레벨의 약속이다. 오류는 적절한 4xx/5xx로 반환해야 한다.

6. 주요 헤더

헤더는 메타정보를 담는 키-값 쌍이다. 용도별로 나눠 기억하면 편하다.

6-1. 요청 헤더

헤더	용도
`Host`	가상 호스팅용 목적지 (HTTP/1.1 필수)
`Authorization`	인증 정보 (`Bearer <token>`, `Basic <base64>`)
`Content-Type`	body 타입 (`application/json`, `multipart/form-data`)
`Accept`	받고 싶은 타입 (`application/json`)
`Accept-Language`	원하는 언어 (`ko-KR,en;q=0.9`)
`Accept-Encoding`	수락하는 압축 (`gzip, br`)
`Cookie`	쿠키 전송
`Origin`	요청 출처 (CORS 판단용)
`Referer`	이 요청을 발생시킨 페이지 URL (오타 historically)
`User-Agent`	클라이언트 식별
`If-None-Match` / `If-Modified-Since`	조건부 요청 (캐시 유효성)

6-2. 응답 헤더

헤더	용도
`Content-Type`	body 타입
`Content-Length`	body 바이트 수
`Content-Encoding`	압축 알고리즘 (`gzip`, `br`)
`Set-Cookie`	쿠키 설정
`Cache-Control`	캐시 정책 (2-9 챕터)
`ETag`, `Last-Modified`	조건부 요청용
`Access-Control-*`	CORS (2-8 챕터)
`Location`	3xx 리다이렉트 대상
`Strict-Transport-Security`	HSTS (강제 HTTPS)

6-3. Content-Type 실전 예시

타입	용도
`application/json`	REST API의 대부분
`application/x-www-form-urlencoded`	전통 HTML form
`multipart/form-data`	파일 업로드
`text/html`	HTML 문서
`text/css`	CSS
`application/javascript`	JS
`application/octet-stream`	바이너리 (다운로드 유도)
`image/png`, `image/webp`	이미지

⚠️ 브라우저가 Content-Type을 잘못 받아들이면 JS 파일이 텍스트로 렌더링되거나 이미지가 깨져 보일 수 있다. 서버 설정에서 올바른 MIME 타입을 보장해야 한다.

6-4. 헤더는 대소문자 구분 없다

HTTP/1.1까지는 대소문자 무시. Content-Type, content-type, CONTENT-TYPE 모두 같음. HTTP/2부터는 소문자가 강제된다.

7. HTTP 버전별 차이

7-1. HTTP/1.0 (역사)

1996년. 한 요청에 한 연결. 모든 리소스마다 TCP 핸드셰이크를 새로 해야 했다. 매우 느렸다.

7-2. HTTP/1.1

1997년. 현재도 가장 널리 쓰인다.

Keep-Alive (Connection: keep-alive): 하나의 TCP 연결로 여러 요청 처리. 매번 핸드셰이크 안 해도 됨.
Pipelining: 여러 요청을 동시에 보낼 수 있음 — but, HOL Blocking 문제로 거의 비활성화.
Host 헤더 필수: 한 IP에 여러 도메인 호스팅 가능

HOL Blocking (Head-of-Line Blocking)

"앞 사람이 막히면 뒤 사람도 전부 대기"라는 의미.

파이프라이닝에서 요청 1이 느리면 요청 2, 3, 4도 전부 기다린다. 이게 HTTP/1.1 성능의 근본 한계.

브라우저는 이걸 우회하려고 한 도메인당 TCP 연결 6개 정도를 동시에 열어 병렬 처리한다 (도메인 샤딩 기법).

7-3. HTTP/2

2015년. 바이너리 프로토콜. 획기적 성능 개선.

멀티플렉싱 (Multiplexing): 하나의 TCP 연결에서 여러 요청을 병렬로 섞어 전송. 애플리케이션 레이어의 HOL Blocking 해결.
헤더 압축 (HPACK): 중복 헤더를 압축
서버 푸시 (Server Push): 클라이언트 요청 없이 리소스 전송 — 대부분 브라우저가 비활성화
바이너리 포맷: 파싱이 빠르고 모호성 없음
스트림 우선순위: 중요한 리소스를 먼저 보낼 수 있음

⚠️ TCP 레벨 HOL Blocking은 남아 있다 — TCP 패킷 하나가 손실되면 뒤의 모든 HTTP/2 스트림이 대기.

7-4. HTTP/3

2022년 RFC. UDP 위 QUIC 기반.

TCP 레벨 HOL 해결: UDP라 패킷 손실이 다른 스트림에 영향 없음
연결 수립이 빠름: TLS와 TCP 핸드셰이크를 합쳐 0-RTT ~ 1-RTT
연결 마이그레이션: Wi-Fi → LTE 전환 시에도 연결 유지 (QUIC Connection ID)

7-5. 버전 비교표

	HTTP/1.1	HTTP/2	HTTP/3
전송	TCP	TCP	UDP (QUIC)
멀티플렉싱	X	O	O
HOL (앱)	O	X	X
HOL (전송)	-	O	X
헤더 압축	X	HPACK	QPACK
포맷	텍스트	바이너리	바이너리
연결 마이그레이션	X	X	O

7-6. FE 관점에서 뭐가 달라지는가

도메인 샤딩이 역효과: HTTP/2부터는 연결 하나에서 멀티플렉싱이 되니, 도메인을 쪼개면 오히려 핸드셰이크 비용만 늘어남
리소스 번들링 전략 변화: HTTP/1.1 시대엔 "요청 수 줄이기"가 최우선이라 하나로 번들링했지만, HTTP/2부턴 작은 파일 여러 개도 부담이 적어짐
Server Push 기대는 접어라: 표준에서 사실상 퇴출. <link rel="preload"> 같은 힌트로 대체

8. HTTPS와 TLS

8-1. HTTPS = HTTP over TLS

HTTP는 평문. 누군가 중간에서 읽거나 변조할 수 있다. **TLS (Transport Layer Security)**는 HTTP를 암호화·인증해서 감싼다.

기밀성(Confidentiality): 도청 방지. 중간자가 내용을 못 읽음
무결성(Integrity): 변조 감지. 중간에 바뀌면 수신 측이 알아챔
인증(Authentication): 서버가 정말 그 도메인의 주인임을 인증서로 증명

TLS는 SSL의 후속. SSL은 1990년대 네트스케이프가 만들었고, 보안 결함으로 TLS 1.0 (1999)으로 대체됐다. 지금도 관습적으로 "SSL 인증서"라 부르지만 실제론 모두 TLS다.

8-2. TLS 1.3 핸드셰이크

클라이언트                          서버
   │─── ClientHello ─────────→│   (지원 암호 스위트, keyshare)
   │                          │
   │←── ServerHello ──────────│   (선택한 암호, keyshare, 인증서, Finished)
   │                          │
   │─── Finished ────────────→│
   │═══ 암호화된 데이터 ══════│

1-RTT로 완료. TLS 1.2는 2-RTT였다. TLS 1.3은 이미 ClientHello에 keyshare를 실어 보내서, 한 번 왕복만으로 암호화 준비가 끝난다.

8-3. 0-RTT (재연결)

이전 연결에서 공유한 키로 첫 패킷부터 암호화된 데이터 전송. 빠르지만 **재전송 공격(replay)**에 취약 → 멱등 요청(GET 등)에만 허용.

8-4. 인증서 체인

Root CA (브라우저에 내장)
  ↓ 서명
Intermediate CA
  ↓ 서명
서버 인증서 (example.com)

브라우저는 서버 인증서를 받으면 체인을 역으로 거슬러 올라가 Root CA까지 검증한다. Root CA가 브라우저/OS에 신뢰 목록으로 내장돼 있다.

만약 누군가 가짜 인증서를 만들어도, Root CA가 서명하지 않았으므로 브라우저가 "이 사이트는 안전하지 않습니다" 경고를 띄운다.

비대칭 키와 대칭 키

TLS는 두 가지를 혼합해 쓴다.

비대칭 키 (공개키/개인키): 느리지만 키 교환과 인증에 사용. 공개키로 암호화한 걸 개인키 가진 쪽만 복호화 가능.
대칭 키: 빠르지만 키를 공유해야 함. 한 번 공유한 뒤 실제 데이터 암호화에 사용.

흐름: 핸드셰이크에서 비대칭 키로 안전하게 대칭 키를 교환 → 이후 통신은 대칭 키로 암호화 (속도)

8-5. SNI (Server Name Indication)

하나의 IP에 여러 도메인이 호스팅될 때, 어느 도메인의 인증서를 내려줘야 할지 알려주는 확장. TLS 핸드셰이크 초반에 평문으로 도메인명이 노출된다.

ESNI / ECH (Encrypted Client Hello): SNI를 암호화하는 새 표준. 트래픽 검열 회피 목적도 있다.

8-6. HSTS (HTTP Strict Transport Security)

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

서버가 "앞으로 1년간은 HTTPS로만 오세요"라고 선언. 브라우저가 HTTP 요청을 자동으로 HTTPS로 변환한다. 중간자 공격에서 강제 HTTP 다운그레이드를 막는다.

preload 옵션을 붙이면 브라우저 내장 목록에 등록되어 첫 방문부터 강제 HTTPS가 적용된다.

9. HTTP 메시지 전송 최적화

9-1. 압축

서버가 Content-Encoding으로 압축을 명시한다. 브라우저는 Accept-Encoding으로 수락 가능 알고리즘을 전달.

gzip: 널리 지원되는 기본값
br (Brotli): 더 나은 압축률. HTTPS 환경에서 지원

CSS/JS는 압축 시 70% 이상 크기 감소가 흔하다. 이미지·영상은 이미 압축 포맷(JPEG, WebP, MP4)이라 추가 압축 효과 미미.

9-2. Connection: keep-alive

HTTP/1.1 기본. 연결 재사용으로 핸드셰이크 비용 절감. Keep-Alive: timeout=5 같은 힌트로 유지 시간 조절.

9-3. Range 요청

Range: bytes=1000-2000

파일의 일부만 받기. 영상 탐색(사용자가 재생 바를 중간으로 옮김), 이어받기(다운로드 재개), 대용량 파일의 병렬 다운로드에 쓴다.

성공 시 206 Partial Content 응답.

연습 문제

멱등성과 안전성의 차이를, 각 메서드별로 예시를 들어 설명하라.
로그인 후 특정 페이지에 접근할 때 권한이 없는 상황에서 401과 403 중 어느 것이 적절한가?
HTTP/1.1의 HOL Blocking과 HTTP/2의 HOL Blocking이 어느 계층에서 발생하는지 구분하라.
HTTP/3이 UDP 위에서 신뢰성을 제공할 수 있는 구조를 설명하라.
TLS 1.3 핸드셰이크가 1-RTT에 완료되는 이유를 TLS 1.2와 비교해 설명하라.
HSTS가 중간자 공격을 막는 원리를 설명하라.
PATCH 메서드가 멱등할 수도 비멱등할 수도 있는 예시를 들어라.
GET을 서버 상태 변경에 쓰면 왜 안 되는지 구체적 시나리오 3가지를 들어라.
서버가 오류 상황에서 200 OK + {error: "..."}를 반환하면 어떤 문제가 생기는가?
HTTPS에서 비대칭 키와 대칭 키를 모두 쓰는 이유를 설명하라.

연습 문제 정답

1. 멱등성 vs 안전성

안전(Safe): 서버 상태 불변. GET, HEAD, OPTIONS.
멱등(Idempotent): 여러 번 호출해도 최종 상태 동일. 안전한 메서드 + PUT, DELETE.
POST: 안전 X, 멱등 X (매번 새 리소스 생성)
PATCH: 안전 X, 멱등은 설계에 따라

2. 401 vs 403

인증은 되어 있는 상태이므로 403 Forbidden. 401은 "토큰이 없거나 유효하지 않음"이다.

3. HOL Blocking 계층

HTTP/1.1: 애플리케이션 레이어 (HTTP 요청 순서)
HTTP/2: 전송 레이어 (TCP 패킷 손실로 모든 스트림 대기)
HTTP/3 (QUIC): 둘 다 해결 (UDP라 스트림별 독립)

멱등: PATCH /user/1 {age: 30} — 몇 번 보내도 최종 age는 30
비멱등: PATCH /user/1 {$inc: {age: 1}} — 호출할 때마다 age가 1씩 증가

8. GET의 상태 변경 금지 이유

프리페치: 브라우저가 사용자가 클릭하기 전에 미리 GET 요청 → 의도치 않은 상태 변경
크롤러: 검색엔진이 링크를 자동 순회 → GET /user/delete?id=5 같은 게 실제로 실행되는 참사
캐시: 중간 프록시나 브라우저가 GET 응답을 캐시 → 재요청이 실제 서버에 닿지 않음

9. 200 OK + 오류 body의 문제

브라우저 캐시가 오류 응답을 "성공"으로 간주해 저장
CDN/프록시도 "성공"으로 처리
모니터링 도구가 오류를 놓침 (2xx율만 보고 SLO 달성으로 오인)
fetch API 등에서 response.ok 체크가 무의미해짐 → 호출부 전체가 복잡해짐

10. 비대칭 + 대칭 혼합 이유

비대칭 (RSA, ECDHE): 공개키로 안전하게 키 교환 가능, 그러나 연산이 느림
대칭 (AES): 매우 빠르지만 키를 미리 안전하게 공유해야 함

흐름: 핸드셰이크에서 비대칭으로 대칭 키를 안전하게 합의 → 이후 실제 데이터는 대칭 키로 빠르게 암호화. 둘의 장점만 취한다.

체크리스트

프로토콜의 개념과 HTTP가 응용 계층임을 안다
HTTP의 요청/응답 메시지 구조를 직접 그릴 수 있다
무상태성의 의미와 그 이점·단점을 설명할 수 있다
주요 메서드와 안전성/멱등성을 표로 그릴 수 있다
GET으로 상태 변경을 하면 안 되는 이유를 3가지 이상 들 수 있다
주요 상태 코드 (2xx, 3xx, 4xx, 5xx)를 즉답할 수 있다
401과 403의 차이를 안다
200 OK + 오류 body의 문제점을 안다
주요 헤더 10개 이상의 용도를 안다
HTTP/1.1, HTTP/2, HTTP/3의 차이를 안다
멀티플렉싱과 HOL Blocking을 설명할 수 있다
HTTP/3이 UDP 위에서 동작하는 이유를 안다
TLS 1.3 핸드셰이크가 1-RTT인 이유를 안다
인증서 체인 검증 과정을 안다
비대칭 키와 대칭 키를 함께 쓰는 이유를 안다
HSTS의 역할과 preload의 의미를 안다

이전: 2-1. 네트워크 기초 | 다음: 2-3. 통신 프로토콜과 API 스타일