제 3장 HTTP 정보는 HTTP 메세지에 있다.

HTTP 메세지 : HTTP에서 교환하는 정보

리퀘스트 측 HTTP메세지를 리퀘스트 메세지, 리스폰스 측 HTTP 메세지를 리스폰스 메세지라고 부른다.
HTTP 메세지는 복수행의 데이터로 구성된 텍스트 문자열이다. 크게 구분하며 메세지 헤더, 메세지 바디로 구성되어 있고, 개행 문자(CR+LF)로 메세지 헤더와 바디를 구분한다.

 

HTTP 메세지 구조

[메세지 헤더]
서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성 등
[CR+LF]
CR(carriage return : 16진수 0x0d)와 LF(line feed : 16진수 0x0a)
[메세지 바디]
꼭 전송되는 데이터 그 자체

---

 

리퀘스트 메세지의 구조	리스폰스 메세지의 구조
[ 메세지 헤더 ] 리퀘스트 라인 리퀘스트 헤더 필드 일반 헤더 필드 엔티티 헤더 필드 그외	[ 메세지 헤더 ] 상태 라인 리스폰스 헤더 필드 일반 헤더 필드 엔티티 헤더 필드 그 외

• 리퀘스트 라인 :  리퀘스트에 사용하는 메소드와 리퀘스트 URI와 사용하는 HTTP 버전이 포함된다.
• 상태 라인 :  리스폰스 결과를 나타내는 상태 코드와 설명, 사용하는 HTTP 버전이 포함된다.
• 헤더 필드 :  리퀘스트와 리스폰스의 여러 조건과 속성 등을 나타내는 각종 헤더 필드가 포함된다.
• 그 외 :  HTTP의 RFC에는 없는 헤더 필드(쿠키 등)가 포함되는 경우가 있다.

---

HTTP로 데이터를 전송할 경우 인코딩(변환)을 실시함으로써 전송 효율을 높일 수 있다.
단지 컴퓨터에서 인코딩 처리를 해야 하기 때문에 CPU 등의 리소스는 보다 많이 소비하게 된다.

⊙ 메세지 바디와 엔티티 바디의 차이

• 메세지(message)
  HTTP 통신의 기본 단위로 옥텟 시퀀스(Octet sequence, octet은 8비트)로 구성되고 통신을 통해서 전송된다.
• 엔티티(entity)
  리퀘스트랑 리스폰스의 페이로드(payload, 부가물)로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.

 

HTTP 메세지 바디의 역할은 리퀘스트랑 리스폰스에 관한 엔티티 바디를 운반하는 일이다. 기본적으로 메세지 바디와 엔티티 바디는 같지만 전송 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하기 때문에 메세지 바디와 달라진다.

⊙ 압축해서 보내는 콘텐츠 코딩

   메일에 파일을 첨부해서 보낼 경우 용량을 줄이기 위해 zip으로 압축해 보내는 일이 있다.
   HTTP에서 이와 같은 일을 하는 기능을 콘텐츠 코딩(Content Codings)이라고 한다.
   콘텐츠 코딩은 엔티티에 적용하는 인코딩을 가리키는데 엔티티 정보를 유지한채로 압축한다.
   콘텐츠 코딩된 엔티티는 수신한 클라이언트 측에서 디코딩한다.

⊙ 분해해서 보내는 청크 전송 코딩

   사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시할 수 있다.
   엔티티 바디를 분할하는 기능을 청크 전송 코딩(Chunked transfer Coding)이라고 부른다.
   청크 전송 코딩은 엔티티 바디를 청크(덩어리)로 분해한다.
   다음 청크 사이즈를 16진수로 단락을 표시하고 엔티티 바디 끝에는 "0(CR+LF)"를 기록해둔다.
   청크 전송 코딩된 엔티티 바디는 수신한 클라이언트 측에서 원래의 엔티티 바디로 디코딩한다.

---

여러 데이터를 보내는 멀티파트

메일의 경우에는 메일의 본문이나 복수의 첨부 파일을 붙여서 함께 보낼 수 있다. 이것은 MIME(Multipurpuse Internet Mail Extensions : 다목적 인터넷 메일 확장 사양)로 불리며 텍스트나 영상, 이미지와 같은 여러 다른 데이터를 다루기 위한 기능으로 사용하고 있다.

MIME는 이미지, 동영상, 문서 등의 바이너리 데이터를 아스키(ASCII) 문자열에 인코딩하는 방법과 데이터 종류를 나타내는 방법 등을 규정하고 있다. 이 MIME의 확장 사양에 있는 멀티파트(Multipart)라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 사용하고 있는 것이다. MIME는 전자우편에서 사용하기 위해 등장했지만 지금은 HTTP 통신에서 전송 데이터를 표현하기 위해서도 사용하고 있다.

하나의 메세지 바디 내부에 엔티티를 여러 개 포함시켜 보낼 수 있다.
주로 이미지나 텍스트 파일 등을 업로드 할 때 사용된다.

• multipart/form-data
  Web 폼으로부터 파일 업로드에 사용된다.
• multipart/byteranges
  상태 코드 206(Partial Content) 리스폰스 메세지가 복수 범위의 내용을 포함하는 때에 사용된다.

---

일부분만 받는 레인지 리퀘스트 

요즘처럼 사용자가 광대역의 네트워크를 이용할 수 있기 전에는 대용량의 이미지와 데이터를 다운로드하기가 힘들었다. 왜냐하면 다운로드 중에 커넥션이 끊어지게 되면 처음부터 다시 다운로드를 해야 했기 때문이다. 이러한 문제를 해결하기 위해서 일반적인 리줌(resume)이라는 기능이 필요하게 된다. 리줌을 통해 이전에 다운로드를 한 곳에서부터 다운로드를 재개할 수 있다.

이 기능을 실현하기 위해서는 엔티티의 범위를 지정해서 다운로드를 할 필요가 있다. 이와 같이 범위를 지정하여 리퀘스트 하는 것을 레인지 리퀘스트(Range Request)라고 부른다.

레인지 리퀘스트를 사용하면 전체 10,000 바이트 정도 크기의 리소스에서 5,001~10,000 바이트의 범위(바이트 레인지) 만을 리퀘스트 할 수 있다. 레인지 리퀘스트를 할 때에는 Range 헤더 필드를 사용해서 리소스의 바이트 레인지를 지정한다.

• 5,001~10,000 바이트
  Range: bytes = 5001-10000
• 5,001 바이트 이상
  Range: bytes = 5001-
• 처음부터 3,000 바이트까지, 그리고 5,000~7,000 바이트까지의 복수 범위
  Range: bytes = 3000, 5000-7000

 

레인지 리퀘스트에 대한 리스폰스 →  상태 코드 206 Partial Content 
복수 범위의 레인지 리퀘스트에 대한 리스폰스 →  multipart/byteranges
서버가 레인지 리퀘스트를 지원하지 않는 경우 →  상태 코드 200 OK 

 

---

최적의 콘텐츠를 돌려주는 콘텐츠 네고시에이션

같은 콘텐츠(내용)이지만 여러 개의 페이지를 지닌 웹 페이지가 있다. 예를 들면, 내용은 같지만 한국판, 영어판과 같이 표시되는 언어가 서로 다른 웹 페이지의 경우이다. 이러한 웹 페이지에서는 브라우저가 같은 URI에 엑세스할 때에 각각 영어판, 한국어 판 웹 페이지를 표시한다. 이와 같은 구조를 콘텐츠 네고시에이션(Content Negotiation)이라고 부른다.

콘텐츠 네고시에이션은 제공하는 리소스를 언어와 문자 세트, 인코딩 방식 등을 기준으로 판단하고 있다. 판단 기준은 리퀘스트 메세지에 포함된 다음과 같은 리퀘스트 헤더 필드이다.

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

콘텐츠 네고시에이션의 종류

• 서버 구동형 네고시에이션(Server-driven Negotiation)
  서버 측에서 콘텐츠 네고시에이션을 하는 방식이다. 서버 측에서 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리한다. 단지, 브라우저가 보내는 정보를 근거로 하기 때문에 유저에게 정말로 적절한 것이 선택되었다고 할 수 없다.
• 에이전트 구동형 네고시에이션(Agent-driven Negotiation)
  클라이언트 측에서 콘텐츠 네고시에이션을 하는 방식이다. 브라우저에 표시된 선택지 중에서 유저가 수동으로 선택한다. JavaScript 등을 사용해서 웹 페이지에서 자동적으로 이것을 정하는 것도 있다. 예를 들면, OS의 종류나 브라우저의 종류 등에 의해서 PC용과 스마트폰용의 웹 페이지를 자동으로 전환하는 것이 이에 해당된다.
• 트랜스페어런트 네고시에이션(Transparent Negotiation)
  서버 구동형과 에이전트 구동형을 혼합한 것으로 서버와 클라이언트가 각각 콘텐츠 네고시에이션을 하는 방식이다.

---

참고 : 그림으로 배우는 Http&Network Basic