1. 캐시 정리 및 공부
https://forensicswiki.xyz/wiki/index.php?title=Chrome_Disk_Cache_Format
Chrome Disk Cache Format - Forensics Wiki
Please help to improve this article by expanding it. Further information might be found on the discussion page. Cache files The cache is stored in multiple: Filename Description index The index file data_# Data block files f_###### (Separate) data stream f
forensicswiki.xyz
1. 캐시의 주소는 4바이트로 구성되어 있으며 오프셋 범위에 따라서 역할이 달라짐
0.0(28/16 비트): 파일번호, f_##### 의 #값을 나타냄/ 블록번호
2.0(8비트): 파일번호(또는 파일 선택기), data_#의 # 값을 나타냄
3.0(2비트): 블록크기(0부터 시작)
3.4(3비트): 파일형식
3.7(1비트): 초기화된 플래그
*파일 형식
- 0: (별도) 데이터 스트림 파일
- 1: (순위) 블록 데이터 파일 (36 바이트 블록 데이터 파일)
- 2: 256 바이트 블록 데이터 파일
- 3: 1024바이트 블록 데이터 파일
- 4: 4096 바이트 블록 데이터 파일
- 6: 알려지지 않은 파일
ex)
1. 0x00000000 : 초기화되지 않음
2. 0x8000002a: 데이터 스트림 파일-f_00002a
3. 0xa0010003: 블록 데이터 파일- data_1, 블록 번호 3. 블록 사이즈 1
2. 인덱스 파일 형식
인덱스 파일 헤더는 크기가 256바이트로 구성되어 있으며 오프셋 마다 역할이 다름.
가장 최근에 사용한(LRU) 데이터는 크기가 112바이트로 구성되어 있고 마찬가지로 오프셋 별로 의미가 다름.
배열 인덱스는 파일 유형에 해당.
- 0: 별도의 파일
- 1: (순위) 블록 데이터 파일
- 2: 256 바이트 블록 데이터 파일
- 3: 1024바이트 블록 데이터 파일
- 4: 4096 바이트 블록 데이터 파일
인덱스 테이블은 캐시 주소의 배열을 의미함.
3. 데이터 블록 파일 형식
데이터 블록 파일은 파일 헤더와 블록 배열로 구성되어 있음. 파일 헤더는 8192 바이트로 구성되어 있고, 오프셋 별로 의미가 다름.
캐시 항목은 256 바이트로 구성되어 있음.
데이터 스트림의 배열 인덱스는 0(HTTP 응잡 헤더)와 페이지 내용(페이로드)로 구성됨.
캐시 진입 상태는
- 0: ENTRY_NOMAL ; 일반 캐시 항목
- 1: ENTRY_ECIVTED ; 캐시 항목이 최근에 제거 되었습니다
- 2: ENTRY_DOOMED ; 캐시 항목이 실패했습니다
캐시 항목 플래그는 맨 뒷 값에 따라서 결정, 1이면 상위 캐시 항목이고 2면 하위 캐시 항목임
순위 노드
36바이트로 구성
4. 데이터 스트림
데이터 스트림은 데이터 블록파일(data_#) 내부에 저장, 소량의 데이터에 대해서는 별도의 파일(f_######)으로 저장됨. 데이터 스트림은 gzip 파일로 저장됨.
https://www.chromium.org/developers/design-documents/network-stack/disk-cache/
Disk Cache
Disk Cache OverviewExternal InterfaceDisk StructureCache AddressIndex File StructureBlock File StructureCache EntryThe Big PictureImplementation NotesLower InterfaceEvictionBufferingDeleting EntriesEnumerationsSparse DataDedicated ThreadData Integrity The
www.chromium.org
외부 인터페이스
크로미움 캐시의 모든 구현은 디스크 캐시 백엔드 및 디스크 캐시 엔드리의 두 가지 인터페이스를 노출함. 백엔드 캐시에 저장된 리소스를 열거하고 이전 항목을 열거나 새 항목을 만드는 등의 방법을 제공. 주어진 리소스에 특정한 작업은 항목 인터페이스로 처리됨.
항목은 리소스의 이름인 키로 식별. 항목이 생성되면 해당 특정 리소스에 대한 데이터는 별도의 청크 또는 데이터 스트림에 저장.
디스크 구조
크로미움의 디스크 캐시를 저장하는 모든 파일은 단일 폴더 안에 있으며 해당 폴더 안의 모든 파일은 캐시의 일부로 간주.
크로미움은 인덱스 파일 1개와 데이터 파일 4개 등 최소 5개의 파일을 사용.
인덱스 파일: 캐시에서 항목을 찾는 데 사용되는 기본 해시 테이블 포함
데이터 파일: 부기 정보에서 실제 HTTP 헤더 및 주어진 요청에 이르기까지 모든 종류의 데이터 포함
인덱스 파일과 데이터 파일은 파일 형식이 고정크기 블록에 정보를 저장하도록 최적화 되어 있어서 블록 파일이라고 하기도 함.
데이터 조각의 크기가 맥스 블록 사이즈보다 클 경우, 표정 블록 파일에 저장되는 것이 아니라 별도 파일에 저장됨. 이 파일은 특별한 헤더가 없고 저장하려는 데이터만 포함하는 파일. 별도의 파일 이름은 f_xx 형식을 따름. 여기서 xx는 파일을 식별하려는 16진수
캐시주소
디스크 캐시에 저장된 모든 데이터에는 지정된 '캐시 주소'가 있음. 캐시 주소는 데이터가 실제로 있는 위치를 정확히 설명하는 32비트 숫자.
캐시 항목에는 주소가 있음. HTTP 헤더, 실제 요청 데이터, 항목 이름(키), 보조 정보에도 다른 주소가 있음. 주소를 통해서 동일한 인프라를 재사용하여 다양한 유형의 데이터를 효율적으로 저장하는 동시에 자주 수정되는 데이터를 함께 보관할 수 있음 -> 액세스 대기 시간을 줄일 수 있음.
캐시 주소는 기본적으로 필요한 데이터가 블록 파일 내부에 저장되어 있는지 혹은 별도의 파일로 저장되어 있는지와 파일번호(블록 파일 또는 기타)를 알려줌. 데이터가 블록 파일의 일부인 경우 캐시 주소에는 데이터가 있는 첫 번째 블록 번호, 사용된 블록 수 및 블록 파일 유형도 있음.
인덱스 파일 구조
인덱스 파일 구조는 실제 해시 테이블에 뒤따르는 디스크 캐시 인덱스 헤더 구조임. 테이블의 항목 수는 최소 테이블 사이즈이지만 실제 크기는 헤더의 table_len 멤버에 의해 제어됨.
전체 파일은 리소스 이름(키)의 해시와 리소스를 저장하는 캐시 주소 간의 빠른 변환을 허용하도록 매핑된 메모리. 해시의 하위 비트는 테이블을 인덱싱하는 데 사용되며 테이블의 내용은 해시에 동일한 하위 비트가 있는 첫 번쨰 저장된 리소스의 주소임.
디스크 캐시 파일(인덱스 및 모든 블록 파일)을 처리할 때는 헤더의 매직 넘버가 예상 값과 일치하고 버전이 올바른지 확인해야 함.
블록 파일 구조
블록 파일 구조는 고정 크기 데이터 블록의 가변수가 뒤 따르는 파일 헤더이다. 블록 파일의 이름은 data_n으로 지정되며, n은 10진수 파일 번호
파일 헤더: 파일 요소를 효율적으로 생성 및 삭제할 수 있도록 매핑된 메모리
*파일에 더 많은 데이터를 저장할 수 있는 여유 블록이 충분하지 않을 때마다 최대 블록 수에 도달할 때 까지 파일이 1024블록씩 증가. 이 때, 동일한 유형의 새로운 블록 파일이 생성되고 헤더의 next_file 멤버를 사용하여 두 파일이 함꼐 연결됨. 블록 파일의 유형은 단순히 파일이 저장하는 블록의 크기.
디스크 공간 할당을 단순화하기 위해서 1~4개의 실제 블록을 사용하는 레코드만 저장가능. 만약 레코드의 전체 그기가 이보다 크면 다른 유형의 블록 파일을 사용해야 함.
캐시 항목
항목은 캐시에 저장된 완전한 엔터티로 크게 두 부분으로 나뉨.
RankingsNode: 자주 변경되고 축출 알고리즘을 구현하는 데 사용되는 부분을 저장. 항상 36바이트이며 전용 유형의 블록 파일에 저장됨
EntryStore: 항목을 완전히 식별하고 자주 변경되지 않는 부분을 저장. 키의 실제 크기에 따라 각각 257 바이트의 1개에서 4개의 블록을 사용 가능. 키가 너무 길어 EntryStore 구조의 일부로 직접 저장할 수 없는 경우 적절한 저장소가 할당되고 키 주소가 전테 키 대신 long_key 필드에 저장됨.
EntryStore에는 항목과 관련된 실제 데이터 스트림의 주소, 키의 해시 및 동일한 하위 해시 비트를 가진 다음 항목에 대한 포인터 역시 저장되어 있음(이들은 인덱스 테이블에서 동일한 위치를 공유)
항목이 사용 중일 때마다 RankingsNode는 사용 중으로 표시되므로 디스트에서 새 항목을 읽을 때 항목이 제대로 닫혔는지 여부를 알 수 있음.
웹 캐시: 클라이언트가 요청하는 html, image, js, css 등에 대해 첫 요청 시에 파일을 내려 받아 특정 위치에 복사본을 저장하고, 이 후 동일한 URL의 리소스 요청은 다시 내려 받지 않고 내부에 저장한 파일을 사용하여 더 빠르게 서비스 받기 위한 것. 서버를 통해 내려 받는 양이 적어지므로 응답 시간이 감소하고 네트워크 트래픽 양 역시 감소시킬 수 있다.
웹 캐시 종류
1. Browser Caches
-브라우저 또는 HTTP 요청을 하는 클라이언트 어플리케이션에 의해 내부 디스크에 저장된 캐시
-캐시된 리소스를 공유하지 않는 한 개인에 한정된 캐시
-브라우저의 백 버튼 또는 이미 방문한 페이지를 재 방문 하는 경우 효과 극대화
2. Proxy Caches
-브라우저 캐시와 동일한 원리로 동작. 클라이언트나 서버가 아닌 네트워크 상에서 동작.
-큰 회사나 ISP 방화벽에 설치 되며 대기 시간, 트래픽이 감소되고, 접근정책이나 제한적 우회, 사용률 기록등의 역할을 수행.
-한정된 수의 클라이언트를 위하여 무한대의 웹 서버의 컨텐츠를 캐시함.
3. Gateway Cache
-서버 앞 단에 설치되어 요청에 대한 캐시 및 효율적인 분배를 통해 가용성, 신뢰성, 성능 등을 향상.
캐시 컨트롤
1. HTML Meta Tags
-HTML 메타 태그를 페이지에삽입하는 방법. 지금은 더 이상 사용하지 않는 방법
2. HTTP Headers
-파일이 이전과 비교하여 변경 되었는가를 체크하는 validation과 캐시의 만료 여부를 체크하는 freshness로 구성.
-HTTP 1.1로 넘어 오면서 cache-control을 하나의 값이 아니라 ,(콤마)를 통해서 다양한 지시라를 이용하여 값을 전달 할 수있음.
캐시 동작
1. 첫요청
-브라우저가 서버에 index.html 파일을 요청
-서버는 index.html 파일을 찾아보고 존재하는 파일이라면 파일 내용을 브라우저에게 몇 가지 header 값과 함께 응답
-브라우저는 응답 받은 내용을 브라우저에 표시, 응답 헤더의 내용에 따라 캐쉬 정책을 수행.
(응답헤더에 Last-Modified, Etag, Expires, Cahce-Control:max-age 항목이 존재 한다면 복사본을 생성하고 값을 저장)
2. 재요청
1) Last-Modified
-브라우저는 최초 응답 시 받은 Last-Modified 값을 If-Modified-Since 라는 헤더에 포함 시켜 페이지를 요청
-서버는 요청 파일의 수정 시간을 if-Modified-Since 값과 비교하여 동일하다면 304 Not Modified로 응답하고 다르다면 200 OK와 함께 새로운 Last-Modified 값을 응답 헤더에 전송
-브라우저는 응답 코드가 304인 경우 캐시에서 페이지를 로드하고 200이면 새로 다운 받은 후 Last-Modified 값을 갱신
2) ETAG(Entity Tag)
-브라우저는 최초 응잡시 받은 Etag 값을 If-None-Match라는 헤더에 포함시켜 페이지를 요청
-서버는 요청 파일의 Etag 값을 If-None_Match 값과 비교하여 동일하다면 304 Not Modified로 응답하고 다르다면 200OK와 함께 새로운 Etag 값을 응답 헤더에 전송
-브라우저는 응답 코드가 304인 경우 캐시에서 페이지를 로드하고 200이라면 새로 다운 받은 후 Etag 값을 갱신
*Etag는 서버마다 생성하는 값이 다름. 1)과 2)는 validation을 체크
3) Expires
-브라우저는 최초 응답 시 받은 Expires 시간을 비교하여 기간 내라면 서버를 거치지 않고 바로 캐시에서 페이지를 로드. 만약 기간이 만료 되었다면 위에 설명한 validation 작업을 수행
4) Cache-Control
-브라우저는 최초 응답 시 받은 Cache-Control 중 max-age 값(초 단위)를 GMT와 비교항 기간 내라면 서버를 거치지 않고 캐시에서 페이지를 로드.만약 기간이 만료 되었다면 위에 설명한 validation 작업을 수행
* 3)과 4)는 freshness를 체크, 기간 내라면 서버와 통신하지 않고 캐시를 사용
캐시 설정
-캐시는 서버에서 설정. 파일 확장자 명으로 다르게 설정하거나 디렉토리 별로 다르게 설정하는 것도 가능. Expires와 Etag는 서버 설정에 의해 사용하지 않을 수도 있음. expires가 설정되면 Expires와 max-age가 같이 설정 됨.
*캐시가 잘 적용되기 위한 전략
- 일관된 URL을 사용하기. 동일한 URL은 동일한 사이트라면 다른 페이지에서도 캐시되어 사용하는 것이 가능
-자주 바뀌는 파일과 그렇지 않은 파일을 분리. 그래야 각 Resource에 대해 최적의 freshness를 설정할 수 있음
-다운가능한 파일의 내용이 바뀌면 이름(URL) 바꾸기. 이래야 수정된 버전을 제공할 수 있음
-SSL을 최소화하기 (암호화된 페이지는 캐시 되지 않음)
https://hahahoho5915.tistory.com/33
웹 캐시(WEB Cache)란 무엇인가?(특징)
개요 > 웹 캐시(WEB Cache)가 무엇(What)인가? > 웹 캐시(WEB Cache)를 사용하는 이유(Why)? 멋대로 요약 캐싱 기본 개념 : 캐싱(Caching)은 애플리케이션의 처리 속도를 높여준다. 이미 가져온 데이터나.
hahahoho5915.tistory.com
'프로젝트 > 연합 세미나' 카테고리의 다른 글
| MP4 영상 캐시 재조립(인스타 릴스) (0) | 2022.08.23 |
|---|---|
| [8차] 캐시 재조립 실습 (0) | 2022.08.23 |
| [6차] 캐시 재조립 실습 (0) | 2022.08.13 |
| [5차] 인코그니토 과제 (0) | 2022.08.08 |
| [논문요약] 「Reconstructing streamed video content」 요약 (0) | 2022.08.05 |
