HTTP를 배워보자

김현정·2025년 3월 17일
TIL내일배움캠프스파르타
0

내일배움캠프 : 스파르타 Spring6기

목록 보기
15/78

HTTP (HyperText Transfer Protocol)

1. http란 클라이언트 to 서버(요청)뿐만 아니라, 서버 to 클라이언트(응답)에도 사용되며 서버 to 서버 간의 데이터 통신에도 사용된다.

2. HTTP 동작 순서


클라이언트에서 서버로 요청(Requset)하고 서버는 요청을 읽어서 처리를 한 후에 결과를 응답(Response)하는 과정

3. HTTP의 특징

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

  • 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다. 서버에서 불특정다수(클라이언트)에게 상태나 연결을 계속 유지해야 한다면 이에 따른 많은 서버의 리소스가 필요하다.
  • 기존에는 클라이언트, 서버가 구분되어 있지 않았음. 클라이언트는 UI에 중점을 두도록 만들었으며, 서버에서는 데이터, 비즈니스 로직을 담당하도록 만들었다.
  • 그 결과 각자 독립적으로 발전하였다.

2) 무상태 (Stateless)

  • 서버는 클라이언트의 상태를 보전하지 않는다.
  • 장점 : Scale Out 수평 확장성이 높고, 갑자기 요청량이 증가하여도 서버를 증설하기 쉽다.
  • 단점 : 클라이언트가 데이터를 추가적으로 전송해야 한다.
  • 한계점 : 무상태로 설계할 수 없는 경우가 있고, 로그인의 방법(Cookie, Session, Token 등 활용)

3) 비연결 (Connectionless)

  • HTTP는 연결을 유지하지 않는 모델이다.
  • 장점 : 서버 자원을 효율적으로 사용할 수 있다.
  • 단점 : 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야하고, 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다. (캐시, 브라우저 캐싱으로 해결)
  • 현재는 HTTP 지속연결((Persistent Connections)로 문제를 해결한다.
HTTP 지속연결
- 하나의 요청에 필요한 요청들이 모두 응답될 때까지 연결을 유지한다.
- 연결을 한번만 맺고 끊기 때문에, Connectionless 방식보다 연결 횟수가 적다. -> 속도가 빨라짐

4. HTTP Message 구조

HTTP Message는 요청 메세지, 응답 메세지 두 가지 종류가 있고 구조가 각각 다르다.

1) HTTP Message 구조

- Start Line

  • HTTP Method

    • GET
    • 요청의 의도를 가진 GET, POST, PUT, PATCH, DELETE 등이 있다.
      • Create - POST
      • Read - GET
      • Update - PUT(전체), PATCH(일부)
      • Delete - DELETE
      • Request Target

  • path

  • /event

  • HTTP Request가 전송되는 대상, 절대 경로(”/”로 시작하는 경로)

  • Query String(= Query Parameter) 에 해당하는 값도 포함한다.

  • HTTP Version

  • 1.1

  • HTTP Version을 나타낸다.

- Header

  • field-name: OWS field-value OWS (OWS : 띄어쓰기 허용) 구조
  • field-name은 대소문자 구분을 하지 않는다.
  • 임의의 Header를 추가할 수 있다. (단, 서버가 값을 알고 있어야 함)
  • 요청의 추가 정보들을 가지고 있다.

- Empty Line

  • 공백 한 줄, 필수 값

- Message Body

  • 실제 전송하는 데이터가 담겨 있는 부분
    • HTML, 이미지, JSON 등 byte로 표현되는 모든 데이터 전송 가능.
  • 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.

2) HTTP 요청 메세지(Request Message)

3) HTTP 응답 메세지(Response Message)

- Start Line

- HTTP Version
- Status Code
   	- 요청이 성공했는지, 실패했는지 나타내는 코드
- Status Text
   	- 코드와 함께 전달될 메세지

- Header

- Response에서만 사용되는 Header 값들이 따로 존재한다.

- Empty Line

- 공백 한줄, 필수값

- Message Body

- 실제 전송하는 데이터가 담겨 있는 부분
- 만약 전송할 데이터가 없다면, Body가 공백으로 존재한다.

5. HTTP Method

클라이언트 - 서버 사이에 이루어지는 요청, 응답 데이터를 전송하는 방식을 뜻한다.

1) 주요 Method

  • Post
    - 리소스 생성

    - 주로 HTML, FORM(회원가입, 게시글 작성 등)에 사용된다.
    - 요청 데이터를 처리하는 방식에 정해진 것은 없다.
    1. 요청 데이터 처리(로그인 등)에 사용한다.
    2. 조회 시 JSON요청 데이터가 필요한 경우에도 사용될 수 있다.
    - Message Body를 통해 요청 데이터를 전달한다.
  • GET
    - 리소스 조회
    1. Query String 미포함하는 경우

      - GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.
    2. Query String 포함하는 경우

      - 서버에 추가적인 데이터 전송을 해야한다면, Message Body가 아닌 Query String(Query Parameter)를 사용한다.
  • PUT
    - 리소스 덮어쓰기
    • POST와는 다르게 클라이언트 측에서 리소스를 식별하여 URI를 지정한다.

    1. 기존 리소스가 존재하는 경우

      - 리소스 전체 수정

      2. 기존 리소스가 존재하고 일부만 변경하는 경우

      - 기존 리소스가 존재하면 완전히 덮어쓰기가 된다.

    2. 기존 리소스가 없는 경우

      - 리소스가 없으면 생성된다.

  • PATCH
    - 리소스 부분 수정

  • DELETE
    - 리소스 삭제

    -> CRUD 너무나도 중요하니 꼭 외우자

  • 기타 Method (거의 사용을 안해서 위에 것이 더 중요)
    - HEAD : GET에서 Message Body를 제외하고 상태 줄과 헤더만 반환한다.

    • OPTIONS : 대상 리소스에 대한 통신 가능한 Method를 설명한다.
    • CONNECT : 대상 지원으로 식별되는 서버에 대한 터널을 설정한다. (잘 사용안함)
    • TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다 (잘 사용안함)

6. HTTP Method 속성

HTTP Method는 안정성(Safe), 멱등성(Idempotent), 캐시가능성(Cacheable) 속성을 가지고 있다.

(Optional은 있을수도 있고, 없을수도 있다라는 말)

1) 안정성(Safe)

  • GET 메소드(조회)는 안전하다
    - 저장 된 데이터를 반환하지 않는다.
  • POST, DELETE, PUT, PATCH는 안전하지 않다.
    - 데이터를 생성, 수정, 삭제한다.

2) 멱등성(Idempotent) (- 계속 일관하다)

  • 한번 호출하거나 수천번을 호출하거나 결과는 같다.
    1. GET 같은 결과가 계속 조회됨
    1. PUT 수정해서 대체된 후의 결과는 계속 같다
    2. DELETE 같은 요청을 여러번해도 삭제된 결과는 같다
    3. POST 멱등성을 보장하지 않음.
  • 요청이 실패한 경우 재시도 하기위해 필요하다.
    1. 항상 결과가 같다면 마음껏 재시도 해도된다.
    1. 만약 멱등하지 않다면, 중복 요청을 보내서는 안된다.
    2. 복구 매커니즘에 사용한다.
  • 리소스 조회(GET Method) 재요청 중간에 변경된다면?

    - 재요청 중간에 리소스가 변경되는 것은 멱등성으로 고려하지 않는다.

3) 캐시가능성 (Cachable)

  • 캐시(Cache) : 클라이언트가 서버에 한번 요청했던 데이터에 대해서 요청할 때 마다 다시 전송할 필요가 없도록 웹 브라우저가 임시적으로 데이터를 보관하고 있는 장소.

  • GET, HEAD, POST 메소드는 캐시가 가능하기에 재사용을 위해 요청에 대한 응답을 저장할 수 있다.

  • 일반적으로 GET, HEAD 정도만 캐시로 사용한다.

7. HTTP 상태코드

HTTP 요청에 대한 처리 상태를 응답하는 코드로 Data를 함께 응답한다.
Spring에서는 Response를 커스텀하여 의미있는 메세지를 만들어 사용하기도 한다.

  • HTTP Response Message 구조

1) HTTP Status Code (HTTP Response Message의 Start Line 안에 위치)

  • 1xx (정보) : 요청 수신 후 처리중인 상태 (잘사용안함)

  • 2xx (성공)
    - 정상 처리 완료된 상태

    	- 대표 상태코드

    - 200 OK : 요청 성공
    - 201 Created : 새로운 리소스 생성
    - 202 Accepted : 요청이 수신되었으나 처리가 완료되지 않음, 주로 Batch 처리에서 사용된다. (설정한 시간마다 반복적으로 동장하는 특성 작업)
    - 204 No Content : 요청은 성공했지만, 응답 데이터가 없음

  • 3xx (리다이렉션)
    - 요청을 완료하려면 추가 행동이 필요한 상태

    • 3xx 응답 + Location HTTP Header가 있으면 Location 위치로 리다이렉트 한다.

      - 리다이렉션 종류
      - 300은 사용하지 않음
      - 영구 리다이렉션 : URL이 영구적으로 변경 된 경우, 기존 URL을 사용하지 않는다.
      - 301 Moved Permanently

      - 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다.
    • 308 Permanent Redirect

      - 리다이렉트시 요청 메서드와 본문이 유지된다.
    • 일시 리다이렉션
      • URI가 일시적으로 변경 된 경우 (PRG 패턴)
        • PRG(Post, Redirect, Get) 패턴 : 시글 작성(Post) → 응답(Redirect) → 리다이렉트 요청(Get)
        • PRG 패턴을 적용하지 않는다면 새로고침하면 요청이 중복으로 처리 됨.

          - PRG 패턴을 적용하면, 새로고침을 할 시에 GET 요청을 한다.

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

  • 5xx (서버 에러)

profile
김현정
이전 포스트

Kiosk 과제 - Class 구별의 중요성

다음 포스트

Spring Annotation 정리

0개의 댓글