2024년 11월 1일
우리는 리액트 같이 CSR 라이브러리들을 배포하거나, 아니면 이미지 같은 정적 리소스들을 활용할떄 AWS의 S3 + CloudFront 를 활용한다.
그리고 왜 S3가 아니라 CloudFront까지 함께 사용해야하는가? 라고 하면 캐싱이라고 말할것이다.
그렇다면 이 캐싱이 얼만큼의 효과를 안겨주길래 사용할까?
CDN
은 Content Delivery Network, 즉 컨텐츠들을 전송해주는 네트워크라고 할 수 있다.
AWS에 CloudFront는 세계 곳곳에 분산 된 엣지 로케이션에서 컨텐츠들을 캐싱하여 빠르게 제공한다.
비유를 하나 들어보자. 우리는 현재 부산에 위치하는 A 상점의 어묵을 먹고 싶다.
만약 CDN이 없다면 우리는 해당 어묵을 먹으러 항상 부산까지 내려가야한다.
하지만 A 상점이 분점들을 서울, 경기, 강원도 각지에 오픈을 한다면 우린 부산까지 가지 않더라도 가까운 지역의 A분점으로 가서 어묵을 먹으면 된다.
CDN도 마찬가지이다. 정적 리소스를 원래의 본 저장소에서 가져오는 것이 아니라 가까운 곳에 위치한 저장소에서 가져온다고 생각하면 된다.
해당 사진이 잘 설명해준 사진 같아서 첨부한다.
가까운 로케이션 저장소에서 컨텐츠를 캐싱해놓고 가져오기 때문에 사용자에게 더 빠르게 컨텐츠를 제공할 수 있다.
또한 다수 지역의 저장소를 둠으로써 전 세계 각지에서 발생하는 트래픽을 분산 처리하여 과부하를 줄일 수 있는 장점도 존재한다.
그럼 CDN을 활용한다면 어느정도의 이점을 누려볼 수 있을까?
일단 CDN을 사용할때와 안할때의 속도부터가 약 10배 넘게 차이가 난다. (257ms vs 24ms)
또한 차이점은 프로토콜 부분에서 s3만 사용할때는 http/1.1
, CDN와 함께 사용한다면 h2
로 표시 된다는 것이다.
여기서 h2
는 http/2
를 의미한다.
이 두개의 차이점은 무엇일까?
먼저 간단히 설명하자면 http/2가 http/1.1의 업그레이드 된 버전이다.
뭐가 구체적으로 다른지 살펴보자.
http/1.1 같은 경우 하나의 요청당 하나의 TCP 연결이 매칭된다.
TCP는 이 전 블로그 글에서 기재했다시피, 패킷을 목적지까지 어떻게 안정적으로 보낼것인가에 대해 정의한 프로토콜이다.
그렇기 때문에 여러 리소스들을 동시에 처리하기 위해선 여러개의 TCP 연결이 필요하다.
만약 HTML, CSS, JS 파일이 필요하다면 총 3개의 TCP 연결 매칭이 이루어져야하기 때문에 네트워크 부담이 크다.
HTTP/2 에서는 하나의 TCP 연결이더라도 여러 요청과 응답을 동시에 처리할 수 있다.
하나의 연결에서 요청을 병렬적으로 처리하기 때문에, 여러 리소스들을 동시에 빠르게 받아올 수 있다.
그렇기 때문에 CDN을 통한 요청에서 http/2로 나타내고 더 빠른 속도로 데이터를 받아올 수 있는 것이다.
http/1.1 의 경우에는 헤더가 압축되지 않고 그대로 전송된다. 만약 요청이 많은 웹페이지라면 반복되는 헤더 정보가 동일하게 보내짐으로써 이 또한 리소스를 낭비할 수 있다.
하지만 http/2는 HPACK
이라는 헤더 압축 방식을 사용하여 전송한다. 이렇게 하면 중복되는 헤더가 압축이 되기 때문에 요청이 많은 페이지에서도 트래픽을 줄일 수 있다.
http/1.1 같은 경우, 클라이언트가 리소스를 요청하기 전에는 서버가 해당 리소스를 전송할 수 없다.
그렇기 때문에 필요한 리소스들을 전달받기 위해서는 여러 요청-응답의 과정을 거쳐야하므로 초기 로딩 속도가 느려질 수 있다.
하지만 http/2에서는 클라이언트측의 요청 없이도 서버에서 미리 리소스를 전송할 수있다.
위에서 예로 들었던 HTML, CSS, JS의 경우를 살펴보자면, 클라이언트가 HTML을 요청하더라도 서버가 CSS, JS를 미리 전송해주는 것이다. 이로 인해 초기 로딩 속도를 개선시킬 수 있다.
이 외에도 보안이라던지, 우선 순위 제어 유무 등도 존재한다.
단순히 여러 로케이션 저장소를 두어서 물리적인 속도를 빠르게 할 뿐만 아니라, http통신 또한 1.1이 아니라 2로 리소스를 주고 받음으로써 속도를 개선 시킨다는 것을 알 수 있었다.