
프록시 캐싱 서버에 관해 덜 일반화된 질문이 있습니다.
가상의 장면을 설정하기 위해 저는 라우터를 통해 흐르는 트래픽 양을 줄이기 위해 집 안에 프록시 캐시 서버를 설치하는 아이디어를 가지고 놀았습니다(ISP는 총 데이터 양에 제한이 있습니다). 사용할 수 있습니다). 서버는 라우터 내부에 위치하므로 라우터는 일부 데이터가 저장되는 것을 인식하지 못합니다.
이 경우 프록시 캐시 서버가 얼마나 효과적일까요? (또한 라우터 전체의 네트워크 트래픽을 줄이기 위해 구현할 수 있는 다른 방법은 무엇입니까?)
프록시 서버가 웹사이트의 개별 사진을 캐시할 수 있나요? 예를 들어 포럼에서는 콘텐츠를 자주 업데이트하지만 웹 사이트에 표시되는 이미지는 변경되지 않습니다. 웹사이트에 관한 정보 중 일부가 저장될 수 있나요? 아니면 동적 용량으로 인해 모든 웹페이지를 다시 요청해야 합니까?
저는 프록시 서버의 기능을 비교적 처음 접했고 이에 대한 충분한 정보를 찾을 수 있다면 결국 IT 업무에 적용하고 싶습니다.
답변1
프록시 서버가 웹사이트의 개별 사진을 캐시할 수 있나요?
예.
동적 용량으로 인해 모든 웹페이지를 다시 요청해야 합니까?
동적 부분을 다시 가져와야 하며, 프록시는 페이지에서 별도로 가져온 각 요소의 프록시 제어 헤더를 검사하여 이를 처리해야 합니다.
다음은 슈퍼유저로부터 웹페이지를 가져오는 Chrome의 Wireshark 캡처에 대한 간단한(편집된) 예입니다.
클라이언트 요청
GET /questions/419790/confused-by-cpu-model HTTP/1.1
Host: superuser.com
Connection: keep-alive
User-Agent: …Chrome…
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://superuser.com/questions
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: …
서버 응답
HTTP/1.1 200 OK
Cache-Control: public, max-age=60
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Expires: Wed, 02 May 2012 19:41:23 GMT
Last-Modified: Wed, 02 May 2012 19:40:23 GMT
Vary: *
Date: Wed, 02 May 2012 19:40:23 GMT
Content-Length: 9831
이는 서버가 각 콘텐츠가 캐시되는 방식을 제어하려고 시도하는 방법입니다 Cache-Control: public, max-age=60
. Expires: Wed, 02 May 2012 19:41:23 GMT
슈퍼유저 질문 페이지에는 개별적으로 가져온 요소가 수십 또는 수백 개 있을 수 있습니다.
무엇을 읽어보세요W3C는 캐시 제어에 대해 말합니다.
Cache-Control 일반 헤더 필드는 요청/응답 체인을 따라 모든 캐싱 메커니즘을 따라야 하는 지시어를 지정하는 데 사용됩니다. 지시어는 캐시가 요청이나 응답을 방해하는 것을 방지하기 위한 동작을 지정합니다. 이러한 지시문은 일반적으로 기본 캐싱 알고리즘을 재정의합니다. 요청에 지시문이 있다고 해서 응답에 동일한 지시문이 제공된다는 의미는 아니라는 점에서 캐시 지시문은 단방향입니다.
나중에
공공의
일반적으로 캐시할 수 없거나 비공유 캐시 내에서만 캐시할 수 있는 경우에도 응답이 모든 캐시에 의해 캐시될 수 있음을 나타냅니다. (자세한 내용은 승인, 섹션 14.8을 참조하세요.)사적인
응답 메시지의 전부 또는 일부가 단일 사용자를 위한 것이며 공유 캐시에 의해 캐시되어서는 안 된다는 것을 나타냅니다. 이를 통해 원서버는 응답의 지정된 부분이 한 명의 사용자만을 위한 것이며 다른 사용자의 요청에 대한 유효한 응답이 아니라는 것을 명시할 수 있습니다. 개인(비공유) 캐시는 응답을 캐시할 수 있습니다. 참고: 비공개라는 단어의 사용은 응답이 캐시될 수 있는 위치만 제어하며 메시지 내용의 개인정보 보호를 보장할 수는 없습니다.캐시 없음
no-cache 지시문이 field-name을 지정하지 않으면 캐시는 원서버와의 성공적인 재검증 없이 후속 요청을 만족시키기 위해 응답을 사용해서는 안 됩니다. 이를 통해 원본 서버는 클라이언트 요청에 대해 오래된 응답을 반환하도록 구성된 캐시에 의한 캐싱도 방지할 수 있습니다.
등등 - 그것은 큰 주제 영역입니다.