본문 바로가기
개인공부/Http Network Basic

3장 - HTTP 정보는 HTTP 메시지에 있다

by 하고싶은건많은놈 2023. 2. 27.

3.1 HTTP 메시지

HTTP 메시지 : HTTP에서 교환하는 정보, 복수 행으로 구성

메시지 헤더 / 개행(CR+ LF) / 메시지 바디로 구분

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

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

리퀘스트 메시지와 리스폰스 메시지는 모두 메시지 헤더 / 개행 / 메시지 바디로 구성되어있으며 메시지 헤더의 구성이 다름

 

리퀘스트 메시지의 메시지 헤더 : 리퀘스트 라인 / 리퀘스트 헤더 필드 / 일반 헤더 필드 / 엔티티 헤더 필드 / 그 외

리스폰스 메시지의 메시지 헤더 : 상태 라인 / 리스폰스 헤더 필드 / 일반 헤더 필드 / 엔티티 헤더 필드 / 그 외

  • 리퀘스트 라인 : 리퀘스트에 사용하는 메소드 + 리퀘스트 URI + 사용하는 HTTP 버전
  • 상태 라인 : 리스폰스 결과를 나타내는 상태 코드와 설명 + 사용하는 HTTP 버전
  • 헤더 필드 : 리퀘스트 또는 리스폰스의 여러 조건 및 속성 등을 나타내는 각종 헤더 필드 포함
    일반 헤더 필드 / 리퀘스트 헤더 필드 / 리스폰스 헤더 필드 / 엔티티 헤더 필드의 네종류가 존재
  • 그 외 : RFC에는 존재하지 않는 헤더 필드(쿠키 등)이 포함됨

 

  • 리퀘스트 메시지 예시
GET / HTTP/1.1
Host: hackr.jp
User-Agent: Mozila/5.0 (Windows NT 6.1; WOW64; rv; 13.0) Gecko/20100101 Firefox/10.0.1
Accept: text/html.application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
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-Modified: Fri, 31 Aug 2007 02:02:20 GMT
ETag: "45bae1-16a-46d776ac"
Accept-Ranges: bytes
Content-Length: 362
Connection: close
Content-Type: text/html
//CRLF
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>hackr.jp</title>
</head>
<body>
<img src="hackr.gif" alt="hackr.jp" width="240" height="84" />
</body>
<html>

3.3 인코딩으로 전송 효율을 높이다

HTTP 메시지 바디는 리퀘스트 또는 리스폰스에 관한 엔티티 바디를 운반하는 역할을 함

기본적으로 메시지 바디와 엔티티 바디는 같으나, 전송 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하여 메시지 바디와 달라짐

  • 메시지(message) : HTTP 통신의 기본 단위, 옥텟 시퀀스(Octet sequence)로 구성되고 통신을 통해 전송
  • 엔티티(entity) : 리퀘스트 또는 리스폰스의 페이로드(payload)로 전송되는 정보, 엔티티 헤더 필드 및 엔티티 바디로 구성

HTTP로 데이터 전송시 인코딩을 실시하여 전송 효율을 높임

단, 컴퓨터에서 인코딩 처리를 해야하므로 CPU등의 리소스는 보다 많이 소비함

HTTP에는 마치 파일을 zip으로 압축하여 보내는 것과 같은 콘텐츠 코딩(Content Codings)이라는 기능이 존재

콘텐츠 코딩은 엔티티에 적용되는 인코딩을 가리키며 엔티티 정보를 유지한 채로 압축하고, 이를 수신한 클라이언트 측에서 디코딩함

주요 콘텐츠 압축에는 gzip(GNU zip) / compress(UNIX 표준 압축) / deflate(zlib) / identity(인코딩 없음) 등이 존재

 

사이즈가 큰 데이터를 전송하는 경우 엔티티 바디를 분할하여 전송하는데, 이를 청크 전송 코딩(Chuncked transfer Coding)이라고 부름

청크 전송 코딩시 엔티티 바디가 청크(덩어리)로 분해되며, 다음 청크 사이즈를 16진수로 사용해 단락을 표시하고 엔티티 바디 끝에는 CRLF를 기록해둠

분해된 엔티티 바디는 수신한 클라이언트 측에서 원래의 엔티티 바디로 디코딩

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

메일의 MIME(Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장 사양)의 확장 사양과 같은 멀티파트(Multipart)는 여러 다른 종류의 데이터를 수용하는 방법

HTTP도 멀티파트에 대응하기 때문에 하나의 메시지 바디 내부에 엔티티를 여러개 포함시켜 보낼 수 있음

이는 이미지나 텍스트 파일 등을 업로드할 때 사용됨

멀티파트 각각의 엔티티를 구분하기 위해서 각 엔티티의 선두에는 "--boundary" 문자열을 사용

멀티파트 마지막에는 "--boundary--"를 삽입하여 마무리

멀티파트에는 파트마다 헤더 필드가 포함되며, 파트의 내부에 또다른 파트를 포함할 수 있음

  • 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 데이터) ...
--AaB03x--
  • multipart/byteranges
    상태 코드 206(Partial Content) 리스폰스 메시지가 복수 범위 내용을 포함하는 때 사용
HTTP/1.1 206 Partial Content
Date: Fri, 13 Jul 2012 02:45:26 GMT
Last-Modified: Fri, 31 Aug 2007 02:02:20 GMT
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--

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

다운로드 중 커넥션이 끊길 경우 다시 다운로드를 해야했는데, 이를 해결하기 위해 일반적인 리줌(resume) 기능이 필요

이 기능을 실현하기 위해 다운로드시 엔티티의 범위를 지정해야하며, 범위를 지정해 리퀘스트하는 것을 레인지 리퀘스트(Range Request)라고 함

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

Range: bytes = 5001-10000
Range: bytes=5001-
Range: bytes=-3000, 5000-7000

레인지 리퀘스트에 대한 리스폰스로는 상태 코드 206 Partial Content가 반환됨

복수 범위의 레인지 리퀘스트의 경우 multipart/byteranges로 리스폰스가 반환됨

서버가 레인지 리퀘스트를 지원하지 않는 경우 상태 코드 200 OK와 함께 완전한 엔티티가 반환됨

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

같은 URI에 엑세스시 영어판 웹 페이지와 한국어판 웹 페이지가 표시되는 것과 같은 구조를 콘텐츠 네고시에이션(Content Negotiation)이라고 함

즉, 클라이언트와 서버가 제공하는 리소스의 내용에 대해 교섭

이 때 제공하는 리소스를 언어 및 문자 세트, 인코딩 방식 등을 기준으로 판단하며 해당 기준이 되는 리퀘스트 헤더 필드에는 Accept / Accept-Charset / Accept-Encoding / Accept-Language / Content-Language 가 있음

  • 서버 구동형 네고시에이션(Server-driven Negotiation)
    서버 측에서 콘텐츠 네고시에이션을 실행, 서버 측에서 리퀘스트의 헤더 필드를 참고하여 자동으로 처리
    단, 브라우저가 보내는 정보를 근거로 하기 때문에 유저에게 적절한 것이 선택되었다고는 할 수 없음
  • 에이전트 구동형 네고시에이션(Agent-driven Negotiation)
    클라이언트 측에서 콘텐츠 네고시에이션을 실행, 브라우저에 표시된 선택지 중 유저가 수동으로 선택
    JavaScript 등을 사용해 웹 페이지에서 자동적으로 정해지는 경우도 존재
  • 트랜스페어런트 네고시에이션(Transparent Negotiation)
    서버 구동형과 에이전트 구동형의 혼합, 서버와 클라이언트가 각각 콘텐츠 네고시에이션을 실행
저작자표시

'개인공부 > Http Network Basic' 카테고리의 다른 글

5장 - HTTP와 연계하는 웹 서버  (0) 2023.02.28
4장 - 결과를 전달하는 HTTP 상태 코드  (0) 2023.02.27
2장 - 간단한 프로토콜 HTTP  (0) 2023.02.27
1장 - 웹과 네트워크의 기본에 대해 알아보자  (0) 2023.02.27

관련글

댓글

티스토리툴바