Chapter 15. Entities and Encodings
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Preface
HTTP ships billions of media objects of all kinds every day. Images, text, movies, software programs... you name it, HTTP ships it. HTTP also makes sure that its messages can be properly transported, identified, extracted, and processed. In particular, HTTP ensures that its cargo:
• Can be identified correctly (using Content-Type media formats and Content-Language headers) so browsers and other clients can process the content properly
• Can be unpacked properly (using Content-Length and Content-Encoding headers)
• Is fresh (using entity validators and cache-expiration controls)
• Meets the user’s needs (based on content-negotiation Accept headers)
• Moves quickly and efficiently through the network (using range requests, delta encoding, and other data compression)
• Arrives complete and untampered with (using transfer encoding headers and Content-MD5 checksums)
-
HTTP는 매일 수십억에 달하는 미디어 객체를 실어 나릅니다.
-
이미지, 텍스트, 영화, 소프트웨어 프로그램 등 이름만 대면 알 만한 모든 것들을 HTTP가 운반하고 있습니다.
-
HTTP는 메시지가 적절히 운송되고, 식별되고, 추출되고, 처리될 수 있도록 보장하기도 합니다.
-
특히 HTTP는 자신이 운반하고 있는 그 화물 자체를 보장합니다.
- 메시지가 Content-Type 미디어 포맷과 Content-Language 헤더를 통해 올바르게 식별될 수 있습니다. 따라서 브라우저와 기타 클라이언트가 해당 콘텐츠를 적절히 처리할 수 있습니다.
- 메시지가 Content-Length와 Content-Encoding 헤더를 통해 압축을 해제할 수 있습니다.
- Entity Validator와 캐시 만료일시 제어를 통해 메시지가 충분히 최신 것인지 확인할 수 있습니다.
- 콘텐츠 협상 Accept 헤더를 통해 사용자의 요구를 충족시킬 수 있습니다.
- 범위 요청, 델타 인코딩, 기타 데이터 압축을 통해 메시지가 네트워크를 통해 빠르게 전송될 수 있습니다.
- 전송 인코딩 헤더와 Content-MD5 체크섬을 활용하여 변조가 발생하지 않은 완전한 메시지를 전달할 수 있습니다.
To make all this happen, HTTP uses well-labeled entities to carry content.
- 이 모든 것이 가능하기 위해서는 HTTP가 알맞게 지정된 엔티티를 사용하여 콘텐츠를 운반해야 합니다.
This chapter discusses entities, their associated entity headers, and how they work to transport web cargo. We’ll show how HTTP provides the essentials of content size, type, and encodings. We’ll also explain some of the more complicated and powerful features of HTTP entities, including range requests, delta encoding, digests, and chunked encodings.
-
이번 챕터에서는 엔티티부터 그와 연관된 엔티티 헤더, 나아가 웹 상의 화물을 운반하는 방식에 대해 살펴봅니다.
-
HTTP가 콘텐츠 사이즈, 타입, 인코딩의 필수 요소를 어떻게 제공하고 있는지 보여드리겠습니다.
-
또한 범위 요청, 델타 인코딩, 다이제스트, 청크 인코딩 등 HTTP 엔티티가 가진 더 복잡하고 강력한 특성들에 대해 설명할 것입니다.
This chapter covers:
• The format and behavior of HTTP message entities as HTTP data containers
• How HTTP describes the size of entity bodies, and what HTTP requires in the way of sizing
• The entity headers used to describe the format, alphabet, and language of content, so clients can process it properly
• Reversible content encodings, used by senders to transform the content data format before sending to make it take up less space or be more secure
• Transfer encoding, which modifies how HTTP ships data to enhance the communication of some kinds of content, and chunked encoding, a transfer encoding that chops data into multiple pieces to deliver content of unknown length safely
• The assortment of tags, labels, times, and checksums that help clients get the latest version of requested content
• The validators that act like version numbers on content, so web applications can ensure they have fresh content, and the HTTP header fields designed to control object freshness
• Ranges, which are useful for continuing aborted downloads where they left off
• HTTP delta encoding extensions, which allow clients to request just those parts of a web page that actually have changed since a previously viewed revision
• Checksums of entity bodies, which are used to detect changes in entity content as it passes through proxies
- 이번 챕터에서 다루는 내용들은 다음과 같습니다.
- HTTP 데이터 컨테이너로써 HTTP 메시지 엔티티의 포맷과 동작
- HTTP가 엔티티 본문의 사이즈를 나타내는 방법과 사이즈 조정 과정에서 필요로 하는 요소
- 엔티티 헤더 : 클라이언트가 적절히 처리할 수 있도록 포맷, 알파벳, 언어를 표현하기 위해 사용하는 헤더
- 디코딩 가능한 콘텐츠 인코딩 : 전송 전에 콘텐츠 데이터의 포맷을 변환하여 적은 공간으로 안전하게 통신하기 위한 기법
- 전송 인코딩 : HTTP가 데이터를 전달하는 방식을 바꾸어 특정 종류의 콘텐츠와의 통신을 향상시키는 기법
- 청크 인코딩 : 데이터를 여러 개의 조각으로 나누어 임의의 길이를 가진 콘텐츠를 안전하게 전송하는 전송 인코딩 기법
- 클라이언트가 요청한 콘텐츠의 최신 버전을 전달하기 위한 태그, 라벨, 시간, 체크섬의 모음
- Validator : 콘텐츠의 버전 번호처럼 동작하면서 웹 응용 프로그램이 최신 콘텐츠를 보유하고 있고 HTTP 헤더 필드가 객체의 최신성을 제어할 수 있도록 설계되었음을 보증하는 기술
- Range : 중단된 다운로드를 중단 시점부터 재개할 때 유용한 기법
- HTTP 델타 인코딩 확장 : 클라이언트가 웹 페이지에서 마지막으로 본 리비전 이후로 변화가 발생한 특정 부분만 요청할 수 있도록 허가하는 기술
- 엔티티 본문 체크섬 : 프록시를 통과할 때 엔티티 본문의 변화를 감지하기 위해 사용되는 기술
Messages Are Crates, Entities Are Cargo
If you think of HTTP messages as the crates of the Internet shipping system, then HTTP entities are the actual cargo of the messages. Figure 15-1 shows a simple entity, carried inside an HTTP response message.
-
HTTP 메시지를 인터넷 운반 시스템의 상자라고 한다면 HTTP 엔티티는 메시지에 담긴 실제 화물입니다.
-
Figure 15-1은 HTTP 응답 메시지 내에서 운반되는 간단한 엔티티의 예시를 보여줍니다.
The entity headers indicate a plaintext document (Content-Type: text/plain) that is a mere 18 characters long (Content-Length: 18). As always, a blank line (CRLF) separates the header fields from the start of the body.
-
엔티티 헤더는 18개의 글자(Content-Length: 18)로 이루어진 평문 문서(Content-Type: text/plain)를 나타내고 있습니다.
-
항상 공백 라인(CRLF)이 본문의 시작 부분과 헤더 필드를 구분합니다.
HTTP entity headers (covered in Chapter 3) describe the contents of an HTTP message. HTTP/1.1 defines 10 primary entity header fields:
-
Chapter 3에서 다룬 HTTP 엔티티 헤더는 HTTP 메시지의 콘텐츠를 묘사합니다.
-
HTTP/1.1에서는 10가지 주요한 엔티티 헤더 필드를 정의하고 있습니다.
Content-Type
The kind of object carried by the entity.
- Content-Type : 엔티티에 의해 전달되는 객체의 종류
Content-Length
The length or size of the message being sent.
- Content-Length : 전달되는 메시지의 길이나 사이즈
Content-Language
The human language that best matches the object being sent.
- Content-Language : 전송되는 객체에 가장 상응하는 Human Language
Content-Encoding
Any transformation (compression, etc.) performed on the object data.
- Content-Encoding : 객체 데이터에 대해 수행된 모든 변환(압축 등)
Content-Location
An alternate location for the object at the time of the request.
- Content-Location : 요청 당시 객체의 대체 위치
Content-Range
If this is a partial entity, this header defines which pieces of the whole are included.
- Content-Range : 부분적인 엔티티, 전체에서 어떤 요소가 포함되었는지 정의
Content-MD5
A checksum of the contents of the entity body.
- Content-MD5 : 엔티티 본문의 콘텐츠에 관한 체크섬
Last-Modified
The date on which this particular content was created or modified at the server.
- Last-Modified : 서버에서 특정 콘텐츠가 생성되거나 수정된 시점
Expires
The date and time at which this entity data will become stale.
- Expires : 엔티티 데이터가 Stale 처리된 시점
Allow
What request methods are legal on this resource; e.g., GET and HEAD.
- Allow : 리소스에 대해 허가된 요청 메서드의 종류 (ex. GET, HEAD)
ETag
A unique validator for this particular instance* of the document. The ETag header is not defined formally as an entity header, but it is an important header for many operations involving entities.
- ETag : 문서의 특정 인스턴스에 대한 Validator (공식적으로 정의된 엔티티 헤더는 아니지만 엔티티와 관련된 많은 연산에서 중요하게 사용되는 헤더)
Cache-Control
Directives on how this document can be cached. The Cache-Control header,like the ETag header, is not defined formally as an entity header.
- Cache-Control : 캐싱 가능한 문서인지 나타내는 지시어 (ETag 헤더와 마찬가지로 공식적인 엔티티 헤더가 아니다)
✏️ 요약
Messages vs Entities
-
Messages : 엔티티를 전송하기 위한 상자 (Crates)
- Message Header : 메시지에 대한 메타 데이터(프로토콜 버전, 상태 코드, 서버 정보, 응답 일시 등)
- Message Body : 메시지가 실제로 담고 있는 데이터(엔티티가 포함된 영역)
-
Entities : 메시지에 담긴 실제 데이터 (Cargos)
- Entity Header : 엔티티에 대한 메타 데이터
- Entity Body : 엔티티가 실제로 담고 있는 데이터
Primary Entity Headers
- Content-Type : 전달되는 객체 타입
- Content-Length : Entity Body의 크기
- Content-Language : 전송되는 객체에 상응하는 언어
- Content-Encoding : 객체에 수행된 모든 변환 (ex. 압축)
- Content-Location : 객체가 저장된 다른 위치 (객체의 사본이 다른 위치에서 제공될 때 유용하게 사용)
- Content-Range : 부분적인 엔티티
- Content-MD5 : Entity Body에 관한 체크섬
- Last-Modified : 서버에서 특정 콘텐츠가 생성 혹은 수정된 시점
- Expires : 엔티티 데이터가 Stale 처리되는 시점
- Allow : 객체에 대해 허가된 요청 메서드의 종류
아래는 Entity Header는 아니지만 엔티티와 관련된 연산에서 사용되는 헤더
- ETag : 특정 문서에 대한 Validator
- Cache-Control : 캐싱 가능한 문서인지 나타내는 지시어
✏️ 감상
다 까먹은 날 위해 준비했어
메모리는 나름 큰 편이지만 하드디스크가 작은 저는..
이전에 읽었던 내용들을 백 퍼센트 기억하지 못합니다 😌
https://velog.io/@dvlp-sy/TIL-HTTP-The-Definitive-Guide-p181-p182
Validator를 통한 캐시 제어 부분을 다시 한 번 읽고 와봅시다. 일단 ETag는 엔티티의 버전을 명시하기 위해 사용하는 헤더입니다. 주로 캐싱된 엔티티가 원본 서버의 엔티티와 비교했을 때 최신 버전인지 "검증"할 때 사용되므로 Validator의 일종이라고 볼 수 있습니다. ETag와 더불어 Last-Modified Date 헤더도 Cache Validator의 한 종류입니다.
Expires와 Cache-Control의 역할에 대해서도 다시 한 번 살펴봅시다.
https://velog.io/@dvlp-sy/TIL-HTTP-The-Definitive-Guide-p182-p183
Expires 헤더는 사본이 만료되는 날짜와 요일과 시간 정보를 포함합니다. 캐시는 응답이 생성된 시점을 나타내는 Date 헤더의 값과 비교하여 사본의 Fresh 여부를 확인합니다.
Cache-Control 헤더는 캐싱된 사본의 "Fresh" 기간을 관리하기 위해 사용되며 여러 가지 옵션을 선택할 수 있습니다. no-store는 캐시가 원본 서버의 응답을 클라이언트에 전송한 후 사본을 캐싱하지 않도록 제어합니다. no-cache는 사본을 저장할 수 있지만 항상 서버와의 검증을 수행한 후 클라이언트에게 사본을 제공하도록 제어합니다(*만료되지 않은 사본의 경우에도 항상 재검증을 수행해야 합니다). max-age는 원본 서버에서 응답이 도착한 후 얼마간 fresh 상태를 유지할 수 있는지 정의합니다. must-revalidate는 만료된 사본을 원본 서버로부터의 재검증 없이 제공할 수 없음을 의미합니다.
Cache-Control은 "Fresh" 기간을 관리하는 것은 물론 "Stale"한 문서를 얼마나 허용할 것인지에 대해서도 여러 가지 옵션을 지정할 수 있습니다. max-stale은 stale 문서를 일부 허용함을 의미하며, min-fresh는 fresh 하다고 판단된 문서조차 보수적으로 허용함을 의미합니다.
https://velog.io/@dvlp-sy/TIL-HTTP-The-Definitive-Guide-p184-p186
응답이 Cache-Control이나 Expires를 포함하지 않은 경우에는 캐시가 직접 Expiration을 연산하는 경우도 있습니다. Last-Modified Date와 서버의 응답 생성 시점을 비교하여 문서의 변경 가능성을 판단하는 겁니다(LM-Factor 알고리즘). 엄,, 근데 Last-Modified Date조차 없다면 디폴트 값을 사용합니다.
https://velog.io/@dvlp-sy/TIL-HTTP-The-Definitive-Guide-p192-p194
캐시는 Cache-Control, Expires, Last-Modified Date 헤더를 통해 사본의 "Fresh" 기간을 먼저 연산한 후, 여기에 max-stale이나 min-fresh와 같은 "Stale" 제약 조건을 더하거나 빼서 최종적인 Freshness를 계산합니다.
좋아요.. 다시 봤으니까 이제는 안 까먹을 거라고 믿습니다 😉
다시 돌아왔어요
한 번 쉬니까 진짜 끝도 없이 쉬게 되네
더 게을러지기 전에 다시 컴퓨터 앞에 앉아보아요.. 시험은 끝났지만 저의 공부는 이제부터 시작이랍니다~!~! 정처기를 위한 CS 공부와 SQL 공부를 병행하기 시작했거든요 🔥🔥 교양 과목 달달달 암기하는 것도 나쁘진 않지만 전공 공부가 훨씬 유익하고 재미있어요. 그래서 저는 4월보다 5월에 더 행복할 거예요. 아마도요? 🤩
제가 조금 심경의 변화가 있어서 요즘들어 세상을 핑크퐁으로 바라보기 시작했는데, 그래서 그런지 전혀 힘든 줄 모르고 살고 있어요. 뭘 해도 별로 스트레스 안 받고 그냥 재밌기만 하네요. 제 기분을 가라앉게 할 수 있는 것은 이제 아무것도 없답니다!
그런 의미로 HTTP도 즐거운 마음으로 495페이지까지 킵고잉 할게요. 멈추더라도 금방 다시 돌아와요~ 믿고 기다려용
