[HTTP] 07. 캐시 (1)

복수의 클라이언트가 자주 쓰이는 원 서버 페이지에 접근할 때, 서버는 같은 요청에 대해 여러번 응답해줘야 한다. 캐시를 이용하면, 첫 번째 서버 응답은 캐시에 보관된다. 이후, 캐시된 사본이 뒤이은 요청들에 대한 응답으로 사용될 수 있기 때문에, 원 서버가 중복해서 트래픽을 주고받는 낭비가 줄어들게 된다.

7.2 대역폭 병목

캐시는 네트워크 병목을 줄여준다. 많은 네트워크가 원격 서버(원 서버)보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공한다. (상식적으로 원격 서버는 멀리 떨어져 있고, WAN에 속할 것이며, 클라이언트가 소속된 네트워크는 LAN이며, 물리적으로 가깝기 때문에 더 빠를 것이다.)

아래 이미지로 설명하면, 서버의 리소스를 LAN 혹은 클라이언트와 근거리에 위치한 곳에 캐시에 저장하면, WAN의 느린 대역폭을 해소할 수 있다.

7.3 갑작스런 요청 쇄도(Flash Crowds)

캐싱은 갑작스런 요청 쇄도에 대처하기 위해 특히 증요하다. 예기치 못한 동시다발적인 요청은 웹 서버에 심각한 장애를 야기할 수 있다.

7.4 거리로 인한 지연

비록 대역폭이 문제가 되지 않더라도, 거리가 문제가 될 수 있다. 모든 네트워크 라우터는 제각각 인터넷 트래픽을 지연시킨다. 그리고, 전송하는 매체의 속도로 인해서도 어느정도 지연이 발생할 수 있따. 가까운 곳은 금방 전송될 것이며, 먼 곳은 이보다 시간이 더 소요될 것이다.

7.5 적중과 부적중

캐시가 세상 모든 문서의 사본을 저장하지는 않는다. 만일 모든 문서를 저장한다고 할지라도, 변경이 잦은 문서일 경우, 그 문서에 대한 최신 상태를 유지하기는 어려울 것이다.

캐시 적중(cache hit) : 대응하는 사본이 있을 경우, 캐시 서버에서 데이터를 응답받음.
캐시 부적중(cache miss) : 대응하는 사본이 없을 경우, 원 서버에서 데이터를 응답받아야 함.

7.5.1 재검사(Revalidation)

원 서버 컨텐츠가 변경 될 수 있기 때문에, 캐시는 반드시 그들이 갖고 있는 사본이 여전히 최신인지 서버를 통해 때때로 점검해야 한다. 이를 HTTP 재검사(Revalidation)이라고 한다. 캐시는 원하는 때에 언제든지 재검사를 수행할 수 있지만, 대역폭 문제로 인해, 대부분의 캐시는 클라이언트가 사본을 요청하였으며 그 사본이 검사할 필요가 있을 정도로 오래된 경우에만 재검사를 수행한다.

만약 재검사의 결과로, 컨텐츠가 변경되지 않았다면, 원 서버는 304 Not Modified 응답 메시지를 전달할 것이다. 이를 재검사 적중(or 느린 적중)이라고 말한다. 순수 캐시 Hit 보다는 느리지만, 캐시 Miss보다는 빠르다.

아래 요청은 MDN Web Docs에 보낸 요청으로 캐시가 Hit일 경우 304 Not Modified 응답 메시지를 보낸다는 것의 예시이다.

HTTP의 If-Modified-Since 헤더를 통해 컨텐츠의 변경 여부를 확인할 수 있다. GET 요청에 이 헤더를 추가하면, 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미를 갖는다. If-Modified-Since 헤더를 포함한 경우의 결과는 다음 세 가지를 따른다.

서버 컨텐츠가 변경되지 않은 경우 : 서버는 클라이언트(캐시)에게 HTTP 304 Not Modified 메시지를 응답한다.

서버 컨텐츠가 변경된 경우 : 컨텐츠와 함께 HTTP 200 OK 응답을 전송한다.
서버 컨텐츠가 삭제된 경우 : HTTP 404 Not Found 응답을 전송한다.

7.5.2 적중률

‘캐시 적중률’(or 문서 적중률)은 캐시가 요청을 처리하는 비율을 의미한다. 실제 적중률은 아래의 사항들을 고려하여 개선한다.

캐시가 얼마나 큰가?
캐시 사용자들의 관심사가 비슷한가?
캐시된 데이터가 얼마나 자주 변경되거나 개인화되는가?
캐시가 어떻게 설정되있는가?

7.5.3 바이트 적중률

문서들이 같은 크기가 아니기 때문에 문서 적중률이 모든 것을 말해주지는 않는다. 몇몇 큰 객체들은 덜 접근되지만 그 크기 때문에 전체 트래픽에는 더 크게 영향을 줄 수 있다. 이 경우에는 바이트 단위로의 캐시 적중률을 측정하는 것이 더 유용할 수 있다.

7.5.4 적중과 부적중의 구별

클라이언트는 요청에 대한 응답이 캐시에서 Hit되어 왔는지, 아니면 원 서버에서 왔는지 직접적으로 알 수 없다. 캐시에서 왔는지 알 수 있는 방법은 “Date” 헤더를 이용하여, Date의 값과 현재 시간을 비교하는 것이다. 다른 방법으로는 “Age” 헤더를 이용하여, 응답이 얼마나 오래되었는지 확인할 수 있다.

7.6 캐시 토폴로지

한 명에게만 할당된 캐시를 ‘개인 캐시’(private cache)라고 말하며, 다수의 이용자에게 할당된 캐시를 ‘공용 캐시’(public cache)라고 말한다.

7.6.1 개인 전용 캐시

개인 전용 캐시의 흔한 예시는 브라우저이다. 웹 브라우저는 개인 전용 캐시를 내장하고 있다. 자주 쓰이는 문서를 개인용 컴퓨터의 디스크와 메모리에 캐시해 놓고, 사용자가 캐시 사이즈와 설정을 수정할 수 있도록 허용한다. 아래의 경로는 윈도우10 환경에서의 크롬의 캐시파일 저장폴더이다.

C:\\Users\\사용자명\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Cache\\Cache_Data

위와 같은 형태로 저장되는데, 내부적으로 캐시 파일명을 정하는 규칙이 있는듯 하다.

7.6.2 공용 프락시 캐시

공용 캐시는 ‘캐시 프락시 서버’ 혹은 ‘프락시 캐시’라고 불린다. 공용 캐시에는 여러 사용자가 접근하기 때문에, 불필요한 트래픽을 줄일 수 있는 더 많은 기회가 있다. 이때 공용 캐시는 개인 사용자의 의해, 다수의 사용자의 높은 관심사로 인해 캐시되었던 데이터가 지워지지 않도록, 충분히 큰 공간을 가지고 있어야 한다.

클라이언트가 공용 캐시를 사용하도록, 클라이언트 단에서 직접 프록시를 설정하는 방법이 있다. 다른 방법으로는 인터셉터 프록시를 이용해 HTTP 요청을 캐시를 통하도록 강제할 수 있다.

7.6.3 프록시 캐시 계층들

작은 캐시에서 캐시 Miss가 발생했을 때, 더 큰 부모 캐시가 Miss되었던 트래픽을 처리하도록 하는 방법을 프록시 캐시 계층이라고 말한다. 이 아이디어는 클라이언트 주위에는 작고 저렴한 캐시를 사용하고, 계층 상단에는 많은 사용자들에 의해 공유되는 문서를 유지하기 위해 더 크고 강력한 캐시를 사용하자는 것이다.

7.6.4 캐시망, 컨텐츠 라우팅, 피어링

몇몇 네트워크 아키텍처는 단순한 캐시 계층 대신 복잡한 캐시망을 만든다. 이러한 캐시망에서는 어떤 부모 캐시로 갈 것인지, 캐시를 우회하여 원 서버로 가야되는지 등을 동적으로 결정한다. 캐시망 안에서의 컨텐츠 라우팅을 위해 설계된 캐시들은 다음에 나열된 일을 수행할 수 있을 것이다.

URL에 근거하여, 부모 캐시와 원 서버 중 하나를 동적으로 선택한다.
URL에 근거하여, 특정 부모 캐시를 동적으로 선택한다.
부모 캐시에게 가기 전, 로컬 캐시를 우선적으로 확인한다.
캐시와 캐시 간의 인터넷 트랜짓(트래픽이 다른 네트워크로 옮겨지는 것)은 허용하지 않는다.

위와 같은 캐시망에서 서로 다른 조직의 캐시를 서로 연결하여, 상호 이득을 취하기 위해 ‘피어링’이라는 관계를 맺기도 한다. 이를 ‘형제 캐시’라고 부른다. HTTP 에서는 형제 캐시를 지원하지 않기 때문에, ICP(Internet Cache Protocol) or HTCP(HyperText Cache Protocol)를 이용해 형제 캐시를 구현한다.

7.7 캐시 처리 단계

간단한 GET 요청을 예시로 들었을 때, 캐시 처리 단계는 다음과 같다.

요청 받기 - 캐시는 네트워크로부터 도착한 요청 메시지를 읽는다.
파싱 - 캐시는 메시지를 파싱하여 URL과 헤더들을 추출한다.
검색 - 캐시는 로컬 복사본이 있는지 검사하고, 없다면 사본을 받아온다.( → 어디에서 받아오는 지는 캐시 계층과 캐시망에 따라 달라진다.)
신선도 검사 - 캐시는 캐시된 사본이 충분히 최신의 것인지 확인하고, 만약 그렇지 않아 보인다면 원 서버에게 변경사항이 있는지 물어본다.
응답 생성 - 캐시는 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다.
발송 - 캐시는 네트워크를 통해 응답을 클라이언트에게 돌려준다.
로깅 - 선택적으로, 로그파일에 트랜잭션에 대한 정보를 기록한다.

7.7.3 단계 3 : 검색

캐시는 URL을 알아내고 그에 해당하는 로컬 사본이 있는지 검사한다. 로컬 복사본은 메모리, 디스크 혹은 근처의 다른 컴퓨터에 저장되어 있을 수 있다. 만약 로컬에서 복사본을 가져올 수 없을 경우, 캐시는 상황이나 설정에 따라서 원 서버나 부모 프락시로 부터 가져오거나, 클라이언트에게 실패(404)를 반환한다.

캐시된 객체는 서버 응답 본문과 원 서버 응답 헤더를 포함하고 있으므로, 캐시 적중 동안 올바른 서버 헤더가 반환될 수 있다.

7.7.5 단계 5 : 응답 생성

캐시된 응답을 원 서버에서 온 것처럼 보이게 하기 위해, 캐시는 캐시된 서버 응답 헤더를 토대로 응답 헤더를 생성한다. 추가적으로, 캐시는 클라이언트에 맞게 응답 헤더를 조정해야 되는 책임이 있기 때문에, 클라이언트가 HTTP/1.1 요청을 보냈고 & 원 서버는 HTTP/1.0 응답을 보냈다면, 원 서버가 보낸 응답 헤더를 HTTP/1.1 로 변환해야 한다.

그리고 캐시 신선도와 관련된 정보(Cache-Control, Age, Expires 헤더 등)을 삽입할 수 있다. 주의할 점은, Date 헤더는 최초의 원 서버로 부터 객체가 생겨난 일시를 나타냄으로, 이를 변경해서는 안된다.

'CS > 네트워크' 카테고리의 다른 글

[HTTP] 10. HTTP/2.0 (2)	2024.01.08
[HTTP] 07. 캐시 (2) (2)	2024.01.08
[HTTP] 06. 프락시 (2)	2024.01.07
[HTTP] 05. 웹 서버 (2)	2024.01.05
[HTTP] 04. 커넥션 관리 (2)	2024.01.05

Waltz for programming

[HTTP] 07. 캐시 (1)

7.1 불필요한 데이터 전송

7.2 대역폭 병목

7.3 갑작스런 요청 쇄도(Flash Crowds)

7.4 거리로 인한 지연