즉, 클라이언트는 리소스를 요청하고, 서버는 해당 요청에 따라 리소스를 제공하거나 결과를 반환한다.
그래서 HTTP 메시지라도 "요청 메시지"와 "응답 메시지"의 형태가 다르다.
미디어 독립적 프로토콜
HTTP 요청 메시지를 통해 서버의 자원을 요청하고, 응답 메시지로 해당 자원을 반환할 수 있다.
여기서 HTTP는 주고받는 자원의 특성을 제한하지 않으며,
단지 자원을 상호 작용하는 데 사용하는 인터페이스를 정의할 뿐이다.
즉, HTTP는 자원의 특성과 무관하게 그저 자원을 주고받을 수단(인터페이스)의 역할만 수행한다.
HTTP에서 메시지로 주고받는 자원의 종류를 "미디어 타입(Media Type)"이라고 부른다.
[ MIME(Multipurpose Internet Mail Extensions) 타입이라고도 부른다. ]
즉, HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 독립적으로 동작이 가능한 프로토콜이다.
미디어 타입(Media Type)은 일종의 확장자같은 개념이다. 일반적으로 파일을 .png, .json, .html, .mp4로 확장자를 나타낼 수 있듯이, HTTP를 통해 송수신하는 정보의 종류는 미디어 타입으로 나타낼 수 있다. 일반적으로 "타입/서브타입" 형식으로 미디어 타입이 구성된다. - 타입 : 데이터의 유형 - 서브타입 : 주어진 타입에 대한 세부 유형 [ image/png는 image타입 중에서 png 타입을 의미한다. ]
추가적으로 미디어 타입에 부가적인 설명을 위해 선택적으로 매개변수가 포함될 수도 있다. "타입/서브타입;매개변수=값" 형식
자원은 URI로 식별된다.
Stateless 프로토콜
HTTP는 상태를 유지하지 않는 프로토콜로
서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 저장하고 있지 않는다는 것이다.
그래서 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주하게 된다.
만약 클라이언트가 특정 HTTP 요청 메시지를 서버에게 여러 번 전송해도
서버는 해당 요청들을 동일한 요청으로 보지 않고 각기 다른 요청으로 간주하여
클라이언트는 같은 응답 메시지를 여러 번 받을 수 있게 된다.
상태를 유지 하지 않는 것은 비효율적으로 보일 수 있지만, 사실 장점이 더 명확하다.
HTTP 서버는 일반적으로 많은 클라이언트와 동시에 상호 작용하는데 만약 동시에 처리해야 하는 요청 메시지가 많아질수록 모든 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담이 된다.
그리고 서버는 하나가 아니라 여러 대로 구성될 수도 있다. 이런 구조라면 모든 서버가 모든 클라이언트의 상태를 유지할 경우 클라이언트는 여러서버를 동시에 이용하기 어려워진다. (모든 서버가 모든 클라이언트의 상태 정보를 공유하는 작업은 복잡하고 번거롭다.)
HTTP가 상태를 유지하는 프로토콜이라면 클라이언트는 자신의 상태를 기억하는 특정 서버하고만 상호 작용할 수 있게 되어, 클라이언트가 특정 서버에 종속될 수 있다. 여기서 만약 특정 서버에 문제가 생기면 해당 서버에 종속된 클라이언트는 여태 HTTP 통신 내역이 없어진다.
지속 연결 프로토콜
HTTP는 계속해서 발전 중인 프로토콜이다.
HTTP/1.0 : 최초 버전으로, 한 연결당 하나의 요청/응답 처리
HTTP/1.1 : 지속 연결과 파이프라이닝 지원
HTTP/2 : 멀티플렉싱을 통해 요청/응답을 병렬로 처리, 헤더 압축 지원
HTTP/3 : QUIC 프로토콜 기반으로 더 빠르고 안정적인 데이터 전송
현대에는 HTTP/1.1과 HTTP/2를 자주 허용한다.
기본적으로 HTTP는 TCP상에서 동작하는데,
HTTP는 "비연결형" 프로토콜이지만, TCP는 '연결형" 프로토콜이다.
그래서 초기 HTTP(1.0 이하) 버전은 3-way 핸드셰이크를 통해 TCP 연결을 수립한 후,
요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작했다.
(추가적인 요청/응답을 하기 위해서는 다시 TCP 연결을 수립해야 함)
이러한 방식을 "비지속 연결"이라고 한다.
HTTP/3.0은 UDP상에서 동작한다.
하지만 HTTP/1.1부터는 "지속 연결"을 제공한다.
다른 표현으로는 "킵 얼라이브(Keep-Alive)"라고도 부른다.
즉, 하나의 TCP 연결상에서 여러 개의 요청/응답을 주고받을 수 있게 된다.
--
HTTP 메시지 구조 (HTTP/1.1 기준)
--
기본적인 HTTP 메시지 구성
시작 라인 (Start-line)
해당 HTTP 메시지가 "요청"인지 "응답"인지에 따라 형식이 다르다.
요청 HTTP 메시지인 경우 "시작 라인"이라고 부르며,
응답 HTTP 메시지인 경우 "상태 라인"이라고 부른다.
요청 HTTP 메시지의 시작 라인
<HTTP 메서드> <요청 대상 경로> <HTTP 버전>
GET /index.html HTTP/1.1
응답 HTTP 메시지의 상태 라인
<HTTP 버전> <상태 코드> <상태 메시지>
HTTP/1.1 200 OK
HTTP 메서드는
클라이언트가 서버의 자원에 대해 수행할 작업의 종류를 의미하며,
대표적으로 GET, POST, PUT, DELETE 등이 존재한다.
요청 대상 경로는
HTTP 요청을 보낼 서버의 자원을 가리키며,
일반적으로 URI 경로가 명시된다.
클라이언트가 "http://www.example.com/index.html"로 요청을 보냈다면 요청 대상은 "/index.html"이 된다. (만약 "http://www.example.com"로 요청을 보냈다면 요청 대상은 "/"이 된다.
HTTP 버전은
말 그대로 사용한 HTTP 버전을 의미한다.
상태 코드는
요청에 대한 결과를 나타내는 3자리 정수로,
해당 상태 코드를 확인한 클라이언트는 해당 요청이 어떻게 처리되었는지 알 수 있다.
상태 메시지는
해당 상태 코드에 대한 문자열 형태로,
상태 코드를 문자열 형태로 간단하게 설명된 메시지다.
필드 라인 (Fild-line) [헤더(header)]
필드 라인에는 0개 이상의 "HTTP 헤더"가 명시된 파트로, "헤더 라인"이라고도 부른다.
HTTP 헤더는 HTTP 통신에 필요한 부가 정보를 의미하고,
콜론(:)을 기준으로 "헤더 이름"과 하나 이상의 "헤더 값"으로 구성된다.
헤더 이름 : 헤더 값
Content-Type: application/json
Host: www.example.com
Content-Type: text/html; charset=UTF-8
메시지 본문 (Message-body)
HTTP 요청/응답 메시지에서 본문이 필요한 경우 명시하는 파트로,
만약 본문이 존재하지 않는다면 해당 파트도 생략된다.
--
HTTP 메서드
--
GET
서버에서 특정 자원(리소스)을 요청할 때 사용한다.
이때 특정 자원을 가리키는 조건(요청 대상)은 URL에 쿼리 문자열로 전달한다.
HEAD
GET 메서드와 동일하지만, 응답 메시지에 본문이 포함되지 않고 헤더만 응답받는다.
POST
서버에 데이터를 전송하거나 자원(리소스)을 생성 등을 수행할 때 사용한다.
즉, 어떠한 작업을 처리하기 위해 사용하며 매우 범용성이 넓은 메서드다.
처리하는 요청 내용은 요청 메시지의 본문(body)에 담아 전달한다.
PUT
서버에 존재하는 자원(리소스)을 새로 갱신하듯이 덮어쓰기를 요청할 때 사용한다.
여기서 만약 서버에 존재하지 않는 자원(리소스)를 덮어쓰기 요청을 하면 새로 생성된다.
여기서도 요청 내용은 본문(body)에 담아서 전달한다.
PATCH
PUT 메서드와 달리 서버에 존재하는 기존 자원(리소스)을 덮어쓰는 게 아니라 일부 수정할 때 사용한다.
