Hyeok의 웹 개발 블로그

<2025.03.18> HTTP 기초 본문

TIL/Spring

<2025.03.18> HTTP 기초

Yhyeok 2025. 3. 18. 22:01

🔎 HTTP 

 - 특징 

 1. 클라이언트와 서버 구조

 

 2. 무상태 (Stateless)

 - 서버는 클라이언트의 상태를 보존하지 않는다.

- 장점

  • Scale Out 수평 확장성이 높다.
  • 갑자기 요청량이 증가하여도 서버를 증설 하기 쉽다.

- 단점

  • 클라이언트가 데이터를 추가적 으로 전송해야한다.

- 한계점

  • 무상태로 설계 할 수 없는 경우가 있다.
  • 로그인? > Cookie, Session, Token 등을 활용

 3. 비연결 (Connectionless)

 - HTTP는 연결을 유지하지 않는 모델이다.

 - 장점

  • 서버 자원을 효율적으로 사용할 수 있다.

- 단점

  • 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야한다.
  • 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다
  • 현재는 HTTP 지속연결로 문제를 해결한다.

💡 HTTP 의 구조

 

  1. Start Line
    • HTTP Version
    • Status Code
      • 요청이 성공했는지, 실패했는지 나타내는 코드
    • Status Text
      • 코드와 함께 전달될 메세지
  2. Header
    • Response에서만 사용되는 Header 값들이 따로 존재한다.
  3. Empty Line
    • 공백 한줄, 필수값
  4. Message Body
    • 실제 전송하는 데이터가 담겨 있는 부분
    • 만약 전송할 데이터가 없다면, Body가 공백으로 존재한다.

- HTTP Method

  • 주요 Method
    - CRUD 
    - C : Creat - POST
    - R : Read - GET 
    - U : Update - PUT (전체) , PATCH (일부) 
    - D : Delet - DELET 
    - Request Target 

- HTTP Method 속성

  1. 안전성(Safe)
    • GET 메소드(조회)는 안전하다.
      • 저장된 데이터를 변환하지 않는다.
    • POST, DELETE, PUT, PATCH는 안전하지 않다.
      • 데이터를 생성, 수정, 삭제한다.
  2. 멱등성(Idempotent)
    • 한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다.
      1. GET → 같은 결과가 계속 조회된다.
      2. PUT → 수정해서 대체된 후의 결과는 계속 같다.
      3. DELETE → 같은 요청을 여러번해도 삭제된 결과는 같다.
      4. POST → 멱등성을 보장하지 않는다.
      ex) 계좌 송금을 두번한다면?, 게시판 글쓰기, 회원가입
    • 요청이 실패한 경우 재시도 하기위해 필요하다.
      1. 항상 결과가 같다면 마음껏 재시도 해도된다.
      2. 만약 멱등하지 않다면, 중복 요청을 보내서는 안된다.
      3. 복구 매커니즘에 사용한다.
      ex) 요청 실패시 서버에서 자동으로 재시도
    • 리소스 조회(GET Method) 재요청 중간에 변경된다면?
      • 재요청 중간에 리소스가 변경되는것은 멱등성으로 고려하지 않는다.
      ex) 도서관 책 재고 조회(실시간으로 대여 혹은 판매됨)
  3. 캐시가능성(Cacheable)
    • 재사용을 위해 요청에 대한 응답을 저장할 수 있는가?
      1. GET, HEAD, POST 메소드는 캐시가 가능하다.
      2. 일반적으로 GET, HEAD 정도만 캐시로 사용한다.
      ex) 변경 가능성이 적은 정적자원(HTML, CSS, IMAGE, JS 등)을 주로 캐싱한다.

- HTTP 상태 코드

▶1xx (정보)
▶2xx (성공)

▶3xx (리다이렉션)

▶4xx (클라이언트 에러)

▶5xx (서버 에러)