(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
Different web servers provide different mechanisms for setting HTTP cache-control and expiration headers. In this section, we’ll talk briefly about how the popular Apache web server supports cache controls. Refer to your web server documentation for specific details.
웹 서버마다 HTTP cache-control과 expiration 헤더를 설정하는 매커니즘이 조금씩 다릅니다.
이번 섹션에서는 널리 사용되는 Apache 웹 서버가 캐시 제어를 지원하는 방식에 대해 간단히 설명합니다.
자세한 사항은 여러분의 웹 서버 문서를 참고하시기 바랍니다.
The Apache web server provides several mechanisms for setting HTTP cache-controlling headers. Many of these mechanisms are not enabled by default—you have to enable them (in some cases first obtaining Apache extension modules). Here is a brief description of some of the Apache features:
Apache 웹 서버는 HTTP 캐시 제어 헤더를 설정하는 몇 가지 매커니즘을 제공합니다.
이 중 대부분은 디폴트로 사용 불가능하므로 직접 설정해주어야 합니다.
(경우에 따라 먼저 Apache 확장 모듈을 포함해야 합니다)
하단의 내용은 Apache의 일부 기능에 대한 간단한 설명입니다.
mod_headers
The mod_headers module lets you set individual headers. Once this module is loaded, you can augment the Apache configuration files with directives to set individual HTTP headers. You also can use these settings in combination with Apache’s regular expressions and filters to associate headers with individual content. Here is an example of a configuration that could mark all HTML files in a directory as uncachable:
<Files *.html> Header set Cache-control no-cache </Files>
mod_headers
mod_headers 모듈은 개별적인 헤더를 설정할 수 있게 합니다.
해당 모듈이 로드되면 개별 HTTP 헤더를 설정하는 명령을 사용하여 Apache 구성 파일을 보충할 수 있습니다.
이때 Apache의 정규표현식과 필터를 함께 사용하여 개별 콘텐츠에 연관된 헤더를 연결할 수 있습니다.
다음은 디렉토리에 위치한 모든 HTML 문서를 캐싱할 수 없는 것으로 표시하는 구성 파일의 예시입니다.
<Files *.html>
Header set Cache-control no-cache
</Files>
mod_expires
The mod_expires module provides program logic to automatically generate Expires headers with the correct expiration dates. This module allows you to set expiration dates for some time period after a document was last accessed or after its last-modified date. The module also lets you assign different expiration dates to different file types and use convenient verbose descriptions, like “access plus 1 month,” to describe cachability. Here are a few examples:
ExpiresDefault A3600 ExpiresDefault M86400 ExpiresDefault "access plus 1 week" ExpiresByType text/html "modification plus 2 days 6 hours 12 minutes"
mod_expires
mod_expires 모듈은 자동으로 올바른 만료일시를 포함한 Expires 헤더를 생성하는 프로그램 로직을 제공합니다.
해당 모듈은 문서를 마지막으로 접근하고 수정한 후 흐른 시간을 계산하여 만료일시를 설정할 수 있게 합니다.
또한 파일 유형에 따라 서로 다른 만료일시를 할당하고 "access plus 1 month"와 같이 편리한 설명으로 Cachability를 기술할 수 있습니다.
아래는 mod_expires에 대한 몇 가지 예시입니다.
ExpiresDefault A3600
ExpiresDefault M86400
ExpiresDefault "access plus 1 week"
ExpiresByType text/html "modification plus 2 days 6 hours 12 minutes"
mod_cern_meta
The mod_cern_meta module allows you to associate a file of HTTP headers with particular objects. When you enable this module, you create a set of “metafiles,” one for each document you want to control,and add the desired headers to each metafile.
mod_cern_meta
mod_cern_meta 모듈은 HTTP 헤더 파일과 특정 오브젝트를 연결시킬 수 있게 합니다.
해당 모듈을 활성화하면 각각의 문서를 제어할 수 있는 "metafiles" 집합을 생성하여 원하는 헤더를 추가할 수 있습니다.
HTTP server response headers are used to carry back document expiration and cache-control information. Web servers interact with configuration files to assign the correct cache-control headers to served documents.
문서의 만료 및 캐시 제어 정보를 불러오기 위해 HTTP 서버 응답 헤더를 사용합니다.
웹 서버는 구성 파일과 상호작용하여 제공되는 문서에 올바른 Cache-Control 헤더를 할당합니다.
To make it easier for authors to assign HTTP header information to served HTML documents without interacting with web server configuration files, HTML 2.0 defined the <META HTTP-EQUIV> tag. This optional tag sits at the top of an HTML document and defines HTTP headers that should be associated with the document. Here is an example of a <META HTTP-EQUIV> tag set to mark the HTML document uncachable:
<HTML> <HEAD> <TITLE>My Document</TITLE> <META HTTP-EQUIV="Cache-control" CONTENT="no-cache"> </HEAD> ...
하지만 웹 서버 구성 파일과 상호작용하지 않고도 제작자가 간단하게 HTML 문서에 HTTP 헤더 정보를 할당할 수 있습니다.
HTML 2.0은 <META HTTP-EQUIV> 태그를 정의하고 있습니다.
이 태그는 HTML 문서의 상단에 위치하여 문서와 연결되어야 하는 HTTP 헤더를 정의합니다.
하단의 내용은 캐싱할 수 없는 HTML 문서에 대하여 <META HTTP-EQUIV> 태그를 붙인 예시입니다.
<HTML>
<HEAD>
<TITLE>My Document</TITLE>
<META HTTP-EQUIV="Cache-control" CONTENT="no-cache">
</HEAD>
...
This HTTP-EQUIV tag was originally intended to be used by web servers. Web servers were supposed to parse HTML for <META HTTP-EQUIV> tags and insert the prescribed headers into the HTTP response, as documented in HTML RFC 1866:
An HTTP server may use this information to process the document. In particular, it may include a header field in the responses to requests for this document: the header name is taken from the HTTP-EQUIV attribute value, and the header value is taken from the value of the CONTENT attribute.
HTTP-EQUIV 태그는 원래 웹 서버가 사용하도록 만들어졌습니다.
HTML RFC1866 표준에 따라 웹 서버는 HTML로부터 <META HTTP-EQUIV> 태그를 파싱하여 HTTP 응답에 헤더를 삽입하는 것을 지원합니다.
Unfortunately, few web servers and proxies support this optional feature because of the extra server load, the values being static, and the fact that it supports only HTML and not the many other file types.
그러나 이러한 선택적인 특성을 지원하는 웹 서버와 프록시는 거의 없습니다.
추가적인 서버 부하와 정적인 값, HTML만 지원할 뿐 다른 파일 타입에 대해서는 지원하지 않는다는 사실 때문입니다.
However, some browsers do parse and adhere to HTTP-EQUIV tags in the HTML content, treating the embedded headers like real HTTP headers (Figure7-17). This is unfortunate, because HTML browsers that do support HTTP-EQUIV may apply different cache-control rules than intervening proxy caches. This causes confusing cache expiration behavior.
일부 브라우저는 임베딩된 헤더를 마치 HTTP 헤더처럼 취급하여 HTML 콘텐츠의 HTTP-EQUIV 태그를 파싱하고 따르기도 합니다. (Figure 7-17)
참 안타까운 일입니다. HTTP-EQUIV를 지원하는 HTML 브라우저가 프록시 캐시와는 또다른 Cache-Control 규칙을 적용할 수도 있기 때문입니다.
이것은 캐시의 만료 동작에 혼란을 초래할 수 있습니다.
In general, <META HTTP-EQUIV> tags are a poor way of controlling document cachability. The only sure-fire way to communicate cache-control requests for documents is through HTTP headers sent by a properly configured server.
일반적으로 <META HTTP-EQUIV> 태그는 문서의 Cachability를 제어하는 좋은 방법이 아닙니다.
문서에 대한 Cache-Control 요청을 제대로 처리하기 위한 유일한 방법은 적절히 구성된 서버가 전송하는 HTTP 헤더를 이용하는 것입니다.
mod_headers : 제어 헤더를 설정할 수 있게 하는 구성 파일
<Files *.html>
Header set Cache-control no-cache
</Files>
mod_expires : 자동으로 Expires 헤더를 생성하는 프로그램 로직
ExpiresDefault A3600
ExpiresDefault M86400
ExpiresDefault "access plus 1 week"
ExpiresByType text/html "modification plus 2 days 6 hours 12 minutes"
mod_cern_meta : 원하는 헤더를 추가하여 오브젝트와 연결할 수 있는 Metafiles
<META HTTP-EQUIV="Cache-control" CONTENT="no-cache">
오늘은 Apache 웹 서버가 Expires와 Cache-Control 헤더를 제어하는 방식과 HTML에서 헤더를 정의하는 방식 두 가지를 살펴보았다. HTML에서 헤더를 정의하는 방식은 충돌 위험이 있어서 권장되는 방식이 아니고, 우리가 주목해야 할 것은 웹 서버의 구성 파일을 작성하는 부분이다.
책에서는 Apache 서버를 예로 들어 설명하고 있지만 최근에는 Nginx를 더 많이 사용하고 있는 추세다(22년 기준 점유율 Nginx 32.88%, Apache 24.25% 라고 한다). 애초에 Nginx가 Apache 서버의 구조를 보완하여 개발된 서버다 보니 그럴 수밖에 없는 듯하다.
어디선가 주어들은 바에 의하면 Apache와 Nginx의 차이점은 바로 프로세스의 관리 방식에 있다. Apache는 새로운 연결이 발생할 때마다 새로운 프로세스를 생성하고 요청이 없어도 이것을 그대로 방치한다. 반면 Nginx는 연결 후에 요청이 없으면 새로운 연결을 생성하거나 다른 연결을 처리하는 등 유연한 처리가 가능하다. Non-Blocking 방식을 사용하기 때문에 요청을 대기중인 프로세스가 리소스를 차지할 일이 없는 것이다.
모 아무튼 그렇다!
옆으로 너무 많이 빠졌는데, 원래 하려고 했던 이야기는 Apache나 Nginx나 구성 파일이 거의 비슷하다는 점이다.
프로세스 관리 방식에서는 조금 차이가 있지만 결국 HTTP로 요청하고 응답하는 건 똑같으니까 말이다. Apache 서버가 구성 파일에 ExpiresDefault, Header 등의 지시어를 사용하듯이 Nginx도 expires와 add_header 등의 지시어를 통해 캐시를 제어할 수 있다.