GET 방식 cacheable 테스트

HTTP의 GET

HTTP 프로토콜을 사용하여 서버에 요청을 보낼 때 사용하는 방식 중 하나로 이번 포스팅에서는 GET방식과 GET방식의 cacheable에 대하여 알아보겠다.

GET방식이란 요청하는 데이터가 HTTP 요청 메시지의 헤더 부분에 URL이 담겨서 전송이 된다. 이러한 방식은 결국 url이라는 공간에 담기기 때문에 전송할 수 있는 데이터 크기가 제한적이다.

얼마나 제한적일까? 2KB로 제한이 되는데 이는 연구자들이 GET방식을 보낼때 2KB가 최적의 효과를 낸다고 결론내어 지금까지 제한이 되어있는 것..

GET방식을 말할 때 꼭 빠질수 없는 하나가 있다. 그건 바로 '캐시'이다.

---

GET방식의 캐시

웹 사이트를 접속할 때 GET방식은 캐시가 된다라는 특징이 있으며 이는 빠른 접속이 가능하지만, 보안상 취약하다는 단점도 존재한다.

그러면 이제 실습을 해보자. GET방식의 캐시를 어떻게 확인하고 측정해볼 수 있을까?

GET 방식에서 저장되는 캐시는 주로 브라우저의 캐시 메모리 또는 디스크에 저장되기 때문에 브라우저 캐시를 확인해보면 된다.

---

개발자 도구 캐시 확인

`Name : 시간 순으로 네트워크 로그들을 보여준다.`

`Status : 서버가 돌려준 HTTP response code`

`Type : resource type`

`Initiator : 어떤 파일에서 요청한 것인지`

`Size : resource의 size`

`Time : 걸린 시간`

`Waterfall : 로딩 순서를 확인할 수 있다.`

여기서 우리가 봐야할 부분은 SIZE부분이다. 로그를 불러오는 크기가 캐시가 안되어 있을때는 사이즈 크기만 나오지만, 만약 새로고침을 통해 network상태를 다시 새로고침하게 된다면 다음과 같은 결과가 나온다.

이번에는 크기가 뜨는 것이 아닌 캐시의 resource가 뜨게 된다. 이는 처음 사이트에 접속 했을때 캐시가 되어지고 두 번째에는 캐시에서 데이터를 꺼내온다는 것을 알 수 있다. 그러면 cache가 되는 종류도 다양한데… memory cache, disk cache, 그리고 prefetch cache..?

memory cache

• 메모리에 저장되는 캐시로 이는 빠른 접근과 응답 속도를 제공한다. 그러나 브라우저를 종료하면 메모리 캐시는 소멸된다.

disk cache

• 하드 디스크에 저장되는 캐시이다. 이는 하드 디스크(또는 SSD)와 메모리(RAM) 사이에 위치한 캐시 메모리리로, 메모리 캐시보다는 속도가 상대적으로 느리다.

prefetch cache

• CPU가 어떤 작업을 수행하면서 일정한 패턴이나 접근 규칙을 가진다고 예측될 때, 패턴에 기반하여 미리 데이터를 캐시를 가져온다.

---

HTTP캐시의 중요성

HTTP캐시는 위와 같이 웹 페이지의 로딩 속도가 향상이 된다. 이는 전에 이미 다운로드한 리소스를 캐시에서 가져와 서버로부터 데이터를 다시 받아올 필요가 없어지기 때문이며, 웹 페이지의 로딩 시간이 단축되어 사용자가 빠르고 효율적으로 웹 페이지를 경험할 수 있다. 또한, 캐시된 리소스를 클라이언트에서 제공하므로 서버의 부하가 줄어든다는 장점과, 서버는 클라이언트에서 자주 요청되는 리소스를 다시 생성하거나 제공할 필요가 없으므로, 리소스를 효율적으로 처리할 수 있다.

다음을 실제로 확인해보기위해, bash에서 캐시가 얼마나 빠른 속도를 낼 수 있는지 실험해보자.

---

캐시 테스트

curl --trace-time -v 'https://www.yahoo.com' | grep -i "cache" ; sleep 70 ;  curl --trace-time -v 'https://www.yahoo.com' | grep -i "cache" ; sleep 70 ; curl --trace-time -v 'https://www.yahoo.com' | grep -i "cache"

위의 명령어를 통해서 bash에서 테스트를 해본다. 캐시가 현재 없는 yahoo 홈페이지에서 처음 접속을 하고, 이후 두 번째 접속에는 캐시가 적용된 상태이니, 요청과 응답 속도를 비교해보는 테스트이다.

🎆첫 번째 결과

🎆두 번째 결과

첫 번째 결과는 1423915 - 954882 = 약 46만

두 번째 결과는 484658 - 102524 = 약 38 만 이다.

두 번째요청에서는 캐시가 적용이 되어, 약 8만정도 더 빠른 것을 확인할 수 있다.

---

마무리

캐시의 중요성과 실제 리소스를 빠르게 업로드 해준다는 것을 이론적으로 공부했지만, 직접 개발자도구를 분석하고, 테스트를 해보니 공부가 완성되어가는 느낌이 들었다.