HTTP 메세지 - 개요

HTTP 메서지에 대해서 알아본다. 메세지는 세 덩어리로 나눌 수 있다 시작줄, 헤더, 본문. 시작줄은 요청과 응답에 따라 다르다. 요청의 시작줄에는 서버에 요구할 동작을 명시하는 메서드, 리소스의 위치를 알려줄 URL, 프로토콜 버전을 명시한다. 응답의 시작줄에는 버전과 처리 결과에 대한 상태코드, 사유구절이 명시되어있다. 다음 줄에는 헤더가 존재한다. 헤더는 일반헤더, 요청헤더, 응답헤더, 확장헤더, entity헤더로 구분할 수 있다. RFC 7231에서는 요청 헤더와 응답 헤더로 나눠서 설명한다. 헤더와 본문 사이에는 꼭 한 줄을 비워두어야한다.(CRLF) 본문은 옵셔널하다. 있을 때도 있고 없을 때도 있다. 메세지의 흐름을 설명하는 용어가 존재하는데, 상대적으로 표현된다. 서버를 기준으로 외부 클라에서 서버로(안으로) 흐르는 메세지를 인바운드, 서버에서 클라로(밖으로) 나가는 메세지를 아웃바운드라고 하며, 발신자를 기준으로 발신자에서 수신자의 방향을 다운스트림, 그 반대를 업스트림이라고 한다.

---

1. 메세지의 흐름

HTTP 메세지는 HTTP 메세지 간에 주고받은 데이터의 블록들이다

• 데이터의 블록
  • 텍스트 메타 정보: 메세지의 내용과 의미를 설명
  • 클라이언트 서버, 프락시 사이를 흐름
  • 메세지의 방향을 의미하는 용어
    인바운드 / 아웃바인드 / 업스트림 / 다운스트림

1.1 인바운드 - 아웃바운드

• HTTP는 인바운드와 아웃바인드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다.
• 흐름 표현은 상대적인 표현방식으로, 인바운드와 아웃바인드는 서버를 기준으로
  클라에서 ⇒ 서버로의 안 쪽 흐름을 인바운드
  서버에서 ⇒ 클라 방향으로의 흐름을 아웃바운드 라고 한다.
• 인바운드로 이동 / 아웃바운드로 이동

1.2 업스트림 - 다운스트림

• 요청/응답 이라는 성격과 상관없이
  발신자와 수신자의 개념에서 발신자를 기준으로
  발신자에서 ⇒ 수신자 방향을 다운스트림
  수신자에서 ⇒ 발신자 방향을 업스트림 이라고 한다.

---

2. 메세지의 문법

• HTTP메세지는 요청이나 응답으로 분류된다.
• 요청 메세지는 웹서버에 어떤 동작을 요구한다. - 메서드
• 응답 메세지는 요청의 결과를 클라이언트에게 돌려준다.

1. 요청
   버전은 프로토콜 버전

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

2. 응답

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

---

3. 메세지의 각 부분

• HTTP 메세지는 단순한, 데이터의 구조화된 블록이다.
• 시작줄 / 헤더블록 / 본문

3.1 시작줄과 헤더

• 줄 단위로 분리된 아스키 문자열
• 각 줄은 캐리지 리턴(13)과 개행문자(10)로 구성된 두 글자의 줄바꿈 문자열로 끝난다.
  • CRLF라고 쓴다.
• HTTP 명세에 따르면
  줄바꿈 문자열은 CRLF이지만
  견고한 어플리케이션이라면 그냥 개행 문자도 받아들일 수 있어야 한다는 점을
  언급할 필요가 있을 듯하다.
  • 그니까 모든 어플리케이션이 CRLF를 받아들일 수 있다는 전제가 깔려야한다.
• 오래되거나 잘못 만들어진 HTTP 어플리케이션들 중에서는 캐리지 리턴과 개행 문자 모두를 항상 전송하지 않는 것들도 있다.

아스키 문자열 ?
미국정보교환표준부호(영어: American Standard Code for Information Interchange), 또는 줄여서 ASCII( /ˈæski/, 아스키)는 영문 알파벳을 사용하는 대표적인 문자 인코딩이다. 아스키는 컴퓨터와 통신 장비를 비롯한 문자를 사용하는 많은 장치에서 사용되며, 대부분의 문자 인코딩이 아스키에 기초를 두고 있다.

아스키코드
10 LF ( Line Feed => 다음 줄로)
13 CR ( Cariage Return => 제일 처음 칸으로)

3.1 시작줄

• 요청 메세지의 시작줄은 무엇을 해야하는지 말해준다.
• 응답 메세지의 시작줄은 무슨 일이 일어났는지 말해준다.

3.1.1 요청줄

요청 메세지는 서버에게 리소스에 대해 무언가를 해달라고 부탁한다.
요청 메세지는

• 메서드 : 서버에서 어떤 동작이 일어나야 하는지 설명해주는
• URL : 동작에 대한 대상을 지칭
• HTTP 버전 : 클라가 어떤 HTTP버전으로 말하고 있는지
  • HTTP/1.0 이전에는 요청줄에 HTTP버전이 미포함이었다.

모든 필드는 공백으로 구분된다.

3.1.1.1 메서드

• 요청의 시작줄은 메서드로 시작한다.
• 서버에게 무엇을 해야 하는지 말해준다.
• HTTP 명세에서 공통 요청 메서드의 집합을 정의한다.

1. GET - 서버에서 어떤 문서를 가져온다.
2. HEAD - 서버에서 어떤 문서에 대한 헤더만 가져온다.
3. POST - 서버가 처리해야 할 데이터를 보낸다.
4. PUT - 서버에 요청 메세지의 본문을 저장한다.
5. TRACE - 메세지가 프락시를 거처 서버에 도달하는 과정을 추적한다.
6. OPTIONS - 서버가 어떤 메서드를 수행할 수 있는지 확인한다.
7. DELETE - 서버에서 문서를 제거한다.

• 모든 서버가 위 메서드를 모두 구현한 것은 아니다.
• 확장메서드 - 하지만 쉽게 확장할 수 (커스텀) 있도록 HTTP가 설계했기 때문에
  그들만의 메서드를 추가로 구현했을 수도 있다.

3.1.1.2 버전

버전 번호는 HTTP로 대화하는 어플리케이션들에게
대화 상대의 능력과 메세지의 형식에 대한 단서를 제공하기 위한 것이다.

• 요청과 응답의 버전이 다를 경우 혼란을 야기할수 있다.
• HTTP/2.22는 HTTP/2.3 보다 큰 버전이다.
  22와 3의 비교라고 보면 된다.

3.1.2 응답줄

응답 메세지는 수행 결과에 대한

• 상태 정보와
• 결과 데이터를 클라이언트에게 돌려준다.

응답 메세지의 시작줄, 즉 응답줄은

• HTTP버전
• 숫자로된 상태코드
• 텍스트로 된 사유구절
  • HTTP/1.0 이전에는 응답에 응답줄이 들어있을 필요가 없었다.

모든 필드는 공백으로 구분된다.

3.1.2.1 상태코드

• 클라이언트에게 무엇이 일어났는지 말해준다.
• 응답의 시작줄에 위치한다.
• 숫자로 된 코드와 문자열(사유구절)로 되어 있어서 사람이 이해하기 쉬운 메세지 두 형태 모두로 반환된다.
• 사유구절이 사람에게 쉽게 읽히고, 숫자로 된 코드는 프로그램이 에러를 처리하기 쉽다.
• 프로토콜이 진화하면서, 더 많은 상태 코드가 HTTP 명세에 공식적으로 정의될 것이다.
• 만약 인식할 수 없는 상태 코드라면 확장코드이다.

3.1.2.2 사유구절

• 응답 시작줄의 마지막 구성요소.
• 사유구절은 상태 코드와 1:1로 대응된다.
• 상태코드의 사람이 이해하기 쉬운 버전이다.
• 엄격한 규칙은 제공하지 않는다.

3.2 헤더

• 0개에서 1개 혹은 여러 개의 HTTP헤더가 온다.
• 긴 헤더 줄은 여러 줄로 쪼개서 더 읽기 좋게 만들 수도 있다.
  스페이스 혹은 탭 문자가 와야 한다.

3.2.1 헤더 분류

• 헤더필드를 정의하다.
• 자유롭게 자신만의 헤더를 만들어낼 수 있다.
• 아래 분류 기준은 헤더를 이해하기 쉽게 카테고리화 한 것이며,
  RFC7231 기준으로는 Controls, Conditionals, Content Negotiation, Authentication Credentials, Request Context 로만 분류되어있다.
  • Controls: 요청의 특정 처리를 지시하는 헤더들
  • Conditionals: 조건부 헤더
  • Content Negotiation: 협상 헤더
  • Authentication Credentials: 권한 헤더
  • Request Context: 요청 정보 헤더

3.2.1.2 일반 헤더

• 요청과 응답 양쪽에 모두 나타날 수 있음
• 예) Date, Connection, Cache-control …

3.2.1.3 요청 헤더

• 요청에 대한 부가정보를 제공
• 예) Host, User-Agent, From, Cookie, Referer, If-Modified-Since, Authorization, Origin, Accept

3.2.1.4 응답 헤더

• 응답에 대한 부가정보를 제공
• 예) Server, Accept-Range, Set-Cookie, Expires, Age, ETag, Proxy-authenticate, Allow, Access-Control-Allow-Origin

3.2.1.5 Entity 헤더

• 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
• 예) Content-Type, Content-language, Content-Encoding, Content-Length, Content-Location, Content-Disposition, Content-Security-Policy, Location, Last-Modified, Transfer-Encoding

3.2.1.6 확장 헤더

• 명세에 정의되지 않은 새로운 헤더

3.2 본문

• 단순히 선택적인 데이터 덩어리이다. 옵셔너얼 ~
• 시작줄과 헤더와 달리 텍스트나 이진 데이터를 포함할 수도 있고 그냥 비어있을 수도 있다
  • 이진데이터: binary 데이터
  • 이미지 파일

---

3. 엔터티 본문

• optional인 엔터티 본문
• 메세지의 화물이라고 할 수 있다.
• 이미지,
  비디오,
  HTML문서,
  소프트웨어 어플리케이션,
  신용카드 트랜젝션,
  전자우편 등
  여러 종류의 디지털 데이터를 실어 나를 수 있다.

---

• 책뽀개기 모임 중 http 완벽가이드 1장 뽀개기 진행 중입니다. (~8월말) (다음 모임은 2장)
  (모임 참여를 원하신다면 댓글로 문의 바랍니다.)
• HTTP 완벽가이드 책을 보고 이해한 내용을 저만의 순서로 정리 한 글입니다.