[Network] HTTP 메시지

HTTP 메시지 구조

• 메시지 헤더
  • 서버와 클라이언트가 처리해야 하는 request와 response 내용과 속성
• 개행 문자(CR + LF)
  • CR(cattiage return) + LF(line feed)
• 메시지 바디
  • 꼭 전송되는 데이터 그 자체

ex) HTTP 메시지

인코딩 - 전송 효율 상승

메시지 바디와 엔티티 바디 차이

• 메시지
  • HTTP 통신의 기본 단위로 Octet sequence로 구성되고 통신을 통해서 전송
• 엔티티
  • 리퀘스트랑 리스폰스의 payload로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성

콘텐츠 코딩

엔티티 정보를 유지한채로 압축 → 콘텐츠 코딩된 엔티티는 수신한 클라이언트에서 디코딩한다.
주요 콘텐츠 압축 - gzip, compress, deflate, identity

청크 전송 코딩

사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시할 수 있다.

Multipart types

• MIME Types은 문서, 파일의 특징과 형식을 나타낸다.

서로 다른 MIME 타입들로 이루어져 각각의 파트들로 나누어지는 문서의 카테고리를 나타낸다.

→ 즉, 여러 종류의 다른 데이터를 수용하는 방법이다.

multipart/form-data
- 브라우저에서 서버로 HTML form 내용 전송시 사용한다.
- multipart는 문서 형식으로 경계 (--)로 각각의 엔티티를 구분한다.
- 마지막 부분에 (--) 를 삽입한다.

 

ex)
HTML form

<form action="http://localhost:8000/" method="post" enctype="multipart/form-data">
    <input type="text" name="myTextField">
    <input type="checkbox" name="myCheckBox">Check</input>
    <input type="file" name="myFile">
    <button>Send the file</button>
</form>

HTML form 전송 메시지
→ boundry 확인

POST / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
Content-Length: 465

-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myTextField"

Test
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myCheckBox"

on
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myFile"; filename="test.txt"
Content-Type: text/plain

Simple file.
-----------------------------8721656041911415653955004498--

 

multipart/byteranges
- 브라우저에 부분 응답을 보내기 위해 사용한다.
→ Content-Range 확인

```
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 385

--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 100-200/1270

eta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 300-400/1270

-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: "Open Sans", "Helvetica
--3d6b6a416f9b5--
```

레인지 리퀘스트

• 엔티티의 범위를 지정해서 리퀘스트하는 것

//5,001 ~ 10,000 바이트
Range: bytes = 5001-10000

Content negotiation

컨텐츠 협상이란 동일한 URI에서 리소스의 서로 다른 버전을 교섭하기 위해 사용되는 메커니즘이다.
클라이언트에게 제일 잘 맞는 것이 무엇인지(ex) 문서의 언어, 이미지 포맷 혹은 컨텐츠 인코딩)를 명시할 수 있다.

• 클라이언트에 더 적합한 더 적합한 리소스를 제공하기 위한 구조

클라이언트에게 적합한 리소스를 제공하는 결정 방식

1) 클라이언트가 보내는 HTTP header를 활용 - 서버 주도 협상
2) 서버에 의해 전달되는 상태 코드를 활용 - 에이전트 주도 협상

1) 서버 구동형 네고시에이션

• 서버 측에서 콘텐츠 협상하는 방식
• 결점: 서버는 브라우저에 대한 전체적인 정보가 없다.
  따라서 에이전트 구동형 네고시에이션보다 다소 제멋대로이다.

2) 에이전트 구동형 네고시에이션

• 클라이언트 측에서 콘텐츠 협상하는 방식
• 애매모호한 요청과 맞닥뜨렸을 경우, 서버는 사용 가능한 대체 리소스들에 대한 링크를 포함하고 있는 페이지를 회신한다.
  사용자는 사용하려는 리소스를 선택한다.

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

• 서버와 클라이언트 각각에서 콘텐츠 협상하는 방식

---

REFERENCES

우에노 센, 그림으로 배우는 HTTP & Network Basic, 2015

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_Types

https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation