[Book - 그림으로 배우는 Http & Network Basic] 3. HTTP 정보는 HTTP 메시지에 있다.
HTTP 메시지
- HTTP 메시지
- HTTP에서 교환하는 정보
- 복수 행(개행 문자는 CR+LF)의 데이터로 구성된 텍스트 문자열
HTTP 메시지 구조
[메시지 헤더]
서버와 클라이언트가 꼭 처리해야 하는 Request와 Response 내용과 속성 등
[CR+LF]
CR(carriage return: 16진수 0x0d) + LF(line feed: 16진수 0x0a)
[메시지 바디]
꼭 전송되는 데이터 그 자체
Request 메시지와 Response 메시지의 구조
Request 메시지
Response 메시지
Request Line
Request에 사용하는 메소드와 Request URI와 사용하는 HTTP 버전 포함
Status Line
Response 결과를 나타내는 상태 코드와 설명, 사용하는 HTTP 버전 포함
Header Field
Request와 Response의 여러 조건과 속성 등을 나타내는 각종 헤더 필드 포함
그 외
HTTP의 RFC에는 없는 헤더 필드(쿠키 등)가 포함되는 경우 존재
인코딩으로 전송 효율 증가
HTTP로 데이터를 전송할 때 인코딩(변환)을 실시함으로써 전송 효율을 높일 수 있다.
인코딩 시 다량의 액세스를 효율 좋게 처리할 수 있지만, CPU 등의 리소스는 보다 많이 소비하게 된다.
message body와 entity body의 차이
message
HTTP 통신의 기본 단위로 Octet sequence(octet: 8비트)로 구성되고 통신을 통해서 전송된다.
entity
Request와 Response의 payload(부가물)로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.
HTTP 메시지 바디의 역할은 Request와 Response에 관한 엔티티 바디를 운반하는 일이다.
기본적으로 메시지 바디와 엔티티 바디는 같지만, 전송 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하기 때문에 메시지 바디와 달라진다.
압축해서 보내는 콘텐츠 코딩
콘텐츠 코딩: 엔티티에 적용하는 인코딩을 가리키고, 엔티티 정보를 유지한 채로 압축한다.
콘텐츠 고정된 엔티티: 수신한 클라이언트 측에서 디코딩한다.
- 주요 콘텐츠 압축
- gzip(GNU zip)
- compress(UNIX의 표준 압축)
- deflate(zlib)
- identity(인코딩 없음)
분해해서 보내는 청크 전송 코딩
HTTP 통신에서는 Request했었던 리소스 전부에서 엔티티 바디의 전송이 완료되지 않으면 브라우저에 표시되지 않지만, 사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시할 수 있다.
즉, 엔티티 바디를 분할하는 기능을 청크 전송 코딩(Chunked transfer Coding)이라고 부른다.
청크 전송 코딩
- 엔티티 바디를 청크(덩어리)로 분해
- 청크 사이즈를 16진수로 사용해서 단락을 표시
- 엔티티 바디 끝에 “0(CR+LF)”를 기록
이렇게 청크 전송 코딩된 엔티티 바디는 수신한 클라이언트 측에서 원래의 엔티티 바디로 디코딩한다.
여러 데이터를 보내는 멀티파트
MIME(Multipurpose Internet Mail Extensions: 다목적 인터넷 메일 확장 사양): 텍스트나 영상, 이미지와 같은 여러 데이터를 다루기 위한 기능을 사용
MIME는 이미지 등의 바이너리 데이터를 ASCII 문자열에 인코딩하는 방법과 데이터 종류를 나타내는 방법 등을 규정한다. 이 MIME의 확장 사양에 있는 Multipart라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 사용한다.
- Multipart 종류
multipart/form-data
Web 폼으로부터 파일 업로드에 사용
multipart/byteranges
상태 코드 206(Partial Content) 리스폰스 메시지가 복수 범위의 내용을 포함할 때 사용
- multipart/form-data
- multipart/byteranges
멀티파트는 파트마다 헤더 필드가 포함되며, 파트의 중간에 멀티파트를 만드는 것과 같이 파트를 내부에 포함할 수 있다.
일부분만 받는 Range Request
리줌(resume): 이전에 다운로드를 한 곳에서부터 다운로드를 재개할 수 있는 기능
리줌 기능을 실현하기 위해서는 엔티티의 범위를 지정해서 다운로드를 할 필요가 있다. 이와 같이 범위를 지정하여 Request하는 것을 Range Request라고 부른다.
Range Request를 사용하면 전체 10,000 바이트 정보 크기의 리소스에서 5,001~10,000 바이트의 범위(바이트 레인지) 만을 Request할 수 있다.
Range Request
Range Request를 할 때에는 Range 헤더 필드를 사용해서 리소스의 바이트 레인지를 지정한다.
5,001 ~ 10,000 바이트
1
Range: bytes = 5001-10000
5,001 바이트 이상
1
Range: bytes=5001-
처음부터 3,000 바이트까지, 그리고 5,000~7,000 바이트까지의 복수 범위
1
Range: bytes=-3000, 5000-7000
Range Request에 대한 Response는 상태 코드 206 Partial Content라는 Response 메시지가 되돌아온다. 또한, 복수 범위의 Range Request에 대한 Response는 multipart/byteranges로 Response가 되돌아 온다.
서버가 Range Request에 지원하지 않는 경우에는 상태 코드 200 OK라는 Response 메시지로 완전한 엔티티가 되돌아온다.
##SSSS 최적의 콘텐츠를 돌려주는 콘텐츠 네고시에이션
콘텐츠 네고시에이션(Content Negotiation): 영어와 한국어와 같이 서로 다른 언어를 주로 사용하는 브라우저가 같은 URI에 액세스할 때 각각 영어판 웹 페이지와 한국어판 웹 페이지를 표시하는 것
- 콘텐츠 네고시에이션(Content Negotiation)
- 클라이언트와 서버가 제공하는 리소스의 내용에 대해서 교섭하는 것
- 클라이언트에 더욱 적합한 리소스를 제공하기 위한 구조
- 제공하는 리소스를 언어와 문자 세트, 인코딩 방식 등을 기준으로 판단 판단 기준: Request 메시지에 포함된 아래와 같은 Request Header Field
- Accept
- Accept-Charset
- Accept-Encoding
- Accept-Language
- Content-Language
- 서버 구동형 네고시에이션(Server-driven Negotiation)
- 서버 측에서 콘텐츠 네고시에이션을 하는 방식
- 서버 측에서 Request Header Field의 정보를 참고해서 자동적으로 처리
- 브라우저가 보내는 정보를 근거로 하기 때문에 유저에게 정말 적절한 것이 선택되었다고 할 수는 없음
- 에이전트 구동형 네고시에이션(Agent-driven Negotiation)
- 클라이언트 측에서 콘텐츠 네고시에이션을 하는 방식
- 브라우저에 표시된 선택지 중에서 유저가 수동으로 선택
- OS의 종류나 브라우저의 종류 등에 의해서 PC용과 스마트폰용의 웹 페이지를 JavaScript 등을 사용해서 자동으로 전환하기도 함
- 트랜스페어런트 네고시에이션(Transparent Negotiation)
- 서버 구동형과 에이전트 구동형을 혼합한 것
- 서버와 클라이언트가 각각 콘텐츠 네고시에이션을 하는 방식