캐시 제어에서 개인 대 공용


127

IIS에서 호스팅되는 asp.net 응용 프로그램에서 Public과 Private Cache-Control의 차이점을 나타내는 예를 설명해 주시겠습니까?

내가 읽어 MSDN 의 차이는 다음입니다 :

Public : 클라이언트와 공유 (프록시) 캐시에서 응답을 캐시 할 수 있도록 Cache-Control : public을 설정합니다.

개인 : 기본값입니다. Cache-Control : private을 설정하여 공유 (프록시 서버) 캐시가 아니라 클라이언트에서만 응답을 캐시 할 수 있도록 지정합니다.

각 선택의 장단점을 완전히 이해하지 못했습니다. 언제 사용하는지에 대한 예가 좋습니다.

예를 들어 동일한 응용 프로그램을 호스팅하는 두 개의 웹 서버가있는 경우 어떻게해야합니까? 비공개 또는 공개를 선택하면주의해야 할 것이 있습니까?

답변:


237

유일한 차이점은 Private을 사용하면 프록시가 프록시를 통해 이동하는 데이터를 캐시 할 수 없다는 것입니다. 결국, 그것은 당신이 보내는 페이지 / 파일에 포함 된 데이터로 요약됩니다.

예를 들어, ISP는 사용자와 인터넷 사이에 보이지 않는 프록시를 가질 수 있는데, 이는 필요한 대역폭의 양을 줄이고 비용을 낮추기 위해 웹 페이지를 캐싱하는 것입니다. cache-control : private를 사용하면 페이지를 캐시하지 말고 최종 사용자가 그렇게 할 수 있도록 지정합니다. cache-control : public을 사용하면 모든 사람이 페이지를 캐시해도 괜찮으므로 프록시가 사본을 보관할 것입니다.

경험상, 모든 사람 이라면 이 액세스 할 수있는 경우 (예 :이 페이지의 로고) 캐시 제어 : 캐시하는 사람이 많을수록 필요한 대역폭이 적기 때문에 public이 더 나을 수 있습니다. 연결된 사용자와 관련된 것이면 (예 :이 페이지의 HTML에 내 사용자 이름이 포함되어 있으므로 다른 사람에게는 유용하지 않습니다) 캐시 제어 : 프록시가 데이터를 캐싱하므로 비공개가 더 좋습니다. 다른 사용자가 요청하지 않으며, 신뢰할 수없는 서버에 보관하고 싶지 않은 데이터를 보관할 수도 있습니다.

물론 공개되지 않은 모든 항목에는 개인 캐시가 있어야합니다. 그렇지 않으면 데이터가 중간 프록시 서버에 저장 될 수 있습니다. 액세스 권한이있는 모든 사람이 액세스 할 수있었습니다.


39
유일한 차이점은 Private을 사용하면 프록시가 캐시를 허용 하지 않는다는 것입니다 ... 오타라고 생각합니다. 그것과는 별개로 +1. 개인은 어느 정도의 보안을 제공하지 않으며 중간에있는 에이전트가 여전히 볼 수 있다고 덧붙일 가치가 있습니다. 이는 "정직한"에이전트가 새로 생성 된 응답 대신 다른 사람에게 제공하지 않음을 의미합니다.
존 한나

결정된! 게시하기 전에 몇 번 다시 읽었 기 때문에 재밌지 만, "not"이 있어야한다는 것을 알았 기 때문에 마음이 추가되었습니다. 그렇습니다. 귀하의 의견에 +1하십시오. 왜냐하면 사용자 관련 데이터에 권장되지만 private은 진정한 보안 (SSL)을 대체하지 않습니다.
salgiza

사용하지 말아야 할 때 "not"을 쓰거나 생략해야 할 때 너무 쉽습니다. 나는 (다른 분야에서) 많은 자기 편집이 같은 오타를 고치고 있다는 것을 알고 있습니다.
Jon Hanna

15
따라서 아무 것도 지정하지 않으면 기본 동작이 "public"또는 "private"입니까?
Pacerier

1
@Honey 그러나 동일한 프록시를 사용하는 여러 클라이언트가있을 수 있습니다. 괜찮다면 모든 클라이언트에게 동일한 응답을 보내면 프록시 수준에서 캐시해도 괜찮습니다.
Jon Hanna
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.