http status 304 를 활용하여 네트워크 전송 절약하기

https://developer.mozilla.org/ko/docs/Web/HTTP/Status/304

304 Not Modified - HTTP | MDN

 

http 스테이터스 코드중 304 (Not Modified) 라는 스테이터스 코드가 있습니다

 

설명을 좀 더 읽어볼까요

 

클라이언트 리디렉션 응답 코드 304 Not Modified 는 요청된 리소스를 재전송할 필요가 없음을 나타낸다. 캐시된 자원으로의 암묵적인 리디렉션이다. 이 는 GET 나 HEAD 요청처럼 요청 방법이 안전 한 경우 또는 요청이 조건부로 If-None-Match (en-US) 또는 If-Modified-Since 헤더를 사용할 때 응답 된다.

 

 

이 내용만으로는 충분하지 않으니 좀더 상세히 설명을 해보겠습니다

 

 

서버는 클라이언트로부터 GET, HEAD의 요청을 받을때 응답결과가 이전에 요청했던것과 변동이 없는 경우

 

304 스테이터스를 리턴할수 있습니다

 

이 경우 status code를 304를 리턴하고 body의 내용은 포함하지 않습니다

 

이미 보냈던 body response이기 때문에 이 내용을 보내지 않고 지난번에 보냈던것과 같다는 사실만 알려주는것입니다

 

그러면 클라이언트에서는 이전의 결과값을 캐싱해두고 이 값을 사용하면되는것이지요

 

 

 

같은 요청에 대한 동일한 응답인지는 클라이언트와 서버가 어떻게 구분을 할까요?

 

바로 이때 사용되는 것이 etag 헤더입니다

 

etag 값은 body로 전송된 값의 해싱된 값이라고 생각하시면 이해가 쉽습니다.

 

 

HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 13901
ETag: W/"364d-rayHNwASYykbhOd67lc1TfbCqpA"
Date: Fri, 09 Dec 2022 03:40:07 GMT

 

특정 HTTP request에서 response header 값으로 이러한 값들을 받습니다(물론 get, head의 요청에서만)

 

이 때 ETag 값이 함께 전송되는것을 볼수 있습니다

 

클라이언트는 이 etag를 기억을 하고있다가

 

 

다음에 동일한 리소스를 요청하게 되면 request header에 지난번에 받았던 etag값을 If-None-Match 헤더에 덧붙여 보냅니다.

 

GET /welcome HTTP/1.1
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Connection: keep-alive
Host: localhost:6001
If-None-Match: W/"364d-rayHNwASYykbhOd67lc1TfbCqpA"
Origin: http://localhost:3000

 

If-None-Match 값으로 아까 response header로 받았던 etag의 값을 보냅니다

 

이렇게 말이죠.

 

 

 

서버는 If-None-Match 헤더로 전송된 etag 값을 확인하여

 

자신이 response할 body의 etag값이 요청받은 etag값과 동일한경우(해시비교)

 

응답결과가 변경이 없구나 라는 것을 확인하게 되면  body 없이 304 status만을 리턴하게 됩니다

 

 

그림으로 다시한번 설명해보겠습니다

 

 

 

 

왜이렇게 복잡하게 하는거죠?

 

이렇게 하면 어떤 장점이 있을까요?

 

어떠한 network 요청의 응답 response가 큰 경우(웹페이지 또는 json 등)

 

이 body response를 전송하지 않기 때문에 클라이언트에서는 좀 더 빠른 서버의 응답을 받게 될 뿐만 아니라

 

네트워크 데이터 소모도 확연히 줄어듭니다

 

 

실제 결과를 테스트해볼까요

 

첫번째 request는 200 응답 코드를 받았고 이와 함께 14kb의 body 결과값도 받았습니다

 

그 다음 요청부터는 304 응답코드를 받았고 body의 결과는 캐싱되어 그만큼 빠른 응답결과를 얻었고(테스트 환경에서는 네트워크 속도가 좋아 큰 차이를 못느끼겠지만 실제로는 더 큽니다)

 

데이터 대역폭 전송량도 줄었습니다

 

그럼 클라이언트에서 뭔가 더 복잡하게 작업을 해야하는건가요?

 

라는 물음에는

 

브라우저는 물론이고 유명 라이브러리들에서는 이 기능이 기본적으로 구현이 되어있어 대부분의 케이스에서는 여러분이 직접 이 기능을 개발하실 필요는 없습니다

 

서버측도 마찬가지로 대부분의 프레임워크에서 이 기능을 지원하기 때문에 특별히 개발할것은 없습니다

 

다만 나도 모르게 이렇게 동작하고 있었구나 라는것을 알면 좋겠습니다

 

 

 

참고로 mac os의 크롬에서는 오류가 하나 있습니다

 

실제 결과로는 서버에서 304를 내려줬지만 크롬 developer console 상에서는 200 status 코드를 받은것처럼 나타납니다

 

하지만 실제 결과를 보면 첫번째 리퀘스트에서 14.2KB를 전송받았는데 그 다음부터는 202B만을 전송받은것을 보면

 

정상적으로 캐싱된 값을 사용한것으로 확인되지만 status code만 200으로 전송되는 오류가 있다고 하네요

 

참고하시면 좋겠습니다