내가 만들고있는 RESTful API에 대한 캐시/스로틀/etc 응답에 Varnish를 사용하는 데 관심이 있습니다. 나는 "HMAC"라는 용어를 너무 느슨하게 사용할 수도 있지만, 내 API에 대한 각 요청에는 요청의 일부 (타임 스탬프 포함)를 해싱하여 클라이언트가 계산 한 해시를 포함하는 헤더를 포함해야한다는 것을 의미합니다. 공유 비밀. 그런 다음 서버는 요청과 동일한 구성 요소를 사용하여 동일한 해시를 계산하고 요청이 유효하고 응답해야하는지 여부를 결정합니다.Varnish를 사용하여 RESTful API를 캐시하는 방법은 있지만 각 요청을 서명/확인하는 데 여전히 HMAC를 사용하고 있습니까?
잘 작동하지만 지금은 바니시를 사용하여 API 응답을 캐시하고 싶습니다. HMAC의 본질은 각 요청이 사용자가 누구인지 확인하기 위해 해시를 계산해야하지만 반환되는 실제 응답은 동일하므로 API 호출의 고기가 대단히 캐시 가능해야합니다.
무엇을하고 싶습니까? (그리고 나는 이것을 달성 할 수 있다고 가정하고 있습니다.) 어떻게 해야할지 모르겠지만, 인증 작업을 백엔드에 전달하는 것입니다. 어떻게 든 바니시에게 "네, 진행하고 이에 응답하십시오. 요청 "또는"아니오,이 요청에 응답하지 않음 "을 선택하고 바니시가 요청이 캐시에서 제공 될 수 있는지 여부를 결정하게합니다.
좀 더 이상적으로 뭔가를 할 것이고, 바니시가 인증 자체를 처리하거나 HMAC 처리를 백엔드보다 빠른 것으로 전달할 수 있습니다. 예를 들어, API는 클라이언트 암호/공개 키를 redis 캐시에 저장하고, Varnish는 실제로 Redis의 값을 사용하여 해시 자체를 계산할 수 있습니다.
인증 작업을 내부적으로 두 개의 요청을 분배하는 백엔드로 전달하거나 인라인 C를 사용하여 바니시 내부에 HMAC를 구현할 수 있습니다. – NITEMAN
답장을 보내 주셔서 감사합니다. @NITEMAN - Varnish를 처음 접했어. 성능/확장 성의 관점에서 "OK"일 것인가? 그리고 애플리케이션과 바니시간에 비밀 키/토큰 정보를 공유하기 위해 Redis와 같은 것을 사용한다고 언급했는데, 바니시 내부에 HMAC를 구현하는 것이 좋은 방법 인 것 같습니까? 다시 한 번 감사드립니다! –
큰시 스템에서 중요한 C 코드를 인라인하는 경험이 없지만 이론 상으로는 잘 작동하고 확장되어야한다고 말하기는 어렵습니다. 퍼포먼스에 관심이 있다면 바니시 모듈을 작성하는 것이 좋습니다. – NITEMAN