캐시(Cache) 작동 원리 완벽 정리: 브라우저·서버·CDN 캐시 차이와 설정 방법

캐시(Cache)가 웹사이트 속도를 높이는 원리를 이해하면 느린 페이지의 원인도 쉽게 보입니다. 웹사이트 주소를 입력하고 화면이 뜨기까지 걸리는 시간은 서버의 처리 속도와 물리적 거리에 비례합니다. 캐시(Cache)는 이 시간을 단축하기 위해 한 번 불러온 이미지, CSS, 자바스크립트 파일 등의 데이터를 사용자 PC나 중간 서버에 임시로 저장해 두는 기술입니다. 원본 서버까지 매번 찾아가지 않고 가까운 곳에 저장된 복사본을 가져오므로, 평균 1~2초가 걸리던 로딩 속도가 10~50밀리초(ms) 수준으로 줄어듭니다.

특히 대용량 파일이나 자주 변하지 않는 웹페이지 구성 요소는 캐시의 효과를 가장 크게 봅니다. 웹 브라우저는 네트워크 대역폭을 아끼고 서버는 불필요한 연산 요청을 받지 않아 양쪽 모두의 자원을 절약할 수 있습니다. 캐시가 작동하는 구체적인 원리와 종류는 다양하며, 이를 올바르게 설정하는 것이 웹 성능 최적화의 핵심입니다.

브라우저가 사용자 컴퓨터 하드디스크를 임시 서버로 쓰는 방식

사용자가 웹사이트에 처음 방문하면 웹 브라우저는 서버로부터 텍스트 파일, 이미지, 로고 등 수십 개의 파일을 다운로드합니다. 이때 브라우저는 다운로드한 파일들을 컴퓨터의 임시 저장 공간(디스크 또는 메모리)에 보관합니다. 동일한 페이지를 다시 방문하거나 다른 페이지로 이동할 때, 브라우저는 서버에 파일을 요청하기 전에 로컬 저장소에 해당 파일이 있는지 먼저 확인합니다.

로컬에 파일이 존재하고 유효 기간이 만료되지 않았다면 네트워크 연결을 아예 시도하지 않습니다. 컴퓨터 하드디스크(SSD)나 RAM에서 파일을 즉시 읽어와 화면에 뿌려줍니다. 이 과정을 개발자 도구에서 직접 확인할 수 있습니다. 구글 크롬 브라우저에서 F12를 눌러 개발자 도구를 열고 Network 탭으로 이동한 뒤 웹페이지를 새로고침(F5)해 봅니다.

네트워크 목록의 Size 항목을 보면 숫자가 아닌 (disk cache)나 (memory cache)라고 표시된 행들을 볼 수 있습니다. 이는 인터넷 망을 타고 물리적인 웹 서버에서 가져온 것이 아니라, 사용자 컴퓨터 내부 저장소에서 파일을 0ms 만에 불러왔다는 의미입니다. 웹 브라우저는 이 방식으로 네트워크 데이터 소모량을 줄이고 렌더링 속도를 극대화합니다.

웹 서버가 브라우저에게 내리는 기간 한정 명령, Cache-Control

컴퓨터에 저장된 파일이 평생 그대로 유지된다면 웹사이트 디자인이 바뀌어도 사용자는 옛날 화면만 보게 됩니다. 이를 방지하기 위해 웹 서버는 파일을 보낼 때 HTTP 응답 헤더에 캐시 유지 기간과 규칙을 명시합니다. 이 명령어가 바로 Cache-Control입니다.

가장 흔히 쓰이는 설정은 Cache-Control: max-age=31536000입니다. 여기서 숫자의 단위는 초(second)입니다. 31,536,000초는 정확히 1년입니다. 로고 이미지나 폰트처럼 1년 동안 바뀔 일이 거의 없는 파일에 이 설정을 부여합니다. 반면, 수시로 변하는 API 데이터나 HTML 파일에는 no-cache 또는 no-store 설정을 붙입니다.

no-store는 브라우저에게 어떤 캐시도 저장하지 말고 매번 새로운 데이터를 받아오라고 강제하는 명령어입니다. 개인정보가 포함된 페이지나 결제 화면에 주로 쓰입니다. 반면 no-cache는 이름과 달리 캐시를 저장하긴 하지만, 사용하기 전에 반드시 서버에 “이 파일이 유효한지” 한 번 물어보라는 명령입니다. 이 미세한 차이를 오해하면 웹사이트의 업데이트가 반영되지 않거나 반대로 서버 트래픽이 폭증하는 문제가 생깁니다.

만약 메인 페이지를 구성하는 index.html 파일에 실수로 1년짜리 캐시를 설정하면, 사이트를 개편해도 사용자들은 1년 동안 이전 메인 페이지만 보게 되는 대참사가 벌어집니다. 따라서 정적 파일의 특성에 맞춰 세밀하게 기간을 조정해야 합니다.

변하지 않은 파일은 재사용하는 유효성 검사 서명, ETag

Cache-Control 기간이 만료되었거나 no-cache 설정이 되어 있다면 브라우저는 서버에 접속해야 합니다. 하지만 서버에 접속했다고 해서 무조건 대용량 파일을 다시 처음부터 다운로드할 필요는 없습니다. 파일 내용이 이전과 완전히 똑같다면 말입니다. 이때 사용하는 도구가 바로 ETag(Entity Tag)입니다.

ETag는 특정 파일의 고유한 해시값(지문과 같은 역할)입니다. 서버는 파일을 전송할 때 헤더에 ETag: "W/5f8d9a2b" 같은 임의의 서명을 붙여 보냅니다. 브라우저는 파일과 함께 이 서명을 저장해 둡니다. 이후 캐시 유효 기간이 지나 서버에 파일을 다시 요청할 때, 브라우저는 헤더에 If-None-Match: "W/5f8d9a2b"라는 질문을 동봉해 보냅니다.

서버는 자신이 가진 현재 파일의 해시값과 브라우저가 보낸 값을 비교합니다. 두 값이 일치한다면 파일이 전혀 수정되지 않았다는 뜻입니다. 이 경우 서버는 본문 데이터를 보내지 않고 304 Not Modified라는 상태 코드만 응답합니다. 본문 데이터가 없으므로 응답 크기는 수백 바이트에 불과하며, 브라우저는 기존에 가지고 있던 캐시 파일을 그대로 재사용합니다.

이 유효성 검증 과정 덕분에 사용자는 기가바이트 단위의 웹사이트 데이터를 매번 새로 받지 않고도 항상 최신 상태를 유지할 수 있습니다. 겉보기에는 서버와 통신하는 것처럼 보이지만 실제 데이터 전송량은 0에 가깝기 때문에 화면 로딩이 끈김없이 매끄럽게 진행됩니다.

대륙 간의 물리적 거리 문제를 해결하는 CDN 캐싱

한국에 있는 사용자가 미국 오레곤주에 서버가 있는 웹사이트에 접속하면 빛의 속도로 전파가 이동하더라도 물리적 거리로 인한 지연 시간(Latency)이 발생합니다. 패킷이 바다 밑 해저 광케이블을 왕복하는 데만 최소 150ms 이상이 걸립니다. 이를 해결하기 위해 전 세계 주요 거점에 캐시 서버를 둔 네트워크가 CDN(Contents Delivery Network)입니다.

Cloudflare나 AWS CloudFront 같은 CDN 서비스를 적용하면, 원본 서버의 파일 복사본이 전 세계 엣지(Edge) 서버에 분산 저장됩니다. 서울에 있는 사용자가 접속하면 오레곤 서버가 아니라 서울 가산동에 있는 CDN 엣지 서버가 응답합니다. 물리적 거리가 몇천 킬로미터에서 수십 킬로미터 수준으로 줄어드는 것입니다.

이를 통해 웹사이트의 첫 번째 바이트를 받는 시간인 TTFB(Time to First Byte)가 획기적으로 개선됩니다. CDN 캐싱은 주로 이미지, 비디오, 대형 자바스크립트 라이브러리에 적용됩니다. 원본 서버의 트래픽 부담을 80% 이상 줄여주기 때문에 대규모 트래픽이 몰려도 서버가 다운되지 않도록 방어하는 역할도 수행합니다.

최근에는 이미지 최적화 기능도 CDN 캐시 단계에서 처리합니다. 사용자의 기기 환경에 맞춰 png 파일을 webp 포맷으로 실시간 변환하여 캐싱해 두는 방식으로 용량을 줄이고 로딩 속도를 한 번 더 끌어올립니다.

데이터베이스 부하를 줄이는 서버 내부 메모리 캐싱

웹사이트의 속도를 느리게 만드는 주범 중 하나는 데이터베이스(DB) 조회입니다. 사용자가 게시판 목록을 누르거나 상품 검색을 할 때마다 웹 서버는 하드디스크에 저장된 DB를 뒤져 결과를 만들어내야 합니다. 사용자가 많아지면 DB 서버의 CPU 사용률이 100%에 도달하며 웹사이트가 마비됩니다.

이 문제를 해결하기 위해 서버 개발자들은 Redis(레디스)나 Memcached(멤버캐시디) 같은 인메모리(In-Memory) 캐시 시스템을 사용합니다. 관계형 데이터베이스(MySQL, PostgreSQL 등)보다 백 배 이상 빠른 RAM 영역에 자주 조회되는 데이터를 키-값(Key-Value) 형태로 저장해 두는 방식입니다.

예를 들어 메인 페이지의 ‘실시간 인기 상품 목록’은 매번 DB에서 정렬 쿼리를 돌릴 필요가 없습니다. 5분에 한 번씩만 DB에서 조회해 Redis 캐시에 올려두고, 사용자가 요청할 때는 Redis에 있는 데이터를 즉시 반환합니다. 컴퓨터의 RAM은 밀리초 미만의 속도로 응답하므로 사용자는 대기 시간 없이 즉각적인 화면을 마주하게 됩니다.

이러한 서버 캐시는 데이터 만료 시간(TTL, Time To Live) 관리가 매우 중요합니다. 너무 길게 잡으면 재고 수량이나 가격 정보가 실제와 달라지는 문제가 생기고, 너무 짧게 잡으면 캐시를 쓰는 의미가 퇴색되므로 데이터의 성격에 맞는 정교한 만료 정책 설계가 뒤따라야 합니다.

개발자의 업데이트가 사용자에게 안 보일 때 대처하는 법

캐시는 웹사이트 속도를 빠르게 만들어 주지만, 치명적인 단점도 존재합니다. 개발자가 버그를 수정하여 app.js 파일을 서버에 새로 올렸는데도, 사용자의 브라우저가 예전 캐시 파일을 계속 사용하면 화면이 깨지거나 기능이 작동하지 않는 오류가 발생합니다.

이 현상이 발생했을 때 일반 사용자가 취할 수 있는 가장 단순한 방법은 강력 새로고침입니다. 윈도우 크롬 기준으로 Ctrl + Shift + R을 누르고, 맥OS에서는 Cmd + Shift + R을 누르면 브라우저는 로컬 캐시를 완전히 무시하고 서버에서 무조건 모든 파일을 새로 내려받습니다. 하지만 모든 사용자에게 일일이 이 단축키를 누르라고 요구할 수는 없습니다.

실제 서비스에서는 이 문제를 해결하기 위해 ‘캐시 버스팅(Cache Busting)’ 기술을 사용합니다. 파일의 이름 뒤에 고유한 버전 번호나 해시값을 붙이는 기법입니다. 예를 들어 <script src="main.js"></script> 대신 웹팩(Webpack) 같은 빌드 도구를 사용하여 <script src="main.a8f9b2.js"></script>처럼 파일명을 빌드할 때마다 동적으로 변경합니다.

파일명이 완전히 바뀌었기 때문에 브라우저는 이를 이전에 다운로드한 적이 없는 완전히 새로운 파일로 인식합니다. 결국 캐시 저장소를 우회하여 새 파일을 즉시 다운로드하게 됩니다. 이 기법을 도입하면 평소에는 브라우저 캐시 기간을 1년으로 길게 설정하여 로딩 속도를 최대로 확보하면서도, 사이트가 업데이트되는 즉시 모든 사용자에게 오류 없이 변경 사항을 반영할 수 있습니다.

원리를 눈으로 확인해 보기: 개발자 도구로 캐시 적중 읽는 순서

여기까지가 이론이라면, 지금부터는 방금 읽은 내용이 내 브라우저에서 실제로 일어나고 있는지 직접 확인하는 방법입니다. 저는 캐시 관련 글을 쓸 때마다 이 순서로 먼저 확인하고 본문을 씁니다. 준비물은 브라우저 하나뿐이고 1~2분이면 끝납니다.

1. 확인하려는 페이지를 열고 F12를 눌러 개발자 도구를 엽니다. 상단 탭에서 네트워크(Network)를 선택합니다.
2. 네트워크 탭이 열린 상태에서 F5로 새로고침합니다. 이때부터 요청 목록이 쌓입니다.
3. 목록의 Size(크기) 열을 봅니다. 숫자 대신 (disk cache)나 (memory cache)로 표시된 항목이 캐시에서 바로 꺼내 쓴 파일입니다. 이 항목들은 네트워크를 타지 않았기 때문에 Time 값도 0에 가깝습니다.
4. Status(상태) 열에서 304가 보이면 브라우저가 서버에 “이 파일 그대로인가요?”라고 묻고 “그대로다”라는 답만 받은 경우입니다. 파일 본문은 다시 받지 않았다는 뜻이라 200보다 훨씬 가볍습니다.
5. 특정 파일을 클릭한 뒤 Headers 탭을 열면 Cache-Control과 ETag 값이 보입니다. max-age 숫자가 이 파일을 며칠 동안 재사용할지 정한 값이고, ETag는 파일이 바뀌었는지 비교하는 서명입니다.

여기서 자주 헷갈리는 지점이 하나 있습니다. 개발자 도구의 Disable cache(캐시 사용 중지) 체크박스는 개발자 도구가 열려 있는 동안에만 동작합니다. 창을 닫으면 다시 캐시를 씁니다. 반대로 Ctrl+F5(맥은 Cmd+Shift+R)로 하는 강력 새로고침은 그 순간의 요청에만 적용됩니다. 둘을 같은 기능으로 알고 테스트하다가 “분명 껐는데 왜 예전 화면이 나오지?”라고 헤매는 경우가 많습니다.

이 확인 절차를 한 번 익혀 두면, 사이트가 느릴 때 원인이 캐시 설정인지 아니면 파일 자체가 무거운 것인지 짐작이 아니라 화면으로 구분할 수 있습니다. Size 열이 대부분 실제 숫자라면 캐시가 거의 걸리지 않고 있다는 뜻이고, 이때는 서버의 Cache-Control 설정부터 손봐야 합니다.

원리를 알았다면 다음은 실무입니다. 아래는 서버에서 캐시 수명을 직접 지정하는 방법, 로그인 페이지가 캐시되어 생기는 정보 노출을 막는 헤더, 그리고 증상만 보고 브라우저와 서버 중 어느 쪽 캐시를 지워야 하는지 가려내는 순서입니다.

Nginx 설정을 통한 정적 자원의 브라우저 캐시 제어

웹 서버 설정 파일을 직접 수정하면 브라우저가 정적 자원을 보관할 기간을 서버 측에서 지정해 내려보낼 수 있습니다. 널리 사용되는 Nginx 웹 서버를 기준으로 캐시 헤더를 설정하는 경로와 방법은 구체적입니다. 우분투 운영체제 기준으로 Nginx의 사이트 설정 파일은 보통 /etc/nginx/sites-available/default 또는 /etc/nginx/nginx.conf 경로에 위치합니다. 이 파일을 에디터로 열고 server 블록 내부에 특정 확장자를 필터링하는 규칙을 추가합니다.

1
2
3
4
5

location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
    expires 30d;
    access_log off;
    add_header Cache-Control "public";
}

위 설정은 웹 브라우저가 이미지나 동영상 파일을 한 번 다운로드하면 30일 동안 서버에 재요청하지 않고 로컬 기기에 저장된 캐시 파일만 사용하도록 지시합니다. 설정을 수정한 뒤에는 반드시 터미널에서 sudo nginx -t 명령어를 입력하여 구문 오류가 없는지 확인해야 합니다. 오류가 없다면 sudo systemctl reload nginx 명령어로 Nginx 프로세스를 재시작합니다.

작업이 정상적으로 완료되었는지 확인하려면 크롬 개발자 도구(F12)의 Network 탭에서 아무 이미지나 클릭한 뒤 Headers 영역의 Response Headers를 조회합니다. 헤더 목록에 Cache-Control: max-age=2592000 문구가 찍혀 있다면 정상적으로 반영된 것입니다. 여기서 2592000초는 정확히 30일을 초 단위로 환산한 수치입니다.

개인 정보 유출을 차단하기 위한 캐시 보안 정책 헤더

데이터 로딩을 빠르게 해주는 캐시는 유용하지만 보안이 필요한 영역에 무분별하게 적용되면 타인의 계정 정보나 개인 정보가 그대로 노출되는 심각한 결함으로 이어집니다. 마이페이지 화면, 장바구니 상세 내용, 가상계좌 발급 내역 같은 개인식별정보(PII)가 담긴 웹 페이지가 공용 PC의 브라우저에 임시 파일로 저장되는 경우, 로그아웃 후 뒤로 가기 버튼을 눌렀을 때 다음 사용자에게 이전 정보가 화면에 그대로 복원되는 상황이 연출되기도 합니다.

이를 원천 차단하기 위해 개인 정보를 다루는 모든 동적 API 및 화면 렌더링 경로의 응답값에는 엄격한 보안 목적의 헤더 구성을 직접 선언해 두어야 합니다. 백엔드 개발 시 HTTP 응답 제어 로직에 아래 헤더 설정을 반드시 주입해야 합니다.

1

Cache-Control: no-store, no-cache, must-revalidate, private Pragma: no-cache Expires: 0

no-store 옵션은 브라우저를 포함한 어떠한 임시 저장 장치도 응답으로 받은 데이터를 파일 형태로 디스크에 기록하지 못하게 강제합니다. private 옵션은 오직 해당 요청을 보낸 사용자의 브라우저 메모리에만 제한적으로 유지될 수 있으며 전송 중간 경로에 놓여 있는 CDN 장비나 공용 프록시 서버에는 절대로 해당 데이터가 캐싱되어 머무를 수 없도록 봉쇄합니다. 사용자의 브라우저 버전에 따라 레거시 규격만 인지하는 상황을 방지하기 위하여 구 구격인 Pragma: no-cache 헤더도 나란히 명시하여 보완합니다. 스프링 시큐리티나 익스프레스 세션 모듈 같은 프레임워크를 연동하여 사용할 때는 해당 보안 헤더들이 핵심 비즈니스 로직 경로에서 자동으로 주입되고 있는지 검증 도구를 사용해 점검할 필요가 있습니다.

증상만 보고 어느 쪽 캐시를 지울지 가려내는 순서

브라우저 캐시와 서버 캐시의 구조를 아는 것과, 문제가 생겼을 때 어느 쪽을 손봐야 하는지 판단하는 것은 다른 일입니다. 저는 수정한 내용이 화면에 안 보인다는 이야기를 들으면 무작정 전체 캐시를 비우기 전에 아래 순서로 범위부터 좁힙니다. 순서가 중요한 이유는, 서버나 CDN 캐시를 통째로 비우면 그 직후 모든 방문자의 요청이 서버로 몰려 오히려 사이트가 느려지기 때문입니다.

1. 시크릿 창으로 같은 주소를 엽니다. 시크릿 창은 기존 브라우저 캐시를 쓰지 않습니다. 여기서 수정한 내용이 정상으로 보이면 원인은 내 브라우저 캐시입니다. 이 경우 해당 사이트 데이터만 지우면 끝납니다.
2. 다른 기기나 모바일 데이터로 접속해 봅니다. 시크릿 창에서도 예전 화면이 나오는데 다른 기기에서는 정상이라면 내 컴퓨터의 DNS 캐시나 네트워크 장비 쪽을 의심할 차례입니다.
3. 모든 환경에서 예전 화면이 나온다면 서버 쪽입니다. 이때는 사이트에 설치한 캐시 플러그인의 캐시를 먼저 비우고, 그래도 그대로면 CDN 캐시를 비웁니다. 순서를 바꾸면 CDN이 다시 옛날 파일을 받아 저장해 버려 헛수고가 됩니다.
4. 특정 파일만 확인하고 싶다면 주소 뒤에 ?v=2 처럼 값을 붙여 봅니다. 이렇게 하면 브라우저와 CDN 모두 새 주소로 인식해 원본을 다시 받아옵니다. 파일 자체는 정상인데 캐시만 오래된 것인지 확인하는 가장 빠른 방법입니다.

반대로 운영자가 아니라 방문자 입장이라면 2번까지만 해도 충분합니다. 서버 캐시는 사이트 운영자만 손댈 수 있고, 방문자가 할 수 있는 것은 자신의 브라우저 캐시를 비우거나 강력 새로고침을 하는 것까지입니다. 며칠이 지나도 계속 옛날 화면이라면 그 사이트 운영자에게 알려 주는 편이 빠릅니다.

전체 비우기 대신 부분 비우기를 먼저 쓰는 이유

캐시를 비울 때 전체 삭제 버튼부터 누르는 습관은 권하지 않습니다. 정적 파일 캐시, 페이지 캐시, 객체 캐시가 각각 다른 역할을 하는데 한꺼번에 지우면 문제가 어디에 있었는지 알 수 없게 되고, 다시 쌓일 때까지 사이트가 눈에 띄게 느려집니다.

• 글 하나만 수정했다면 해당 글 주소의 캐시만 비웁니다. 대부분의 캐시 플러그인은 글 편집 화면이나 관리자 툴바에서 개별 삭제를 지원합니다.
• 디자인(CSS)이나 스크립트를 바꿨다면 정적 파일 캐시만 비우고, 파일명 뒤 버전 값을 올려 두면 재발을 막을 수 있습니다.
• 메뉴 구성이나 위젯처럼 모든 페이지에 나오는 요소를 바꿨을 때만 전체 비우기를 씁니다. 이때는 방문자가 적은 시간대를 고르는 편이 안전합니다.
• CDN을 함께 쓴다면 서버 캐시를 비운 다음에 CDN을 비우고, 마지막으로 브라우저에서 강력 새로고침으로 확인하는 순서를 지킵니다.

이 글과 헷갈리기 쉬운 주제 구분

캐시를 다루는 글이 여러 편이라 어디를 봐야 할지 헷갈릴 수 있어 정리해 둡니다. 이 글은 캐시가 속도를 만들어 내는 구조와 그것을 직접 확인하는 방법에 초점을 둡니다.

• 캐시라는 개념 자체가 처음이라면 웹사이트 캐시란 무엇일까요부터 보는 편이 순서상 자연스럽습니다.
• 내 컴퓨터의 캐시와 서버의 캐시 중 어느 쪽을 손봐야 하는지 판단하려면 브라우저 캐시와 서버 캐시 차이점을 참고하세요.
• 지금 당장 지우는 절차만 필요하다면 브라우저 캐시 비우기 방법으로 바로 가시면 됩니다.

캐시 작동 원리 자주 묻는 질문

Cache-Control과 ETag는 무엇이 다른가요?

Cache-Control은 얼마 동안 다시 묻지 않고 재사용할지를 정하는 기간 규칙이고, ETag는 기간이 지난 뒤 파일이 바뀌었는지 확인하는 서명입니다. 내용이 그대로면 서버가 304로 답해 파일을 다시 내려받지 않습니다.

304 응답은 무슨 의미인가요?

요청한 파일이 이전과 동일하니 저장해 둔 것을 그대로 쓰라는 뜻입니다. 본문 데이터를 전송하지 않으므로 트래픽과 로딩 시간이 크게 줄어듭니다.

CDN 캐시와 브라우저 캐시는 어느 쪽이 먼저 동작하나요?

브라우저 캐시가 먼저입니다. 내 컴퓨터에 저장된 파일이 유효하면 네트워크 요청 자체가 발생하지 않고, 없거나 만료된 경우에만 가까운 CDN 서버로 요청이 넘어갑니다.

웹사이트 속도를 높이는 원리를 더 깊게 보는 자료

캐시가 웹사이트 속도를 높이는 원리를 실제 설정과 연결해 보고 싶다면 아래 글들을 함께 추천합니다. 기본 개념은 웹사이트 캐시란 무엇일까요에서, 계층별 차이는 브라우저 캐시와 서버 캐시 차이점에서 확인할 수 있습니다. CDN 적용 사례는 클라우드플레어 캐시 설정 가이드가 도움이 됩니다. 표준 사양은 MDN HTTP 캐싱 문서와 web.dev HTTP 캐시 가이드에서 확인하세요.

Leek의 블로그 홈으로

다른 속도 최적화와 문제 해결 가이드도 홈에서 모아 보실 수 있습니다.