03. Http Message

3. HTTP Message

1. 메세지의 흐름

HTTP 메세지는 HTTP 어플리케이션 간에 주고받은 데이터 블록들이다. 이 데이터 블록들은 메세지 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고, 그 뒤에 선택적으로 데이터가 올 수 있다. 이 메세지는 클라이언트, 서버, 프록시, 게이트웨이 사이에서 움직인다.

3.1 인바운드와 아웃바운드

HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다. 메세지가 원 서버로 이동하는 것은 인바운드, 사용자 에이전트에게 돌아오는 것은 아웃바운드로 이동하는 것이다.

3.2 다운스트림과 업스트림

요청 메세지냐 응답 메세지이냐와 무관하게, 모든 메세지는 업스트림에서 다운스트림으로 흐른다. 요청 시에는 클라이언트가 업스트림, 서버가 다운스트림이지만 응답시에는 서버가 업스트림, 클라이언트가 다운스트림이다.

2. 메세지의 각 부분

메세지는 시작줄, 헤더, 본문의 세 부분으로 구성된다.

시작줄은 이것이 어떤 메세지인지 서술하며, 헤더 블록은 속성을, 본문은 데이터를 담고 있다. 본문은 비어 있을 수도 있다.

본문은 데이터 덩어리이다. 시작줄과 헤더와는 달리 텍스트나 이진 데이터를 포함할 수도 있고, 그냥 비어있을 수도 있다.

2.1 메세지 문법

모든 HTTP 메세지는 요청 메세지와 응답 메세지로 분류할 수 있다. 요청 메세지는 웹 서버에 어떠한 동작을 요구하고, 서버는 응답 메세지에 요청의 결과를 담아 보낸다. 두 메세지의 구조는 다음과 같다.

요청 메세지

<메서드> <요청 URL> <버전>
<헤더>
<엔티티 본문>

응답 메세지

<버전> <상태 코드> <사유 구절>
<헤더>
<엔티티 본문>

각 부분들에 대한 설명은 아래와 같다.

메서드

클라이언트 측에서 서버가 리소스에 대해서 수행해주기를 바라는 동작. GET, HEAD, POST 와 같이 되어있다.

요청 URL

요청 대상이 되는 리소스를 지칭하는 URL(혹은 URL의 경로 구성요소).

버전

메세지에서 사용 중인 HTTP의 버전. 형식은 HTTP/<메이저>.<마이너> 와 같이 표현한다. (HTTP/1.1)

상태 코드

요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자. 첫 번째 자리수는 일반적인 분류를 나타낸다. (‘성공’, ‘에러’ 등)

사유 구절

숫자로 된 상태 코드의 의미를 사람이 쉽게 이해할 수 있도록 해주는 짧은 문구. 사유 구절은 오로지 사람에게 읽히기 위한 목적이므로, HTTP/1.0 200 NOT OK와 HTTP/1.0 200 OK는 사유 구절이 다름에도 불구하고 동등하게 성공을 의미하는 것으로 처리되어야 한다.

헤더들

헤더의 목록은 빈 줄(CRLF)로 끝나 헤더의 목록의 끝과 엔터티 본문의 시작을 표시한다. HTTP/1.1과 같은 몇몇 버전의 HTTP는 요청/응답에 특정한 헤더가 포함되어야만 유효한 것으로 간주한다.

엔티티 본문

엔티티 본문은 선택적으로 데이터 블록을 포함한다. 본문이 없는 메세지는 그냥 CRLF로 끝나게 된다. 헤더나 엔티티 본문이 없어도, HTTP 헤더 집합은 항상 빈 줄(CSRF)로 끝나야 한다.

2.2 시작줄

모든 HTTP 메세지는 시작줄로 시작한다. 요청 메세지의 시작줄은 무엇을 해야하는지, 응답 메세지의 시작줄은 무슨 일이 (서버에서) 일어났는지를 말해준다.

요청 메세지의 시작줄

요청 메세지는 서버에 무엇인가를 요청한다. 요청 메세지의 시작줄에는 대상(무엇을)과 메서드(어떻게)가 담겨있다. 또한, 클라이언트가 현재 어떤 HTTP 버전으로 말하고 있는지도 포함한다. 이 모든 필드는 공백으로 구분한다. 아래 예시를 보면, 무엇을, 어떻게 처리해 달라는 것인지와 현재 클라이언트가 사용하고 있는 HTTP 버전 정보를 알 수 있다.

GET /test/hello.txt HTTP/1.1

응답 메세지의 시작줄

응답 메세지는 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에 돌려준다. 이때, 응답 메세지의 시작줄에는 응답 메세지의 HTTP 버전과 응답의 상태 코드, 사유 구절이 들어가있다. 아래 예시를 보자.

HTTP/1.0 200 OK

메서드

요청의 시작줄은 메서드로 시작한다. 서버에게 어떤 행동을 기대하는지 말해준다. 아래 일곱 가지 메서드가 대표적이다.

HTTP 메서드	설명
GET	서버로부터 리소스를 조회/요청
POST	서버에 데이터를 보내 처리 요청
PUT	서버의 리소스를 저장/수정
DELETE	서버의 특정 리소스를 삭제
HEAD	GET과 동일하지만 응답 본문 없이 헤더만 요청
OPTIONS	해당 리소스가 지원하는 HTTP 메서드 확인
TRACE	메세지가 프록시를 거쳐가는 과정을 추적

상태 코드와 사유 구절

서버는 상태 코드를 통해 수행한 결과를 클라이언트에게 알려준다. 크게 다섯 가지로 구분할 수 있다.

상태 코드	범위	분류
1xx	100-101	정보 응답
2xx	200-206	성공 응답
3xx	300-305	리다이렉션
4xx	400-415	클라이언트 오류
5xx	500-505	서버 오류

사유 구절은 해당 상태 코드와 일대일 매핑되는 것으로, 사람이 이해하기 쉽게 자연어로 작성된 것을 말한다.

버전 정보

버전 정보는 서버나 클라이언트가 처리할 수 있는 가장 높은 단계의 HTTP 프로토콜을 의미한다. 해당 메세지의 HTTP 프로토콜이 아니다. 해당 버전 정보를 동봉함으로써, 메세지를 받은 상대방이 프로토콜에 맞추어 응답을 보내기를 기대할 수 있다.

2.3 헤더

헤더는 시작줄 다음에 오는 n개의 Key-Value 값이다. 클라이언트나 서버의 상태, 혹은 메세지의 정보를 표현하는데 사용된다. 크게 다섯 가지로 구분할 수 있다.

일반 헤더

요청 메세지와 응답 메세지 모두가 사용하는 헤더. 아래 예시는 메세지가 만들어진 일시를 표현한다.

Date: Tue, 3 Oct 1974 02:16:00 GMT

헤더	설명
Connection	클라이언트와 서버가 연결에 대한 옵션을 정할 수 있게 해준다
Date	HTTP 메시지가 만들어진 날짜와 시간
MIME-Version	발송자가 사용한 MIME 버전
Trailer chunked transfer	인코딩으로 인코딩된 메시지의 끝 부분에 있는 헤더 목록
Transfer-Encoding	수신자에게 안전한 전송을 위해 메시지에 적용된 인코딩 안내
Upgrade	발송자가 업그레이드하길 원하는 새 버전이나 프로토콜
Via	이 메시지가 지나간 중간 노드(프록시, 게이트웨이)들을 나열
Cache-Control	메세지와 함께 캐시 관련 지시자 전달

Cache-Control은 HTTP 통신에서 캐싱을 제어하는 헤더이다. 이 헤더를 통해 클라이언트와 서버는 캐시 사용 여부, 캐시 유효 기간, 그리고 캐싱된 데이터의 유효성 검증 방식을 설정할 수 있다. 서버 측면에서는 불필요한 요청 처리로 인한 부하를 크게 줄일 수 있고, 클라이언트 측면에서는 이미 받은 데이터를 재사용함으로써 중복 요청을 방지할 수 있다.

요청 헤더

요청 메세지를 위한 헤더. 서버에게 클라이언트의 상황을 설명하는데 사용된다. 요청이 최초 발생한 곳에서 누가, 혹은 무엇이 그 요청을 보냈는지에 대한 정보나 클라이언트의 선호나 능력에 대한 정보를 준다. Accept 관련 헤더는 클라이언트의 선호나 능력을 표현한다.

아래 예시는 모든 미디어 타입을 받아들일 것임을 의미한다.

Accept: */*

헤더	설명
Accept	클라이언트가 처리할 수 있는 미디어 타입(MIME 타입) 지정
Accept-Charset	클라이언트가 이해할 수 있는 문자 인코딩 방식 명시
Accept-Encoding	클라이언트가 지원하는 압축 인코딩 방식 지정
Accept-Language	클라이언트가 선호하는 언어 설정
TE(Transfet-Encoding)	클라이언트가 받아들일 수 있는 전송 인코딩 방식 지정

응답 헤더

응답 메세지를 위한 헤더. 클라이언트에게 서버의 상황을 설명하는데 사용된다. 아래 예시는 현재 클라이언트가 소통하고 있는 서버의 버전을 명시한다.

Server: Tiki-Hut/1.0

엔티티 헤더

엔티티 본문에 대한 헤더. 아래 예시는 데이터가 iso-latin-1 문자 집합으로 된 HTML 문서임을 알려준다.

Content-Type: text/html; charset=iso-latin-1

확장 헤더

확장 헤더는 어플리케이션 개발자들에 의해 만들어졌으나, 아직 승인되지는 않은 비표준 헤더이다. HTTP 프로그램은 해당 헤더가 무슨 의미인지 몰라도, 전달해야 한다.