[HTTP] 무상태 프로토콜, HTTP 메시지 구조, HTTP 메서드에 대하여 !

 

HTTP 란 ?

 

- HyperText Transfer Protocol 

- HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML 등을 HTTP 메시지로 전송

: 거의 모든 형태의 데이터 전송 가능하다.

: 서버 간의 데이터 주고받을 때도 사용한다.

 

HTTP 역사

HTTP/1.1 : 가장 많이 사용하는 버전 (RFC 9110 ~ 9112 개정 버전)

(HTTP/2, HTTP/3 은 성능 개선에 초점)

 

특징

- 클라이언트 서버 구조로 동작

- 무상태 프로토콜 지향, 비연결성

- HTTP 메시지 구조로 통신

- 단순함, 확장 가능

 

클라이언트 서버 구조

- Request Response 구조

- 클라이언트와 서버가 분리

 

1. 클라이언트는 서버에 요청을 보내고, 응답을 대기

2. 서버가 요청에 대한 결과를 만들어 응답

클라이언트	1. 요청 >	서버
	< 2. 응답

 

무상태 프로토콜 (Stateless)

Stateful : 상태 정보를 같이 전송하지 않아 기존의 상태 정보를 가지고 있는 서버랑만 통신해야 함

Stateless : 상태 정보를 같이 전송하여 매번 새로운 서버와 통신이 가능함

> Stateless 는 응답 서버를 쉽게 바꿀 수 있어 무한한 서버 증설이 가능, 수평적 확장에 유리

 

한계

최대한 무상태로 설계하고,

로그인 같은 상태 유지는 쿠키와 서버 세션 등을 사용하여 최소한으로 사용한다.

 

비연결성

- 서버와 클라이언트는 요청-응답 후 연결을 닫는 형식

- 초 단위 이하의 빠른 속도로 응답

- 많은 사람이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 매우 작음

- 서버 자원을 매우 효율적으로 사용

 

한계

- TCP/IP 연결을 새로 맺어야 함 (+ 3 way handshake 시간 소요)

- 수 많은 자원이 계속 다운로드 > HTTP 지속 연결(Persistent Connections) 로 해결

 

> 참고 <

- 초기의 HTTP : 하나의 요청을 하나의 연결에서 처리

- HTTP 지속 연결 : 연결을 유지하여 여러 요청을 하나의 연결에서 처리

- HTTP/2, HTTP/3 은 다중 스트림으로 여러 요청을 하나의 연결에서 병렬로 처리하여 성능 최적화가 이뤄짐

  

 

HTTP 메시지 구조

start-line 시작 라인

header 헤더

empty line 공백 라인 (CRLF)

message body

 

공식 스펙

HTTP-message = start-line
               * ( header-field CRLF)
               CRLF
               [ message-body ]

* ( ___ ) : 여러 개

[ ___ ] : 생략 가능

 

시작 라인

- 요청 메시지 : HTTP 메서드 + 요청 대상 + HTTP 버전

  GET /search?q=hello&hl=ko HTTP/1.1 

- 응답 메시지 : HTTP 버전 + HTTP 상태 코드 + 이유 문구

  HTTP/1.1 200 OK  

 

헤더

- 메시지 바디를 제외한 필요한 모든 부가 정보

 

메시지 바디

- 실제 전송할 데이터 (byte 로 표현 가능한 데이터 전송 가능)

 

HTTP 메서드

GET : 리소스 조회

POST : 요청 데이터 처리, 주로 등록에 사용

PUT : 리소스를 대체, 해당 리소스가 없으면 생성

PATCH : 리소스 부분 변경

DELETE : 리소스 삭제

 

> 참고  <

- HEAD : GET 과 동일하지만, 메시지 부분 제외하고 상태 줄과 헤더만 반환

 

GET

- 요청 데이터 조회

클라이언트가 요청 대상에 있는 자원을 요청하면,

서버는 자원을 메시지 바디에 넣어서 클라이언트에게 전달

 

메시지 바디를 허용하지 않는 사이트가 많음

(POST 사용)

 

POST

- 요청 데이터를 처리

클라이언트가 메시지 바디를 통해 데이터를 전달하면,

서버는 요청 데이터를 처리한 후, 자원 생성 경로와 데이터를 클라이언트에게 전달

 

클라이언트가 리소스를 식별할 수 없음

(리소스 위치를 모른 채로 데이터를 전달)

 

사용 경로

1. 서버가 아직 식별하지 않은 새 리소스를 생성

2. 데이터 생성/변경을 넘어 프로세스를 처리하는 경우

(ex. 결제완료 > 배달시작 > 배달완료 같은 프로세스 상태가 변경되는 경우)

3. 다른 메서드로 처리하기 애매한 경우

(GET 메시지 사용하기 어려운 경우)

(PATCH 가 적용되지 않는 서버의 경우)

 

PUT

- 리소스 대체

클라이언트가 리소스 위치와 데이터를 전달하면, 

리소스 있는 경우 > 서버는 요청 데이터를 완전히 대체

리소스 없는 경우 > 서버는 해당 리소스 위치에 요청 데이터를 생성

 

클라이언트가 리소스를 식별

(리소스 위치를 알고 URI 지정)

 

주의점

특정 필드가 존재하지 않아도 기존 리소스를 완전히 삭제 후 대체하기 때문에 주의해야 한다.

 

PATCH

- 리소스 부분 변경

클라이언트가 특정 필드의 데이터를 전달하면,

서버는 특정 필드의 데이터만 변경

 

PATCH가 적용 안되는 서버가 존재한다.

(POST 사용)

 

DELETE

- 리소스 제거

클라이언트가 리소스 위치를 전달하면, 

서버는 해당 리소스 위치의 리소스를 제거

 

HTTP 메서드 속성

- 안전(Safe Methods) : 호출해도 리소스를 변경하지 않는다.

    > ⭕ GET / HEAD

    > ❌ POST / PUT / DELETE / PATCH

- 멱등(Idempotent Methods) : 몇 번을 호출해도 결과가 같다.

    > ⭕ GET / HEAD / PUT / DELETE
    > ❌ POST / PATCH

- 캐시가능(Cacheable Methods) : 응답 결과 리소스를 캐시 해서 사용할 수 있다.

    > ⭕ GET / HEAD / POST / PATCH
    > ❌ PUT / DELETE

    (실제는 GET / HEAD 정도만 캐시로 사용)

 

멱등하는 경우, 자동 복구 메커니즘에 사용할 수 있다.

 

> 참고 <

- 자동 복구 메커니즘은 서버가 정상 응답을 주지 못하였을 때, 클라이언트가 같은 요청을 다시 하는 것

 

 

 

 

 

 

 

 

 

 

출처 | HTTP 웹 기본 지식(김영한) - 인프런