[24일차] Proxy & CDN

프록시 서버

• 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다.
• 프록시(Proxy)란 '대리' 라는 의미를 갖고 있으며, 서버와 서버 사이의 중계 역할을 한다
• 보통 웹은 클라이언트에서 서버로, 서버에서 클라이언트로 통신하며 데이터를 전달한다. 이때 필연적으로 중복되는 데이터를 반복하여 전달하는 상황이 발생하는데, 이렇게 동일한 요청을 매번 처리하는 것은 곧 리소스 낭비 와 서버의 부하 로 이어지게 된다. 때문에 본 서버에 도달하기 전에 새로운 서버(proxy server)를 미리 배치하여 중복 요청에 대해 (연산이 필요없는) 동일한 응답을 할 수 있다면, 클라이언트에겐 빠른 속도의 서비스를, 서버에게는 불필요한 부하를 줄이는 효과를 낼 수 있게 된다.
• 프록시 서버는 네트워크 상 어디에 위치하느냐, 혹은 어느 방향으로 데이터를 제공하느냐에 따라 Forward Proxy 와 Reverse Proxy 로 나뉘게 된다.

프록시 서버

• 프록시 서버는 그림처럼 클라이언트 바로 뒤에 놓여 있다.
• 같은 내부망에 존재하는 클라이언트의 요청을 받아 인터넷을 통해 외부 서버에서 데이터를 가져와 클라이언트에게 응답해준다.​
• 즉, 클라이언트가 서버에 접근하고자 할때, 클라이언트는 타겟 서버의 주소를 포워드 프록시에 전달하여, 포워드 프록시가 인터넷으로 요청된 내용을 가져오는 방식이다.
• 예를 들어 우리가 naver.com 을 요청하면 포워드 프록시 서버가 naver.com 리소스를 대신 받아와 클라이언트에게 내밀어준다(forward)고 생각하면 된다.
• 우리가 흔히 말하는 ‘프록시 서버’란 바로 포워드 포록시 서버를 의미하는 것이다.

 

• 보안 (Security)

보통 정부, 학교, 기업 등과 같은 기관은 해당 기관에 속한 사람들의 제한적인 인터넷 사용을 위해 방화벽을 사용한다.

포워드 프록시 서버는 방화벽과 같은 개념으로 제한을 위해 사용 된다고 보면 된다.

즉, 해당 기관에 속한 사람들이 그들이 방문하고자 하는 웹사이트에 직접적으로(directly) 방문하는 것을 방지할 수 있다. 예를 들어, 포워드 프록시 서버에 룰을 추가해서 특정 사이트에 접속하는 것을 막을 수 있다.

 

 

• 캐싱 (Caching)

우리가 어떤 웹 페이지에 접근하면 프록시 서버는 해당 페이지 서버의 정보를 캐싱(임시보관)해둔다.

그래서 똑같이 해당 페이지에 접근하거나, 다른 클라이언트가 해당 페이지를 요청할 때 , 캐시된 정보(페이지)를 그대로 반환할 수 있고, 이는 서버의 부하를 줄이는 효과도 낼 수 있다.

 

위의 그림에서 만일 4명의 클라이언트가 naver.com에 접근할때 본래는 각각 따로 인터넷을 경유해서 네이버 페이지를 받겠지만, 포워드 프록시를 이용하면 프록시내 캐싱 된 네이버 페이지를 불러오기 때문에 훨씬 빠르게 조회할수 있는 원리이다.

 

• 암호화 (Encryption)

클라이언트의 요청은 포워드 프록시 서버를 통과할 때 암호화된다.

암호화된 요청은 다른 서버를 통과할 때 필요한 최소한의 정보만 갖게 되는데, 이는 클라이언트의 ip 를 (보안을 위해) 감춰주는 보안 효과를 내준다.

따라서 본 서버에서 IP 주소를 역추적해도 포워드 프록시 서버를 사용하면 정체를 파악하기 어렵게 된다.

왜냐면 IP 추적해도 포워드 프록시 서버 IP만 보이기 때문이다.

 

 

리버스 프록시

• 리버스 프록시는 그림 처럼 웹서버/WAS 앞에 놓여 있는 것을 말한다.
• 클라이언트는 웹서비스에 접근할때 웹서버에 요청하는 것이 아닌, 프록시로 요청하게 되고, 프록시가 배후(reverse)의 서버로부터 데이터를 가져오는 방식이다.
• 클라이언트쪽으로 데이터(response)를 밀어주는게 포워드라면, 그 반대편인 서버 쪽으로 데이터(request)를 밀어주는 것이 리버스 프록시 라고 보면 된다.

 

• 로드 밸런싱 (Load Balancing)

유명한 웹 사이트는 하루에도 수백만명이 방문한다.

그리고 그러한 대량의 트래픽을 하나의 싱글 서버로 감당해 내기란 어렵다.

하지만 리버스 프록시 서버를 여러개의 본 서버들 앞에 두면 특정 서버가 과부화 되지 않게 로드밸런싱이 가능하다.

 

 

• 서버 보안 (Security)

리버스 프록시를 사용하면 서버 측 보안에 좋다.

리버스 프록시를 사용하면 본래 서버의 IP 주소를 노출시키지 않을 수 있다. 따라서 해커들의 DDoS 공격과 같은 공격을 막는데 유용하다.

위의 그림 에서 보면, 클라이언트는 인터넷을 통해 리버스 프록시 서버 url에게 요청을 한다. 그리고 리버스 프록시는 본서버에게 요청을 경유해서 보내게 된다.

이렇게 되면 클라이언트는 본 서버의 url을 모른채 리버스 프록시 url을 통해 서비스를 이용하게 되고, 이는 즉 본서버의 정보를 숨기는 효과가 된다.

 

• 캐싱 (Caching)

만약 어떤 한국에 있는 유저가 미국에 웹서버를 두고 있는 사이트에 접속할때, 리버스 프록시 서버가 한국에 있다고 해보자.

그러면 한국에 있는 유저는 한국에 있는 리버스 프록시 서버와 통신해서 리버스 프록시 서버에 캐싱되어 있는 데이터를 사용할 경우에는 더 빠른 성능을 보여줄수 있다.

포워드 프록시의 캐싱과 비슷한 기능을 한다고 보면 된다. (정확히 프록시의 본래 기능)

 

• 암호화 (Encryption)

마지막으로 SSL 암호화에도 좋다.

본래 서버가 클라이언트들과 통신을 할때 SSL(or TSL)로 암호화, 복호화를 할 경우 비용이 많이 들게 된다.

그러나 리버스 프록시를 사용하면 들어오는 요청을 모두 복호화하고 나가는 응답을 암호화해주므로 클라이언트와 안전한 통신을 할수 있으며 본래 서버의 부담을 줄여줄 수 있다.

 

포워드 프록시 vs 리버스 프록시 차이점

• 프록시 서버 위치

Forward Proxy 서버는 클라이언트 앞에 놓여져 있는 반면,

Reverse Proxy 서버는 웹서버/WAS 앞에 놓여 있다는 차이점이 있다.

 

• 프록시 서버 통신 대상

Forward Proxy는 내부망에서 클라이언트와 Proxy 서버가 통신하여 인터넷을 통해 외부에서 데이터를 가져온다.

Reverse Proxy는 내부망에서 Proxy 서버와 내부망서버가 통신하여 인터넷을 통해 요청이 들어오면 Proxy 서버가 받아 응답해준다.

 

• 감춰지는 대상

Forward Proxy는 직접 서버 url로 요청을 보내지만, Reverse Proxy는 프록시 서버 url로만 접근이 가능하다.

이로서 Reverse Proxy는 본서버의 IP 정보를 숨길수 있는 효과를 얻게 된다.

Forward Proxy는 내부망에서 인터넷 상에 있는 서버에 요청할때 먼저 포워드 프록시 서버를 호출하고 프록시가 서버에게 요청을 보내게 되는데, 이로서 서버에게 클라이언트가 누구인지 감출수 있다.

즉, 서버 입장에서 응답받은 IP는 포워드 Forward Proxy의 IP이기 때문에 클라이언트가 누군지 알 수 없다.

 

로드 밸런서

로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 요청을 분산시켜 부하를 분산한다.

로드 밸런서에는 서비스를 위한 가상 IP를 하나 제공하고, 사용자는 각 서버의 개별 IP 주소가 아닌 동일한 가상 IP를 통해 각 서버로 접근한다. 이 외에도 로드 밸런서는 각 서버의 서비스 상태를 체크해 서비스가 가능한 서버로만 사용자의 요청을 분산하므로 서버에서 장애가 발생하더라도 기존 요청을 분산하여 다른 서버에서 서비스를 제공할 수 있다.

 

• L4 로드 밸런서

일반적인 로드 밸런서가 동작하는 방식이다. TCP, UDP 정보(특히 포트넘버)를 기반으로 로드 밸런싱을 수행한다. 이 때, 부하를 분산하는 기능 뿐만 아니라, TCP 계층에서의 최적화와 보안 기능을 함께 제공한한다. 그러나 최근 사용되는 로드 밸런서는 4계층과 7계층의 기능을 모두 지원하기 때문에 4계층 로드밸런싱만 제공하는 경우는 찾기 어렵다.

 

• L7 로드 밸런서

HTTP, FTP, SMTP와 같은 애플리케이션 프로토콜 정보를 기반으로 로드 밸런싱을 수행한다. 이 때 HTTP 헤더 정보나 URI와 같은 정보를 기반으로 프로토콜을 이해한 후 부하를 분산한다. 일반적으로 이런 장비를 ADC(Application Delivery Controller)라고 부르며 리버스 프록시 역할을 수행한다. 대부분의 L7 로드밸런서는 4계층에서 7계층까지 로드밸런싱 기능을 제공하며, 장애극복(Failover), 리다이렉션의 기능도 함께 수행한다.

 

CDN이란 무엇인가요?

콘텐츠 전송 네트워크(CDN)는 데이터 사용량이 많은 애플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크이이다. CDN은 콘텐츠 전송 네트워크 또는 콘텐츠 배포 네트워크를 의미할 수 있다. 사용자가 웹 사이트를 방문할 때 해당 웹 사이트 서버의 데이터는 사용자의 컴퓨터에 도달하기 위해 인터넷을 통해 이동해야 한다. 사용자가 해당 서버에서 멀리 떨어져 있는 경우 동영상 또는 웹 사이트 이미지와 같은 대용량 파일을 로드하는 데 시간이 오래 걸린다. CDN은 세계 곳곳에 분포하는 데이터 센터에 콘텐츠를 저장해 두고, 이후 콘텐츠 요청을 받으면 지리적으로 가장 가까운 데이터 센터에서 콘텐츠를 제공해 주는 방식이다

 

• CDN이 중요한 이유는 무엇인가요?

콘텐츠 전송 네트워크(CDN)의 주 목적은 대기 시간을 줄이거나 네트워크 설계로 인해 발생하는 통신 지연을 줄이는 것이다. CDN은 클라이언트와 웹 사이트 서버 간에 중간 서버를 두어 효율성을 높인다. 이러한 CDN 서버는 클라이언트-서버 통신의 일부를 관리한다. 웹 서버에 대한 웹 트래픽을 줄이고, 대역폭 소비를 줄이며, 애플리케이션의 사용자 환경을 개선한다.

 

CDN을 사용하면 어떤 이점이 있나요?

• 페이지 로드 시간 단축

페이지 로드 시간이 너무 느리면 웹 사이트 트래픽이 감소할 수 있습니다. CDN은 반송률을 줄이고 사용자가 사이트에서 보내는 시간을 늘릴 수 있다.

 

• 대역폭 비용 절감

들어오는 모든 웹 사이트 요청은 네트워크 대역폭을 사용하기 때문에 대역폭 비용이 상당히 높다. 캐싱 및 기타 최적화를 통해 CDN은 오리진 서버가 제공해야 하는 데이터의 양을 줄여 웹 사이트 소유자의 호스팅 비용을 절감할 수 있다.

 

• 콘텐츠 가용성 제고

한 번에 너무 많은 방문자가 방문하거나 네트워크 하드웨어 오류가 발생하면 웹 사이트가 중단될 수 있다. CDN 서비스는 더 많은 웹 트래픽을 처리하고 웹 서버의 로드를 줄일 수 있다. 또한 하나 이상의 CDN 서버가 오프라인으로 전환되면 다른 운영 서버가 해당 서버를 대체하여 서비스가 중단되지 않도록 할 수 있다.

 

• 웹 사이트 보안 강화

분산 서비스 거부(DDoS) 공격은 대량의 가짜 트래픽을 웹 사이트로 전송하여 애플리케이션이 작동 중지되도록 만들려고 시도한다. CDN은 여러 중간 서버 간에 로드를 분산하여 오리진 서버에 미치는 영향을 줄임으로써 이러한 트래픽 급증을 처리할 수 있다.

 

CDN을 통해 전송할 수 있는 인터넷 콘텐츠는 어떤 것들이 있나요?

콘텐츠 전송 네트워크(CDN)는 정적 콘텐츠와 동적 콘텐츠의 두 가지 유형의 콘텐츠를 전송할 수 있다.

 

• 정적 콘텐츠

정적 콘텐츠는 사용자 간에 변경되지 않는 웹 사이트 데이터이이다. 웹 사이트 헤더 이미지, 로고 및 글꼴 스타일은 모든 사용자에게 동일하게 유지되며 기업이 자주 변경하지 않는다. 정적 데이터는 수정, 처리 또는 생성할 필요가 없으며 CDN에 저장하는 데 이상적이 데이터다.

 

• 동적 콘텐츠

소셜 미디어 뉴스 피드, 날씨 보고서, 로그인 상태 및 채팅 메시지와 같은 동적 콘텐츠는 웹 사이트 사용자마다 다르다. 이 데이터는 사용자의 위치, 로그인 시간 또는 사용자 기본 설정에 따라 변경되며 웹 사이트는 모든 사용자와 모든 사용자 상호 작용에 대한 데이터를 생성해야 한다. 

 

• 동적 콘텐츠 지원 방법

CDN에 저장되어 있는 콘텐츠들은 내용이 바뀔 때마다 CDN 서버들에도 변경 내용이 전파되어야 한다. 그렇기 때문에 내용이 자주 바뀌는 동적 콘텐츠 자체는 CDN 네트워크가 지원하기 어렵다. 따라서 동적 콘텐츠 자체를 저장하기보다는 공통적인 HTML 파일 부분을 저장한다.

 

CDN은 어떻게 작동하나요?

콘텐츠 전송 네트워크(CDN)는 여러 지리적 위치에 접속 지점(POP) 또는 CDN 엣지 서버 그룹을 설정하는 방식으로 작동한다. 지리적으로 분산된 이 네트워크는 캐싱, 동적 가속 및 엣지 로직 계산의 원리를 기반으로 작동한다.

 

• 캐싱

캐싱은 더 빠른 데이터 액세스를 위해 동일한 데이터의 여러 복사본을 저장하는 프로세스로, 네트워크의 여러 서버에 정적 웹 사이트 콘텐츠를 저장하는 프로세스를 의미한다. CDN에서 캐싱은 다음과 같이 작동한다.

• 지리적으로 멀리 떨어진 웹 사이트 방문자는 사이트에서 정적 웹 콘텐츠를 처음 요청한다.
• 요청이 웹 애플리케이션 서버 또는 오리진 서버에 도달하고, 오리진 서버는 원격 방문자에게 응답을 보낸다. 또한 해당 방문자와 지리적으로 가장 가까운 CDN POP에 응답 복사본을 보낸다.
• CDN POP 서버는 복사본을 캐싱된 파일로 저장한다.
• 다음에 해당 방문자 또는 해당 위치에 있는 다른 방문자가 동일한 요청을 하면, 오리진 서버가 아닌 캐싱 서버가 응답을 보낸다.

 

• 동적 가속

동적 가속은 웹 애플리케이션과 클라이언트 사이의 중개 CDN 서버로 인해 발생하는 동적 웹 콘텐츠 요청에 대한 서버 응답 시간을 단축하는것이다. 사용자 요청이 있을 때마다 콘텐츠가 변경될 수 있기 때문에 동적 웹 콘텐츠에서는 캐싱이 제대로 작동하지 않는다. CDN 서버는 모든 동적 요청에 대해 오리진 서버와 다시 연결해야 하지만 자신과 오리진 서버 간의 연결을 최적화하여 프로세스를 가속화한다.

클라이언트가 인터넷을 통해 웹 서버로 직접 동적 요청을 보내는 경우 네트워크 지연 시간으로 인해 요청이 손실되거나 지연될 수 있다. 보안 검증을 위해 연결을 열고 닫는 데에도 시간이 걸릴 수 있다. 반면, 근처의 CDN 서버가 요청을 오리진 서버로 전달할 경우, 신뢰할 수 있는 지속적인 연결이 이미 설정되었을 것이다.

 

 

CDN은 무엇에 사용되나요?

• 고속 콘텐츠 전송

정적 및 동적 인터넷 콘텐츠 전송을 결합하여 CDN을 사용하여 고객에게 글로벌 고성능 전체 사이트 환경을 제공할 수 있다. 

 

• 실시간 스트리밍

CDN은 고품질의 풍부한 미디어 파일을 안정적이고 비용 효율적으로 제공할 수 있도록 지원한다. 비디오 및 오디오를 스트리밍하는 기업은 CDN을 사용하여 대역폭 비용 절감, 확장성 향상, 제공 시간 단축이라는 세 가지를 해결 할 수 있다.

 

• 다중 사용자 확장

CDN은 다수의 동시 사용자를 지원하는 데 도움이 된다. 웹 사이트 리소스는 한 번에 제한된 수의 클라이언트 연결만 관리할 수 있습니다. CDN은 애플리케이션 서버에서 로드 일부를 가져옴으로써 이 수를 빠르게 확장할 수 있다.

CDN이 서버를 분산하는 방식은 크게 Scattered 방식과 Consolidated 방식을 사용합니다. .

 

• Scattered 방식

Scattered 방식은 세계 곳곳에 비교적 낮은 성능의 데이터 센터를 구성하고 연결해 둠으로서, 최대한 빠른 응답속도를 목표로 하고 있다.

해당 방식은 관리해야 하는 데이터 센터의 수가 많기 때문에 데이터 센터 유지 비용 또한 높다.

따라서 사용 요금이 매우 높다.

 

 

• Consolidated 방식

기존의 Scattered 방식과 다르게 데이터 센터들을 통합하여 운용하는 방식으로, Scattered 방식에서 사용했던 낮은 성능 대신 고성능의 데이터 센터들을 운용해야 한다.

비록 응답시간이 증가하지만 데이터 센터의 수가 줄어듦으로 데이터 센터의 관리 및 유지 비용을 절감할 수 있다.

유지 관리 비용이 적어진다는 것은 사용자들에게 전가되는 요금이 줄어든다는 의미로 데이터 센터를 통합하면 사용자의 부담이 줄어든다.

해당 방식은 연결 수요가 많은 지역에 데이터 센터를 설립해야 적절한 방식이다.

 

캐시의 기본 원리 및 적용

클라이언트가 logo.jpg 이미지에 대한 요청을 보내고 서버가 해당 이미지에 대한 응답을 줄 때, HTTP 헤더가 0.1M, 바디가 1.0M로 총 1.1M로 가정해 보면 같은 이미지를 다시 요청하더라도 첫 번째처럼 똑같이 1.1M의 응답을 보낸다.

이 경우 logo.jpg 데이터가 변경되지 않아도 계속 데이터를 새로 다운받아야 한다.

 

브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있다.

이 경우 60초로 설정한다면 60초 동안은 해당 캐시가 유효하다는 의미이다.

 

만약 캐시의 유효시간이 초과한다면 다시 서버에 요청을 하고 60초간 유효한 logo.jpg 이미지를 응답을 받는다. 이때 다시 네트워크 다운로드가 발생하게 된다.

Last Modified는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함하여 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장된다.

if-midified-since를 통해서도 조건부 요청이 가능하다

서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정이 안되었을 경우 응답 메시지에 이를 담아서 알려준다.

이때 응답 데이터에 HTTP Body는 없으며 상태 코드는 304 Not Modified로 변경된 것이 없다는 뜻으로 전송한다. 전송 데이터에 바디가 빠졌기 때문에 헤더만 포함된 0.1M만 전송된다.

클라이언트에 해당 응답을 받은 뒤 캐시를 갱신해 주고 다시 일정 시간(60초) 동안 유효하게 된다

 

Last_modified와 if-Modified_since를 정리하면

캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304Not Modified + 헤더 메타데이터만 응답한다(바다x)

클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타데이터를 갱신하고 클라이언트는 캐시에 저장되어 있는 데이터 재활용한다. 결과적으로 네트워크 다운로가 발생하지만 용량이 적은 헤더만 다운로드 – 실용적인 해결책

 

• 단점

1초 미만(0.x초)단위로 캐시 조정이 불가능

날짜 기반 로직의 사용됨

데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우

서버에서 별도의 캐시 로직을 관리하고 싶은 경우

- 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

 

ETag와 If-None-Match 검증 헤더

ETag는 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다

-ex) ETag: v1.1, 61df5ee64dd7261~

데이터가 변경되면 이 이름을 바꾸어서 변경함(hash를 다시 생성)

- ETag: 61df5ee64dd7261~ -> 3ac587fa90f44dfc

단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식

 

만약 캐시 시간이 초과돼서 다시 요청을 해야 하는 경우라면 이때 ETag 값을 검증하는 If-None-Match를 요청 헤더에 작성해서 보낸다.

서버에서 데이터가 변경되지 않았을 경우 ETag는 동일하기에 그래서 If-None-Match는 거짓이 된다 이 경우 서버에서는 304 Not Modified를 응답하며 이때 역시 HTTP Body는 없고 브라우저 캐시에서는 응답 결과를 재사용하고 헤더 데이터를 갱신한다.

 

캐시 지시어(directives)

• Cache-Control: max-age

캐시 유효 시간, 초 단위

• Cache-Control: no-cache

데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용

• Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안됨

(메모리에서 사용하고 최대한 빨리 삭제)

• Cache-Control: must-revalidate

캐시 만료 후 최초 조회 시 원 서버에 검증해야함

원 서버 접근 실패 시 반드시 오루가 발생해야함 – 504(Gateway Timeout)

must-revalidate는 캐시 유효 시간이라면 캐시를 사용한다

 

• Expires

캐시 만료일 지정(하위 호환)

Cache-Control: max-age와 함께 사용하면 Expires는 무시

프록시 캐시서버를 통해 자료를 가져오면 이미 캐시에 등록되어 있어 원서버에 접근하는 것보다 빠른 속도로 자료를 가져올 수 있다.

이때 클라이언트에서 사용하고 저장하는 캐시를 private 캐시라 하며 프록시 캐시 서버의 캐시를 public 캐시라 한다.

 

• Cache-Control: public

응답이 public에 저장되어됨

• Cache-Control: private

데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용

응답이 private에 저장되어야함, 사용자만을 위한 캐시

 

캐시 무효화

클라이언트가 캐시를 적용하지 않아도 임의로 브라우저가 캐시를 적용하는 경우, 특정 페이지에서 캐시가 되면 안 되는 정보(e.g. 통장 잔고)가 있을 경우 사용한다.

만약 프록시 캐시 서버와 원 서버 간 네트워크 연결이 단절되어 접근이 불가능하다면, no-cache에서는 응답으로 오류가 아닌 오래된 데이터라도 보여주자라는 개념으로 200OK으로 응답을 한다.

하지만 must-revalidate라면 원 서버에 접근이 불가할 때 504 Gateway Timeout 오류를 보낸다

통장 잔고 등 중요한 정보가 원 서버를 못 받았다고 해서 예전 데이터로 뜬다면 큰 문제가 생기기 때문에 이런 경우 must-revalidate를 써야 한다