HTTP - (3) 캐시와 게이트웨이/터널

캐시는 흔히 듣는 단어이다.

자주 쓰이는 문서를 자동으로 보관하여, 캐시에 로컬 사본이 있으면 서버가 아닌 캐시로부터 제공한다.

캐시는 이처럼 네트워크 요금 비용을 줄여줄 뿐더러, 처리 속도를 개선해준다.

좀 더 자세히 캐시의 장점에 대해 살펴보자.

​

여러 클라이언트에서 동일한 문서에 접근할 때, 가장 첫 요청에 따른 응답이 캐시에 저장된다.

그 후에 요청하는 클라이언트들은 모두 캐시 서버로부터 데이터를 전달받게 된다.

이에 따라 네트워크의 대역폭 병목을 줄여줄 수도 있다. 먼 서버까지 접근하지 않아도 되기 때문이다.

갑작스럽게 이슈가 터져 서버로의 접근 트래픽이 과도하게 많아질 경우에도 서버 과부하를 줄여주는 역할을 한다.

또한 거리로 인한 처리 지연 문제도 캐시 서버를 클라이언트 가깝게 위치하도록 설계함으로써 줄일 수 있다.

​

캐시가 모든 문서를 저장하는 것이 아니다.

요청이 도착했을 때, 대응하는 사본을 캐시 서버에서 찾을 수 있다면 '적중(hit)'했다고 한다.

캐시 관리자는 캐시 적중률이 100%에 최대한 근접하도록 성능을 높여 설계한다.

​

캐시에 저장되어있는 문서가 서버에서 변경되지 않았는지, 즉 최신성을 띄고 있는지를 점검하기 위해 '신선도 검사'를 시행한다.

HTTP는 서버로부터 전체 문서를 다 가져오지 않더라도 캐시에 저장되어있는 문서가 신선한지를 체크할 수 있도록 기능을 제공한다.

캐시는 언제든지 원하면 스스로 재검사를 요청할 수 있다.

다만 캐시에 배정할 네트워크 대역폭은 적기 때문에 검사할정도로 문서가 오래된 경우에만 재검사 요청이 가능하다.

​

캐시는 서버로 Get요청에 If-Modified-Since헤더를 추가하여 문서가 변경되었을 경우에만 보내달라는 요청을 할 수 있다.

만약 캐시에 저장되어있는 문서가 신선하다면, 서버는 304 Not Modified 라는 요청을 보내어 캐시 서버에서 확인이 가능하도록 해준다.

캐시에 저장되어있는 문서와 서버에 저장되어있는 객체간의 차이가 발생했을 경우, 서버는 콘텐츠와 함께 HTTP 200 OK 응답을 보낸다.

만약 객체가 삭제되었을 경우 서버는 404 Not Found 응답을 보내게 되고, 캐시는 사본을 삭제한다.

​

적중률 뿐만 아니라 바이트 단위 적중률이라는 캐시 성능을 평가할 수 있는 지표도 있다.

모든 문서가 크기가 동일하지 않기 때문에, 큰 문서일 수록 적중률이 높을 때 더 좋은 점수를 주는 것이다.

바이트 단위 적중률의 개선은 대역폭 절약을 실천하는 방법 중 하나이다.

​

클라이언트는 데이터가 서버로부터 도착했는지, 캐시로부터 받았는지 알 수 없다.

모두 200OK 응답을 지니고 있기 때문인데, Date 헤더와 Age 헤더를 이용하여 유추할 수 있다.

응답의 생성일이 요청일자보다 더 과거일 경우 캐시로부터 도착했다는 것을 알 수 있다.

​

캐시는 개인 전용 캐시 뿐만 아니라 공용 캐시로도 있다.

개인 전용 캐시는 작고 저렴하고, 대부분 웹브라우저가 개인 전용 캐시 기능을 제공한다.

자주 쓰이는 문서를 PC의 디스크와 메모리에 캐시해둔다.

공용 캐시는 특정한 종류의 프락시 서버인데, 프락시 캐시는 인터셉트 프락시를 사용하여 HTTP 요청이 캐시를 통하도록 강제한다.

공용 캐시는 계층을 두어 (level-1 캐시, level-2 캐시 등) 하위 계층의 캐시 서버에 저장되어있지 않은, 더 큰 부모 캐시를 두기도 한다.

​

캐시 처리 단계는 아래와 같이 7단계로 구성되어 있다.

1. 클라이언트가 보낸 요청 메시지를 읽는다.

2. 메시지를 파싱하여 URL과 헤더들을 추출한다.

3. 로컬 사본이 있는지 확인하고, 없다면 서버로부터 받아와 저장한다.

4. 신선도 검사를 진행하여 서버에게 변경된 사항이 없는지 묻는다.

5. 새로운 헤더와 본문으로 응답 메시지를 생성한다.

6. 클라이언트에게 해당 응답 메시지를 전송한다.

7. 로그 파일에 트랜젝션에 대해 기록한다.

​

다음은 캐시의 신선도 관리를 위한 기능들을 설명할 것이다.

HTTP는 서버가 각 문서에 Cache-control(max age 등)과 Expires라는 특별한 헤더들을 저장할 수 있도록 해준다.

이 만료 기간이 다되면 캐시는 반드시 서버에 재검사 요청을 해야한다.

​

HTTP는 조건부 메서드를 통해 재검사를 효율적으로 할 수 있게 해준다.

If-Modified-Since와 If-None-Match 두 조건부 메서드가 재검사 관련인데,

전자는 주어진 날짜 이후로 수정되었다면 요청 메서드를 처리하는 것이고,

후자는 변경된 날짜를 맞춰지않고 문서에 대한 특별한 태그를 통해 그 태그를 서로 비교하는 것이다.

가장 흔하게 쓰이는 것은 전자이고, 줄여 IMS라고 부른다.

IMS를 사용할 수 없는 특수한 경우가 있다. 예를 들어 담고있는 컨텐츠는 동일한데, 일정 간격으로 다시 쓰여지는 문서들이다.

이러한 경우에는 If-None-Match를 사용하곤 한다.

위 두 가지를 캐시 검사기라고 부르는데, 서버에서는 변경 사항에 대해 강약을 첨가할 수 있다.

예를 들어 약한 검사기를 사용할 때는, 차이가 있더라도 '그 정도면 같다' 라고 판단할 수 있도록 해준다.

​

HTTP는 캐시를 제어할 수 있는 기능들을 제공하는데, 이에 대해 좀 더 알아보자.

Cache control에 no-store 혹은 no-cache, max-age 등과 같은 값을 지정할 수 있다.

No-store의 의미는 캐시가 응답의 사본을 만드는 것을 금지하는 것이다. 전달하고 나면 객체를 삭제하는 것이다.

No-cache는 서버와 재검사하지 않고선 절대 보낼 수 없는 것을 의미한다. 이름과 달리 실제 캐시 저장소에 저장한다.

Max-age는 문서가 서버로부터 온 이후 지난 시간이며, 초로 표기된다.

Expires는 실제 만료 날짜를 지정하게 된다. 하지만 서버들이 서로 동기화가 되어있지 않거나 잘못된 시계를 갖고 있어 잘 사용하지 않는다.

Must-revalidate는 만료를 엄격하게 따르도록 지정하는 것이고, 재검사 없이는 제공되어서는 안됨을 강요하고 있다.

서버로부터의 응답 중에 max age나 expires 헤더가 모두 없다면 캐시 서버는 휴리스틱하게 만료일자를 지정한다.

---

HTTP는 다른 프로토콜과 애플리케이션 간 통신을 할 수도 있어야하는데, 이번엔 그 방법에 대해 살펴볼 것이다.

우선 가장 처음으로 리소스와 애플리케이션 간 연결을 제공하는 '게이트웨이'이다.

HTTP 프로토콜을 다른 프로토콜로 변환하여, HTTP 클라이언트 쪽은 전혀 상관 쓰지 않도록 해준다.

만약 HTTP요청이 FTP URL을 담고 있다면, 게이트웨이는 FTP커넥션을 맺고 서버에 명령을 전송한다.

게이트웨이는 클라이언트/서버 쪽 프로토콜을 / 를 통해 구분한다.

​

게이트웨이는 여러 종류가 있다.

1) HTTP/* : 서버 측 웹 게이트웨이로서, HTTP요청을 왜리 프로토콜로 전환한다.

2) HTTP/HTTPS : 서버측 보안 게이트웨이, 웹 요처을 암호화하여 개인정보보호, 보안을 제공하는 기능을 한다.

3) HTTPS/HTTP : 클라이언트 측 보안 가속 게이트웨이, 웹 서버 앞단에 위치하여 HTTPS 트래픽을 복호화한다.

​

앞전까지 살펴본 경우는 네트워크에서 클라이언트와 서버를 연결하는 게이트웨이이다.

추가로 애플리케이션 게이트웨이가 있는데, 클라이언트와 서버측에 있는 어플리케이션 간 통신을 가능하게 한다.

게이트웨이에는 어플리케이션 프로그래밍 인터페이스(API)를 통해 요청을 서버로 보낸다.

​

애플리케이션 게이트웨이에서 가장 유명한 최초 API는 공용 게이트웨이 인터페이스(CGI)이다.

특정 URL에 대한 HTTP 요청에 따라 프로그램을 실행하고, 그 출력을 수집하여 HTTP 응답을 제공하는 웹 서버용 표준화 인터페이스이다.

웹에서 동적 HTML, 신용카드 처리, DB 쿼리 등에 사용된다.

단순한 원리로 거의 모든 HTTP 서버가 이를 지원하고, 다양한 언어로 구현할 수 있도록 해주었다.

​

터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용하여 통신할 수 있도록 해준다.

웹 터널은 게이트웨이와 클라이언트 사이에 놓여, HTTP CONNECT메서드를 통해 커넥션을 맺기를 요청한다.

웹 터널은 본래 방화벽을 통해 암호화된 SSL 트래픽을 전송하고자 개발된 것이었는데, 프락시를 통해 더 철저히 보안하는 추세이다.

앞전에 살펴본 프락시 인증 기능은 클라이언트가 터널을 사용할 수 있는 권한을 소지하고 있는지 검사하는 용도로 사용될 수 있다.

​

---

참고자료 :

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980