Post

03 network - HTTP

Posted
By Yoo hyeonjun
13 min read
03 network - HTTP

1.HTTP

1. 기본용어

  • 클라이언트/서버모델
    • 네트워크 통신 구조 중 하나로, 클라이언트는 서비스나 데이터를 요청하고, 서버는 해당 요청을 처리하고 응답하는 구조
    • 웹 브라우저(클라이언트) ↔ 웹 서버
  • 요청 메시지
    • 클라이언트가 서버로 전송하는 메시지. 요청 방식(메서드), 요청 대상(리소스 경로), 헤더, 바디 등을 포함.
    • HTTP GET /index.html
  • 응답 메시지
    • 서버가 요청에 대해 반환하는 메시지. 상태 코드(Status Code), 헤더, 응답 본문(Body)을 포함.
    • HTTP/1.1 200 OK + HTML 페이지 데이터

2. 상태

  • stateless
    • 서버가 각 요청 간의 상태 정보를 유지하지 않는 방식.
    • 모든 요청은 독립적으로 처리되며, 이전 요청과의 관계를 알 수 없음.
  • stateful
    • 서버가 클라이언트의 이전 요청 상태를 기억하고 다음 요청 처리에 반영하는 방식.
    • 로그인 세션을 유지하는 TCP 기반 연결
  • 비연결성
    • 요청-응답 처리 후 연결을 바로 끊는 통신 특성.
    • 연결 유지 비용이 낮지만, 매 요청마다 새로운 연결이 필요함.

2. HTTP 메시지구조

1. 응답 메시지

1
2
3
4
5
6

  POST /login HTTP/1.1 ← 요청라인
  Host: www.example.com ← 헤더
  Content-Type: application/x-www-form-urlencoded ← 헤더
  Content-Length: 27 ← 헤더

  username=admin&password=1234 ← 본문
  • 상태라인: 프로토콜 버전 + 상태 코드 + 상태 메시지
  • 헤더(Header): 응답 관련 부가 정보
  • 빈 줄(CRLF): 헤더와 본문 구분
  • 본문(Body): 실제 응답 데이터

2. 요청 메시지

1
2
3
4
5
6
7
8
9
10

  HTTP/1.1 200 OK ← 상태라인
  Date: Fri, 08 Aug 2025 11:00:00 GMT ← 헤더
  Content-Type: text/html  ← 헤더
  Content-Length: 137  ← 헤더

  <html>                             ← 본문
  <head><title>Example</title></head>
  <body><h1>Hello World</h1></body>
  </html>
  • 요청라인: 메서드 + 요청 URI + 프로토콜 버전
  • 헤더(Header): 요청 관련 부가 정보
  • 빈 줄(CRLF): 헤더와 본문 구분
  • 본문(Body): 요청에 필요한 데이터

3. HTTP 메소드(응답메시지의 메소드)

1. GET 메소드

  • 서버에 데이터를 요청할 때 사용
  • 요청 데이터는 URL의 쿼리스트링(Query String)에 포함 (?key=value)
  • 본문(body) 없이 전송 (HTTP 표준상 가능은 하지만 일반적으로 사용 안 함)
  • 캐싱 가능, 즐겨찾기 가능
  • 데이터 길이 제한 존재(브라우저나 서버 제한)

2. POST 메소드

  • 서버에 데이터를 전송하거나 리소스를 생성할 때 사용
  • 요청 데이터는 본문(body)에 포함
  • URL에 데이터 노출 안 됨
  • 캐싱 기본적으로 불가
  • 대용량 데이터 전송 가능

3. PUT 메소드

  • 지정한 리소스를 완전히 교체(Replace)
  • 요청 시 보낸 데이터가 리소스의 전체 내용이 됨
  • 같은 요청을 여러 번 보내도 결과가 같음 → 멱등(Idempotent) 특성 있음

4. PATCH

  • 지정한 리소스를 부분 수정(Partial Update)
  • 변경할 필드만 보냄
  • 멱등성을 가질 수도, 안 가질 수도 있음 (구현 방식에 따라 다름)

  • 5. 안전성 / 멱등성

  • 안정성 (Safety)
    • 이 요청을 처리해도 서버 리소스의 상태가 변하지 않는다는 성질
    • 요청이 읽기 전용(Read-only)임을 보장
    • 서버의 데이터나 상태를 수정하지 않음
    • 요청을 여러 번 반복해도, 서버의 상태에 영향이 없음
  • 멱등성
    • 같은 요청을 여러 번 보내더라도 결과가 처음 한 번 보냈을 때와 동일하다는 성질
    • 요청이 서버에 적용되는 최종 상태가 동일해야 함
    • 요청을 1번 하든 100번 하든 리소스의 상태는 변함없음
    • 서버 응답 메시지 내용이 매번 동일해야 한다는 뜻은 아님
  • 안정성과 멱등성
구분안전성(Safety)멱등성(Idempotency)
의미상태를 변경하지 않음여러 번 호출해도 최종 상태 동일
예시GET, HEADGET, PUT, DELETE
관계안전한 메서드는 멱등성을 가질 수 있음멱등하지만 안전하지 않은 경우 존재 (DELETE 등)

4. Header

1. Header 헤더

  • 요청(Request)이나 응답(Response) 메시지에 부가적인 정보를 담는 필드들의 집합
  • 메시지의 첫 줄(요청라인/상태라인) 다음에 오고, 빈 줄(CRLF)로 본문과 구분
  • 요청/응답에 메타데이터(Metadata) 제공
  • 본문이 어떤 형식인지, 얼마나 되는지, 인코딩 방식은 무엇인지 등의 정보 전달
  • 인증, 캐싱, 연결 방식, 콘텐츠 타입 등 다양한 제어 가능

2. 헤더종류

분류위치(사용처)주요 역할대표 헤더 예시
공통 헤더요청 & 응답 모두메시지 전체에 대한 일반 메타정보Cache-Control, Connection, Date
요청 헤더클라이언트 → 서버요청 조건, 클라이언트 정보 전달Host, User-Agent, Accept, Authorization
응답 헤더서버 → 클라이언트서버 상태, 쿠키, 리다이렉션 정보Server, Set-Cookie, Location
엔티티 헤더요청/응답 본문 관련본문 내용 타입, 길이, 인코딩 등Content-Type, Content-Length, ETag

5. 상태코드

1. 상태코드의 구성

  • 3자리 숫자 코드로 이루어짐
  • 첫 번째 숫자가 상태 그룹(클래스)을 나타냄
  • 뒤에 간단한 텍스트 메시지가 따라옴 (예: 200 OK)

2. 상태코드 그룹별 의미

코드 첫 자리분류의미예시
1xx정보 응답요청을 받았고 프로세스를 계속함100 Continue
2xx성공요청이 정상적으로 처리됨200 OK, 201 Created
3xx리다이렉션추가 작업 필요 (다른 위치로 이동 등)301 Moved Permanently, 302 Found
4xx클라이언트 오류요청에 문법 오류 또는 잘못된 요청400 Bad Request, 404 Not Found
5xx서버 오류서버가 요청 처리 중 에러 발생500 Internal Server Error, 503 Service Unavailable

6. HTTP 보안

1. HTTPS의 역할

  • HTTP 데이터 통신을 암호화해서 도청 방지
  • 서버와 클라이언트 간에 데이터 무결성 보장
  • 서버 신원을 검증해 중간자 공격(Man-in-the-middle) 방지

2. HTTP에서 IP 주소와 MAC 주소를 확인하는 것만으로는 보안이 약한 이유

  • MAC 주소는 네트워크 계층(2계층)에서만 의미가 있음
    • MAC 주소는 같은 로컬 네트워크(LAN) 내에서만 식별 가능
    • 인터넷 같은 광역 네트워크(WAN)에서는 MAC 주소가 라우터에서 바뀌기 때문에 도달하지 않음
    • 서버가 인터넷 상에서 직접 클라이언트 MAC 주소를 알 수 없음
  • IP 주소는 쉽게 위조 가능 (IP 스푸핑)
    • IP 주소는 패킷 헤더에 기록되는 값이고, 네트워크 패킷 조작으로 변경 가능
    • 공격자는 IP를 위조해서 접근할 수 있음
    • IP 주소는 공유기, NAT, 프록시를 거치면 실제 사용자 식별 불가능
  • HTTP는 암호화되지 않음 (평문 전송)
    • 요청 메시지, 헤더, 본문이 모두 암호화 없이 평문으로 전송됨
    • 네트워크 중간에서 패킷을 가로채서 IP, 헤더, 쿠키, 세션 정보 등 모두 탈취 가능
    • IP/MAC 기반 인증도 쉽게 우회 가능
  • HTTP 자체에 인증·암호화 기능이 없음
    • IP, MAC 체크 외에는 사용자 신원 확인, 데이터 무결성, 비밀 유지가 보장되지 않음
    • 세션 하이재킹, 중간자 공격(Man-in-the-middle) 등 공격에 취약

7. HTTP 흐름

1. HTTP/1.0 (1996년)

  • 최초의 널리 사용된 HTTP 표준 버전
  • 비연결성(Non-persistent connection): 요청 하나당 TCP 연결 하나 사용 후 종료
  • 요청-응답 방식 간단하지만, 연결 매번 새로 열어 느리고 비효율적
  • 캐싱, 상태 코드, 헤더 필드 기본 지원 시작
  • HTMl뿐만 아니라 이미지/파일 등 다양한 데이터 ㅍ타입을 주고받을 수 있게 됨.

2. HTTP/1.1 (1997년)

  • 가장 널리 쓰이는 표준 버전 (현재도 많이 사용 중)
  • 지속 연결(Persistent connection) 지원: TCP 연결을 재사용해 여러 요청 처리 가능 → 성능 개선
  • 파이프라이닝(pipelining) 도입(하지만 브라우저별 지원 문제로 제한적)
  • 향상된 캐싱, 청크 전송 인코딩(Chunked Transfer-Encoding), Host 헤더 필수화
  • 요청 메서드 추가 (예: OPTIONS, PUT, DELETE 등)
  • 상태 코드, 콘텐츠 협상(content negotiation) 등 기능 강화

3. HTTP/2 (2015년)

  • 성능 최적화에 초점
  • 이진 프로토콜 도입 → 텍스트 기반 HTTP/1.x보다 처리 효율↑
  • 멀티플렉싱(Multiplexing) 지원: 하나의 TCP 연결로 여러 요청과 응답 동시 처리 → 지연시간 감소
  • 헤더 압축(HPACK) → 네트워크 사용량 감소
  • 서버 푸시(Server Push): 서버가 클라이언트 요청 없이도 리소스 미리 전송 가능
  • TLS 암호화 권장, 대부분 HTTPS와 함께 사용됨

4. HTTP/3 (2022년 표준화, 본격 적용 중)

  • UDP 기반 전송 프로토콜 QUIC 위에 구현
  • TCP의 연결 지연과 헤드 오브 라인 블로킹 문제 해결
  • 빠른 연결 설정과 복구
  • 멀티플렉싱, 헤더 압축 유지
  • 기존 HTTP/2의 성능 개선 및 안정성 향상
  • HTTPS 필수 적용
network, network basics
network
This post is licensed under CC BY 4.0 by the author.