3일차 - HTTP 메시지

오늘은 HTTP 통신에서 정보를 주고 받을 때 사용하는 HTTP 메시지에 대해 간략하게 배우고

통신을 할 때 유용하게 사용하는 기능들에 대해 배웠다.

책을 읽으면서 이 기능이 왜 존재하는지에 대한 예시를 잘 들어줘서 이해하기 편했다.

 

 

 

1. HTTP 메시지

HTTP는 클라이언트에서 리퀘스트를 전송하고 그에 응답하는 리스폰스를 서버 측에서 보낸다고 배웠다.

이렇게 리퀘스트와 리스폰스를 주고 받을 때 교환하는 정보를 담는 것을 HTTP 메시지라고 한다.

HTTP 메시지는 여러 행의 데이터로 구성된 텍스트 문자열이고 메시지 헤더와 메시지 바디로 구성된다.

여기서, 메시지 헤더 부분과 메시지 바디 부분의 구분하는 경계선을 나타내는 것은

[CR+LF]이다. (CR: 16진수 0x0d, LF: 16진수 0x0a)

 

모든 HTTP 메시지에 메시지 바디가 존재하는 것은 아니다.

저번 시간에 배웠던 HEAD 메소드의 경우 리스폰스로 메시지 헤드만 돌려준다고 했다.

이러한 경우 리스폰스 메시지에 메시지 바디를 포함하지 않는 것이다.

 

 

2. 리퀘스트 메시지와 리스폰스 메시지의 구조

리퀘스트 메시지는 리퀘스트에서 사용하는 HTTP 메시지를 말하고 리스폰스 메시지는 리스폰스에서 사용하는

HTTP 메시지를 말한다.

리퀘스트 메시지의 메시지 헤더는 리퀘스트 라인, 리퀘스트 헤더 필드, 일반 헤더 필드, 엔티티 헤더 필드로 되어있고

리스폰스 메시지의 메시지 헤더는 상태 라인, 리스폰스 헤더 필드, 일반 헤더 필드, 엔티티 헤더 필드로 되어있다.

하나씩 어떠한 역할을 하는지 알아보자.

 

1) 리퀘스트 라인

리퀘스트 라인에서는 리퀘스트에 사용하는 메소드, 리퀘스트 URI, HTTP 버전을 포함하고 있다.

 

2) 상태 라인

상태 라인은 리퀘스트에 따른 결과를 알려주는 상태 코드와 설명, HTTP 버전을 포함하고 있다.

 

3) 헤더 필드

위 2가지를 제외한 헤더 필드는 조건과 속성 등을 나타내는 역할을 하고 있다.

 

오늘은 간단하게 어떠한 역할을 하는지 배웠지만 다음에 더 자세히 배울 시간이 있을 것이다.

 

 

3. 콘텐츠 코딩(Content Codings)

우리가 일상생활에서 메일로 첨부파일을 보내거나 카카오톡을 통해 파일 등을 보낼 때 용량이 너무 크면 압축을 통해 크기를 줄여서 보낸다.

이와 같이 압축을 HTTP에서도 활용을 하는데 이것을 콘텐츠 코딩이라고 부른다.

콘텐츠 코딩을 HTTP관점에서 정확히 말하면 엔티티에 적용하는 인코딩을 말하는 것이다.

여기서 엔티티란 무엇을 의미할까?

 

※ 메시지와 엔티티의 차이

- 메시지는 우리가 앞에서 배웠듯이 HTTP 통신의 기본 단위로 8비트 시퀀스로 구성된 것이다.

- 엔티티는 리퀘스트와 리스폰스의 페이로드로 전송되는 정보를 의미한다.

  엔티티에 대해 정확히 무엇을 의미하는지 감이 잘 안오는데 페이로드는 전송의 근본적인 목적이 되는 데이터의

  일부분을 말하는 것으로 엔티티를 한마디로 말하면 메시지가 말하고자하는 정보가 담긴 것으로 보면 된다.

 

 

4. 청크 전송 코딩(Chunked transfer coding)

앞에서 배운 콘텐츠 코딩은 큰 크기의 엔티티를 작게 압축하여 보내는 방식이였다.

청크 전송 코딩은 한마디로 표현하면 큰 크기의 엔티티를 작은 크기의 청크로 쪼개어 보내는 것이다.

이렇게 여러 개의 청크로 쪼개지면 자기자신(청크) 다음 청크 사이즈를 16진수로 자기자신(청크)의 끝을 표시하고

엔티티 끝에는 0(CR+CF)를 기록해둔다.

 

 

5. 레인지 리퀘스트(Range Request)

요즘에는 네트워크 환경이 잘 되어있어서 파일이나 동영상 등을 다운로드 받으면서 통신이 끊긴 적이 없겠지만

만약, 다운로드 중 통신이 끊겼다고 가정해보자.

오랫동안 기다리면서 다운로드 받았는데 중간에 끊겨서 다시 처음부터 다운로드를 받게 된다면 매우 기분이 불쾌할 것이다.

이러한 상황을 방지하기 위해 우리가 다운로드 받은 부분을 기억해두는 리줌(resume)기능을 만든 것이다.

이 리줌기능을 구현하기 위해서는 HTTP입장에서 엔티티의 범위를 지정해서 다운로드를 할 필요성이 생겼다.

이처럼 범위를 지정하여 리퀘스트 하는 것을 레인지 리퀘스트라고 한다.

우리가 절반을 다운로드하고 통신이 끊겼다면, 그 이후부터 끝까지의 정보를 요구해야하는데

이 범위를 지정하여 리퀘스트할 수 있다는 것이다.

 

 

6. 콘텐츠 네고시에이션(Content Negotiation)

콘텐츠 네고시에이션을 설명하기 전에 간단한 예시를 들어보자.

우리가 구글 홈페이지를 접속하면 한글로 잘 표시되어 웹 페이지가 나온다.

그리고 구글 홈페이지의 내용(content)는 같지만 영어로 표시되어 언어만 다르게 웹 페이지가 나올 수도 있다.

이것은 우리가 http://www.google.com에 접속을 했을 때 브라우저가 같은 URI에 접속할 때 한국어판 웹 페이지를 표시해주는 것이다.

이렇게 사용자에게 맞는 최적의 콘텐츠로 보여주는 기능을 하는 것이 콘텐츠 네고시에이션이다.

 

콘텐츠 네고시에이션은 클라이언트와 서버가 제공하는 리소스의 내용에 대해서 서로 의논하는 것이다.

즉, 클라이언트에게 더욱 적합한 리소스를 제공하기 위한 구조로 만들어졌다.

리소스를 제공하는 판단 기준은 언어, 문자 세트, 인코딩 방식 등이다.

이러한 판단 기준은 리퀘스트 메시지에 포함된 리퀘스트 헤더 필드를 사용하는데

사용되는 헤더 필드는

Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Language

5가지로 자세한 설명은 다음에 알 수 있다.

(오늘 배운 장에서는 헤더 필드에 대한 세부설명은 하지 않았다..)

 

콘텐츠 네고시에이션에는 3가지 종류가 있다.

1) 서버 구동형 네고시에이션(Server-driven Negotiation)

서버측에서 콘텐스 네고시에이션을 시행하는 방식으로 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리한다.

브라우저가 보내는 정보만을 가지고 처리하기 때문에 유저에게 정말 적합한 내용을 선택했다고 확신할 수는 없다.

 

2) 에이전트 구동형 네고시에이션(Agent-driven Negotiation)

클라이언트 측에서 콘텐츠 네고시에이션을 시행하는 방식으로 브라우저에 표시된 선택지 중에서 유저가 수동으로 선택하는 것이다.

웹 페이지를 사용하다가 영어로 된 페이지가 있다면 오른쪽 위에 번역하겠냐는 표시를 본적이 있는데

그 기능이 에이전트 구동형 네고시에이션 중 하나인 것같다.

 

3) 트랜스페어런트 네고시에이션(Transparent Negotiation)

1번과 2번을 혼합한 것으로 서버와 클라이언트가 각각 콘텐츠 네고시에이션을 하는 방식이다.