HTTP 완벽 가이드(2)

HTTP 완벽 가이드의 2. HTTP 아키텍처를 읽고 정리한 내용입니다.

7장: 캐시

웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치다. 웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면, 그 문서는 원 서버가 아니라 그 캐시로부터 제공된다. 캐시는 다음과 같은 혜택을 준다

• 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다
• 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 해준다
• 원 서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다
• 페이지를 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다

적중과 부적중

캐시에 요청이 도착했을 때, 만약 대응하는 사본이 있다면 이를 사용해 요청이 처리된다. 이를 캐시 적중(cache hit)이라고 부른다. 대응하는 사본이 없다면 원 서버로 요청이 전달된다. 이를 캐시 부적중(cache miss)라고 부른다.

재검사(revalidation)

사본이 최신인지 서버를 통해 점검해야 하는데 이러한 신선도 검사를 HTTP 재검사라고 부른다. 캐시는 원한다면 스스로 사본을 재검사 할 수 있다. 대부분의 캐시는 클라이언트가 사본을 요청하였으며 그 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 한다.

콘텐츠가 변경되지 않았다면, 서버는 304 Not Modified 응답을 보낸다. 캐시는 사본이 신선하다고 임시로 다시 표시한 뒤 그 사본을 클라이언트에 제공한다. 이를 재검사 적중 혹은 느린 정중이라고 부른다. 이는 원 서버와 검사가 필요하기 때문에 순수 캐시 적중보다는 느리고, 서버로부터 객체 데이터를 받아올 필요가 없기 때문에 캐시 부적중보다는 빠르다.

HTTP는 캐시된 객체를 재확인하기 위해 If-Modified-Since 헤더를 자주 사용한다. 이는 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미이다.

• 재검사 부적중: 서버 객체가 캐시된 사본과 다르다면, 서버는 컨텐츠 전체와 함께 HTTP 200 OK 응답을 클라이언트에게 보낸다.
• 객체 삭제: 만약 서버 객체가 삭제되었다면, 서버는 404 Not Found 응답을 돌려보내며, 캐시는 사본을 삭제한다.

적중률

캐시가 요청을 처리하는 비율을 캐시 적중률 또는 문서 적중률이라고 부른다. 적중률 40%면 웹 캐시로 괜찮은 편이다.

바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 표현한다.

문서 적중률을 개선하면 전체 대기 시간이 줄어들고, 바이트 단위 적중률의 개선은 대역폭 절약을 최적화한다.

클라이언트가 응답이 캐시에서 왔는지 알아내는 방법은 Date 헤더를 이용하는 것이다. 응답의 생성일이 현재 시각보다 오래되었다면 클라이언트는 응답이 캐시된 것임을 알 수 있다. 다른 방법은 응답이 얼마나 오래되었는지를 말해주는 Age 헤더를 사용하는 것이다.

캐시 토폴로지

한 명에게만 할당된 캐시를 개인 전용 캐시(private cache), 공유된 캐시를 공용 캐시(public cache)라고 부른다. 웹 브라우저는 개인 전용 캐시를 내장하고 있다. 공용 캐시는 프락시 캐시로, 로컬 캐시에서 문서를 제공하거나, 사용자 입장에서 서버에 접근한다. 공용 캐시는 불필요한 트래픽을 줄일 수 있는 기회가 많다.

캐시 처리 단계

1. 요청 받기
2. 파싱: 메시지를 파싱하여 URL과 헤더를 추출한다
3. 검색: 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아와 로컬에 저장한다
4. 신선도 검사: 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사항이 있는지 서버에게 물어본다
5. 응답 생성: 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다
6. 발송: 네트워크를 통해 응답을 클라이언트에게 돌려준다
7. 로깅: 선택적으로 캐시는 트랜잭션에 대해 서술한 로그를 남긴다

사본을 신선하게 유지하기

HTTP는 Cache-Control과 Expries라는 특별한 헤더들을 이용해 원 서버가 각 문서에 유효기간을 붙일 수 있게 해준다.

캐시는 필요하다면 서버와의 접촉 없이 사본을 제공할 수 있다. 캐시 문서가 만료되면, 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야 하며, 만약 변경이 있다면 신선한 사본을 새 유효기간과 함께 얻어 와야 한다.

캐시된 문서가 만료되었다는 것은, 그 문서가 원 서버에 존재하는 것과 실제로 다르다는 것을 의미하지는 않으며, 이제 검사할 시간이 되었음을 뜻한다. 캐시는 문서의 신선도를 매 요청마다 검증할 필요 없이 문서가 만료되었을 때 한 번만 서버와 재검사하면 된다.

조건부 메서드와 재검사

조건부 메서드는 재검사를 효율적으로 만들어준다. If-Modified-Since와 If-None-Match가 있다.

• If-Modified-Since: <date> : 만약 문서가 주어진 날짜 이후로 수정되었다면 요청 메서드를 처리한다.만약 변경되지 않았다면 304 Not Modified 응답 메시지를 클라이언트에게 돌려준다.
• If-None-Match: <tags> : 캐시된 태그가 서버에 있는 문서의 태그와 다를 때만 요청을 처리한다.

캐시 제어(Cache-Control)

HTTP 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 있는 방법.

• no-store: 캐시가 그 응답의 사본을 만드는 것을 금지한다.
• no-cache: 로컬 캐시 저장소에 저장된다. 다만 먼저 서버와 재검사를 하지 않고서는 캐시에서 클라이언트로 제공될 수 없다.
• max-age: 신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간을 명시한다. s-maxage는 공용 캐시에만 적용 가능하다
• expires: 실제 만료 날짜를 명시한다.
• must-revalidate: 캐시가 만료 정보를 엄격하게 따르길 원할 때. 캐시가 이 객체의 신선하지 않은 사본을 원 서버와의 최초의 검사 없이는 제공해서는 안됨을 의미한다. must-revalidate로 신선도 검사를 했을 때 원 서버를 사용할 수 없다면 504 Gateway Timeout error를 반환한다.

휴리스틱 만료

만약 응답이 Cache-Control: max-age헤더나 Expires 헤더 중 어느 것도 포함하지 않고 있다면, 캐시는 경험적인 방법으로(heuristic) max age를 계산한다.

8장: 통합점: 게이트웨이, 터널, 릴레이

게이트웨이

게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.게이트웨이는 요청을 받고 응답을 보내는 포털같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.

웹 게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 / 으로 구별하여 기술한다.

프로토콜 게이트웨이

• HTTP/*: 서버 측 웹 게이트웨이. 게이트웨이는 응답을 HTTP 응답에 실어서 클라이언트에 전송한다
• HTTP/HTTPS: 서버 측 보안 게이트웨이. 기업 내부의 요청을 암호화하여 개인 정보와 보안을 제공. 사용자의 모든 세션을 암호화함
• HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이. 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.

리소스 게이트웨이

게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.애플리케이션 게이트웨이에서 유명했던 최초의 API는 공용 게이트웨이 인터페이스(CGI)였다. CGI가 내부에서 어떤 처리를 하는지는 사용자에게 보이지 않는다.

터널

웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다. HTTP 커넥션 안에 HTTP가 아닌 트래픽을 얹어, 웹 트래픽만을 허락하는 방화벽이 있더라도 HTTP가 아닌 트래픽을 전송할 수 있다.

SSL 터널링

웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다. 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP만을 허용하는 방화벽을 통과시킬 수 있다.