2월 12일 수요일: 7장(2) 스터디

[kwaksj329]

곽수정: link
유미라: link
윤태연: link
최선아: link

[ssum1ra]

어느 경우에 여러 개의 엔터티 태그를 If-None-Match 헤더에 포함할까?

[ssum1ra]

1. 캐시에 여러 버전이 존재할 수 있기 때문이다.

• 브라우저는 한 개의 최신 버전만 유지하는 것이 일반적이지만, 특정한 조건에서는 여러 버전을 캐싱할 수도 있다.

2. ETag 비교를 통한 캐시 검증 과정

예제 1: 단일 ETag 요청

GET /app.js HTTP/1.1
If-None-Match: "v2"

• 서버가 현재 버전이 ETag: "v2"라면 → 304 Not Modified 반환 (클라이언트는 기존 v2 사용)
• 서버가 현재 버전이 ETag: "v3"라면 → 새로운 app.js 다운로드
• 만약 최신 버전이 ETag: "v1"이라면? → 200 OK + app.js (v1) 다운로드

예제 2: 여러 개의 ETag 요청

GET /app.js HTTP/1.1
If-None-Match: "v1", "v2"

• 서버가 ETag: "v1" 또는 "v2"를 가지고 있다면 → 304 Not Modified 반환 (캐시된 버전 사용)
• 서버가 최신 버전으로 ETag: "v3"를 가지고 있다면 → 200 OK + app.js (v3) 다운로드

3. 예전 방식의 ETag와 새로운 방식의 ETag를 모두 확인할 수 있다.

GET /page.html HTTP/1.1
If-None-Match: "old-v1", "new-v2"

[ssum1ra]

한 리소스에 대해 Strong ETag와 Weak ETag는 혼용해서 사용될 수 있는가?

[rhino-ty]

Note

Strong ETag와 Weak ETag는 동일한 리소스에 대해 혼용해서 사용하지 않는 것이 best practice

// Express.js 예시
const express = require('express');
const app = express();

// 1. Strong ETag가 적합한 경우: 정적 이미지 파일
app.get('/images/:id', (req, res) => {
    const image = getImage(req.params.id);
    // 이미지의 해시값으로 Strong ETag 생성
    const strongETag = `"${calculateHash(image)}"`;
    res.setHeader('ETag', strongETag);
    res.send(image);
});

// 2. Weak ETag가 적합한 경우: 사용자 프로필 데이터
app.get('/users/:id/profile', (req, res) => {
    const profile = getUserProfile(req.params.id);
    // 데이터의 마지막 수정 시간과 주요 필드로 Weak ETag 생성
    const weakETag = `W/"${profile.lastModified}-${profile.version}"`;
    res.setHeader('ETag', weakETag);
    res.json(profile);
});

혼용하면 아래와 같은 문제가 발생함.

1. 일관성 문제

• 동일 리소스에 대해 두 가지 다른 검증 방식을 사용하면 캐시 로직이 복잡해짐
• 클라이언트/서버 간 어떤 ETag를 우선할지 모호해질 수 있음

2. 의도 충돌

• Strong ETag : 바이트 단위 정확한 일치를 의도
• Weak ETag : 의미적 동등성을 의도
• 이 두 가지 다른 의도를 혼용하면 리소스 캐싱 정책이 불명확해짐

3. HTTP 스펙 권장사항

• HTTP/1.1 스펙에서는 한 리소스에 대해 하나의 ETag 방식을 일관되게 사용할 것을 권장함
• ETag를 변경할 때는 기존 캐시를 모두 무효화하고 새로운 정책을 적용하는 것이 안전함

문제 예시

1. 조건부 요청 처리 혼란

   // 클라이언트가 가진 ETag들
   If-None-Match: "123abc"         // Strong ETag
   If-None-Match: W/"123abc"       // Weak ETag
   
   // 서버가 두 가지 ETag를 모두 보내는 경우
   ETag: "123abc"
   ETag: W/"123abc"

   • 서버는 어떤 ETag로 비교해야 할지 모호해짐
   • HTTP 스펙상 이런 경우의 정확한 동작이 정의되어있지 않음

2. 캐시 로직 충돌

   // 서버 구현 예시 - 잘못된 방식
   app.get('/resource', (req, res) => {
     const resource = getResource();
     
     // 동일 응답에 두 종류의 ETag 설정 시도
     res.setHeader('ETag', `"${calculateHash(resource)}"`);        // Strong
     res.setHeader('ETag', `W/"${resource.version}"`);            // Weak
     
     // 어떤 ETag로 비교해야 할지 불분명
     if (req.headers['if-none-match']) {
       // 어떤 비교 로직을 사용해야 하나?
       // Strong 비교? Weak 비교?
     }
   });

3. 성능 저하

   • Strong ETag는 정확한 바이트 비교를 하므로 더 많은 리소스 소모
   • Weak ETag는 느슨한 비교를 하므로 더 효율적
   • 두 가지를 혼용하면 불필요한 검사가 중복될 수 있음

4. 일관성 문제

   // 첫 번째 요청
   GET /resource
   Response: ETag: "123abc"
   
   // 두 번째 요청
   GET /resource
   Response: ETag: W/"123abc"
   
   // 클라이언트는 같은 리소스인지 다른 리소스인지 판단하기 어려움

따라서 리소스의 특성에 맞춰 Strong ETag나 Weak ETag 중 하나를 선택해 일관되게 사용하는 것이 바람직함.

[rhino-ty]

현대의 웹 개발에서 브라우저 내 HTTP 캐시 처리는 어떻게 적용되고 있는 건가요? 개발자가 직접 적용해야하나요?

[rhino-ty]

Note

브라우저의 HTTP 캐시는 환경에 따라 기본적으로 자동으로 동작

팀 프로젝트에 캐싱을 적용하진 않았지만, 네트워크 탭의 Size 부분을 보면 자동으로 되고 있는 모습을 관찰할 수 있음.

하지만, 개발자가 헤더를 통해 세부적인 동작을 제어할 수도 있음.

Cache-Control 헤더

// 서버 응답에서 설정
response.setHeader('Cache-Control', 'max-age=3600'); // 1시간 캐시

// 주요 옵션들
Cache-Control: no-store  // 캐시 사용 안함
Cache-Control: no-cache  // 매번 재검증 필요
Cache-Control: private   // 브라우저만 캐시
Cache-Control: public    // 중간 캐시 서버도 캐시 가능

ETag 활용

// 서버에서 리소스의 버전 식별자 제공
response.setHeader('ETag', '"123abc"');

// 브라우저는 후속 요청 시 자동으로 If-None-Match 사용
// If-None-Match: "123abc"

그 외에도 NginX같은 정적 리소스 배포 서버나 API를 캐싱하기 위해 Express.js같은 애플리케이션 서버에도 적용 할 수 있다.

[choiseona]

캐시 3단계 '검색' 단계

고급 캐시는 빠른 알고리즘을 사용하여 로컬 캐시에서 객체를 찾고, 없으면 원 서버나 부모 프락시에서 가져오거나 실패를 반환함

에서 고급 캐시는 어떤 빠른 알고리즘을 사용하는건가요?

[choiseona]

🔥 고급 캐시에서 빠른 검색을 위한 알고리즘

1. 해시 테이블 (Hash Table)

• 키-값 매핑을 통해 데이터를 빠르게 찾을 수 있는 자료구조.
• 평균적으로 O(1) 시간 복잡도로 검색 가능하지만, 해시 충돌이 발생하면 O(n) 까지 느려질 수 있음.
• Redis, Memcached 같은 인메모리 캐시 시스템에서 사용됨.

2. B-트리 (B-Tree) / B+-트리

• 균형 탐색 트리의 일종으로, 디스크 I/O를 최소화하도록 설계됨.
• 범위 검색과 정렬된 데이터 검색이 효율적이며, O(log N) 시간 복잡도를 가짐.
• B+-트리는 B-트리의 변형으로, 리프 노드에만 실제 데이터를 저장하여 범위 검색을 더 빠르게 수행할 수 있음.
• MySQL InnoDB, RocksDB 등에서 인덱스 구조로 사용됨.

3. LSM-트리 (Log-Structured Merge Tree)

• 쓰기 성능을 최적화한 트리 구조.
• 데이터가 바로 디스크에 저장되지 않고, 메모리 내 정렬된 구조(SSTable) 에 저장된 후 주기적으로 디스크에 머지됨.
• WAL(Write-Ahead Log) 를 사용하여 장애 발생 시 데이터 복구 가능.
• LevelDB, RocksDB, Apache Cassandra 같은 NoSQL 및 데이터베이스에서 쓰기 중심 캐시로 사용됨.

4. Bloom Filter

• 특정 값이 존재하는지 여부만 빠르게 판별하는 확률적 자료구조.
• 거짓 긍정(false positive, 존재하지 않는 데이터를 "있다"고 잘못 판단하는 일) 가능성이 있으며, 거짓 부정(false negative, 있는 데이터를 "없다"라고 잘못 판단하는 일)은 없음.
• O(1) 시간 복잡도로 빠른 검사가 가능하며, 메모리 사용량이 적음.
• CDN 캐시, 웹 프록시, 대규모 데이터베이스의 쿼리 필터링 등에 활용됨.

5. 퍼펙트 해싱 (Perfect Hashing)

• 해시 충돌이 발생하지 않는 완벽한 해싱 함수를 사용하는 기법.
• 정적으로 구성된 데이터셋에서 사용되며, O(1) 검색을 보장.
• GPU 캐싱, 네트워크 라우터의 패킷 라우팅 테이블, 데이터베이스 읽기 전용 인덱스 등에 활용됨.

6. Counting Bloom Filter & Cuckoo Hashing

• Counting Bloom Filter: 기존 Bloom Filter의 확장판으로, 데이터 삭제가 가능함.
• Cuckoo Hashing: 한 개의 키가 여러 개의 해시 슬롯을 가질 수 있도록 하여 해시 충돌을 최소화하는 방법.
• 데이터베이스 쿼리 캐싱, DNS 캐싱, CDN 트래픽 관리에서 사용됨.

[kwaksj329]

고성능 캐시는 종종 로컬 저장장치와 네트워크 I/O 버퍼 사이에서 문서의 콘텐츠 복사를 피해 데이터를 효과적으로 전송하기 위해 노력함

저장장치와 버퍼 사이에서 어떻게 콘텐츠 복사를 피하고, 어떤 효과가 있다는 것일까요?

[kwaksj329]

동작 과정

비효율적인 방식:
디스크 → 커널버퍼 → 애플리케이션버퍼 → 네트워크버퍼 → 네트워크
(3번의 복사 발생)

효율적인 방식:
디스크 → 네트워크버퍼 → 네트워크
(1번의 복사로 끝)

그렇다면 커널 버퍼나 애플리케이션 버퍼는 왜 필요할까?

1. 커널 버퍼가 필요한 이유

• 커널 버퍼: OS 레벨에서 I/O 작업을 위해 사용
• 하드웨어와 직접 통신하는 것은 커널만 가능
• 시스템 보안을 위해 사용자 프로그램은 하드웨어에 직접 접근 불가
• 디스크나 네트워크 같은 느린 장치와의 속도 차이를 완충

3. 애플리케이션 버퍼가 필요한 이유

• 애플리케이션 버퍼: 프록시 프로그램이 데이터를 처리하기 위해 사용
• 프로그램이 데이터를 처리하고 가공하기 위해 필요
• 데이터 유효성 검사나 변환 작업 수행
• 사용자 레벨에서의 캐싱과 최적화

5. 단, 단순히 파일을 네트워크로 전송하는 것과 같이 데이터를 수정하지 않고 전달만 하는 경우에는 ...

• sendfile() 같은 시스템 콜을 사용해
• 애플리케이션 버퍼를 거치지 않고
• 커널 버퍼에서 네트워크로 직접 전송이 가능하다.

따라서 상황에 따라 불필요한 과정을 생략해 성능을 개선할 수 있다.