즉, 클라이언트는 리소스를 요청하고, 서버는 해당 요청에 따라 리소스를 제공하거나 결과를 반환한다.
그래서 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 연결을 수립한 후,
즉, 클라이언트는 리소스를 요청하고, 서버는 해당 요청에 따라 리소스를 제공하거나 결과를 반환한다.
그래서 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 연결을 수립한 후,