HTTP 메세지는 무엇일까?

제이든·2021년 4월 26일
1

네트워크

목록 보기
5/13
post-thumbnail

1. HTTP 메세지란

1.1 HTTP 메세지는..

  • HTTP 통신 시 리퀘스트 / 리스폰스에 담긴 정보를 말합니다.
  • 크게 메시제 헤더와 메세지 헤더와 메세지 바디로 구성되어 있고 최초에 나타나는 개행 문자(CR + LF)로 헤더와 메세지 바디를 구분합니다.

🕶 캐리지 리턴이란❓

CR, LF 와 이 용어들의 조합인 CRLF 는 개행의 방식을 의미합니다.
타자기를 사용하던 시절에는 다음과 같은 방식으로 개행이 동작했었습니다.

  • CR : 현재 커서를 줄 올림 없이 가장 앞으로 옮기는 동작
  • LF : 커서는 그 자리에 둔 상태로 종이만 한줄 올려 줄을 바꾸는 동작

잠시 캐리지 리턴에 대해서 알아보았습니다. 이어서 HTTP 메세지의 구조에 대해서 알아보겠습니다.

1.2 HTTP 메세지의 구조

이미지 출처

  • 메세지 헤드, 개행 문자, 메세지 바디로 구성됩니다.

메세지 구조

  • head
    start-line : 실행되어야 할 요청, 또는 요청 수행에 대한 성공, 실패 유무 기록
    HTTP headers : 요청에 대한 설명 혹은 메세지 본문에 대한 설명
  • empty line(CR+LF) : 요청에 대한 메타 정보가 전송되었음을 알림
  • body : 전송되는 데이터 그 자체를 의미합니다. payload

HTTP / 2.0 에서는 프레이밍 메커니즘이 추가되어 데이터와 헤더 프레임이 분리되었기 때문에 프레임을 더 쉽게 확인할 수 있습니다.

2. 인코딩

인코딩
이미지 출처

  • 인코딩(Encoding) : 사용자가 입력한 문자나 기호들을 컴퓨터 신호로 바꾸는 것입니다.
    ex) 유니코드, 아스키

  • 디코딩(Decoding) : 인코딩과 반대의 작업을 의미하고 소프트웨어 알고리즘을 의미합니다.

2.1 인코딩이 왜 필요한가 ❓

HTTP로 데이터를 그대로 전송할 수도 있지만 전송할 때에 인코딩을 실시함으로 전송 효율을 높일 수 있기 때문입니다.
단, CPU등의 리소스는 보다 많이 소비할 수도 있습니다.

2.2 인코딩 종류

2.2.1 콘텐츠 코딩

  • 엔티티에 적용하는 인코딩을 가리키는데 엔티티 정보를 유지한 채로 압축합니다. 인코딩된 엔티티는 수신한 클라이언트 측에서 디코딩합니다.
  • gzip, compress, deflate, identity 등이 있다.

2.2.2 청크 전송 코딩

  • 사이즈가 큰 데이터를 전송하는 경우에 사용이 됩니다.
  • 엔티티 바디를 분할해서 전송하는 기능을 청크 전송 코딩(Chunked transfer Coding) 이라고 부릅니다.

3. Range Request

사용자가 광대역의 네트워크를 이용할 수 있기 전에는 대용량의 이미지와 데이터를 다운로드하기 힘들었습니다. 다운로드 중 커넥션이 끊어지면 다시 다운로드를 시작해야 했기 때문입니다.

이를 해결하고자 resume 기능이 필요했고 엔티팉의 범위를 지정해서 다운로드 하는 방식으로 resume 기능을 구현했습니다.

이미지 출처

4. Content Negotiation

동일한 URI에서 리소스의 서로 다른 버전을 서브하기 위해 사용되는 메커니즘으로, 사용자 에이전트가 사용자에게 제일 잘 맞는 것이 무엇인지(예를 들어, 문서의 언어, 이미지 포맷 혹은 컨텐츠 인코딩에 있어 어떤 것이 적절한지)를 명시할 수 있습니다.

content negotiation

4.1 기준

Content Negotiation은 제공하는 리소스를 언어와 문자 세트, 인코딩 방식등을 기준을 판단합니다.
다음과 같은 리퀘스트 헤더 필드가 판단 기준을 제공합니다.

  • Accept
  • Accept-Charet
  • Accept-Encoding
  • Accept-Language
  • Content-Language

4.2 방식

4.2.1 서버 주도형 협상

간단하게 말해서 서버 내부의 알고리즘을 통해 자동으로 처리하는 방식입니다.

서버 주도형 협상이 일반적인 방법이긴 하지만, 몇가지 결점을 가지고 있습니다.

  • 서버는 브라우저에 대한 전체적인 지식을 가지고 있지 않습니다. 즉, 서버는 브라우저의 수용 능력에 대한 완벽한 정보를 가지고 있진 않습니다. 클라이언트가 선택하는 에이전트 주도 협상과는 다르게, 서버 선택은 다소 임의적입니다.

  • 클라이언트에 의한 정보는 상당히 장황하며 사생활 침해에 대한 위협을 가지고 있습니다(HTTP 핑거프린팅).

4.2.2 에이전트 주도 협상

  • 이 협상에서, 애매모호한 요청과 맞닥뜨렸을 경우, 서버는 사용 가능한 대체 리소스들에 대한 링크를 포함하고 있는 페이지를 회신하게 됩니다. 사용자는 해당 리소스들을 표시하고 사용하려는 리소스를 선택하게 됩니다.

    클라이언트 측에서 수동으로 선택하는 방식을 의미합니다.

🎯 HTTP 메세지 구조, 인코딩, 컨텐츠 협상등에 대해 알아보았습니다. 다음 포스팅에서는 HTTP 상태코드에 대해 적어보겠습니다..!

profile
개발자 제이든

0개의 댓글