Chapter 15. Entities and Encodings
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Transfer Encoding and Chunked Encoding
The previous section discussed content encodings—reversible transformations applied to the body of the message. Content encodings are tightly associated with the details of the particular content format. For example, you might compress a text file with gzip, but not a JPEG file, because JPEGs don’t compress well with gzip.
-
이전 섹션에서는 메시지 본문에 적용되는 디코딩 가능한 변환 기법인 콘텐츠 인코딩에 대해 설명하였습니다.
-
콘텐츠 인코딩은 특정 콘텐츠 포맷의 세부사항과 밀접한 연관이 있습니다.
-
예를 들어 JPEG는 gzip으로 잘 압축되지 않기 때문에 JPEG 파일이 아닌 텍스트 파일만을 gzip으로 압축할 것입니다.
This section discusses transfer encodings. Transfer encodings also are reversible transformations performed on the entity body, but they are applied for architectural reasons and are independent of the format of the content. You apply a transfer encoding to a message to change the way message data is transferred across the network (Figure 15-5).
-
이번 섹션에서는 전송 인코딩에 대해 설명합니다.
-
전송 인코딩 또한 마찬가지로 Entity Body에 적용되는 디코딩 가능한 변환 기법이지만, 아키텍처적인 이유로 콘텐츠의 포맷과 독립적으로 적용됩니다.
-
여러분은 메시지에 전송 인코딩을 적용하여 네트워크를 통해 메시지 데이터를 전송하는 방식을 변경할 수 있습니다. (Figure 15-5)
Safe Transport
Historically, transfer encodings exist in other protocols to provide “safe transport” of messages across a network. The concept of safe transport has a different focus for HTTP, where the transport infrastructure is standardized and more forgiving. In HTTP, there are only a few reasons why transporting message bodies can cause trouble. Two of these are:
-
역사적으로 전송 인코딩은 네트워크를 통해 메시지를 안전하게 전송하기 위해 제공되는 다른 프로토콜에도 존재하였습니다.
-
안전한 전송의 개념은 전송 인프라가 표준화되어 있고 보다 관대한 HTTP에서는 또다른 의미를 가집니다.
-
HTTP는 전송 메시지 본문이 문제를 일으킬 수 있는 원인은 몇 가지에 불과합니다.
-
그 중 두 가지는 다음과 같습니다.
Unknown size
Some gateway applications and content encoders are unable to determine the final size of a message body without generating the content first. Often, these servers would like to start sending the data before the size is known. Because HTTP requires the Content-Length header to precede the data, some servers apply a transfer encoding to send the data with a special terminating footer that indicates the end of data.
Unknown Size
-
일부 게이트웨이 응용 프로그램과 콘텐츠 인코더는 콘텐츠를 먼저 생성하지 않고 메시지 본문의 최종 길이를 결정할 수 없습니다.
-
이러한 서버들은 종종 사이즈가 알려지기 전에 데이터 전송을 시작하기를 원하는 경우가 있습니다.
-
HTTP는 데이터앞에 Content-Length 헤더가 필요하기 때문에 일부 서버는 전송 인코딩을 적용하여 데이터의 끝을 나타내는 특수한 Terminating Footer와 함께 데이터를 전송합니다.
Security
You might use a transfer encoding to scramble the message content before sending it across a shared transport network. However, because of the popularity of transport layer security schemes like SSL, transfer-encoding security isn’t very common.
Security
-
전송 인코딩을 적용하면 공유 전송 네트워크를 통해 메시지를 송신하기 전에 메시지 콘텐츠를 뒤섞을 수 있습니다.
-
하지만 SSL과 같은 Transport Layer 보안 기법이 인기를 끌면서 전송 인코딩 보안은 그리 일반적으로 적용되지 않습니다.
Transfer-Encoding Headers
There are just two defined headers to describe and control transfer encoding:
Transfer-Encoding
Tells the receiver what encoding has been performed on the message in order for it to be safely transportedTE
Used in the request header to tell the server what extension transfer encodings are okay to use
-
전송 인코딩을 표현하고 제어하기 위한 두 가지 헤더가 존재합니다.
-
Transfer-Encoding : 메시지를 안전하게 전송하기 위해 어떤 인코딩 기법이 적용되었는지 수신자에게 설명합니다.
-
TE : 어떤 확장 인코딩을 사용해도 괜찮은지 서버에게 전달하기 위해 사용하는 요청 헤더입니다.
In the following example, the request uses the TE header to tell the server that it accepts the chunked encoding (which it must if it’s an HTTP 1.1 application) and is willing to accept trailers on the end of chunk-encoded messages:
GET /new_products.html HTTP/1.1 Host: www.joes-hardware.com User-Agent: Mozilla/4.61 [en] (WinNT; I) TE: trailers, chunked ...
-
위의 예제에서 요청은 TE 헤더를 사용하여 청크 인코딩을 허용한다는 사실을 서버에게 전달합니다(HTTP 1.1 응용 프로그램이라면 필수).
-
그리고 청크 인코딩된 메시지 끝에 트레일러를 허용할 의사가 있음을 알립니다.
The response includes a Transfer-Encoding header to tell the receiver that the message has been transfer-encoded with the chunked encoding:
HTTP/1.1 200 OK Transfer-Encoding: chunked Server: Apache/3.0 ...
- 응답은 Transfer-Encoding 헤더를 포함하여 메시지가 청크 인코딩을 통해 전송 인코딩이 적용되었음을 수신자에게 알립니다.
After this initial header, the structure of the message will change.
- 최초의 헤더를 주고받은 이후에 메시지의 구조는 변화할 것입니다.
All transfer-encoding values are case-insensitive. HTTP/1.1 uses transfer-encoding values in the TE header field and in the Transfer-Encoding header field. The latest HTTP specification defines only one transfer encoding, chunked encoding.
-
모든 전송 인코딩 값은 대소문자 구분이 없습니다.
-
HTTP/1.1은 TE 헤더 필드와 Transfer-Encoding 헤더 필드의 전송 인코딩 값을 사용합니다.
-
최신의 HTTP 명세에서는 전송 인코딩 기법으로 오직 청크 인코딩만을 정의하고 있습니다.
The TE header, like the Accept-Encoding header, can have Q values to describe preferred forms of transfer encoding. The HTTP/1.1 specification, however, forbids the association of a Q value of 0.0 to chunked encoding.
-
Accept-Encoding 헤더와 같은 TE 헤더는 선호하는 전송 인코딩의 형식을 표현하는 Q 값을 가질 수 있습니다.
-
하지만 HTTP/1.1 명세에서는 청크 인코딩에 Q 값으로 0.0을 사용하는 것을 금지하고 있습니다.
Future extensions to HTTP may drive the need for additional transfer encodings. If and when this happens, the chunked transfer encoding should always be applied on top of the extension transfer encodings. This guarantees that the data will get “tunneled” through HTTP/1.1 applications that understand chunked encoding but not other transfer encodings.
-
추후 확장되는 HTTP에서는 또다른 전송 인코딩의 형태가 필요할 수 있습니다.
-
그런 일이 생긴다면 청크 인코딩은 항상 확장 전송 인코딩의 상위에서 적용되어야 합니다.
-
이것은 데이터가 청크 인코딩은 이해하지만 다른 전송 인코딩 기법을 이해할 수 없는 HTTP/1.1 응용 프로그램을 통해 터널링 됨을 보장합니다.
✏️ 요약
Transfer Encoding
: 아키텍처적인 이유로 콘텐츠의 포맷과 독립적으로 적용되어 데이터의 전송 방식을 정의하는 헤더
- Safe Transport
- 메시지의 최종 크기를 알 수 없는 경우 사용
- 보안이 요구되는 상황에서 안전하게 데이터를 터널링하기 위해 사용
TE: 어떤 확장 인코딩을 사용할 수 있는지 서버에게 전달- Q 값으로 선호하는 전송 인코딩 형식 표현(단, HTTP/1.1에서는 청크 인코딩에 Q 값으로 0.0을 사용하는 것을 금지함)
Trasnfer-Encoding: 메시지를 안전하게 전송하기 위해 어떤 인코딩 기법이 적용되었는지 수신자에게 전달
✏️ 감상
Presentation Layer
나는 개인적으로 OSI 7 Layer를 공부할 때 가장 느낌적으로 알기 어려웠던 부분이 Presentation Layer였다. Application Layer에서 HTTP로 데이터를 전송한다는 사실은 알았어도, 이 데이터가 Transport Layer로 전달되기까지 5, 6 레이어는 도대체 무슨 일을 하는 건지 이해하기가 어려웠다. 당시의 내가 이 부분을 읽었더라면 Presentation Layer의 역할을 조금 더 직관적으로 이해할 수 있었을지도 모르겠다.
HTTP로 데이터를 보낼 때 그냥 아무렇게나 전송하는 것이 아니라 콘텐츠를 적절히 압축하는 과정도 필요하고, 여러 요청으로 나누어 데이터를 전송할 때도 청크 인코딩을 사용해야 한다는 점을 알게 되었다. 그리고 HTTP보다 하위 레이어에서 이러한 데이터들의 인코딩, 디코딩 작업을 수행하는 것이 Presentation Layer라는 사실을 알게 되었다.
이제 진짜 OSI 7 Layer 박사 학위 땄다. 누가 물어봐도 당당하게 설명할 수 있을 정도로 빠삭해진 것이다...🍗
