HTTP 메시지

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

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

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

HTTP/2 이진 프레이밍 메커니즘이 고안되었는데 사용 중인 API나 설정 파일에 대한 어떠한 수정도 필요로 하지 않습니다: 그것은 장비를 제어하는 사용자에게 있어 대부분 명확합니다.

HTTP 요청과 응답 모두 동일한 구조를 공유하며 다음과 같이 구성됩니다:

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

시작 줄과 HTTP 헤더는 요청의 head라고 부리며, 페이로드는 반대로 body라고 불립니다.

HTTP 요청

시작 줄

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

1. 첫번째는 HTTP 메서드로, (GET, PUT 혹은 POST와 같은) 동사형 혹은 (HEAD 혹은 OPTIONS와 같은)  명사형이 있으며, 수행되어야 할 동작을 설명합니다. 예를 들어, GET은 하나의 리소스를 불러와야 한다는 것을 가리키며, POST는 데이터가 서버로 들어가야 함(리소스가 생성 혹은 수정되거나, 회신되어야 하는 임시 문서를 만드는 동작 등)을 의미합니다.
2. 다음은 요청 대상으로, 일반적으로 URL이거나 , or only the absolute path part of it as the protocol, port, and domain are defined by the context most of the time. 이 요청 대상의 포맷은 서로 다른 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 https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
   • 도메인 이름과 (':'가 앞에 붙은) 부가적인 포트로 이루어진 URL의 authority 컴포넌트로 authority form이라 부릅니다. HTTP 터널을 구축하는 경우에만 사용됩니다.
     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와 같은 엔티티 헤더들은 요청의 몸체에 적용됩니다. 요청 내에 본문이 없는 경우 말할 필요도 없이 헤더 또한 전송되지 않습니다.

본문

요청의 마지막 부분은 본문입니다. 모든 요청들이 본문을 가지는 건 아닙니다: GET 혹은 HEAD와 같이, 리소스를 가져오는 요청들은 일반적으로 본문을 필요로 하지 않으며, DELETE나 OPTION도 마찬가지입니다. 어떤 요청들은 서버(의 리소스)를 갱신하기 위한 목적으로 데이터를 전송합니다: 이것은 대게 (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와 같은 엔티티 헤더들은 요청의 본문에 적용됩니다. 요청 내에 본문이 없는 경우 말할 필요도 없이 헤더 또한 전송되지 않습니다.

본문

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

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

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

HTTP/2 프레임

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

• 본문과 달리 헤더는 압축되지 않습니다.
• 헤더는 어떤 메시지 그리고 그 다음의 메시지 간에 매우 유사하기 마련인데, 그것들이 전송마다 반복됩니다.
• 다중전송이 불가능합니다. 몇 개의 커넥션들이 동일한 서버에 대해 열립니다: 활발한 TCP 커넥션이 한가한 TCP 커넥션보다 성능 상으로 이득입니다.

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

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

결론

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