[Network] HTTP

HTTP 프로토콜 & HTTPS

1. HTTP (HyperText Transfer Protocol)

1-1. HTTP란?

[HTTP란 무엇인가?]
: 웹에서 클라이언트(브라우저)와 서버가 데이터를 주고받기 위해 사용하는 애플리케이션 계층 프로토콜
텍스트, 이미지, JSON, 동영상 등 거의 모든 리소스를 주고받는 표준 방식

[특징]

• 클라이언트 - 서버 구조
  클라이언트가 요청(Request)을 보내고, 서버가 응답(Response)을 반환하는 구조
• 무상태(Stateless)
  각 요청은 독립적 → 이전 요청 상태를 기억하지 않음
  세션(Session), 쿠키(Cookie), 토큰(Token)을 통해 상태를 보완
• 비연결성(Connectionless)
  기본적으로 요청-응답 후 연결을 끊음
  HTTP/1.1부터는 Keep-Alive로 연결 유지 가능
  [c.f.] Keep-Alive?

[HTTP 동작 방식 (클라이언트–서버 모델, Request/Response 구조)]

• 사용자가 브라우저에 URL 입력
• DNS 조회 → IP 주소 찾기
• TCP 3-way Handshake → 서버와 연결
• 클라이언트가 HTTP 요청 메시지 전송
• 서버가 요청 처리 후 HTTP 응답 메시지 반환
• 브라우저가 응답 데이터 렌더링

1-2. HTTP의 버전

버전	출시 시기	주요 특징	장점	단점
HTTP/1.0	1996	- 요청마다 새로운 TCP 연결- 기본적으로 요청 1개 → 응답 1개	단순한 구조, 초기 웹 구현 용이	연결 재사용 불가 → 성능 저하
HTTP/1.1	1997	- 지속 연결 (Keep-Alive)- 파이프라이닝(잘 안 씀)- Host 헤더 필수- 캐싱·Range 요청 지원	연결 재사용 가능 → 성능 개선다중 도메인 운영 가능	요청/응답 순차 처리 → HOL 블로킹 문제
HTTP/2	2015	- 이진 프로토콜- 멀티플렉싱 (동시 요청 처리)- 헤더 압축 (HPACK)- 서버 푸시	성능 대폭 향상대역폭 절약	TCP 기반이라 TCP HOL 블로킹 존재
HTTP/3	2020~	- QUIC(UDP 기반) 사용- 0-RTT 연결 설정- 멀티플렉싱 유지 + TCP HOL 제거- 모바일 환경 최적화	빠른 연결 수립지연 최소화네트워크 이동 시 안정적	UDP 기반 특성상 네트워크 장비/방화벽 호환성 문제 (점진적 해결 중)

1. HTTP/1.0 (1996)

• 초기 버전
• 특징
  • 요청마다 TCP 연결 새로 맺음 → 비효율적 (연결/해제 오버헤드 큼)
  • 기본적으로 한 번의 요청-응답 후 연결 종료
• 단점
  • 다수의 리소스(HTML, CSS, JS, 이미지 등)를 불러올 때 매번 TCP 연결 → 성능 저하

---

1. HTTP/1.1 (1997, 현재도 많이 사용)

• 가장 널리 쓰이는 버전
• 특징
  • 지속 연결(Persistent Connection, Keep-Alive) 지원 → 하나의 TCP 연결로 여러 요청/응답 가능
  • 파이프라이닝(Pipelining) 지원 (요청을 순차 처리하지 않고 여러 개 동시에 보낼 수 있음 → 하지만 HOL(Head-of-Line) 블로킹 문제로 잘 쓰이지 않음)
  • Host 헤더 필수 → 하나의 서버(IP)에서 여러 도메인 운영 가능 (가상 호스팅)
  • 캐싱, 상태 코드, Range 요청(부분 요청) 등 기능 확장
• 단점
  • 여전히 요청/응답이 순차적으로 처리 → 병목 발생
  • HOL 블로킹 문제 존재

---

1. HTTP/2 (2015, 구글 SPDY 기반)

• 성능 최적화에 중점
• 특징
  • 이진(Binary) 프로토콜 → 효율적인 파싱 가능
  • 멀티플렉싱(Multiplexing) → 하나의 연결에서 여러 요청/응답 동시 전송 가능 → HOL 블로킹 문제 해결
  • 헤더 압축 (HPACK) → 네트워크 트래픽 절감
  • 서버 푸시(Server Push) → 서버가 클라이언트 요청 전에 리소스 전송 가능
• 장점
  • HTTP/1.1 대비 속도와 효율성 크게 개선
• 단점
  • TCP 기반이라 여전히 TCP 레벨 HOL 블로킹 문제 존재

---

1. HTTP/3 (2020~, 현재 확산 중)

• QUIC 프로토콜(UDP 기반)을 사용하는 최신 버전
• 특징
  • TCP 대신 UDP 기반 → 연결 지연 최소화
  • 0-RTT 연결 설정 → 거의 즉시 연결 가능
  • 멀티플렉싱 유지 + TCP HOL 블로킹 제거
  • 이동 환경(모바일, Wi-Fi → LTE 전환 등)에서 연결 안정성 크게 향상
• 장점
  • 빠른 연결 수립, 지연 최소화, 더 안정적인 성능
• 단점
  • UDP 기반이라 방화벽/네트워크 장비 호환성 이슈 존재 (점차 개선 중)

2. HTTP 메서드 (GET, POST, PUT, DELETE)

메서드	CRUD 매핑	멱등성	캐시 가능성	본문 사용
GET	Read	O	O	X
POST	Create	X	X	O
PUT	Update	O	X	O
DELETE	Delete	O	X	보통 X

1) GET

• 서버에서 리소스(데이터)를 조회(Read)
• 특징:
  • 요청 데이터는 쿼리 스트링(?key=value) 또는 헤더로 전달
  • 본문(Body)을 가지지 않음 (명세상 허용은 되지만 일반적으로 사용하지 않음)
  • 캐싱 가능 → 성능 최적화에 자주 사용

// id=10인 사용자 정보 조회
GET /users?id=10 HTTP/1.1
Host: example.com

---

2) POST

• 서버에 새로운 리소스 생성(Create) 또는 데이터 전송
• 특징:
  • 요청 본문(Body)에 데이터 포함
  • 멱등성(같은 요청 여러 번) 보장하지 않음

// 새로운 사용자 생성
POST /users HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Alice",
  "age": 25
}

---

3) PUT

• 특정 리소스를 전체 수정(Update)
• 특징:
  • 요청 본문(Body)에 리소스의 전체 내용을 보냄
  • 멱등성 보장 (같은 요청 여러 번 실행해도 결과 동일)
  • 없는 리소스라면 생성하기도 함 (서버 구현 방식에 따라 다름)

// id=10번 사용자의 정보를 통째로 교체
PUT /users/10 HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Alice",
  "age": 26
}

---

4) DELETE

• 특정 리소스 삭제(Delete)
• 특징:
  • 보통 본문 없음
  • 멱등성 보장 (여러 번 호출해도 최종 결과는 동일 → 삭제됨)

// id=10 사용자 삭제
DELETE /users/10 HTTP/1.1
Host: example.com

3. 멱등성 & 안전성

메서드	멱등성	안전성	설명
GET	O	O	단순 조회
HEAD	O	O	헤더만 조회
OPTIONS	O	O	서버가 지원하는 메서드 확인
POST	X	X	리소스 생성 (반복 시 계속 생성됨)
PUT	O	X	리소스 전체 교체
DELETE	O	X	리소스 삭제

1) 멱등성 (Idempotency)

• 같은 요청을 여러 번 반복해서 보내더라도 결과가 달라지지 않는 성질
• 한 번 수행했을 때와 여러 번 수행했을 때 서버의 상태가 동일해야 함
• PUT /users/10 { "name": "Alice" }
  • 1번 실행 → 사용자 정보 업데이트됨
  • 10번 실행해도 결과는 동일 (Alice로 유지) → 멱등
• DELETE /users/10
  • 1번 실행 → 삭제됨
  • 10번 실행 → 이미 삭제 상태 그대로 유지 → 멱등
• POST /users { "name": "Alice" }
  • 1번 실행 → 새로운 사용자 생성
  • 10번 실행 → 사용자 여러 개 생성 → 비멱등

2) 안전성(Safety)

• 요청이 서버의 리소스를 변경하지 않는 성질
• 읽기 전용(Read-only) 요청인지 여부
• GET /users/10
  • 단순 조회 → 서버 데이터 변경 없음 → 안전
• HEAD /users/10
  • 본문 제외하고 헤더만 응답 → 서버 변경 없음 → 안전
• PUT /users/10
  • 리소스 수정 → 서버 상태 변경 → 안전하지 않음
• DELETE /users/10
  • 리소스 삭제 → 서버 상태 변경 → 안전하지 않음

4. HTTP 헤더 구조와 역할

[특징]

• http에서 헤더는 요청과 응답 메세지 모두에서 쓰임
• 이름: 값 쌍으로 이루어짐
• 대소문자를 구분하지 않음 (Host = host)
• 여러개의 값 가능 (,로 구분)

헤더의 구조

• 전통적 분류에 따르면 (General / Request / Response / Entity) 로 크게 구분되지만, 기능적 측면에서 캐싱, 인증, 콘텐츠 협성, 보안등으로 나눠 설명 가능

분류	설명	예시
일반 헤더 (General Headers)	요청/응답 양쪽에서 공통으로 사용	Cache-Control, Date, Connection
요청 헤더 (Request Headers)	클라이언트 → 서버, 요청 관련 정보 전달	Host, User-Agent, Accept, Authorization
응답 헤더 (Response Headers)	서버 → 클라이언트, 응답 관련 정보 전달	Server, Set-Cookie, Location
엔티티 헤더 (Entity Headers)	본문(Body) 데이터의 속성/메타데이터 전달	Content-Type, Content-Length, Last-Modified

5. HTTP 메세지 구조 (요청 & 응답)

1) 요청 메세지

RequestLine: <메서드> <요청 대상(URI)> <HTTP 버전>
Header: <헤더들>
CRLF: <빈 줄>
Body: <본문>

1. 시작줄 (Request Line)
   • GET /index.html HTTP/1.1
   • 메서드(Method): GET, POST, PUT, DELETE 등
   • 요청 대상(URI): /index.html
   • HTTP 버전: HTTP/1.1
2. 헤더(Header)
   • 요청에 대한 부가 정보 전달
   • 예시:

     Host: www.example.com
     User-Agent: Chrome/117
     Accept: text/html
     Content-Type: application/json

3. 빈 줄 (CRLF)
   • 헤더와 본문을 구분
4. 본문(Body)
   • 요청에 담을 데이터 (POST, PUT 등일 때 사용)
   • 예시:

     {
       "username": "test",
       "password": "1234"
     }

2) 응답 메세지

StatusLine: <HTTP 버전> <상태 코드> <상태 메시지>
Header: <헤더들>
CRLF: <빈 줄>
Body: <본문>

• 상태줄 (Status Line)
  • HTTP/1.1 200 OK
  • HTTP 버전: HTTP/1.1
  • 상태 코드(Status Code): 200
  • 상태 메시지: OK
• 헤더(Header)
  • 응답에 대한 부가 정보 전달
  • 예시:

    Content-Type: text/html; charset=UTF-8
    Content-Length: 1024
    Cache-Control: no-cache
    Set-Cookie: sessionId=abcd1234; HttpOnly
    

• 빈 줄 (CRLF)
• 본문(Body)
  • 실제 응답 데이터
  • 예시:

    <html>
      <body>Hello, World!</body>
    </html>
    

6. HTTP 상태 코드 (HTTP Status Code)

• HTTP 응답 메시지의 상태 줄(Status Line) 에 포함되어, 요청 처리 결과를 3자리 숫자로 표현됨

HTTP/1.1 200 OK

범위	의미	예시
1xx (정보)	요청을 계속 진행 중	100 Continue, 101 Switching Protocols
2xx (성공)	요청 정상 처리 완료	200 OK, 201 Created, 204 No Content
3xx (리다이렉션)	추가 작업(다른 위치로 이동 등) 필요	301 Moved Permanently, 302 Found, 304 Not Modified
4xx (클라이언트 오류)	클라이언트 요청이 잘못됨	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx (서버 오류)	서버가 요청을 처리하지 못함	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

성공 (2xx)

• 200 OK → 요청 성공, 응답 본문에 결과 포함
• 201 Created → 새로운 리소스 생성 성공 (POST 요청 등)
• 204 No Content → 요청 성공했지만 본문 없음 (DELETE 응답 등)

리다이렉션 (3xx)

• 301 Moved Permanently → 요청한 리소스가 영구적으로 새로운 URI로 이동
• 302 Found → 일시적인 이동 (브라우저는 보통 자동 이동)
• 304 Not Modified → 캐시된 데이터 사용 (조건부 요청 결과)

클라이언트 오류 (4xx)

• 400 Bad Request → 잘못된 요청 (파라미터 오류 등)
• 401 Unauthorized → 인증 필요 (로그인 필요)
• 403 Forbidden → 접근 권한 없음 (로그인했어도 권한 불충분)
• 404 Not Found → 요청한 리소스 없음
• 405 Method Not Allowed → 허용되지 않은 메서드 요청

서버 오류 (5xx)

• 500 Internal Server Error → 서버 내부 오류 (원인 불명)
• 502 Bad Gateway → 게이트웨이/프록시가 잘못된 응답 수신
• 503 Service Unavailable → 서버 과부하 또는 점검 중
• 504 Gateway Timeout → 게이트웨이가 응답 기다리다 타임아웃

7. HTTPS

[HTTPS?]

HTTP: 단순 요청/응답, 평문 전송 → 보안 취약

HTTPS: TLS/SSL 적용 → 암호화 + 무결성 + 인증 → 안전

• HTTP는 여전히 웹 요청/응답 구조를 그대로 사용
• 실제 서비스: 로그인, 결제, 개인정보 처리 등은 HTTPS 필수
• TLS/SSL 계층에서 데이터 암호화, 무결성 확인, 서버 인증 수행
• SEO 측면에서도 HTTPS 사이트가 우선 순위

[HTTPS의 특징]

1. 암호화

• 대칭키 암호화: 실제 데이터 전송 시 사용
  • 빠르고 효율적
• 비대칭키 암호화: 세션 키(대칭키) 교환 시 사용
  • 공개키/개인키 방식 → 중간 공격 방지

2. 무결성

• 데이터가 전송 중 변조되지 않았는지 확인
• TLS 메시지 인증 코드(MAC) 사용

3.인증

• 서버 인증서(Certificate)를 통해 서버 신원 확인
• 신뢰할 수 있는 CA(Certificate Authority)가 발급