HTTP Messages

프론트엔드/HTTP - 후

HTTP Messages

5ub1n 2024. 10. 13. 14:40

HTTP 메시지

HTTP 메시지는 서버와 클라이언트 사이에서 데이터가 교환되는 방식이다.

메시지에는 두 가지 유형이 있다.

클라이언트가 서버에서 작업을 트리거하기 위해 보낸 요청과 서버의 답변인 응답이다.

웹 개발자 또는 웹마스터가 이러한 텍스트 HTTP 메시지를 직접 만드는 경우는 드물다.

소프트웨어, 웹 브라우저, 프록시 또는 웹 서버가 이 작업을 수행한다.

이들은 구성 파일(프록시 또는 서버용), API(브라우저용) 또는 기타 인터페이스를 통해 HTTP 메시지를 제공한다.

HTTP 요청과 응답은 유사한 구조를 공유하며 다음으로 구성된다.

구현해야 할 요청을 설명하거나 성공, 실패 여부에 대한 상태를 설명하는 시작 줄이다.
항상 단일 라인이다.
요청을 정확히 정의하거나 메시지에 포함된 본문을 설명하는 HTTP 헤더의 선택적 집합이다.
요청에 대한 모든 메타 정보가 전송되었음을 나타내는 빈 줄이 전송되었다.
요청과 관련된 데이터를 포함하는 선택적 본문(HTML 양식의 내용과 동일하다.) 또는 응답과 관련된 문서다.
본문의 존재 여부와 크기는 시작 줄과 HTTP 헤더를 통해 지정된다.

HTTP 메시지의 시작 줄과 HTTP 헤더는 집합적으로 요청 헤드라고 하며, 페이로드는 본문이라고 한다.

HTTP 요청 HTTP Requests

요청 줄 Request line

참고 : 요청에서는 시작 줄을 "요청 줄"이라고 한다.

HTTP 요청은 클라이언트가 서버에서 작업을 시작하기 위해 보내는 메시지다.

그들의 요청 줄에는 세 가지 요소가 들어있다.

수행할 작업을 설명하는 HTTP 메서드, 동사(GET, PUT, POST) 또는 명사(HEAD, OPTION)다.
예를 들어, GET은 리소스를 가져와야 함을 나타내고 POST는 데이터가 서버로 푸시됨을 의미한다.(리소스를 생성, 수정하거나 다시 보낼 임시 문서를 생성한다.)
요청되는 대상(요청의 목적지가 되는 자원이나 리소스)은 일반적으로 URL, 프로토콜, 포트 및 도메인의 절대경로로 구성되며, 이는 보통 요청 컨텍스트에 의해 특정지어진다.
이러한 요청 대상이 어떻게 표현될지(형식)는 HTTP 메서드에 따라 달라질 수 있다.
다음과 같은 형식일 수 있다.

a. 절대 경로 뒤에 '?' 및 쿼리 문자열이 오는 형식이다.
이 형식은 GET, POST, HEAD, OPTIONS 메서드에서 사용되며 이를 원본(origin) 형식이라고 한다.
예시 :
POST / HTTP/1.1 (데이터를 제출하여 처리하도록 요청하는 데 사용되고 제출할 데이터가 본문에 포함된다..)
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0

b. 절대 형식이라고도 하는 완전한 URL은 프록시에 연결될 때 주로 GET과 함께 사용된다.
GET https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1

c. 도메인 이름과 선택적으로 포트(접두사 ':')로 구성된 URL의 권한 구성 요소를 권한 형식이라고 한다.
이는 HTTP 터널을 설정할 때, CONNECT 메서드와 함께 사용된다.
CONNECT developer.mozilla.org:80 HTTP/1.1

d. 별표 형식인 간단한 별표는 OPTIONS와 함께 사용되어 서버 전체를 나타낸다.
서버의 기능을 확인하고, 어떤 HTTP 메서드를 원하는지 알아보기 위한 요청이다.
이 요청에는 보통 본문이 없다.
OPTIONS * HTTP/1.1
HTTP 버전은 나머지 메시지의 구조(세 가지 요소 중 마지막)를 정의하며, 응답에 사용할 예상 버전의 지표 역할을 한다.

헤더 Headers

요청의 HTTP 헤더는 HTTP 헤더의 기본 구조를 따른다.

대소문자를 구분하지 않는 문자열 뒤에 콜론(':')과 헤더(헤더 이름)에 따라 구조가 달라지는 값이 뒤따라온다.

전체 헤더는 값까지 포함하여 하나의 단일 줄로 구성되며, 이 줄은 상당히 길 수 있다.

요청에는 다양한 헤더가 나타날 수 있다.

Via와 같은 일반 헤더는 메시지 전체에 적용된다.
User-Agent 또는 Accept와 같은 요청 헤더는 Accept-Language와 같이 추가로 지정하거나, Referer와 같이 컨텍스트를 제공하거나, If-None-Match 와 같이 조건부로 제한하여 요청을 구정한다.
Content-Type과 같은 표현 헤더는 메시지 데이터의 원래 형식과 적용된 인코딩을 설명한다.(메시지에 본문이 있는 경우에만 표시된다.)

본문 Body

요청의 마지막 부분은 본문이다.

모든 요청에 본문이 있는 것은 아니다.

GET 또는 HEAD와 같은 리소스를 가져오는 요청은 일반적으로 본문이 필요하지 않다.

PUT 또는 POST 요청과 같이 리소스를 생성하기 위해 데이터를 서버에 보내는 요청에는 일반적으로 요청을 이행하는 데 사용되는 데이터가 포함된 본문이 필요하다.(예 : HTML 양식 데이터)

본문은 대체로 두 가지 범주로 나눌 수 있다.

단일 파일로 구성되고 Content-Type과 Content-Length라는 두 개의 헤더로 정의되는 단일 리소스 본문
다중 리소스 본문은 여러 부분으로 구성된 본문으로, 각각 다른 정보 비트를 포함한다.
이는 일반적으로 HTML 양식과 관련이 있다.

HTTP 응답 HTTP Responses

상태 줄 Status line

참고 : 응답에서는 시작 줄을 "상태 줄"이라고 한다.

HTTP 응답의 시작 줄을 상태 줄이라고 하며 다음 정보를 포함한다.

프로토콜 버전은 일반적으로 HTTP/1.1이지만 HTTP/1.0일 수도 있다.
요청의 성공 또는 실패를 나타내는 상태 코드다.
일반적인 상태 코드는 200, 404 또는 302다.
HTTP 메시지를 사람이 이해하도록 돕는 상태 코드에 대한 간략하고 순전히 정보적인 텍스트 설명인 상태 텍스트다.

일반적인 상태 줄은 다음과 같다 : HTTP/1.1 404 Not Found

헤더 Headers

응답을 위한 HTTP 헤더는 다른 헤더와 동일한 구조를 따른다.

대소문자를 구분하지 않는 문자열 뒤에 콜론(':')과 헤더 유형에 따라 구조가 달라지는 값이 뒤따라온다.

전체 헤더는 값까지 포함하여 하나의 단일 줄로 구성되며, 이 줄은 상당히 길 수 있다.

응답에는 다양한 헤더가 나타날 수 있다.

이러한 것들은 여러 그룹으로 나눌 수 있다.

Via와 같은 일반 헤더는 전체 메시지에 적용된다.
Vary와 Accept-Ranges와 같은 응답 헤더는 상태 줄에 들어가지 않는 서버에 대한 추가 정보를 제공한다.
Content-Type과 같은 같은 표현 헤더는 메시지 데이터의 원래 형식과 정용된 인코딩을 설명한다.(메시지에 본문이 있는 경우에만 존재한다.)

본문 Body

응답의 마지막 부분은 본문이다.

모든 응답에 본문이 있는 것은 아니다.

해당 페이로드가 필요 없이, 요청에 충분히 응답하는 상태 코드가 있는 응답(예 : 201 Created 또는 204 No Content)은 일반적으로 본문이 없다.

본문은 크게 세 가지 범주로 나눌 수 있다.

두 개의 헤더(Content-Type, Content-Length)로 정의되고 알려진 길이의 단일 파일로 구성된 단일 리소스 본문이다.
단일 리소스 본문은 알려지지 않은 길이의 단일 파일로 구성되며, Transfer-Encoding을 Chunked로 설정하여 청크로 인코딩된다.
다중 리소스 본문은 여러 부분으로 구성되어 있으며 각각 다른 정보 섹션을 포함하는 본문이다.
이런 경우는 비교적 드물다.

HTTP/2 프레임 HTTP/2 Frames

HTTP/1.x 메시지는 성능에 있어 몇 가지 단점이 있다.

헤더는 본문과 달리 압축되지 않는다.
헤더는 한 메시지에서 다음 메시지까지 매우 유사한 경우가 많지만, 여전히 연결을 통해 반복적으로 헤더가 전송된다.
HTTP/1.1에는 파이프라이닝이 있지만 대부분 브라우저에서 기본적으로 활성화되지 않으며 멀티플렉싱을 허용하지 않는다.(즉, 요청을 동시에 보내는 것을 허용하지 않는다.)
요청을 동시에 보내려면 동일한 서버에서 여러 개의 연결을 열어야 한다.
또한, warm TCP 연결은 cold TCp 연결보다 효율적이다.

HTTP/2에서는 추가 단계가 도입되었다.

HTTP/1.x 메시지를 스트림에 포함된 프레임으로 나눈다.

데이터 프레임과 헤더 프레임이 분리되어 헤더 압축이 가능하다.

여러 스트림을 결합하는 과정을 멀티플렉싱이라고 하는데, 이를 통해 기본 TCP 연결을 보다 효율적으로 사용할 수 있다.

이제 HTTP 프레임은 웹 개발자에게 투명해졌다.

이는 HTTP/1.1 메시지와 기본 전송 프로토콜 사이의 HTTP/2의 추가 단계다.

HTTP 프레임을 활용하기 위해 웹 개발자가 사용하는 API는 변경이 필요하지 않다.

대신, HTTP/2가 브라우저와 서버 모두에서 사용 가능한 경우에는 자동으로 HTTP/2가 켜지고 사용된다.

결론 Conclusion

구조가 간단하고 확장성이 매우 뛰어난 HTTP 메시지는 HTTP 사용의 핵심이다.

HTTP/2 프레이밍 메커니즘은 HTTP/1.x 구문과 기본 전송 프로토콜 사이에 새로운 중간 계층을 추가하지만, 근본적으로 수정하지는 않는다.

입증된 메커니즘을 기반으로 구축한다.

HTTP Messages - HTTP | MDN

HTTP messages are how data is exchanged between a server and a client. There are two types of messages: requests sent by the client to trigger an action on the server, and responses, the answer from the server.

developer.mozilla.org