HTTP 메시지

 

HTTP 메시지

 
HTTP에서 교환하는 정보는 HTTP 메시지라고 불리는데 요청 측 HTTP 메시지를 요청 메시지, 응답 측 HTTP 메시지를 응답 메시지라고 부른다.
 
HTTP 메시지는 복수 행(개행 문자는 CR+LF)의 데이터로 구성된 텍스트 문자열이다. HTTP 메시지는 크게 구분하면 메시지 헤더와 메시지 바디로 구성되어 있고, 최초에 나타나는 개행 문자(CR+LF)로 메시지 헤더와 메시지 바디를 구분한다.
 

메시지 헤더
개행 문자(CR+LF)
메시지 바디

 

• 메시지 헤더 : 서버와 클라이언트가 꼭 처리해야 하는 요청과 응답 내용과 속성 등
• CR+LF : CR(carriage return : 16진수 0x0d)와 LF(line feed : 16진수 0x0a)
• 메시지 바디 : 꼭 전송되는 데이터 그 자체
   
  요청 메시지와 응답 메시지의 메시지 헤더 내부는 다음과 같은 데이터로 구성되어 있다.
   

요청(request) 메시지 헤더 내부	응답(response) 메시지 헤더 내부
요청(request) 라인	상태 라인
요청(request) 헤더 필드	응답(response) 헤더 필드
일반 헤더 필드	일반 헤더 필드
엔티티 헤더 필드	엔티티 헤더 필드
그 외	그 외

 

• 요청(request) 라인 : 요청에 사용하는 메소드와 요청 URI와 사용하는 HTTP 버전이 포함된다.
• 상태 라인 : 응답 결과를 나타내는 상태 코드와 설명, 사용하는 HTTP 버전이 포함된다.
• 헤더 필드 : 요청과 응답의 여러 조건과 속성 등을 나타내는 각종 헤더 필드가 포함됨(일반 헤더 필드, 요청(request) 헤더 필드, 응답(response) 헤더 필드, 엔티티 헤더 필드 등 4종류가 있다.)
• 그 외 : HTTP의 RFC에 없는 헤더 필드(쿠키 등)가 포함되는 경우가 있다.
   

  인코딩

   
  HTTP로 데이터를 전송할 때 인코딩(변환)을 실시함으로서 전송 효율을 높일 수 있다.
   
• 메시지 바디와 엔티티 바디의 차이
  • 메시지 : HTTP 통신의 기본 단위로 옥텟 시퀀스(Octet sequence, Octet은 8비트)로 구성되고 통신을 통해서 전송된다.
  • 엔티티 : 요청(request)와 응답(response)의 페이로드(payload, 부가물)로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.
     
    HTTP 메시지 바디의 역할은 요청과 응답에 관한 엔티티 바디를 운반하는 일이다. 기본적으로 메시지 바디와 엔티티 바디는 같지만 전송 코딩이 적용된 경우네는 바디 내용이 변화하기 때문에 메시지 바디와 달라진다.
     
• 콘텐츠 코딩(Content Codings)
   
  파일을 zip으로 압축해서 송신하는 것 처럼 HTTP에도 콘텐츠 코딩(Content Coding)이라고 불리는 기능이 있다. 콘텐츠 코딩은 엔티티에 적용하는 인코딩을 가리키는데 엔티티 정보를 유지한채 압축한다. 압축된 엔티티는 수신한 클라이언트 측에서 디코딩한다.
   
• 청크 전송 코딩(Chunked transfer Coding)
   
  사이즈가 큰 데이터를 전송하는 경우 데이터를 분할해서 조금씩 표시할 수 있다. 이렇게 엔티티 바디를 분할하는 기능을 청크 전송 코딩(Chunked transfer Coding)이라 부른다.
   
  청크 전송 코딩은 엔티티 바디를 청크(덩어리)로 분해한다. 다음 청크 사이즈를 16진수로 사용해서 단락을 표시하고 엔티티 바디 끝에는 "0(CR + LF)"를 기록해둔다.
   
  청크 전송 코딩된 엔티티 바디는 수신한 클라이언트 측에서 원래의 엔티티 바디로 디코딩한다. HTTP/1.1에는 전송 코딩(Transfer Codings)라는 어떤 인코딩 방식에 따라서 전송하는 구조가 마련되어 있지만 전송 코딩에는 청크 전송 코딩만 정의되어 있다.
   

  멀티 파트(Multipart)

   
  메일의 경우 MIME(Multipurpose Internet Mail Extensions: 다목적 인터넷 메일 확장 사양)으로 불리는 기능을 사용하여 텍스트나 영상, 이미지와 같은 여러 다른 데이터를 다룰 수 있다. 이 MIME의 여러 다른 종류의 데이터를 수용할 수 있는 것은 확장 사양에 있는 멀티파트(Multipart)를 사용하고 있기 때문이다.
   
  HTTP도 멀티파트에 대응하고 있어 하나의 메시지 바디 내부에 엔티티를 여러 개 포함시켜 보낼 수 있다. HTTP 메시지로 멀티파트를 사용할 때에는 Content-type 헤더 필드를 사용한다.
   
  멀티파트 각각의 엔티티를 구분하기 위해 "boundary" 문자열을 사용한다. 각 엔티티의 prefix에는 "boundary" 문자열 앞에 "--"을 삽입한다.(예를 들면, "--AaB03x", "--THIS_STRING_SEPARATES"). 멀티파트의 마지막에는 그 문자열의 마지막 부분에 "--"를 삽입해서(예를 들면, "--AaB03x--", "--THIS_STRING_SEPARATES--") 마무리 한다.
   

  레인지 리퀘스트(Range Request)

   
  대용량의 이미지와 데이터를 다운로드하는 중 커넥션이 끊어지게 되면 처음부터 다시 다운로드를 해야하는 문제가 있었다. 이 문제를 해결하기 위해서 일반적인 리줌(resume)이라는 기능이 필요하게 되었고 이 기능을 통해 이전에 다운로드를 한 곳에서부터 다운로드를 재개할 수 있다.
   
  이 기능을 실현하기 위해서는 엔티티 범위를 지정해서 다운로드를 할 필요가 있다. 이와 같이 범위를 지정하여 리퀘스트 하는 것을 레인지 리퀘스트(Range Request)라고 부른다.
   
  레인지 리퀘스트를 할 때는 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

   

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

   
  영어와 한국어와 같이 서로 다른 언어를 주로 사용하는 브라우저가 같은 URI에 액세스할 떄에 각각 영어판 웹페이지와 한국어판 웹 페이지를 표시한다. 이와 같은 구조를 콘텐츠 네고시에이션(Content Negotiation)이라고 부른다.

1. 클라이언트와 서버가 제공하는 리소스의 내용에 대해서 교섭하는 것이다.
2. 클라이언트에 더욱 적합한 리소스를 제공하기 위한 구조이다.
3. 제공하는 리소스를 언어와 문자 세트, 인코딩 방식 등을 기준으로 판단하고 있다.
    
   판단 기준은 요청 메시지에 포함된 다음과 같은 요청 헤더 필드이다.

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Content-Language
   
  콘텐츠 네고시에이션에는 다음과 같은 종류들이 있다.
   
• 서버 구동형 네고시에이션(Server-driven Negotiation)
  서버 측에서 콘텐츠 네고시에이션을 하는 방식이다. 서버 측에서 요청 헤더 필드의 정보를 참고해서 자동적으로 처리한다.
   
• 에이전트 구동형 네고시에이션(Agent-driven Negotiation)
  클라이언트 측에서 콘텐츠 네고시에이션을 하는 방식이다. 브라우저에 표시된 선택지 중에서 유저가 수동으로 선택한다.
  JavaScript 등을 사용해서 웹 페이지에서 자동적으로 이것을 정하는 것도 있다. 예를 들어 OS의 종류나 브라우저의 종류 등에 의해서 PC용과 스마트폰용의 웹페이지를 자동으로 전환하는 것이 이에 해당한다.
   
• 트랜스페어런트 네고시에이션(Transparent Negotiation)
  서버 구동형과 에이전트 구동형을 혼합한 것으로 서버와 클라이언트가 각각 콘텐츠 네고시에이션을 하는 방식이다.

 

**본 글은 "그림으로 배우는 Http&Network Basic"의 내용을 정리하였습니다