MDN wants to talk to developers like you: https://qsurvey.mozilla.com/s3/8d22564490d8

HTTP 메시지

HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식입니다. 메시지에는 두 가지 타입이 존재합니다: request는 클라이언트에 의해 전달되어 서버의 동작을 일으키는 것이고, response는 그에 대한 서버의 회신입니다.

HTTP 메시지는 ASCII로 인코딩된 텍스트 정보로 구성되며, 여러 줄에 걸쳐 만들어집니다. HTTP/1.1과 프로토콜 초기 버전에서, 이 메시지들은 연결을 통해 직접 전달되었습니다. HTTP/2에서는 최적화와 더 나은 성능을 이끌어내도록 인간이 읽을 수 있는 메시지가  HTTP 프레임으로 나누어집니다.

웹 개발자 혹은 웹 마스터가 직접 텍스트로 이루어진 HTTP 메시지를 만들어내는 경우는 드뭅니다: 그것은 소프트웨어, 브라우저, 프록시, 혹은 웹 서버의 몫입니다. 그들은 설정 파일(프록시 혹은 서버의 경우), API(브라우저의 경우), 혹은 다른 인터페이스를 통해 그것을 제어합니다.

From a user-, script-, or server- generated event, an HTTP/1.x msg is generated, and if HTTP/2 is in use, it is binary framed into an HTTP/2 stream, then sent.

HTTP/2 이진 프레임 구성 메커니즘이 고안되었는데 사용 중인 API나 설정 파일의 변경을 요구하지 않도록 설계되었습니다: 이는 사용자에게 있어 대부분 명확합니다.

HTTP 요청과 응답은 유사한 구조를 공유하며 다음과 같이 구성됩니다:

  1. 시작 줄에는 실행해야 할 요청 혹은 요청에 대한 성공 혹은 실패를 나타내는 상태를 기술합니다. 시작 줄은 항상 한 줄로 이루어집니다.
  2. 요청을 특정하거나 메시지 내 포함되는 본문을 부연 설명하는 선택적 HTTP 헤더의 집합입니다.
  3. 요청에 대한 모든 메타 정보가 전송되었음을 가리키는 빈 줄.
  4. 요청과 연관된 (HTML 폼의 내용과 같은) 데이터 혹은 응답과 연관된 문서를 포함하는 선택적 본문입니다. 본문의 존재 여부와 그것의 크기는 시작 줄과 HTTP 헤더에 의해 정의됩니다.

HTTP 메시지의 시작 줄과 HTTP 헤더는 총체적으로 요청의 head(헤드)라고 알려져 있으며, 페이로드는 반대로 body(본문)라고 불립니다.

Requests and responses share a common structure in HTTP

HTTP 요청

시작 줄

HTTP 요청은 서버 상의 동작을 일으키기 위해 클라이언트가 전송하는 메시지입니다. 시작 줄은 다음의 세 가지 요소를 포함합니다:

  1. 첫번째는 HTTP 메서드, (GET, PUT 혹은 POST와 같은) 동사형 혹은 (HEAD 혹은 OPTIONS와 같은)  명사형이 있으며, 수행되어야 할 동작을 설명합니다. 예를 들어, GET은 하나의 리소스를 불러와야 한다는 것을 가리키며, POST는 데이터가 서버로 들어가야 함(리소스가 생성 혹은 수정되거나, 회신되어야 하는 임시 문서를 만드는 동작 등)을 의미합니다.
  2. 보통 URL 혹은 프로토콜, 포트 그리고 도메인의 절대 경로라고 하는 request target(요청 대상)은 일반적으로 요청 컨텍스트에 의해 특징지어진다. 이 요청 대상의 포맷은 서로 다른 HTTP 메서드마다 다릅니다. 다음과 같을 수 있습니다
    • 절대 경로로 뒤에 '?'과 쿼리 문자열이 올 수도 있습니다. 이것이 가장 일반적인 폼으로 origin form이라고 불리며, GET, POST, HEAD 그리고 OPTIONS 메서드들과 함께 사용됩니다.
      POST / HTTP 1.1
      GET /background.png HTTP/1.0
      HEAD /test.html?query=alibaba HTTP/1.1
      OPTIONS /anypage.html HTTP/1.0
    • 완전한 URL이고, absolute form이라고 알려져 있으며, 대부분 프록시에 연결하는 경우 GET과 함께 사용됩니다.
      GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
    • 도메인 이름과 (':'가 앞에 붙은) 선택적으로 포트가 붙는 URL의 권한 컴포넌트로 authority form이라 부릅니다. HTTP 터널을 구축하는 경우에만 CONNECT와 함께 사용됩니다.
      CONNECT developer.mozilla.org:80 HTTP/1.1
    • asterisk form이라 불리며, OPTIONS와 함께 사용되는 간단한 asterisk ('*')로 서버 전체를 나타냅니다.
      OPTIONS * HTTP/1.1
  3. 마지막으로 HTTP 버전이 오는데, 메시지의 나머지 부분의 구조를 정의하며, 응답에 사용될 버전 표시자 역할을 합니다.

헤더

요청의 HTTP 헤더는 모든 HTTP 헤더의 기본 구조를 따릅니다: 뒤에 콜론(':')이 오는 대소문자 구분없는 문자열 다음에 구조가 헤더에 종속적인 값으로 이루어집니다. 값을 포함하는 전체 헤더는 상당히 길 수도 있는 단일 줄로 구성됩니다.

많은 요청 헤더를 이용할 수 있습니다. 요청 헤더들은 몇 가지 그룹으로 나누어집니다:

  • Via와 같은 일반적인 헤더들은 메시지 전체에 적용됩니다.
  • User-Agent, Accept-Type와 같은 요청 헤더들은 (Accept-Language처럼) 좀 더 특정짓고, (Referer처럼) 컨텍스트를 제공하며, (If-None처럼) 조건에 따라 제한함으로써 요청을 수정합니다.
  • Content-Length와 같은 엔티티 헤더들은 요청의 본문에 적용됩니다. 요청 내에 본문이 없는 경우 말할 필요도 없이 그런 헤더 또한 전송되지 않습니다.

Example of headers in an HTTP request

본문

요청의 마지막 부분은 본문입니다. 모든 요청들이 본문을 가지는 건 아닙니다: GET, HEAD, DELETE 또는 OPTIONS와 같이, 리소스를 가져오는 요청들은 일반적으로 본문을 필요로 하지 않습니다. 어떤 요청들은 리소스를 갱신하기 위한 목적으로 데이터를 전송합니다: 이것은 대게 (HTML 폼 데이터를 포함하는) POST 요청일 경우에 그렇습니다.

본문은 넓은 의미에서 두 개의 종류로 나눠집니다:

  • 두 개의 헤더(Content-Type와 Content-Length)로 정의되는, 단일 파일을 구성하는 단일 리소스 본문.
  • 멀티파트 본문으로 구성되는 다중 리소스 본문은 각자가 정보의 서로 다른 부분을 포함합니다. 이것은 일반적으로 HTML 폼과 연계되어 사용됩니다.

HTTP 응답

상태 줄

상태 줄이라고 불리는, HTTP 응답의 시작 줄은 다음의 정보들을 포함합니다:

  1. 프로토콜 버전, 일반적으로 HTTP/1.1.
  2. 요청의 성공 혹은 실패를 가리키는 상태 코드. 일반적인 상태 코드는 200, 404 혹은 302입니다.
  3. 순수하게 정보를 제공하는 차원의 상태 텍스트로 상태 코드에 대한 텍스트로 된 짧은 설명으로, HTTP 메시지를 인간이 이해하는데 도움을 줍니다.

전형적인 상태 줄은 다음과 같이 보입니다: HTTP/1.1 404 Not Found.

헤더

응답을 위한 HTTP 헤더는 다른 헤더와 동일한 구조를 따릅니다: 뒤에 콜론(':')이 오는 대소문자를 구분하지 않는 문자열 다음에  구조가 헤더에 종속적인 값으로 이루어집니다. 값을 포함하여, 전체 헤더는 단일 줄로 표시됩니다.

이용 가능한 많은 요청 헤더들이 있습니다. 그들은 몇 가지 그룹으로 나누어질 수 있습니다:

  • Via와 같은 일반적인 헤더는 전체 메시지에 적용됩니다.
  • Vary와 Accept-Ranges와 같은 응답 헤더들은 상태 줄에서 설명하지 못했던 서버에 관한 추가적인 정보들을 제공합니다.
  • Content-Length와 같은 엔티티 헤더들은 요청의 본문에 적용됩니다. 요청 내에 본문이 없는 경우 말할 필요도 없이 헤더 또한 전송되지 않습니다.

Example of headers in an HTTP response

본문

응답의 마지막 부분은 본문입니다. 모든 응답이 본문을 갖진 않습니다: 201 혹은 204와 같은 상태 코드를 갖는 응답에는 일반적으로 아무것도 없습니다.

본문은 넓은 의미에서 세 가지 종류로 나누어질 수 있습니다:

  • 길이를 알고 있는 단일 파일로 구성된 단일 리소스 본문은 두 개의 헤더(Content-Type와 Content-Length)에 의해 정의됩니다.
  • 길이를 알지 못하는 단일 파일로 구성된 단일 리소스 본문은 여러 부분으로 나누기 위해 설정된 Transfer-Encoding를 이용해 청크별로 인코딩됩니다.
  • 멀티파트 본문으로 구성되는 다중 리소스 본문는 각자가 서로 다른 정보를 포함합니다. 이런 경우는 매우 희귀합니다.

HTTP/2 프레임

HTTP/1.x 메시지는 성능 상 몇 가지 결함을 가지고 있습니다:

  • 본문과 달리 헤더는 압축되지 않습니다.
  • 헤더는 어떤 메시지 그리고 그 다음의 메시지 간에 매우 유사하기 마련인데, 그것들이 전송마다 반복됩니다.
  • 다중전송이 불가능합니다. 여러 연결을 동일한 서버에서 열어야 합니다: 활발한 TCP 연결이 한가한 TCP 연결보다 효율적입니다.

HTTP/2은 특별한 단계를 도입했습니다: HTTP/1.x 메시지를 스트림에 포함된 프레임으로 나누는 것입니다. 데이터와 헤더 프레임이 구별되어 헤더 압축이 가능합니다. 몇 개의 스트림들이 함께 묶일 수 있으며, 그러한 처리 과정을 멀티플렉싱이라고 부르는데, 내재된 TCP 연결을 좀 더 효율적으로 만들어줍니다.

HTTP/2 modify the HTTP message to divide them in frames (part of a single stream), allowing for more optimization.

HTTP 프레임은 웹 개발자들에게 있어 명백합니다. HTTP/1.1 메시지와 기본 전송 프로토콜 사이의 특별한 단계입니다. 웹 개발자가 사용하는 API에는 변경이 필요없습니다; 브라우저와 서버에서 이용 가능해지면, HTTP/2가 활성화되어 사용됩니다.

결론

HTTP 메시는 HTTP 사용의 핵심 요소입니다; 그 구조는 단순하며 확장성이 좋습니다. HTTP/2 프레임 구성  메커니즘은 HTTP/1.x 구문과 기본 전송 프로토콜 사이에 새로운 중간 레이어를 추가했는데, 기본적으로 메시지 구문을 수정하지는 않습니다: 메시지는 기존의 입증된 메커니즘으로 만들어집니다.

문서 태그 및 공헌자

 이 페이지의 공헌자: devcken
 최종 변경: devcken,