• 카테고리

    질문 & 답변
  • 세부 분야

    웹 개발

  • 해결 여부

    해결됨

캐시가능 Cachable 질문

24.07.04 20:08 작성 조회수 38

1

응답 결과 리소스를 캐시해서 사용해도 되야 캐시 기능을 편하게 사용할 수 있다. GET의 경우 만약 요청 메세지가 같다면 굳이 통신까지 사용해서 서버에서 응답을 받을 것이 아니라 이전 응답에 의한 응답 메세지가 캐싱되어있다면 캐시에서 꺼내올 수 있을 것이다. 이러한 방식을 완전 캐시 히트 (Full Cache Hit)라고 한다.

캐시를 활용하여 서버와의 최소한의 통신만 하는 조건부 요청이 가능하다. 만약 캐시를 이용할 수 있는 GET요청이지만 이전 요청과 요청조건이 다르다면 서버와의 최소한의 통신으로 응답이 같을 건지 확인하고 같을 것이라면 캐시에서 이전 응답을 꺼내오는 것이다.

POST를 생각해보자. POST는 body message를 처리한다고 했다. 즉 GET과 달리 body message가 추가된다. 아래는 "만약 POST작업을 캐싱한다면"의 예시이다. 캐시는 key:value 구조를 가진다.

만약 url을 key로 사용한다면 body message가 달라질 경우 동일한 작업이 보장되지 않는다.

/api/submit: POST /api/submit {"username": "user1", "password": "pass1"}

/api/submit: POST /api/submit {"username": "user2", "password": "pass2"}

보통 HTTP 캐시는 요청을 구분하는 주요 키로 URL을 사용한다. POST 요청의 본문은 URL과는 별도로 고유한 캐시 키를 구성해야 하며, 이는 복잡성과 추가적인 관리를 필요로 한다.

즉 GET보다 POST가 다뤄야할 변수가 많기에 상태를 저장하는 것이 유리하지 않을 확률이 더 높다는 것이다. POST는 응답 메시지를 캐싱하기에도, 요청 메시지를 캐싱하기에도 난이도가 높아진다.


이해를 확인하기 위해 제가 작성한 캐시가능에 대한 설명입니다. 혹시 틀린점이 있을까요? 요청정보 캐싱과 응답정보 캐싱에 대한 제 설명이 확신이 서지 않습니다...

답변 1

답변을 작성해보세요.

0

y2gcoder님의 프로필

y2gcoder

2024.07.05

안녕하세요. 영한노게임님, 공식 서포터즈 y2gcoder입니다.

저는 잘 정리하셨다 생각합니다.

결론을 내자면

  • GET 요청은 캐싱하기에 적합하며, 캐시된 데이터를 사용할 수 있어 서버 부하를 줄이고 성능을 향상시킬 수 있습니다.

  • POST 요청은 본문 데이터 때문에 캐싱이 복잡하며, 일반적으로 캐싱되지 않습니다. 그러나 특수한 경우에 캐싱이 필요하다면, URL과 본문 데이터를 조합하여 고유한 캐시 키를 생성해야 합니다.

정도로 정리할 수 있을 것 같습니다.

추가로 더 궁금하시면 HTTP 1.1 스펙 문서 등을 참고해보시면 좋을 것 같습니다 🙂

감사합니다.

채널톡 아이콘