백엔드 공부 메모/네트워크

HTTP 메시지

볼륨조절불가 2024. 2. 29. 20:12
728x90

 

 

* 해당 게시글은 <그림으로 배우는 Http&Network Basic>을 읽고 정리하면서 공부하기 위해 메모하듯 작성하는 글입니다.

 

 

 

 

HTTP 메시지의 구조

  • HTTP에서 교환하는 정보를 HTTP 메시지라고 함
  • 복수 행(개행 문자는 CR+LF)의 데이터로 구성된 텍스트 문자열
  • 최초에 나타나는 개행 문자로 메시지 헤더와 메시지 바디를 구분

리퀘스트 메시지의 구조

리퀘스트 라인

  • 리퀘스트에 사용하는 메소드와 리퀘스트 URI, 사용하는 HTTP 버전을 명시하는 라인

리스폰스 메시지의 구조

상태 라인

  • 리스폰스 결과를 나타내는 상태 코드와 설명, 사용하는 HTTP 버전을 명시한 라인

 

 

 

 

인코딩

HTTP로 데이터를 전송할 때, 인코딩(변환)을 하여 전송 효율을 높일 수 있음
  • 전송시 컴퓨터에서 인코딩 처리→CPU 등의 리소스를 전보다 더 소비
  • 서버 측에서도 디코딩(해독)을 위해 CPU 등의 리소스를 전보다 더 소비

엔티티

  • HTTP 메시지(리퀘스트, 리스폰스)에 적재되는 실제 데이터(정보). 부가물(payload)이라고도 함
  • 엔티티 헤더+엔티티 바디 구조로 구성

메시지

  • HTTP 통신의 기본 단위로 옥텟 시퀀스(8비트열)로 구성됨
  • 메시지 바디의 역할→엔티티 바디를 운반(전달)하는 일
    • 메시지 바디를 운반책, 엔티티 바디를 화물 정도로 생각하면 됨
  • HTTP 메시지에 전송 인코딩이 적용되면 엔티티 바디의 내용이 변화

콘텐츠 코딩

엔티티에 적용하는 인코딩
  • 전송할 데이터의 용량을 줄이기 위해 HTTP에서 엔티티를 압축할 때 사용됨
  • 주요 콘텐츠 압축의 종류
    • gzip(GNU zip)
    • compress(UNIX의 표준 압축)
    • deflate(zlib)
    • identity(인코딩 없음)

청크 전송 코딩

엔티티 바디를 분할하는 기능
  • HTTP: 리퀘스트한 리소스를 브라우저에서 볼 때, 엔티티 바디의 전송이 아직 완료되지 않으면 브라우저에서 볼 수 없음
  • 사이즈가 큰 데이터를 전송할 때→데이터를 분할해서 조금씩 표시
  • 방식
    • 엔티티 바디를 청크(덩어리)로 분해
    • 다음 청크 사이즈를 16진수로 적으면서 단락 표시, 엔티티 바디 끝에는 ‘0(CR+LF)’를 기록
  • 참고: HTTP 1.1 버전의 전송 코딩에는 청크 전송 코딩만이 정의됨

 

 

 

 

멀티파트

MIME(Multipurpose Internet Mail Extensions)

  • 메일의 경우 복수의 첨부파일을 붙여 함께 전송 가능→MIME(인터넷 메일 확장 사양)
  • MIME는 이미지 등의 바이너리 데이터를 아스키 문자열에 인코딩하는 방법, 데이터 종류를 나타내는 방법 등을 규정

멀티파트

클라이언트와 서버 간에 전송되는 HTTP 요청 또는 응답에서 여러 종류의 데이터를 동시에 전송하기 위해 사용되는 방식. MIME의 확장 사양임
  • 주로 이미지나 텍스트 파일 등을 업로드할 때 사용
  • 등장 배경
    • HTTP 메시지의 Content-Type 헤더 필드에는 text/plain, image/jpeg 등의 값이 하나씩만 들어갈 수 있어 여러 종류의 데이터를 보내지 못함

멀티파트 종류

HTTP 메시지의 Content-Type 헤더 필드에 멀티파트 종류 지정 가능

multipart/form-data

  • 웹 폼으로부터 파일을 업로드하는 데 사용
  • 파일이나 이미지는 문자가 아닌 바이너리 데이터로 전송해야 함→문자나 숫자 데이터(쿼리 스트링)와는 독립적인 처리(인코딩) 필요
  • 멀티파트 요청은 여러 개의 파트로 구성되며, 각 파트마다 헤더(메타 데이터)와 바디(실제 데이터) 존재
    • 멀티파트 요청 각각의 파트(엔티티)를 구별하기 위해 boundary 문자열(임의로 정해짐. 아래 예시에선 AaB03x) 사용
Content-Type: multipart/form-data; boundary=AaB03x

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

Chanhyuk
--AaB03x
Content-Disposition: form-data; name=”pics”; filename=”file1.txt”
Content-Type: text/plain
…(file1.txt의 데이터)…
--AaB03x--

 

multipart/byteranges

  • 상태 코드 206(Paritial Content) 리스폰스 메시지가 복수 범위(전체 내용의 여러 일부분)의 내용을 포함하는 때에 사용
HTTP/1.1 206 Partial Content
Date: Fri, 13 Jul 2012 02:45:26 GMT
Last-Modified: Fri, 13 Aug 2002 11:53:16 GMT
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes=500-999/8000

…(지정한 범위의 데이터: 전체 8000바이트 중 500-999 바이트를 차지하는 부분)…
--THIS_STRING_SEPARATES

Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

…(지정한 범위의 데이터: 전체 중 7000-7999 바이트 범위)…
--THIS_STRING_SEPARATES--

 

 

 

 

레인지 리퀘스트

등장 배경

  • 요즘은 네트워크 속도가 빨라서 대용량의 이미지와 데이터를 다운받기 쉬웠으나, 옛날엔 아니었음
    • 다운로드 중에 커넥션이 끊어지면, 처음부터 다시 다운받아야 했기 때문
  • 그래서 리줌 기능(이전에 다운로드한 곳에서부터 다운로드 재개)이 필요해졌고, 이를 가능하게 하는 리퀘스트 방법이 레인지 리퀘스트

레인지 리퀘스트 진행 방식

  • 클라이언트: HTTP 요청시 Range 헤더 필드로 원하는 범위를 설정
  • 서버: Content-Range 헤더 필드로 응답하는 데이터의 범위를 명시
    • 서버가 레인지 리퀘스트를 지원하지 않는 경우 200 OK 상태 코드와 함께 전체 범위 엔티티로 응답

 

 

 

 

컨텐츠 네고시에이션

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

  • 컨텐츠 네고시에이션에 의해, 같은 컨텐츠더라도 요청하는 클라이언트에 따라 서버가 다른 형식(한국어판, 영어판 등)으로 응답 가능
예시) 구글 사이트
영어판 브라우저의 경우 영어판 페이지를 표시하고, 한국판 브라우저의 경우 한국어판 페이지 표시

컨텐츠 네고시에이션의 판단 기준

서버는 클라이언트가 보내는 리퀘스트 메시지의 헤더 필드 중 아래 5개를 보고 컨텐츠 네고시에이션 진행
  • Accept
  • Accept-Charset
  • Accept-Encoding
  • Accept-Language
  • Content-Language

컨텐츠 네고시에이션의 종류

서버 구동형 네고시에이션

서버 측에서 컨텐츠 네고시에이션을 하는 방식

  • 서버 측에서 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리
  • 브라우저가 보내는 정보를 근거로 선택→유저에게 정말로 적절한 것이 선택됐는지는 불확실

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

클라이언트 측에서 컨텐츠 네고시에이션을 하는 방식

  • 브라우저에 표시된 선택지 중에서 유저가 수동 선택
  • 자바스크립트 등을 사용해 웹페이지에서 자동적으로 이것을 정하는 경우 존재
  • 예시: OS의 종류나 브라우저 종류 등을 보고 PC용과 스마트폰용 웹 페이지 자동 전환

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

서버 구동형과 에이전트 구동형을 혼합한 것

  • 서버와 클라이언트가 각각 컨텐츠 네고시에이션을 하는 방식
728x90