캐시(cache)란?
자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 캐시는 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다.
캐싱(Caching)이란?
애플리케이션의 처리 속도를 높여 준다. 이미 가져온 데이터나 계산된 결괏값의 본사본을 저장함으로써 처리속도를 향상시키며, 이를 통해 향후 요청을 더 빠르게 처리할 수 있다. 대부분의 프로그램이 동일한 데이터나 명령어를 반복해서 액세스 하기 때문에 캐싱은 효율적인 아키텍처 패턴이다.
웹 캐시(WEB Cache)란?
사용자가 웹사이트(client)에 접속할 때, 정적 컨텐츠(JS, 이미지, CSS)를 특정 위치에 저장하여, 웹 사이트 서버에 해당 콘텐츠를 매번 요청하여 받는 것이 아닌, 특정 위치에서 불러옴으로써 사이트 응답 시간을 줄이고, 서버 트래픽 감소 효과를 볼 수 있는 것을 말한다.
❗️ 웹 캐쉬의 종류
웹 캐쉬의 종류는 어디에 적용하느냐에 따라 다음과 같이 나뉠 수 있다. 이중 중점적으로 볼 내용은 Browser Cache이다.
1. Browser Cashes
- 브라우저 또는 HTTP 요청을 하는 Client Appliction에 의해 내부 디스크에 캐시
- 캐시된 리소스를 공유하지 않는 한 개인에 한정된 캐시
- 브라우저의 back버튼 또는 이미 방문한 페이지를 재 방문하는 경우 극대화
2. Proxy Caches
- Browser Cashes와 동일한 원리로 동작하며 Client나 Server가 아닌 네트워크 상에서 동작
- 큰 회사나 IPS의 방화벽에 설치되며 대기시간 & 트래픽 감소, 접근 정책 & 제한 우회, 사용률 기록 등을 수행
- 한정된 수의 클라이언트를 위해 무한 대의 웹 서버 콘텐츠를 캐시
3. GateWay Caches
- 서버 앞 단에 설치되어 요청에 대한 캐시 및 효율적인 분배를 통해 가용성, 신뢰성, 성능 등을 향상
- Encryption, SSL acceleration, Load balancing, Server/ cache static content, Compression 등을 수행
- 무한 대의 클라이언트들에게 한정된 수의 웹 서버 콘텐츠를 제공
📌 어떻게 캐시를 컨트롤하나요?
브라우저는 한번 요청한 파일은 그 이후부터는 캐시를 사용한다. 하지만 만약 캐쉬되지 않아야하거나 캐쉬된 내용에 변경이 필요하면 어떻게 될까? 브라우저가 어떻게 캐쉬를 컨트롤하는지 알아야 한다.
HTTP header를 사용하는 방법이다.
쿠키는 클라이언트(프론트)와 서버 간에 데이터를 주고받는 가장 간단한 방법 중 하나이고 브라우저에 저장되는 작은 데이터 조각으로, 임시 데이터 보관 또는 웹페이지 개인화 등에 사용된다. 이런 것들에 대한 설정을 헤더를 통해 할 수 있다. 쿠키나 캐시에 대한 정보는 개발자 도구(크롬 기준)의 Application 탭에서 쉽게 확인할 수 있다.
보통 캐싱은 GET 요청에만 한다. GET이 REST적 의미로 가져오다이기 때문에, 가져온 데이터를 저장해 두고 두고두고 쓰는 것이다. 다른 요청 메서드를 캐싱하는 것을 잘 보지 못했습니다. 복잡한 경우는 제외하고요. 일반적으로 200(가져오기 성공), 301(다른 주소로 이동 후 가져옴), 404(가져올 게 없음) 상태 코드로 온 응답을 캐싱할 수 있다.
아무것도 캐싱하지 않음.
Cache-Control: no-store
를 하면 된다. 또는 no-cache, no-store, must-revalidate로 no 시리즈를 다 붙여준다.
Cache-Control: no-cache
는 가장 많이 헷갈려하는 헤더 설정인데, no-cache이지만 cache하지 말라는 뜻이 아니다. 모든 캐시를 쓰기 전에 서버에 이 캐시를 써도 되냐고 물어보라는 뜻이다.
Cache-Control: must-revalidate
must-revalidate는 만료된 캐시만 서버에 확인을 받도록 하는 거다.
Cache-Control: public 또는 private
public이면 공유 캐시(또는 중개 서버)에 저장해도 된다는 뜻이고 private이면 브라우저 같은 특정 사용자 환경에만 저장하라는 뜻이다.
Cache-Control: public, max-age=3600
max-age로 캐시 유효시간을 줄 수 있다. 초 단위이므로 위 예제에서는 1시간이다. 1시간이 지나면 이 응답 캐시는 만료된 것으로 여겨진다.
참고로 위의 옵션들은 혼합해서 사용할 수 있다. no-store, no-cache, must-revalidate처럼 콤마로 구분하면 된다.
Age
Age 헤더는 캐시 응답 때 나타나는데, max-age 시간 내에서 얼마나 흘렀는지 초 단위로 알려준다. 위 예제에서 max-age = 3600을 설정한 경우, 1분이 지나면 Age: 60
Expires
Cache-Control과는 별개로 응답에 Expires라는 헤더를 줄 수도 있다.
Expires: Thu, 26 Jul 2018 07:28:00 GMT
응답 콘텐츠가 언제 만료되는 지를 나타내며, Cache-Control의 max-age가 있는 경우 이 헤더는 무시된다.
ETag
HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그이다. 같은 주소의 자원이더라도 컨텐츠가 달라졌다면 Etag가 다르다.
예를 들어
GET www.zerocho.com의 응답 본문이 안녕 제로초이고 ETag 헤더 값이 12345라 칩시다. 만약 서버 컨텐츠(응답 본문)가 동일하다면 매번 GET www.zerocho.com을 할 때마다 ETag는 12345입니다. 그런데 안녕 제로초에서 안녕 이 태그로 콘텐츠가 바뀌었다면 ETag 헤더 값도 34567로 바뀝니다. 그러면 서버가 클라이언트의 응답 내용이 달라졌구나를 깨닫게 되어 캐시를 지우고 새로 콘텐츠를 내려받을 수 있게 됩니다.
Etag: W/"3bf2-wdj3VvN8/CvXVgafkI30/TyczHk"
If-None-Match
서버 보고 Etag가 달라졌는지 검사해서 Etag가 다를 경우에만 콘텐츠를 새로 내려주라는 뜻이다.
If-None-Match: W/"3bf2-wdj3VvN8/CvXVgafkI30/TyczHk"
만약 Etag가 같다면 서버는 304 Not Modified를 응답해서 캐시를 그대로 사용하게 한다.
Set-Cookie
서버에서 클라이언트(브라우저)한테 이런 쿠키를 저장하라고 명령하는 응답 헤더이다.
Set-Cookie: 키=값; 옵션들
Set-Cookie: hello=zero면 hello라는 키에 값을 zero로 해서 보낼 수 있는 거죠. 옵션들도 몇 개 알려드리겠습니다.
- Expires: 쿠키 만료 날짜를 알려줄 수 있다.
- Max-Age: 쿠키 수명을 알려줄 수 있다. Expires는 무시된다.
- Secure: https에서만 쿠키가 전송된다. (안전)
- HttpOnly: 자바스크립트에서 쿠키에 접근할 수 없다. XSS 요청을 막으려면 활성화해두는 것이 좋다.
- Domain: 도메인을 적어주면 도메인이 일치하는 요청에서만 쿠키가 전송된다. 가끔 도메인이 다른 쿠키들이 있는데, 이런 쿠키들은 써드 파티 쿠키로 사용자를 추적하고 있는 쿠키이다. 구글이나 페이스북 같은 곳이 써드 파티 쿠키를 적극적으로 사용한다.
- Path: 패스를 적어주면 이 패스와 일치하는 요청 요청에서만 쿠키가 전송된다.
예를 들면 다음과 같이 가능하다.
Set-Cookie: zerocho=babo; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
쿠키는 XSS 공격과 CSRF 공격 등에 취약하기 때문에 HttpOnly 옵션을 켜 두고, 쿠키를 사용하는 요청은 서버 단에서 검증하는 로직을 꼭 마련해두는 것이 좋다.
'기본 지식' 카테고리의 다른 글
프론트엔드 성능 최적화를 시작하기 전에 (1) | 2023.01.27 |
---|---|
브라우저 동작 원리의 모든 것. (0) | 2022.09.22 |