HTTP Message, HTTP Encoding, Multipart, Range Request, Content Negotiation

WOOK JONG KIM·2023년 1월 9일
HTTP&Network
0

Http&Network

목록 보기
4/12
post-thumbnail

HTTP 메세지


헤더 : 요청과 응답에 대한 정보를 제공

바디 : 요청과 응답에 실제로 전송되는 데이터가 위치

리퀘스트 메세지의 헤더필드에는 리퀘스트 라인, 리퀘스트 헤더 필드, 일반 헤더 필드, 엔티티 헤더 필드로 구성

리스폰스 메세지의 헤더필드에는 상태 라인, 리스폰스 헤더 필드, 일반 헤더 필드, 엔티티 헤더 필드로 구성

  • 리퀘스트 라인 : 리퀘스트에 사용하는 메소드와 리퀘스트 URI와 사용하는 HTTP 버전이 포함됨
  • 상태 라인 : 리스폰스 결과를 나타내는 상태 코드와 설명, HTTP 버젼이 포함됨
  • 헤더 필드 : 리퀘스트와 리스폰스의 여러 조건과 속성 등을 나타내는 헤더 필드가 포함됨

예시 코드

GET / HTTP/1.1   -> 리퀘스트 라인, 나머지는 헤더 필드

Host:hackr.jp
User-Agent: Mozila/5.0
Accept : text/html,application/xhtml_xml.application/xml;q=0.9
Accept-Language : ja,en-us,q = 0.7
Accept-Encoding : gzip, deflate
DNT : 1
Connection : keep-alive
Pragma : no-cache
Cache-Control:no-cache
HTTP/1.1 200 OK

Date:Fri, 13 Jul 2012 02:45:26 GMT
Server : Apache
Last-Modifed : Fri 31 Aug 2007
ETag:"45bae1-16a-46d776ac"
Accept-Ranges : bytes
Content-length : 362
Connection : close
Content-Type : text/html

개행 문자(CR+LF)

<html>
	<head>
   	</head>
    <body>
    </body>
</html>

Encoding

정보를 저장하거나 전송할 때 이를 기계가 인식할 수 있는 형태로 변환하는 과정

HTTP로 데이터를 전송할때 그대로 전송할 수도 있지만, 전송할 때에 인코딩을 실시함으로써 전송 효율을 높일 수 있음
-> 컴퓨터에서 인코딩을 처리하기 때문에 리소스는 보다 많이 소비

메세지 바디 : HTTP 요청 또는 응답 메시지의 바디를 의미, 요청 메시지에서는 요청할 정보가, 응답 메시지에서는 응답할 정보가 메시지 바디에 포함

엔티티 바디 : HTTP 요청 또는 응답 메시지에서 실제로 전송할 데이터가 위치하는 부분을 의미
-> 엔티티 바디는 메시지 바디의 일부이며, 실제로 전송할 정보를 포함, 엔티티 바디가 존재하는 경우, 요청 메시지에서는 요청할 정보가 엔티티 바디에 포함되고, 응답 메시지에서는 응답할 정보가 엔티티 바디에 포함

메세지 바디의 역할은 리퀘스트랑 리스폰스에 관한 엔티티 바디를 운반하는 일
-> 기본적으로 메세지 바디와 엔티티 바디는 같지만 전송 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하기 때문에 메세지 바디와 달라짐
-> 바디 부분은 실제로 전송할 정보가 포함된 엔티티 바디(Entity Body)와 전송 코딩이 적용된 정보가 포함된 메시지 바디(Message Body)로 구분
-> 전송 코딩은 전송할 정보를 압축하거나 암호화하기 위해 사용, 이러한 전송 코딩이 적용되면 실제 전송할 정보인 엔티티 바디의 내용이 변화하게 된다

POST /login HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 23

{"username":"user1","password":"pwd1"}

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 39

{"status":"success","message":"Logged in"}

전송 코딩 예시 --

POST /login HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 23

H4sIAAAAAAAAE2SQQ6DMAyGJ79QskLgPXFbEKDU1NHSwNzUytKizKUcFzU6Mk4vLy8vIKUhNTY4MTM4NzMwTfV1TzZSkTQKiDlQAAAA==

HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 39

H4sIAAAAAAAAE2SQQ6DMAyGJ79QskLgPXFbEKDU1NHSwNzUytKizKUcFzU6Mk4vLy8vIKUhNTY4MTM4NzMwTfV1TzZSkTQKiDlQAAAA==

위 예시에서 요청과 응답 메시지의 바디 부분(Entity Body + Message Body)은 아래와 같이 구성

  • 요청 메시지 바디(Entity Body + Message Body) : {"username":"user1","password":"pwd1"}
  • 응답 메시지 바디(Entity Body + Message Body) : {"status":"success","message":"Logged in"}

위 예시에서 요청과 응답 메시지 모두 전송 코딩인 Content-Type: application/json과 압축 코딩인 Content-Encoding: gzip이 적용된 경우
-> 결과적으로 엔티티 바디(Entity Body)의 내용은 JSON 형식의 정보가 되고, 메시지 바디(Message Body)의 내용은 전송 코딩이 적용된 정보가 된다

콘텐츠 코딩(압축)

엔티티에 적용하는 인코딩을 가리킴, 엔티티 정보를 유지한채 압축 진행
-> 콘텐츠 코딩된 엔티티는 수신한 클라이언트 측에서 디코딩 됨

주요 콘텐츠 압축 : gzip, compress, deflate, identity

청크 전송 코딩(chunked transfer coding)

HTTP 통신에서는 리퀘스트 했었던 리소스 전부에서 엔티티 바디의 전송이 완료되지 않으면 브라우저에 표시되지 않음
-> 사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시 가능
-> 이 처럼 엔티티 바디를 분할하는 기능을 청크 전송 코딩이라고 함

청크 전송 코딩된 바디는 수신한 클라이언트 측에서 원래의 엔티티 바디로 디코딩

Multipart

메일의 경우에는 메일의 본문이나 복수의 첨부 파일을 붙여서 함께 보낼 수 있음
-> MIME

MIME는 이미지 등의 바이너리 데이터를 아스키 문자열에 인코딩하는 방법과, 데이터 종류를 나타내는 방법등을 규정
-> 이는 멀티파트라고 하는 여러 다른 종류의 데이터를 수용하는 방법 사용

HTTP도 멀티파트에 대응하고 있어 하나의 메세지 바디 내부에 엔티티를 여러개 포함시켜 보낼수 있음
-> 주로 이미지나 텍스트 파일등을 업로드 할 때 사용

  • multipart/form-data : Web 폼으로부터 파일 업로드에 사용
  • multipart/byteranges : 상태 코드 206 리스폰스 메세지가 복수 범위의 내용을 포함할때 사용

multipart/form-data 예시

Content-Type : multipart/form-data; boundary=AaB03x

--AaB03x
Content-Disposition : form-data; name="field1"

Joe Blow
--AaB03X
Content-Disposition : form-data; name="pics";filename="file1.txt"
Content-Type : text/plain

(file1.txt data)
--A3B03x--

multipart/byteranges

HTTP/1.1 206 Partial Content
Date : Fri, 13 Jul 2012 02:45:26 GMT
Last Modified : ~~~
Content-Type : multipart/byteranges : boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type : application/pdf
Content-Range: bytes 500-999/8000
(지정한 범위의 데이터)
--THIS_STRING_SEPARATES

Content-Type : application/pdf
Content-Range : bytes 7000-7999/8000
(지정한 범위의 데이터)
--THIS_STRING_SEPARATES--

HTTP 메세지로 멀티 파트 사용 시에는 Content-Type 헤더 필드를 사용
-> 각각의 엔티티 구분을 위해 boundary 문자열 사용
-> 문자열 앞에 --를 삽입하며 마지막엔 --로 감쌈

멀티파트는 파트마다 헤더 필드가 포함됨

Range Request

사용자가 광대역 네트워크를 이용할 수 있기 전에는 대용량의 이미지와 데이터를 다운로드하기 힘듬
-> 다운로드 중 커넥션이 끊기면 처음부터 다시 다운로드 했어야 함
-> 이를 해결하기 위해 resume이라는 기능이 필요
-> resume이란 이전에 다운로드 한 곳에서부터 다운로드를 재개하는 기능

resume을 실현하기 위해서 엔티티의 범위를 지정해서 다운로드 할 필요가 있었음
-> 범위를 지정해서 리퀘스트 하는 것을 Range Request라고 함
-> 사용 시 전체 10000 바이트 정도 크기의 리소스에서 5001~10000 바이트 범위만을 리퀘스트 가능

ex) 이미지 일부의 리스폰스를 내려받은 뒤 나머지 이미지에 대한 리퀘스트를 보낼떄

GET /tip.jpg HTTP /1.1
Host : www.usagedesign.jp
Range : bytes = 5001-10000

HTTP /1.1 206 Partial Content
Date : Fri 13 Jul 2012 04:39:17
Content-Range : bytes 5001-10000/100000
Content-Length : 5000
Content-Type : image/png

레인지 리퀘스트 시에는 Range 헤더 필드를 사용하여 리소스의 바이트 레인지 지정

레인지 리퀘스트에 대한 리스폰스는 상태 코드 206으로 메세지 내려옴
-> 복수 범위 레인지 리퀘스트는 multipart/byteranges로 리스폰스 내려옴

서버가 레인지 리퀘스트를 지원하지 않는 경우엔 200OK 메세지 내려옴

Content Negotiation

같은 콘텐츠이지만 여러개의 페이지를 지닌 웹 페이지 존재
-> ex) 구글의 영어판과 한국어판
-> 영어판 브라우저와 한국판 브라우저가 있을때, www.google.com 입력 시 즉 같은 URI에 엑세스 할때 각각 영어판,한국판 웹페이지 표시
-> 이러한 구조를 콘텐츠 네고시에이션이라고 함

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

콘텐츠 네고시에이션은 제공하는 리소스를 언어와,문자 세트, 인코딩 방식등을 기준으로 판단

종류

  1. 서버 구동형 네고시에이션
    서버 측에서 콘텐츠 네고시에이션을 하는 방식, 서버 측에서 리퀘스트 헤더 필드의 정볼르 참고해서 자동으로 처리

  2. 에이전트 구동형 네고시에이션
    클라이언트 측에서 콘텐츠 네고시에이션을 하는 방식, 유저가 수동으로 선택
    ex) OS의 종류나 브라우저의 종류 등에 의해서 PC용과 스마트폰용의 웹 페이지를 자동으로 전환하는 것

  3. 트랜스페어런트 네고시에이션
    위 두방식 혼합, 서버와 클라이언트가 각각 콘텐츠 네고시에이션을 하는 방식

profile
WOOK JONG KIM
Journey for Backend Developer
이전 포스트

HTTP 프로토콜

다음 포스트

HTTP 상태 코드

0개의 댓글

관련 채용 정보