소개
WWW는 인터넷에서 가장 인기 있는 애플리케이션 중 하나입니다. 급속한 성장으로 인해 네트워크 정체와 서버 과부하가 발생하여 고객 액세스 지연이 증가하고 WWW 서비스 품질 문제가 발생했습니다. 캐싱 기술은 서버 부하를 줄이고, 네트워크 혼잡을 줄이고, WWW 확장성을 향상시키는 효과적인 방법 중 하나로 간주됩니다. 그 기본 아이디어는 고객 액세스의 시간적 지역성 원칙을 사용하여 고객이 액세스한 콘텐츠를 서버에 저장하는 것입니다. 캐시 - 복사본을 저장합니다. 다음에 콘텐츠에 액세스할 때 호스팅 웹 사이트에 연결할 필요가 없으며 캐시에 보관된 복사본을 통해 제공됩니다.
웹 콘텐츠는 클라이언트, 프록시 서버 및 서버 측에서 캐시될 수 있습니다. 연구에 따르면 캐싱 기술은 WWW 성능을 크게 향상시킬 수 있으며[1][2] 다음과 같은 이점을 가져올 수 있습니다.
(1) 네트워크 트래픽을 줄여 네트워크 혼잡을 완화합니다.
(2) 고객 액세스 지연을 줄이는 주요 이유는 다음과 같습니다. ① 프록시 서버에 캐시된 콘텐츠의 경우 고객이 원격 서버가 아닌 프록시에서 직접 가져올 수 있으므로 전송 지연이 줄어듭니다. 네트워크 혼잡 및 서버 부하가 감소되어 고객이 더 빠르게 얻을 수 있습니다.
(3) 클라이언트의 요청 내용 중 일부를 프록시에서 얻을 수 있으므로 원격 서버의 부하가 줄어듭니다.
(4) 원격 서버가 원격 서버 오류나 네트워크 오류로 인해 클라이언트의 요청에 응답할 수 없는 경우 클라이언트는 프록시에서 콘텐츠의 캐시된 복사본을 얻을 수 있으므로 WWW 서비스의 견고성이 향상됩니다.
웹 캐싱 시스템은 또한 다음과 같은 문제를 가져옵니다.
(1) 고객이 대리인을 통해 얻은 콘텐츠가 오래되었을 수 있습니다.
(2) 캐시 무효화가 발생하면 추가 프록시 처리 오버헤드로 인해 클라이언트의 액세스 지연 시간이 늘어납니다. 따라서 웹 캐시 시스템을 설계할 때 캐시 적중률을 최대화하고 실패 비용을 최소화하도록 노력해야 합니다.
(3) 에이전트가 병목 현상을 일으킬 수 있습니다. 따라서 에이전트에는 서비스 고객 수의 상한선과 서비스 효율성의 하한선을 설정하여 에이전트 시스템의 효율성이 최소한 원격 서버에 직접 연결된 클라이언트의 효율성과 같도록 해야 합니다.
현재 웹 캐싱 시스템과 최적화 문제를 중심으로 광범위하고 심층적인 연구가 진행되고 있으며, 이러한 연구 작업은 주로 프록시의 역할에 중점을 두고 있습니다.
2 웹 캐싱 시스템의 이상적인 특성 이상적인 웹 캐싱 시스템은 다음과 같은 특성을 가져야 합니다.
(1) 속도: 캐싱 시스템은 고객 액세스 지연을 효과적으로 줄일 수 있어야 합니다.
(2) 견고성: 견고성은 가용성을 의미하며 고객은 언제든지 웹 서비스를 사용할 수 있기를 원합니다.
(3) 투명성: 캐싱 시스템은 고객에게 투명해야 하며 고객이 얻은 결과는 빠른 응답과 우수한 가용성뿐입니다.
(4) 확장성: 웹 캐싱 시스템은 네트워크 규모와 밀도가 지속적으로 증가함에 따라 확장이 가능해야 합니다.
(5) 효율성: 웹 캐싱 시스템이 네트워크에 가져오는 오버헤드가 작을수록 좋습니다.
(6) 적응성: 캐싱 시스템은 캐시 관리, 캐시 라우팅, 프록시 구성 등을 포함하는 고객 요청 및 네트워크 환경의 동적 변화에 적응할 수 있으며 이상적인 캐시 성능을 얻는 데 중요합니다.
(7) 안정성: 웹 캐싱 시스템이 채택한 솔루션은 네트워크에 불안정성을 가져와서는 안 됩니다.
(8) 로드 밸런싱: 이상적인 캐싱 솔루션은 전체 네트워크에 로드를 고르게 분산하여 특정 에이전트나 서버가 병목 현상이나 핫스팟이 되어 시스템 일부 또는 전체 시스템의 성능 저하를 초래하는 것을 방지할 수 있어야 합니다.
(9) 이기종 처리 기능: 네트워크 규모와 적용 범위가 계속 증가함에 따라 네트워크는 일련의 다양한 하드웨어 및 소프트웨어 아키텍처로 확장됩니다. 웹 캐싱 시스템은 다양한 네트워크 아키텍처에 적응할 수 있어야 합니다.
(10) 단순성: 간단한 솔루션은 구현하기 쉽고 일반적으로 받아들여집니다. 이상적인 웹 캐싱 솔루션은 간단하고 구성하기 쉬워야 합니다.
위의 특성에 초점을 맞춰 웹 캐싱 시스템은 다음과 같은 문제를 해결해야 합니다.
(1) 캐시 아키텍처: 캐싱 프록시가 네트워크에서 어떻게 구성되고 구성되는지;
(2) 에이전트 협력: 에이전트 간 협력 방법. 서로 협력하는 에이전트는 적중률을 높이고 캐시 시스템의 성능을 향상시킬 수 있습니다.
(3) 캐시 라우팅: 하나의 캐시 프록시가 실패할 경우 요청을 다른 캐시 프록시로 전달하는 방법;
(4) 캐시 교체 알고리즘: 캐시 공간이 충분하지 않은 경우 캐시 콘텐츠를 교체하는 방법
(5) 캐시 일관성: 즉, 캐시된 콘텐츠의 적시성과 캐시된 콘텐츠가 오래된 것이 되는 것을 방지하는 방법입니다.
(6) 콘텐츠 프리페칭: 에이전트가 클라이언트의 액세스 지연을 줄이기 위해 서버나 다른 에이전트에서 콘텐츠를 프리페치하기로 결정하는 방법입니다.
(7) 로드 밸런싱: 네트워크의 "핫스팟" 현상을 해결하는 방법;
(8) 캐시 콘텐츠: 캐시할 수 있는 콘텐츠의 종류입니다.
웹 캐싱 시스템을 설계할 때 위의 문제를 해결해야 합니다.
3 웹 캐싱 솔루션 개요
3.1 웹 캐시 아키텍처 웹 캐시 시스템의 성능은 고객 기반의 규모에 따라 달라집니다. 고객 기반이 클수록 캐시된 콘텐츠가 다시 요청될 가능성이 높아집니다. 서로 협력하는 캐시 그룹은 적중률을 높이고 캐시 시스템의 성능을 향상시킬 수 있으므로 캐시 시스템의 아키텍처는 에이전트가 효과적으로 협력할 수 있도록 보장해야 합니다. 일반적인 캐시 아키텍처에는 계층적, 분산형 및 하이브리드가 포함됩니다.
그림 1 웹 캐싱 시스템 아키텍처 다이어그램
3.1.1 계층적 캐시 아키텍처
Harvest 프로젝트[3]는 계층적 웹 캐싱 아키텍처를 처음으로 제안했습니다. 계층적 캐시 아키텍처에서 캐시는 그림 1(a)에 표시된 것처럼 네트워크의 여러 수준에서 구성됩니다. 단순화를 위해 하위 계층 캐시, 로컬 계층 캐시, 지역 계층 캐시 및 광역 계층 캐시의 네 가지 수준이 있다고 가정합니다. 맨 아래 계층은 클라이언트/브라우저 캐시입니다. 클라이언트 캐시가 클라이언트의 요청을 충족할 수 없으면 요청은 로컬 영역 계층 캐시로 전달됩니다. 그래도 만족되지 않으면 해당 요청은 와이드까지 지역 계층 캐시로 전달됩니다. 영역 레이어 캐시. 요청이 모든 수준의 캐시에서 충족될 수 없는 경우 요청은 결국 서버로 전달됩니다. 그런 다음 요청에 대한 서버의 응답은 하향식으로 클라이언트로 전송되며 그 과정에서 각 중간 계층 캐시에 복사본이 남습니다. 동일한 콘텐츠에 대한 다른 요청은 특정 수준의 캐시에서 충족될 때까지 아래에서 위로 전달됩니다.
계층적 캐싱 아키텍처는 대역폭 효율성이 매우 높으며 클릭률이 높은 웹 콘텐츠를 네트워크에 빠르고 효율적으로 배포할 수 있습니다. 그러나 이 아키텍처에는 몇 가지 단점도 있습니다[4].
(1) 캐시 서버는 네트워크의 주요 액세스 포인트에 구성되어야 하며 캐시 서버는 서로 협력해야 합니다.
(2) 각 캐시 수준은 추가 지연을 가져옵니다.
(3) 높은 수준의 캐시는 병목 현상을 일으키고 대기 시간이 길어질 수 있습니다.
(4) 동일한 콘텐츠의 여러 복사본이 서로 다른 캐시에 저장되며 전체 시스템의 캐시 공간 활용도가 높지 않습니다.
3.1.2 분산 캐시 아키텍처 위에서 언급한 계층적 캐시 구조의 단점을 고려하여 일부 연구자들은 그림 1(b)와 같이 하위 수준 캐시만 존재하는 분산 캐시 아키텍처를 제안했습니다. 문헌[5]의 분산형 웹 캐시 구조에는 로컬 계층 외에 중간 캐시 계층이 없으며, 캐시가 서로 협력하여 장애를 처리합니다. 유효하지 않은 콘텐츠를 얻기 위해 클라이언트 요청을 전달할 로컬 영역 계층 캐시를 결정하기 위해 각 로컬 영역 계층 캐시는 캐시된 콘텐츠의 디렉토리 정보 복사본을 다른 로컬 영역 계층 캐시에 유지하므로 클라이언트 요청은 다음과 같이 수행될 수 있습니다. 무효화가 발생하면 해당 로컬 레이어 캐시로 정확하게 전달됩니다. Cache Array Routing Protocol CARP [6](Cache Array Routing 프로토콜)은 URL 공간을 여러 부분으로 나누고 각 부분을 느슨하게 결합된 캐시 그룹에 할당하는 분산 캐싱 방식입니다. 각 캐시는 URL이 할당된 웹 콘텐츠만 캐시할 수 있습니다. 이를 통해 클라이언트가 콘텐츠를 요청한 URL을 기반으로 요청을 전달할 캐시를 결정할 수 있습니다.
분산 캐시 구조에서는 대부분의 네트워크 트래픽이 네트워크 하단에서 발생하므로 네트워크 정체를 일으킬 가능성이 적습니다. 캐시 공간 활용도가 높고 로드 공유가 더 잘 이루어지며 내결함성이 더 좋습니다. 그러나 대규모 분산 캐시 시스템의 구성에는 많은 연결 수, 높은 대역폭 요구 사항, 관리의 어려움 등 여러 가지 문제가 발생할 수 있습니다[4].
3.1.3 하이브리드 캐시 아키텍처 하이브리드 아키텍처는 그림 1(c)와 같다. 동일한 레벨의 캐시는 분산 캐시 구조를 채택하고 서로 협력한다. Harvest Group이 설계한 인터넷 캐시 프로토콜 ICP(인터넷 캐시 프로토콜)는 가장 작은 RTT로 상위 캐시 또는 이웃 캐시에서 해당 콘텐츠를 얻을 수 있도록 지원합니다.
3.1.4 캐시 아키텍처에 대한 최적화 연구에 따르면 [4] 분산 캐시 구조에 비해 계층적 캐시 아키텍처는 연결 시간이 짧아서 중간 계층에 캐시에 캐시되는 경우 분산 캐시 구조가 더 짧아집니다. 전송 시간 및 더 높은 대역폭 활용도. 이상적인 솔루션은 두 가지를 결합하여 연결 시간과 전송 시간을 줄이면서 각각의 장점을 최대한 활용하는 것입니다.
3.2 캐시 라우팅 웹 캐싱 시스템의 확장성을 고려할 때 대부분의 캐싱 시스템은 많은 수의 캐시를 인터넷에 분산시킵니다. 이로 인해 발생하는 가장 큰 문제는 필요한 콘텐츠를 캐시하는 캐시를 어떻게 신속하게 찾을 수 있는가 하는 것입니다. . 이 문제는 네트워크 라우팅과 다소 유사하지만 같은 방식으로 해결할 수는 없습니다. 전통적인 네트워크 라우팅은 주소 클러스터링(계층적 주소 표현으로 주소 클러스터링 가능)을 기반으로 할 수 있지만, WWW에서는 동일한 URL 접두어 또는 서버 주소 접두어를 가진 문서가 동일한 클라이언트로 전송되지 않을 수 있으므로 주소를 라우팅하기가 어렵습니다. 캐시 라우팅 테이블이 관리할 수 없을 정도로 커지도록 클러스터링됩니다. 또한 캐시 콘텐츠는 지속적으로 업데이트되며 오래된 캐시 라우팅 정보로 인해 캐시가 무효화됩니다. 캐시 실패 비용을 줄이기 위해 이상적인 캐시 라우팅 알고리즘은 클라이언트의 요청을 다음 프록시로 라우팅해야 합니다. 이 프록시는 적중 가능성이 더 높고 클라이언트에서 서버까지의 네트워크 경로에 있거나 가까이 위치해 있습니다.
3.2.1 캐싱 라우팅 테이블 방식
Malpani 등[7]은 클라이언트의 요청이 지정된 캐시로 전달될 때 캐시에 요청된 콘텐츠가 있으면 클라이언트로 전송됩니다. IP 멀티캐스트를 통해 동일한 그룹의 다른 캐시는 해당 콘텐츠를 캐시하는 캐시에서 클라이언트의 요청에 응답합니다. 요청한 콘텐츠가 어떤 캐시에도 캐시되어 있지 않으면 요청이 원본 서버로 전달됩니다. Harvest[3] 캐싱 시스템은 캐시를 계층적 구조로 구성하고 캐시 해결 프로토콜 ICP(인터넷 캐시 프로토콜)를 사용합니다. 캐시 오류가 발생하면 하위 수준 캐시는 고객 요청을 전달하기 전에 먼저 형제 노드 캐시를 쿼리합니다. 상위 수준 캐시. 최상위 캐시의 과부하를 방지하기 위해 해당 콘텐츠를 캐시할지 여부입니다. 적응형 웹 캐싱 시스템[8]은 각 서버에 대한 캐시 트리를 설정하고 트리의 캐시는 중첩되는 멀티캐스트 그룹으로 구성되며 요청은 이러한 전송 그룹을 통해 해당 캐시된 콘텐츠를 얻습니다. 이 방법은 서버마다 서로 다른 Cache Tree를 구성하므로 루트 노드의 과부하 문제가 없으며 자체 구성 및 견고성이 비교적 좋습니다. 그러나 클릭률이 낮은 콘텐츠에 대한 요청은 더 많은 캐시를 거치게 되어 캐시 통신 오버헤드가 커질 수 있으므로 저자는 이 문제를 해결하기 위해 요청이 통과하는 캐시 수를 제한할 것을 권장합니다.
3.2.2 해시함수 방식
Cache Array Routing Protocol CARP [6]는 배열 구성원 목록과 URL을 기반으로 하는 해시 함수를 사용하여 웹 개체의 정확한 캐시 주소나 웹 개체가 캐시되어야 하는 위치를 결정합니다. 요약 캐시[9]에서 각 프록시는 동일한 그룹의 다른 프록시가 캐시한 콘텐츠의 URL 요약 정보를 저장합니다. 프록시는 클라이언트 요청을 전달할 때 이러한 요약 정보를 확인하여 요청을 전달할 프록시를 결정합니다. 오버헤드를 줄이기 위해 이러한 요약 정보는 주기적으로 업데이트됩니다. 실험에 따르면 이 시스템은 ICP와 거의 동일한 캐시 적중률을 유지하면서 프로토콜로 인해 발생하는 캐시 간의 정보량, 대역폭 소비 및 CPU 오버헤드를 크게 줄일 수 있는 것으로 나타났습니다.
3.3 캐시 교체 알고리즘
캐시 교체 알고리즘은 프록시 캐시 시스템의 성능에 영향을 미치는 중요한 요소입니다. 좋은 캐시 교체 알고리즘은 더 높은 적중률을 생성할 수 있습니다. 지금까지 제안된 알고리즘은 다음과 같은 세 가지 범주로 나눌 수 있습니다.
(1) 전통적인 대체 알고리즘과 그 직접적인 진화는 다음과 같습니다. ①LRU(Least Recent Used) 알고리즘: 캐시 중 가장 최근에 사용된 콘텐츠를 대체합니다. ②LFU(Lease잦은 사용) 알고리즘: 캐시에서 가장 적게 방문한 콘텐츠를 대체합니다. Cache Cache; ③Pitkow/Recker[10]는 교체 알고리즘을 제안했습니다. Cache의 모든 내용이 같은 날 캐시되면 가장 큰 문서가 Cache에서 교체되고, 그렇지 않으면 LRU 알고리즘에 따라 교체됩니다.
(2) 캐시 콘텐츠의 핵심 특성을 기반으로 한 대체 알고리즘은 다음과 같습니다. ①Size[10] 대체 알고리즘: 캐시 중 가장 큰 콘텐츠를 대체합니다. ②LRU-MIN[11] 대체 알고리즘: 이 알고리즘은 다음과 같습니다. 대체된 문서 개별 최소 숫자입니다. 캐시할 문서의 크기를 S라고 가정하고, 캐시에 S 크기 이상의 캐시된 문서를 LRU 알고리즘에 따라 교체한다고 가정하고, 크기가 S 이상인 객체가 없으면 LRU를 실행합니다. 교체 알고리즘은 S/2 이상의 문서부터 사용됩니다. ③LRU - 임계값[11] 교체 알고리즘: 특정 임계값을 초과하는 문서는 캐시할 수 없다는 점을 제외하면 LRU 알고리즘과 동일합니다. 12] 교체 알고리즘: 캐시 중 접근 지연이 가장 작은 문서를 교체합니다.
(3) 비용 기반 교체 알고리즘 이 유형의 알고리즘은 비용 함수를 사용하여 캐시의 개체를 평가하고 최종적으로 비용 값을 기반으로 교체 개체를 결정합니다. 대표적인 알고리즘은 다음과 같습니다. ①하이브리드[12] 알고리즘: 캐시에 있는 각 객체에 유틸리티 함수를 할당하고, 캐시 중 가장 작은 유틸리티 값으로 객체를 대체합니다. ②최저 상대 값[13] 알고리즘: 객체를 다음으로 대체합니다. ③ LCNR(Least Normalized Cost replacement) [14] 알고리즘: 이 알고리즘은 대체 문서를 결정하기 위해 문서 액세스 빈도, 전송 시간 및 크기에 대한 추론 기능을 사용합니다. 문서 전송 시간 비용을 기준으로 제안된 방법과 마지막 액세스 시간의 가중치 추론 함수를 사용하여 문서 교체를 결정합니다. ⑤Size-Adjust LRU(SLRU) [16] 알고리즘: 비용 비율에 따라 캐시된 객체를 정렬합니다. 크기를 조정하고 교체할 비율이 가장 작은 객체를 선택합니다.
즉, 캐시 적중률을 극대화하기 위해 캐시 교체 알고리즘에 대한 많은 연구가 진행되어 왔지만 대체 알고리즘의 성능은 WWW 액세스의 특성에 크게 좌우됩니다. 모든 웹 액세스 모드를 처리하는 것이 다른 알고리즘보다 낫습니다.
3.4 캐시 일관성
웹 캐싱 시스템은 액세스 지연 시간을 줄일 수 있지만 부작용이 있습니다. 고객에게 제공되는 캐시된 복사본은 오래된 콘텐츠일 수 있으므로 캐시된 콘텐츠가 적시에 업데이트되고 검증될 수 있도록 캐시 일관성 메커니즘이 마련되어야 합니다. 방식으로 고객에게 최신 콘텐츠를 제공합니다.
현재 캐시 일관성에는 강력한 캐시 일관성과 약한 캐시 일관성이라는 두 가지 주요 유형이 있습니다.
3.4.1 강력한 캐시 일관성 (1) 클라이언트 확인: 각 액세스에 대해 프록시는 캐시된 콘텐츠가 오래된 것으로 간주하고 "IF-Modified-Since-date" 헤더를 요청과 함께 서버에 보냅니다. 지정된 시간 이후에 콘텐츠가 변경되면 서버는 업데이트된 콘텐츠를 에이전트에 보내고 결국 클라이언트에 요청한 콘텐츠가 수정되지 않은 경우 문서가 수정되지 않았음을 나타내는 "304" 응답이 다시 전송됩니다. 캐시된 콘텐츠는 계속 효율적으로 유지됩니다.
(2) 서버 확인: 서버는 콘텐츠가 변경되었음을 감지하면 최근에 콘텐츠를 요청했고 콘텐츠를 캐시했을 수 있는 모든 클라이언트에게 무효화 정보를 보냅니다[17]. 이 방법을 사용하려면 잘못된 정보를 전송하기 위해 서버가 콘텐츠에 액세스하는 클라이언트의 연결 목록을 저장해야 합니다. 클라이언트 수가 많으면 이 방법을 적용할 수 없게 되며 연결 목록 자체도 오래될 수 있습니다. , 이로 인해 서버가 더 이상 캐시되지 않는 많은 클라이언트에 메시지를 보내게 됩니다. 이 콘텐츠의 고객에게 잘못된 정보가 전송됩니다.
3.4.2 약한 캐시 일관성 (1) 적응형 TTL [18] (Time To Live) 메커니즘: 문서의 수명을 관찰하여 생존 시간을 조정함으로써 캐시 일관성 문제를 해결합니다. 문서가 상당한 기간 동안 수정되지 않으면 다시 변경되지 않는 경향이 있습니다. 이러한 방식으로 문서의 수명 속성에는 문서의 현재 "연한"(현재 시간에서 마지막 수정 시간을 뺀 것과 동일)의 백분율이 할당됩니다. 적응형 TTL 방법은 문서가 쓸모 없게 될 가능성을 5% 미만으로 제어할 수 있습니다. 대부분의 프록시 서버는 이 메커니즘을 사용하지만 문서 수명을 기반으로 하는 이 캐시 일관성 메커니즘은 캐시된 콘텐츠의 유효성을 보장하지 않습니다.
(2) 피기백 무효화 메커니즘
Krishnamurthy 등은 캐시 일관성의 효율성을 향상시키기 위해 피기백 무효화 메커니즘을 사용할 것을 제안했습니다. 그들은 세 가지 메커니즘을 제안했습니다. ① PCV(피기백 캐시 유효성 검사) [19] 메커니즘: 캐시 일관성을 향상시키기 위해 프록시가 서버로 보낸 요청을 사용합니다. 예를 들어, 프록시가 서버에 요청을 하면 유효성 확인을 위해 캐시되었지만 오래되었을 수 있는 일련의 콘텐츠를 서버에서 전달합니다. ② PSI(Piggyback Service Invalidation) [20](Piggyback Service Invalidation) 메커니즘: 기본 아이디어 서버가 프록시에 응답할 때 마지막 프록시 액세스 이후 변경된 일련의 콘텐츠를 프록시 서버에 알리고 프록시는 이러한 콘텐츠를 무효화하여 캐시에 캐시된 다른 콘텐츠의 캐시 시간을 연장합니다. 및 PCV 하이브리드 메커니즘[21]: 이 메커니즘은 마지막 요청이 에이전트에 의해 무효화된 이후 현재 간격의 크기를 기반으로 최상의 전체 성능을 달성하기 위해 사용할 메커니즘을 결정합니다. 이 시간 간격이 작으면 PSI 메커니즘이 사용되며, 그렇지 않으면 PCV 메커니즘이 캐시 내용을 확인하는 데 사용됩니다. 기본 원칙은 시간 간격이 작을수록 PSI와 함께 전송되는 Void의 수가 적어지지만 시간이 증가함에 따라 Void를 전송하는 오버헤드가 확인을 요청하는 오버헤드보다 커지게 됩니다.
3.5 콘텐츠 미리 가져오기
웹 캐싱 기술은 웹 성능을 향상시킬 수 있지만 연구에 따르면 어떤 캐싱 방식을 사용하든 최대 캐시 적중률은 일반적으로 40~50%를 넘지 않는 것으로 나타났습니다. 캐시 적중률을 더욱 향상시키기 위해 프리페칭 기술이 도입되었습니다. 프리페치(Prefetch) 기술은 본질적으로 능동형 캐싱 기술로, 고객의 현재 요청을 처리할 때 고객의 액세스 내용이나 모드에 대한 사전 지식을 활용하여 고객의 다음 요청 콘텐츠를 예측하고, 고객이 요청한 콘텐츠를 Gap 캐시에 활용하는 것이 기본 아이디어입니다. 캐시를 사용하여 대기 시간을 더 효과적으로 숨기고 서비스 품질을 향상할 수 있습니다.
초기 연구는 브라우저/클라이언트와 웹 서버 간의 콘텐츠 미리 가져오기에 중점을 두었습니다. 프록시가 도입되자 사람들의 연구 관심은 프록시와 서버 간의 미리 가져오기 기술로 옮겨졌습니다. 연구에 따르면 프리페칭 기술은 고객 액세스 대기 시간을 효과적으로 줄일 수 있지만 프리페치 기술은 다음 두 가지 이유로 여전히 논란의 여지가 있습니다.
(1) 콘텐츠 프리페치는 실시간 요구 사항이 높은 작업으로 주로 고객 요청 간격을 사용하며, 이 시간 간격은 일반적으로 이 시간 내에 프리페치 작업을 완료할 수 없는 경우에 발생합니다. , 프리페치는 의미가 없게 됩니다. 따라서 프리페치 알고리즘의 효율성에 대한 요구 사항이 더 높습니다.
(2) 콘텐츠 프리페치는 서버 로드와 네트워크 트래픽을 증가시키면서 클라이언트 응답 시간을 줄이므로 프리페치 정확도에 대한 요구 사항이 더 높습니다. 동시에 프리페치 모델은 프리페치된 문서 수를 결정할 때 고객의 액세스 특성, 서버 로드 및 네트워크 트래픽 상태를 고려해야 합니다. 이러한 요소 없이 프리페치하면 역효과가 발생할 수 있습니다.
간단히 말해서, 좋은 프리페칭 모델은 낮은 비용으로 높은 효율성과 정확성을 갖춰야 합니다. 프리패치의 효율성과 정확성에 대한 추가 연구가 필요합니다.
3.5 로드 밸런싱(Load Balancing) 많은 고객이 동시에 한 서버에서 데이터나 서비스를 얻으면 핫스팟(Hot Spot) 현상이 발생하여 서버 성능이 저하되거나 심지어 장애가 발생하기도 합니다. 이 문제를 해결하기 위한 현재 방법의 대부분은 요청된 콘텐츠를 인터넷에 저장하기 위해 일부 복제 전략을 사용하여 단일 서버가 병목 현상을 일으키지 않도록 여러 서버(에이전트)[24]에 로드를 분산시키는 것입니다.
3.6 콘텐츠 캐싱 프록시는 데이터 캐싱 외에도 연결 캐싱 및 계산 캐싱을 수행할 수 있습니다. 연결 캐싱이란 클라이언트와 에이전트, 에이전트와 서버 간의 지속적인 연결을 사용하여 TCP 연결을 설정하는 오버헤드와 서버가 전송할 때 느린 시작 오버헤드를 줄여 고객 액세스 지연 시간을 줄이는 것을 말합니다. ]. 컴퓨팅 캐싱은 서버 병목 현상을 완화하기 위해 서비스 중 일부를 프록시로 마이그레이션할 수 있는 웹 서버로 볼 수 있습니다. 해당 애플리케이션 중 하나는 프록시를 통해 동적 데이터를 캐시하고 계산의 일부를 프록시로 마이그레이션하는 동적 데이터 캐싱입니다. 캐시된 동적 데이터를 프록시하고 유지함으로써 동적 데이터를 얻는 고객의 성능을 향상시킵니다.
4 추가 연구가 필요한 문제 웹 캐싱 기술을 중심으로 많은 연구가 진행되어 유익한 결과를 얻었지만 여전히 추가 연구가 필요한 몇 가지 문제가 있습니다. 이러한 문제에는 다음이 포함됩니다.
(1) 고객 액세스 패턴 연구: 고객 액세스 패턴을 연구함으로써 캐시 관리 및 콘텐츠 미리 가져오기를 더 잘 수행하고 캐시 적중률을 향상시킬 수 있습니다.
(2) 동적 데이터 캐싱: 현재 웹 캐시 적중률이 높지 않은 중요한 이유는 콘텐츠(개인 데이터, 인증 데이터, 동적 데이터 등)의 상당 부분을 캐시할 수 없다는 점입니다. 더 많은 데이터를 캐시할 수 있게 만드는 방법과 고객이 캐시되지 않은 페이지에 액세스하는 데 대한 액세스 지연을 줄이는 방법은 웹 성능을 향상시키는 데 중요한 문제가 되었습니다.
(3) 웹 트래픽 특성: 캐싱 시스템의 효율성은 웹 액세스 흐름의 시간 지역성과 우수한 캐시 관리 전략에 달려 있습니다. 웹 클라이언트에 의해 생성되는 로드 특성을 이해하는 것은 더 나은 웹 서비스를 설계하고 제공하는 데 매우 중요합니다.
(4) 프록시 구성: 우수한 웹 성능을 얻으려면 프록시 구성 전략의 이상적인 표준은 자체 구성, 효율적인 라우팅, 로드 밸런싱, 안정적인 동작 등입니다. 이 문제에 대한 추가 연구가 필요합니다.
간단히 말해서, 웹 성능을 향상시키기 위한 최첨단 연구는 확장 가능하고 강력하며 적응 가능하고 안정적이며 효율적이며 현재와 미래의 네트워크에서 더 잘 구성할 수 있는 캐싱 솔루션을 개발하는 데 있습니다.
왕식커 우지진 시야오
(창사 410073 국립국방기술대학교 컴퓨터 과학부 병렬 및 분배 국가 핵심 연구소)
-