[Spring] RFC 7232 - Conditional Requests로 비용 및 부하 최적화 하기

개요

RFC 7232 - Conditional Requests는 브라우저가 불필요한 서버 요청을 최소화하고, 네트워크 트래픽과 서버 자원을 절약할 수 있도록 도와주는 인터넷 표준 정의 문서를 말합니다.

 

이 기능을 잘 사용한다면 AWS와 같은 클라우드 환경에서 비용 최적화 및 대용량 트래픽에서의 트래픽 개선도 가능합니다.

기능 소개

• If-Modified-Since의 시간 기준으로 업데이트된 것만 조회 가능​ ​
• ETag와 Last-Modified 기준으로 기존에 받았던 정책 값을 캐시 해서 사용 가능​ ​
• 브라우저의 캐시 자동 처리로 인해 서버에 불필요한 요청 제어

일단 위의 기능들은 굳이 규약을 안 지켜도 만들 수 있으나 규약을 지켜서 만든다면 좀 더 효율적인 코드 개발이 가능해지겠습니다.

바로 활용 예시를 몇개 확인해 보겠습니다.

활용 예시

If-Modified-Since의 시간 기준으로 업데이트된 것만 조회 가능

예를 들어 시간 값을 보내서 특정 리스트 안에 특정 값만 업데이트된 것만 추출해서 사용할 수 있습니다.

근데 느껴지시겠지만 이건 굳이 Header가 아니어도 구현이 가능합니다.

아래부터 이제 특별한 사용 사례를 확인할 수 있습니다.

ETag와 Last-Modified 기준으로 기존에 받았던 값을 캐시 해서 사용 가능

위의 활용 예시는 ETag를 활용합니다.

ETag에 응답 값에 대한 HashCode를 추출해서 사용자에게 넘겨줍니다.

그래서 첫 번째 요청은 단순히 200 OK로 정상 응답으로 끝나지만 두 번째 요청부터는 클라이언트는 ETag 값을 다시 Header에 Last-Modified 값으로 보낸다면 서버는 이를 확인해 304 Not Modified를 리턴합니다.

그럼 브라우저에서는 304 Not Modifed를 확인하고 이전에 받았던 응답값을 그대로 활용할 수 있습니다.

즉, 서버는 Response로 응답 값을 제공해주지 않아도 된다는 점이 중요합니다.

 

굳이 캐시 기능을 구현하지 않아도 되는 것이겠죠.

브라우저의 캐시 자동 처리로 인해 서버에 불필요한 요청 제어​​

이 부분도 마찬가지입니다.

서버에서는 Cache에 대한 시간을 설정을 해주고 사용자는 해당 캐싱 시간 동안 똑같은 API 요청을 한다면 disk에 저장된 캐시를 사용하게 됩니다.

즉, API 요청을 하더라도 아예 서버에 전달이 되지 않습니다.

그러니 굳이 어렵게 캐시 기능을 만들지 않아도 되겠습니다.