CS_ HTTP 메시지에 있는 HTTP 정보

정윤숙·2023년 7월 21일

HTTP&Network

CS

목록 보기

3/5

📒 오늘의 공부

1. 그림으로 배우는 Http & Network

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

1. HTTP 메시지

HTTP 메시지: HTTP에서 교환하는 정보
- 복수 행(개행 문자는 CR+LF)의 데이터로 구성된 텍스트 문자열
- 리퀘스트 메시지: 리퀘스트 측 HTTP 메시지
- 리스폰스 메시지: 리스폰스 측 HTTP 메시지
- 구조: 메시지 헤더 / 개행문자[CR+LF] / 메시지 바디
  - 메시지 헤더: 서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성 등
  - [CR+LF]: CR(carriage return:16진수 0x0d), LF(line feed:16진수 0x0a)
  - 메시지 바디: 꼭 전송되는 데이터 그 자체

CR+LF(Carriage Return + Line Feed)란?

컴퓨터에서 개행(새로운 줄로 이동)을 표현하는 데 사용되는 제어 문자의 조합
이 조합은 텍스트 파일이나 텍스트 기반의 데이터를 표현할 때 줄 바꿈을 나타내기 위해 사용
- CR (Carriage Return): 캐리지 리턴은 표기상으로 \r으로 나타내며, 행의 시작으로 커서를 이동시킨다.
  ex. "Hello\rWorld"에서 \r은 "Hello"와 "World" 사이에서 커서를 첫 번째 문자 "H"로 이동. 이후에 오는 문자열은 "Hello"를 덮어쓰게 된다.
- LF (Line Feed): 라인 피드는 표기상으로 \n으로 나타내며, 커서를 다음 줄로 이동시킨다.
  ex. "Hello\nWorld"에서 \n은 "Hello"의 다음 줄로 커서를 이동시킨다.
CR+LF는 초기 컴퓨터에서 사용되던 줄 바꿈 표시 방식으로, 특히 MS-DOS와 Windows 운영 체제에서 널리 사용되었다.
- MS-DOS와 Windows에서는 줄 바꿈을 나타내기 위해 항상 CR(캐리지 리턴)와 LF(라인 피드)를 연속해서 사용한다.
- 텍스트 파일 등을 MS-DOS/Windows 환경에서 작성하고 저장하면 각 줄이 CR+LF로 구분되는 형태로 저장된다.
- 유닉스 및 리눅스 운영 체제에서는 LF(라인 피드)만 사용하여 줄 바꿈을 나타낸다.
- 텍스트 파일 등을 유닉스/리눅스 환경에서 작성하고 저장하면 각 줄이 LF로 구분되는 형태로 저장된다.
CR+LF와 LF는 각 운영 체제에서의 줄 바꿈 표시 방식의 차이로, 텍스트 파일을 다른 운영 체제로 이동할 때 주의해야한다.
- 이를 위해 텍스트 편집기 등에서는 줄 바꿈 표시 방식을 변경할 수 있는 기능을 제공하고 있다.

2. 리퀘스트, 리스폰스 메시지 구조

기본 구조: 메시지 헤더 / 개행문자[CR+LF] / 메시지 바디
- 리퀘스트 메시지 헤더
  - 리퀘스트 라인 / 리퀘스트 헤더 필드 / 일반 헤더 필드 / 엔티티 헤더 필드 / 그 외
- 리스폰스 메시지 헤더
  - 상태 라인 / 리스폰스 헤더 필드 / 일반 헤더 필드 / 엔티티 헤더 필드 / 그외
리퀘스트 라인
- 리퀘스트에 사용하는 메소드와 리퀘스트 URI와 사용하는 HTTP 버전 포함
상태 라인
- 리스폰스 결과를 나타내는 상태 코드와 설명, 사용하는 HTTP 버전 포함
헤더 필드
- 리퀘스트와 리스폰스의 여러 조건과 속성 등을 나타내는 각종 헤더 필드 포함
- 일반 헤더 필드, 리퀘스트 헤더 필드, 리스폰스 헤더 필드, 엔티티 헤더 필드 등 4종류
그 외
- HTTP의 RFC에는 없는 헤더 필드(쿠키 등)이 포함되는 경우가 있다.

HTTP의 RFC란?

RFC (Request for Comments)는 인터넷 표준 및 프로토콜을 정의하고 설명하는 문서를 의미
HTTP의 RFC는 HyperText Transfer Protocol의 정의와 동작 방식에 대해 설명하고 있으며, HTTP 통신에 사용되는 프로토콜 규격을 제시한다.
- 가장 널리 사용되는 HTTP 버전인 HTTP/1.1의 경우, RFC 7230부터 RFC 7235까지의 일련의 문서들에 걸쳐 정의되어 있다.
- 이러한 RFC 문서들은 HTTP 프로토콜의 구성 요소, 헤더, 상태 코드, 메소드 등을 정의하고, HTTP 메시지의 형식과 전송 방법, 보안과 인증 등에 대해 설명한다.

3. 인코딩으로 전송 효율 높이기

HTTP로 데이터를 전송할 때 인코딩(변환)을 실시함으로써 전송 효율을 높일 수 있다.
컴퓨터에서 인코딩 처리를 해야 하기 때문에 CPU 등의 리소스는 보다 많이 소비하게 된다.
메시지 바디와 엔티티 바디의 차이
- 메시지(message): HTTP 통신의 기본 단위. 옥텟 시퀀스(Octet Sequence, octet은 8비트)로 구성되고 통신을 통해 전송된다.
- 엔티티(entity): 리퀘스트랑 리스폰스의 페이로드(payload, 부가물)로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.

옥텟 시퀀스(Octet Sequence)란?

8개의 비트로 이루어진 이진 데이터를 나타내는 데이터 구조
각각의 비트는 0 또는 1의 값을 가질 수 있으며, 8개의 비트가 조합되어 하나의 바이트(Byte)를 형성
옥텟 시퀀스는 이진수로 표현되기 때문에 다양한 데이터를 나타낼 수 있다.
ex. ASCII 문자, 이미지, 오디오, 비디오 등 모든 종류의 데이터를 옥텟 시퀀스로 표현 가능
옥텟 시퀀스는 컴퓨터에서 데이터를 처리하고 저장하는 데 기본적으로 사용되며, 이를 조합하여 다양한 형식의 데이터를 생성하고 해석할 수 있다.

HTTP 메시지 바디의 역할: 리퀘스트랑 리스폰스에 관한 엔티티 바디를 운반
- 기본적으로 메시지 바디와 엔티티 바디는 같지만 전송 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하여 메시지 바디와 달라진다.
압축해서 보내는 콘텐츠 코딩(Content Codings)
- 콘텐츠 코딩은 엔티티에 적용하는 인코딩을 가리키는데 엔티티 정보를 유지한 채로 압축한다.
- 콘텐츠 코딩된 엔티티는 수신한 클라이언트 측에서 디코딩한다.
- 주요 콘텐츠 압축
  - gzip(GNU zip)
  - compress(UNIX의 표준 압축)
  - deflate(zlib)
  - identity(인코딩 없음)
분해해서 보내는 청크 전송 코딩
- HTTP통신에서는 리퀘스트한 리소스 전부에서 엔티티 바디의 전송이 완료되지 않으면 브라우저에 표시되지 않는다.
- 청크 전송 코딩(Chunked Transfer Coding): 사이즈가 큰 데이터를 전송할 때 데이터를 작은 조각(청크)으로 나누어 전송하는 방식. 엔티티 바디를 분할하는 기능.
  - 엔티티 바디를 청크(덩어리)로 분해
  - 청크 사이즈를 16진수로 사용해서 단락을 표시
  - 엔티티 바디 끝에 "0(CR+LF)"를 기록
  - 청크 전송 코딩된 엔티티 바디는 클라이언트 측에서 원래의 엔티티 바디로 디코딩

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

MIME(Multipurpose Internet Mail Extensions: 다목적 인터넷 메일 확장 사양)
- 텍스트, 영상, 이미지와 같은 여러 다른 데이터를 다루기 위한 기능 사용
- 이미지 등의 바이너리 데이터를 아스키(ASCII) 문자열에 인코딩하는 방법, 데이터 종류를 나타내는 방법 등을 규정
- MIME의 확장 사양에 있는 멀티파트(Multipart)라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 사용하는 것
HTTP도 멀티파트에 대응하고 있어 하나의 메시지 바디 내부에 엔티티 여러 개를 포함시켜 보낼 수 있다.
- 주로 이미지나 텍스트 파일 등을 업로드할 때 사용되고 있다.

멀티파트(Multipart)란?

MIME(Multipurpose Internet Mail Extensions) 형식의 하나로, 여러 개의 독립적인 데이터 블록을 하나의 메시지에 결합하여 전송하거나 표현하는 방식

멀티파트 종류
- multipart/form-data: Web 폼으로부터 파일 업로드에 사용
- multipart/byteranges: 상태 코드 206(Partial Content) 리스폰스 메시지가 복수 범위의 내용을 포함할 때 사용
HTTP 메시지로 멀티파트를 사용할 때에는 Content-type 헤더 필드를 사용
멀티파트 각각의 엔티티를 구분하기 위해 "boundary" 문자열 사용
- 각 엔티티의 선두에 "boundary" 문자열 앞에 "ㅡㅡ"를 삽입
  ex. "ㅡㅡAaB03x"
- 멀티파트의 마지막에는 해당 문자열의 마지막에 "ㅡㅡ"를 삽입
  ex. "ㅡㅡAaB03xㅡㅡ"
멀티파트는 파트마다 헤더 필드가 포함된다.
파트의 중간에 멀티파트를 만드는 것과 같이 파트를 내부에 포함할 수 있다.

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

리줌(resume) 기능: 대용량 이미지와 데이터를 다운로드할 때 커넥션이 끊어지면 처음부터 다시 다운로드를 해야 하는 문제를 해결하기 위해 만들어진 기능으로 이전에 다운로드를 한 곳에서부터 다운로드를 재개한다.
- 이 기능을 실현하기 위해서는 엔티티의 범위를 지정해서 다운로드를 해야 한다.
레인지 리퀘스트(Range Request): 범위를 지정하여 리퀘스트 하는 것
- 전체 10,000 바이트 정도 크기의 리소스에서 5,001~10,000 바이트의 범위(바이트 레인지) 만을 리퀘스트할 수 있다.
- 레인지 리퀘스트를 할 때는 Range 헤더 필드를 사용해서 리소스의 바이트레인지를 지정한다.
  - 5,001~10,000 바이트
    => Range: bytes = 5001-10000
  - 5,001 바이트 이상
    => Range: bytes = 5001-
  - 처음부터 3,000 바이트까지, 그리고 5,000~7,000 바이트까지의 복수 범위
    => Range: bytes = 5001, 5000-7000
레인지 리퀘스트에 대한 리스폰스: 상태 코드 206 Partial Content
복수 범위의 레인지 리퀘스트에 대한 리스폰스: multipart/byteranges
서버가 레인지 리퀘스트에 지원하지 않는 경우: 상태 코드 200 OK로 완전한 엔티티가 되돌아온다.

6. 콘텐츠 네고시에이션

같은 콘텐츠(내용)이지만 여러 개의 페이지를 지닌 웹 페이지
ex. 내용은 같지만 영어판, 한국어판과 같이 표시되는 언어가 다른 경우
- 서로 다른 언어를 사용하는 브라우저가 같은 URI에 액세스 할 때 각각 영어판 웹 페이지와 한국어판 웹 페이지를 표시하는데 이와 같은 구조를 콘텐츠 네고시에이션(Content Negotiation)이라고 한다.
콘텐츠 네고시에이션(Content Negotiation)
- 클라이언트와 서버가 제공하는 리소스의 내용에 대해서 교섭하는 것
- 클라이언트에 더욱 적합한 리소스를 제공하기 위한 구조
- 콘텐츠 네고시에이션은 제공하는 리소스를 언어와 문자 세트, 인코딩 방식 등을 기준으로 판단
- 판단 기준은 아래와 같은 리퀘스트 헤더 필드
  - Accept
  - Accept-Charset
  - Accept-Encoding
  - Accept-Language
  - Content-Language
- 종류
  - 서버 구동형 네고시에이션(Server-driven Negotiation): 서버 측에서 콘텐츠 네고시에이션을 하는 방식. 서버 측에서 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리.
  - 에이전트 구동형 네고시에이션(Agent-driven Negotiation): 클라이언트 측에서 텐츠 네고시에이션을 하는 방식. 브라우저에 표시된 선택지 중에서 유저가 수동으로 선택.
    Javascript 등을 사용해서 웹 페이지에서 자동적으로 이것을 정하는 것도 있다. ex. OS의 종류나 브라우저의 종류 등에 의해 PC용과 스마트폰용의 웹 페이지를 자동으로 전환하는 것이 이에 해당
  - 트랜스페어런트 네고시에이션(Transparent Negotiation): 서버 구동형과 에이전트 구동형을 혼합한 것. 서버와 클라이언트가 각각 콘텐츠 네고시에이션을 하는 방식