[네트워크] 웹 캐시와 HTTP framing

Web Cache

1. Web Cache (웹 캐시)

1.1 정의

Web Cache는 클라이언트의 요청을 원 서버(origin server)로 보내지 않고도 응답할 수 있도록 하는 중간 서버이다.

일반적으로 Proxy Server(프록시 서버) 라고도 불리며, 대신 요청을 처리해주는 대리인(Agent) 역할을 한다.

1.2 동작 원리

1. 사용자는 브라우저 설정을 통해 Web Cache를 사용하도록 구성한다.
2. 브라우저는 모든 HTTP 요청을 Web Cache로 보낸다.
3. Web Cache의 처리:
   • 요청한 객체가 캐시에 있다면, Web Cache는 그 객체를 클라이언트에 직접 전달한다.
   • 캐시에 없다면, Web Cache는 원 서버에 요청을 보내고, 응답 받은 객체를 자신의 캐시에 저장한 후, 클라이언트에 전달한다.

---

2. Web Cache의 프로토콜 관점 역할

Web Cache는 클라이언트 입장에서는 서버이고,

서버 입장에서는 클라이언트로 동작한다.

즉, 클라이언트-서버 아키텍처를 유지하면서도 중간 캐시 역할을 수행한다.

---

3. Web Cache의 설치 위치

Web Cache는 일반적으로 ISP(Internet Service Provider) 또는 조직(학교, 회사 등)의 로컬 네트워크 내에 설치된다.

• 예시: 건국대학교의 네트워크는 자체적으로 로컬 ISP이며, 그 위에는 KT, SKT 등 글로벌 ISP가 있다.
• 학교/기관은 글로벌 ISP로부터 대역폭(bandwidth)을 구매하여 인터넷에 연결된다.
• 이때, 트래픽 절감을 위해 로컬 네트워크 내부에 Web Cache를 설치할 수 있다.

---

4. Web Cache 설치 이유

경제적 이유

• ISP는 클라이언트의 성능 향상보다 트래픽 절감을 더 중요하게 생각한다.
• Web Cache는 기관의 외부 접속 링크(access link)에 발생하는 트래픽을 줄일 수 있다.

성능적 이유

• 클라이언트와 가까운 곳에 캐시가 있으므로 응답 시간이 단축된다.
• 콘텐츠 제공 능력이 떨어지는 서버(poor content provider)도 캐시 덕분에 콘텐츠를 효율적으로 전달할 수 있다.

---

5. Web Cache 성능 분석

시나리오

• Access Link 속도: 1.54 Mbps
• RTT(Round Trip Time): 2초
• 웹 객체 크기: 100 Kbits
• 요청률: 15 requests/sec
• 평균 브라우저로의 데이터 전송 속도: 1.50 Mbps

LAN Utilization (내부망)

• LAN 속도: 1 Gbps
• Utilization = (1.5 Mbps / 1 Gbps) ≈ 0.0015 (매우 낮음)

Access Link Utilization

• 평균 1.50 Mbps 사용 → Utilization = 1.5 / 1.54 ≈ 0.97 (매우 높음 → 병목 발생)

End-to-End Delay

• 인터넷 지연: 2초
• Access Link 지연: 매우 높음 (수 분 이상 대기)
• LAN 지연: 마이크로초 수준 (무시 가능)
• 총 지연 시간: 2초 + 수 분 + μs → 성능 매우 낮음

---

6. 해결책: 대역폭 업그레이드 vs Web Cache 설치

1) Access Link 업그레이드

• 속도: 1.54 Mbps → 154 Mbps
• 장점: 지연 시간 줄어듦
• 단점: 비용 증가 (예: 월 10만 원 → 100만 원)

 

2) Web Cache 설치

• Cache Hit Rate: 40% 가정
• 전체 요청 중 60%만 Access Link 사용 → 평균 전송률 = 0.6 × 1.5 Mbps = 0.9 Mbps
• Utilization = 0.9 / 1.54 ≈ 0.58 (절반 수준)
• 지연 시간:
  • 60%: 원 서버에서 2.01초 지연
  • 40%: 로컬 캐시에서 msec 수준
  • 평균 ≈ 1.2초
• 비용은 저렴하고 성능 향상 큼

---

7. Conditional GET

Conditional GET은 클라이언트가 이미 가지고 있는 객체가 최신인지 서버에 확인하고, 최신이라면 객체를 다시 전송받지 않는 방식이다. 이는 불필요한 데이터 전송을 줄이고, 링크 이용률을 낮추며, 응답 시간을 단축한다.

클라이언트는 HTTP 요청 메시지에 If-Modified-Since 헤더를 추가하여 자신의 캐시 버전의 날짜를 서버에 알려준다.

 

예시 요청

예시 요청: GET /image.png HTTP/1.1

Host: example.com

If-Modified-Since: Wed, 02 Apr 2025 02:01:05 GMT

 

서버는 클라이언트가 가지고 있는 객체가 최신이면 다음과 같이 응답한다: HTTP/1.0 304 Not Modified

이때 객체 본문은 포함되지 않는다. 반대로 객체가 변경된 경우에는 새로운 객체와 함께 200 OK 응답을 보낸다.

이를 통해 객체 전송 지연이 발생하지 않고, 전체 네트워크 리소스를 절약할 수 있다.

Conditional GET은 HTTP/1.0에 도입되었으며, Web Cache와 함께 사용할 때 매우 효과적이다.

---

8. HTTP/2

HTTP/1.1의 HOL 블락 문제

HTTP/1.1은 파이프라이닝(pipelining)을 도입해 하나의 TCP 연결에서 여러 개의 GET 요청을 순차적으로 보낼 수 있도록 했다. 그러나 서버는 여전히 FCFS(First-Come, First-Served) 방식으로 응답하므로, 작은 객체가 큰 객체 뒤에서 대기하게 되는 HOL(Head-of-Line) blocking 문제가 발생했다.

또한 TCP 손실 복구 과정에서 하나의 세그먼트 손실이 전체 객체 전송을 지연시키는 문제가 있었다.

HTTP/2(RFC 7540, 2015)는 이러한 지연을 줄이기 위해 다음과 같은 기능을 도입했다:

 

• 기존의 메소드, 상태 코드, 헤더 필드는 HTTP/1.1과 동일하게 유지 (Backward Compatibility)
• 클라이언트가 요청 객체에 우선순위를 지정할 수 있고, 서버는 그에 따라 객체 전송 순서를 조정
• 서버는 클라이언트가 요청하지 않은 객체도 미리 푸시할 수 있음 (Server Push)
• 모든 객체를 프레임(frame)으로 나누고, 이 프레임들을 인터리브(interleave) 방식으로 전송하여 HOL blocking을 완화함

프레이밍(framing)은 큰 객체를 작은 프레임으로 나누어 전송하는 기법으로, 다양한 객체를 동시에 조금씩 나누어 보낼 수 있도록 한다. 예를 들어, O1(큰 파일), O2, O3, O4(작은 파일들)이 있을 때, 프레임 단위로 분리하여 O1-1, O2-1, O3-1, O4-1, O1-2... 이런 식으로 전송하면 작은 객체들을 빠르게 처리할 수 있다.

이 방식은 라운드로빈 스케줄링처럼 공정하고 효율적인 전송 방식을 제공하며, 전체 응답 시간 단축에 크게 기여한다.

---

9. HTTP/3와 QUIC

HTTP/2는 여전히 TCP를 기반으로 하기 때문에, 패킷 손실 시 전송이 지연되며, 병렬 연결 성능에 한계가 있었다.

HTTP/3는 이를 극복하기 위해 QUIC(Quick UDP Internet Connections) 프로토콜을 기반으로 설계되었다. 이는 UDP 위에 신뢰성과 혼잡 제어, 보안을 포함시킨 새로운 프로토콜이다.

HTTP/3의 주요 특징:

• TCP 대신 UDP 사용 → 연결 설정 시간 단축, 빠른 전송 가능
• 손실 복구와 혼잡 제어 기능을 HTTP 자체가 담당
• 보안을 기본적으로 포함 (TLS 내장)
• 빠른 다중 객체 전송 지원

HTTP/3는 다중 객체를 효율적으로 전송하면서도 TCP의 연결 설정, 손실 처리 지연을 없앴으며, 크롬 등 주요 브라우저에서 채택되고 있다.

---

마무리

• HTTP는 TCP 기반의 무상태 프로토콜이며, 쿠키를 통해 상태 유지를 보완한다.
• Web Cache는 성능 향상과 트래픽 절감을 위해 중요하며, Conditional GET과 함께 효율적으로 동작한다.
• HTTP/2는 프레임과 인터리빙 전송으로 HOL blocking을 해결했고, HTTP/3는 UDP 기반의 QUIC을 통해 빠르고 안전한 전송을 지원한다.