Duplicate
📃

수업 맛보기 (04. 웹 브라우저 성능 개선 및 웹 서버 부하 완화)

본 콘텐츠(텍스트, 이미지 등)는 저작권법에 의해 보호받고 있습니다. 무단 복제, 배포, 공유가 엄격히 금지합니다. 해당 콘텐츠는 실제 수업에서 사용하는 수업 자료이며, 수강생들에게 제공되고 있습니다.

웹 성능 개선을 위한 HTTP Cache

웹 서버(혹은 WAS, 통칭)는 웹 브라우저 요청에 따라 그에 맞는 웹 페이지를 반환
•
웹의 본질은 요청을 보내고 결과를 받는것, 그 사이의 모든것
•
웹의 성능은 요청을 보냈을때 결과를 가능한 빠르게 받는것 = 웹 페이지 로드 시간 단축
◦
결과 = HTTP Resource : 웹 페이지뿐만아니라 영상, 음성, 이미지 등 모두
▪
웹 서버로부터 웹 페이지 로드 성능 개선 : SEO 를 위한 Performance Metrics
▪
웹 캐시로부터 웹 페이지 로드 성능 개선 : HTTP Cache

매번 요청에 따른 웹 브라우저와 웹 서버의 부하

•
웹의 본질은 요청을 보내고 결과를 받는것, 그 사이의 모든것
◦
웹 브라우저 는 매번 웹 서버에게 요청해서 결과를 받아와야하고
◦
웹 서버 는 매번 웹 브라우저의 요청에 대해 결과를 만들고, 반환해야한다.
•
그래서, 웹 브라우저와 웹 서버는 너무 힘들다
◦
웹 브라우저 : 웹 페이지 로드 결과가 똑같다면, 웹 브라우저는 매번 웹 서버에게 받아올 필요가 없다.
▪
이전에 받았던 결과를 저장 후, 매번 요청할시 저장해놓은 결과를 재사용 반환하면 되지 않을까?
1.
HTTP Cache 중 Private (웹 브라우저 사이드 = 클라이언트 사이드)
◦
웹 서버 : 웹 페이지 로드 결과가 똑같다면, 웹 서버는 매번 웹 브라우저에게 만들어 반환할 필요가 없다.
▪
이전에 반환한 결과를 저장 후, 매번 요청받을시 저장해놓은 결과를 재사용 반환하면 되지 않을까?
1.
HTTP Cache 중 Public or Shared (프록시 = CDN or Forward/Reverse Proxy)
2.
API Server 자체 Cache (서버 사이드 = Local or Global)

웹 서버 부하 완화 및 웹 페이지 로드 성능 개선

웹 브라우저 : 결과 “반환” 비용(시간, 네트워크)를 줄이자

웹 브라우저 캐시 흐름 : 캐시 후 0초 후 응답 = 네트워크 사용 X (0초) + 서버자원 사용 X (0초)
•
반복 : 웹 브라우저는 매번 똑같은 100MB 짜리 고양이 영상을 웹 서버로부터 받아온다.
1.
네트워크 트래픽 및 비용 발생 문제
2.
100MB 다운로드 완료까지 긴 대기시간 후에야 시청 가능 문제
•
이전에 받았던 100MB 짜리 고양이 영상을 재사용한다면?
1.
네트워크 트래픽 및 비용 감소
2.
100MB 다운로드 완료의 긴 대기시간 없이 바로 시청 가능 = 유저 경험 증진

웹 서버 : 결과 “생성” 비용(노동, 자원)를 줄이자

웹 서버 캐시 흐름 : 캐시 후 3초 후 응답 = 네트워크 사용 O (3초) + 서버자원 사용 X (0초)
•
반복 : 웹 서버는 매번 똑같은 100MB 짜리 고양이 영상을 만들어서 웹 브라우저에게 만들어준다.
1.
반복적인 서버자원(CPU, Memory) 소비 문제 = 모든 유저의 요청에 대한 반복 연산
•
이전에 만들어놓았던 100MB 짜리 고양이 영상을 재사용한다면?
1.
반복적인 서버자원(CPU, Memory) 여유 = 반복되는 모든 유저의 요청 간단히 처리 가능
2.
불특정 다수의 웹 브라우저에게도 캐시된 자원 제공 가능
•
웹 브라우저 캐시는 웹 브라우저 유저만 캐시된 자원을 활용할 수 있었음

HTTP Cache : 웹 브라우저와 웹 서버 사이 임시 중간 저장소

Cache 캐시 용어의 범용성
“클라이언트와 서버” 처럼 문맥에 따라 워낙 다양하게 사용되니 짚고가자
•
캐시 (명사) : 임시 (단기적 : 기간 설정 or 알고리즘 설정) 로 재사용할 내용을 저장
◦
CPU 캐시 : CPU 연산을 위해 메모리에서 값 가져와 사용 후 폐기 (칩셋)
◦
HTTP 캐시 : 웹 요청에 따른 결과를 임시 저장 후
◦
서버 캐시 : LRU-Cache ‘로컬 캐시’ 혹은 인메모리 DB 인 Redis ‘글로벌 캐시’
▪
LRU : Least Recently Used = 가장 오랫동안 사용되지 않는것 먼저 폐기
•
캐시 (동사) : “임시 저장해” 의 의미 (Default 와 같은 개발자 용어)
HTTP Cache 데이터를 캐시하는곳은 크게 두 곳으로 나뉨 : Shared 와 Private 그리고 두 타입으로 나뉜다 Public 과 Private - Public : Private(웹 브라우저) 와 Shared(프록시) 모두에 저장 | - Private : Private(웹 브라우저) 에만 저장
•
웹 브라우저 : 웹 브라우저가 이전에 받았던 100MB 짜리 고양이 영상을 재사용 한다면?
•
웹 서버 : 웹 서버가 이전에 만들었던 100MB 짜리 고양이 영상을 재사용 한다면?
◦
웹 브라우저와 웹 서버는 반복되는 요청에 대해 부담을 나누기 위한 기술을 도입 HTTP Cache
▪
웹 브라우저와 웹 서버 사이 임시 중간 저장소에 재활용하려는 고양이 영상(결과) 저장
▪
웹 브라우저와 웹 서버 사이 임시 중간 저장소에 재활용하려는 동적 웹 페이지(결과) 저장
▪
웹 브라우저와 웹 서버 사이 HTTP Cache 에 재활용하려는 HTTP Resource 결과 저장

HTTP Cache 종류

웹 캐시 혹은 HTTP Cache 는 위에서 노란색 부분만을 의미한다. 번외로 Server Cache 도 현업에서 언급을 자주하기에 추가함
임시 저장 데이터를 누가 필요로 하는가? 특정된 한명인가, 불특정 다수인가?
•
A. Private : 임시 중간 저장소가 웹 브라우저 안에 있다면, 해당 웹 브라우저 유저 한명만을 위한것
•
B. Shared : 임시 중간 저장소가 웹 브라우저와 웹 서버 사이에 있다면, 모든 웹 브라우저 유저 다수를 위한것

[심화] Server Cache

•
서버 캐시 : HTTP Cache 가 아닌 웹 서버에서 사용하는 캐시이며, 현업에서 언급할일이 많다.
◦
데이터베이스는 영구적 저장 이라면, 캐시는 일시적 저장(반영구적 저장)
◦
솔직히 귀에 걸면 귀걸이 코에 걸면 코걸이인것처럼 데이터베이스를 일시적 저장소로 쓴다면 캐시라 부른다.
▪
일반적으로 인메모리 기반의 NoSQL(Key-Value) 데이터베이스인 Redis 를 캐시로 많이 활용
▪
반영구적이라는 의미에 걸맞게, 주기를 갖고 미사용 데이터를 지우거나 특정 상황에 지우도록 설정 필요
•
서버 캐시 종류는 로컬 / 글로벌로 나뉜다.
◦
로컬 캐시 : LRU-Cache, Memcache, Ehcache
◦
글로벌 캐시 : Redis (캐시 서버, 데이터베이스에 가까운 사용)
질문 - ”설명주신 Redis 가 그럼 DB 서버인건가요?”
•
네, 여러분이 데이터베이스하면 흔히 MySQL이나 MSSQL 생각하시는데 Redis 도 DB 입니다.
•
정확히 Redis 는 인메모리 기반의 NoSQL(Key-Value) DB 로 속도가 뛰어난 장점이 있습니다.

Private : 웹 브라우저에 위치

웹 브라우저 캐시 : 해당 웹 브라우저(특정 한명)만을 위해 캐시가 사용된다.
•
브라우저 캐시 : 웹 서버 HTTP Cache 헤더 (Cache-control) 를 통한 제어 (웹 브라우저에 저장하라)
•
서비스 개발자가 Service Worker (Cache API) 활용하여 오프라인 시 웹 페이지 렌더링 가능
◦
신입 프론트엔드 개발자가 이런 기능을 구현한다면 좋은 포트폴리오가 될 수 있다.

[수업 실습] 웹 브라우저 캐시가 어떻게 동작 하는지 간단히 알아보자!

Shared : 웹 브라우저와 (원본)웹 서버사이 프록시에 위치

프록시 캐시 : 모든 웹 브라우저(모든 유저)를 위해 캐시가 사용된다.
•
프록시 캐시 : 웹 서버 HTTP Cache 헤더 (Cache-control) 를 통한 제어 (프록시 서버에 저장하라)
•
관리형 캐시 : 서비스 개발자가 직접 정책 제어, 배포, 캐싱할 데이터 직접 업로드 등이 가능
◦
여러분들이 가장 많이 사용할 Reverse Proxy, CDN 의 예가 있다.
•
첨언 : 프록시 캐시, 관리형 캐시는 Cache-Control 헤더를 통해 제어하느냐 직접하냐의 여부이지만
◦
굳이 이렇게까지 세세하게 프록시 캐시, 관리형 캐시를 구별할 필요는 없을것같다. 아래와 같이만 외우자!
◦
= HTTP Cache 종류 중 Shared 캐시는 프록시 캐시를 뜻하며, Reverse Proxy 나 CDN 이 있다.

[수업 실습]

HTTP Cache 동작 : 재검증을 통한 캐시값의 준실시간성 보장

어쨌든 당신이 HTTP Cache 를 쓰기로 결정했다면, 과연 그것이 유효한 전략인지 가장 먼저, 다시 생각해보자. 캐시 사용 여부 : 실시간성이 매우 중요한 데이터는 성능에 문제가 되더라도 캐시는 사용하지 않는 것이 맞다.

HTTP Cache 동작 원리

캐시는 임시(반영구적) 저장을 위한 전략이자 실시간을 아예 포기하자는것이 아닌 준실시간을 보장하는 정책이다.
•
준실시간 : 캐시해놓은 데이터가 너무 오래된 데이터가 되지 않도록 특정 주기에 따라 재검증을 해주어야한다.
•
재검증 : 캐시한 데이터의 원본 주인인 웹 서버가 설정한 특정 주기에 따라, 캐시한 데이터가 오래됐는지 검증
◦
검증 방법 : 조건부 요청 사용 = 재검증 기준이 되는 값을 서버에게 보낸다.
▪
우리가 마주할 조건부 요청 종류 2개 1. HTTP Cache 재검증 2. CORS 요청 가능여부 확인
1.
재검증 주기 : 캐시 해놓은 데이터를 얼마 간격으로 재검증할지 특정 주기 (예, 1년마다)
•
개발자들은 데이터의 갱신 특성에 따라 주기 설정 : 자주 바뀌는 데이터? or 잘 안바뀌는 데이터?
◦
주기가 너무 길어도 안되고 : (두부산지 1년 뒤) “엄마, 이거 먹어도 돼?” → “미친놈아”
◦
주기가 너무 짧아도 안된다 : (두부사놓은뒤 매번) “엄마, 이거 먹어도 돼?” → “그만 좀 물어봐”
2.
재검증 기준 : 캐시 해놓은 데이터가 오래됐는지 여부를 원본 주인인 웹 서버가 판단하기 위한 기준 근거
•
수정일 = Last-Modified
•
고유값 = ETag (Entity Tag, ETag 값으로 가장 많이 쓰이는것이 Hash-based)

HTTP Cache 재검증 기준

Last-Modified (수정일)
ETag (고유값)
낮은 정확도 - 파일이 수정되지 않았는데 수정일이 변경되는 경우 - 텍스트 파일 수정 후, 다시 원상복구한 경우 수정일만 변경
높은 정확도 - 그렇기에 사실 Last-Modified 보다 ETag 사용이 좋다. - 다만, HTTP 1.0 혹은 1.1 호환성을 위해 둘 다 사용하는편
검사 방법 - If-Modified-Since : 바뀌었어? - If-Unmodified-Since : 안바뀌었어?
검사 방법 - If-None-Match : 바뀌었어? - If-Match : 안바뀌었어?
상세 설명 들어가기에 앞서 간단하게 HTTP Cache 동작 대충 훑어보기 : Last-Modified (수정일) 활용 예제

Last-Modified : 수정일(시간) 기반

웹 서버가 해당 헤더를 주었다면 Last-Modified : 전송 Resource 의 마지막 수정일 캐시가 유효한지 여부를 시간을 기반으로 판단한다.
웹 서버가 Last-Modified 헤더를 보내줬다면, 재검증 시 If-Modified-Since 헤더 혹은 If-Unmodified-Sinse 헤더 전달
•
재검증 시 캐시 소유자 (웹 브라우저) : If-Modified-Since (바뀌었어?)
◦
서버 답변 : 응 (바뀌었어) : 200 + Resource Cache
◦
서버 답변 : 아니 (안바뀌었어) : 304 Not Changed
•
재검증 시 캐시 소유자 (웹 브라우저) : If-Unmodified-Since (안바뀌었어?)
◦
서버 답변 : 응 (안바뀌었어) : 304 Not Changed
◦
서버 답변 : 아니 (바뀌었어) : 412 Precondition Failed

ETag : 고유값(해시) 기반

웹 서버가 해당 헤더를 주었다면 Etag : 전송 Resource 의 고유값(해시, ID) 캐시가 유효한지 여부를 고유값(해시, ID)을 기반으로 판단한다.
웹 서버가 ETag 헤더를 보내줬다면, 재검증 시 If-None-Match 헤더 혹은 If-Match 헤더 전달
•
재검증 시 캐시 소유자 (웹 브라우저) : If-None-Match (바뀌었어?)
◦
서버 답변 : 응 (바뀌었어) : 200 + Resource Cache
◦
서버 답변 : 아니 (안바뀌었어) : 304 Not Changed
▪
412 Precondition Failed (서버 상태 변경 Methods 일때)
•
재검증 시 캐시 소유자 (웹 브라우저) : If-Match (안바뀌었어?)
◦
서버 답변 : 응 (안바뀌었어) : 304 Not Changed
◦
서버 답변 : 아니 (바뀌었어) : 412 Precondition Failed

[심화] Hash 란 무엇이며, 어떻게 활용되는가?

HTTP Cache 동작 : Cache-control 헤더를 통한 세부 설정

캐시할 데이터는 웹 서버가 반환하는값이고, 반환값에 대한 소유주는 웹 서버이기에 웹 서버가 캐시를 모두 제어
•
갑은 웹 서버이고 웹 서버가 캐시를 하냐마냐 등을 모두 제어
•
을은 해당 반환값을 캐싱하는 웹 브라우저나 프록시에 해당하며, 시키는대로 할 수 밖에 없다.

캐시 저장 여부 : “캐시해? 말아?”

•
no-store : 캐시 안함
•
no-cache : 캐시 함. 단, 매번 재검증 후 사용 (패킷 경량화) ← 헷갈리지 말것! 캐시안하는게 아님

캐시 저장 장소 : “어디에 저장해?”

•
public : Private(웹 브라우저) + Shared(프록시) 모두에 저장 ← 헷갈리지 말것! 브라우저에도 저장
•
private : Private(웹 브라우저) 에만 저장

캐시 재검증 주기 : “얼마가 지나면 재검증해?”

•
max-age : Expires(유효시간)으로 변환 (기존 Expires 가 있다면 덮어쓴다)
◦
이해를 돕기 위한 연습 문제 : max-age=0 는 무엇과 같은 의미일까요? no-cache = 매번 재검증
•
s-maxage : 프록시 캐시에만 적용되는 유효기간
◦
이해를 돕기 위한 연습 문제 : s-maxage=31536000(1년), max-age=0 는 무엇을 의미할까요?
▪
웹 브라우저는 계속 CDN 에게 재검증을 수행, CDN 은 1년을 주기로 본 웹 서버에게 재검증
▪
웹 브라우저는 CDN 이 자체적으로 Invalidation(무효화)하지 않는한 1년 동안 같은 데이터만

재검증 강제 : “재검증이 꼭 서버로부터 이뤄진 데이터만 보겠습니다.”

•
must-revalidate : 꼭 “웹 서버”와 직접 재검증이 완료된 뒤 캐시를 사용해야한다는 의미의 정책
◦
서버와의 접속 문제로 재검증이 실패한 경우 기본 행동은 그냥 기존 캐시 되어있는 데이터를 반환
▪
하지만, must-revalidate 가 활성화되어있다면 504 에러 발생 = 웹 서버가 연락이 안돼요!

SWR (stale-while-revalidate) : “캐시의 즉시성과 최신성을 한번에!”

HTTP Cache 제어 중 SWR (stale-while-revalidate) 확장 디렉티브 전략
•
현재에(당장에) 캐싱된 컨텐츠를 즉시 로드하는 즉시성 (Stale 이더라도)
•
미래에 업데이트된 캐싱 컨텐츠가 사용될 수 있도록 보장하는 최신성
•
60초 이내에 요청이 오는 경우 (stale-while-revalidate = 60)
◦
재검증 요청을 동시에 하면서 오래된 캐시(Stale) 를 반환한다.
Cache-Control: max-age=1, stale-while-revalidate=60
JavaScript
복사
즉시성(빨간색)과 최신성(주황색)을 한번에 보장하는 방법
- 즉시성(빨간색) = 일반적인 Cache 반환 - 최신성(주황색) = Revalidate - SWR(초록색) = 즉시성(빨간색) + 최신성(주황색)
0-1 초 (신선 = 즉시성) ⇒ 캐싱된 응답을 “재검증” 없이 바로 반환
1-60 초 (오래되었지만 반환과 동시 재검증) ⇒ 캐싱된 응답을 바로 반환 + “재검증” 요청 (백그라운드)
•
60+ 초 (재검증 = 최신성) ⇒ 캐싱된 응답을 사용하지 않음 + 서버에 요청보내어 응답 캐싱 및 반환

최악의 Cache-Control 헤더 사례 : 모든 헤더값 무지성으로 때려넣기

•
과거 HTTP Cache 몰이해로 작성된 구식 프록시 캐시 (진짜 정도없이 때려박음) : 이렇게 살지 맙시다.
Cache-Control: no-store, no-cache, max-age=0, must-revalidate, proxy-revalidate
JSON
복사

HTTP Cache 이점

•
웹 서버 입장에서
◦
웹 서버 부하 완화
▪
반복 연산 감소 : 웹 서버가 동적 웹 페이지를 생성하는 연산을 하지 않아도 된다 ← 캐시가 반환
▪
트래픽 분산 : 웹 서버가 모든 요청 트래픽을 받아내지 않아도 된다 ← 캐시가 일부 트래픽 분담
•
부분 DDoS 방어
•
웹 브라우저 입장에서
◦
네트워크 트래픽 감소 (레이턴시 및 네트워크 대역폭 사용 감소)
◦
유저 경험 증진

서버 부하 완화 및 보안(요청/응답 변조)을 위한 Proxy

Proxy 는 클라이언트측 Forward Proxy 와 서버측 Reverse Proxy, 두 종류로 나뉜다.
Proxy vs Reverse Proxy (Real-world Examples)
Weekly system design newsletter: https://bit.ly/3tfAlYD Checkout our bestselling System Design Interview books: Volume 1: https://amzn.to/3Ou7gkd Volume 2: https://amzn.to/3HqGozy ABOUT US: Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.
https://youtu.be/4NB0NDtOwIQ?si=2DFuLNKQgK1CE1Gz
수업하기에 앞서서 정말 간단하게 잘 정리해주는 영상 하나로 Forward Proxy 와 Reverse Proxy 차이를 알아보자
앞서 다뤘던 HTTP Cache + Server Cache 그림을 가져와봤는데, 굵게 표기된 선을 보면 클라이언트측/서버측 나뉘어있다.

Forward Proxy : 웹 클라이언트 보안 및 접근 제어 (예, ISP)

•
요청 보내는 측 : 클라이언트 (웹 브라우저)
◦
요청에 대한 세부적 추가 작업
▪
클라이언트 은닉 : IP 변환을 통해 원 요청자 은닉
•
우회 (Bypass) : 특정 클라이언트 IP 가 블락되어있다면, 그걸 피해서 접속하기 위해 IP 구라
▪
클라이언트 접근 제어 : 특정 IP 혹은 웹 페이지에 대한 접근 금지
▪
캐싱 : 클라이언트가 받을 요청을 중간에 임시 저장 (개인이 소비하는 입장에서)
•
심화 예시 : Residential Proxy & Datacenter Proxy - ISP(Internet Service Provider) 연결 (추가)
◦
앞서 배웠던 ISP(Internet Service Provider) 가 Forward Proxy

Reverse Proxy : 웹 서버 부하 완화 및 보안 (예, 로드 밸런서)

L2 Reverse Proxy : Load Balancer

한 서버(Reverse Proxy)가 Private Key 를 가지고 있으면 관리 및 인증 간편
캐싱 : 클라이언트가 자주하는 요청에 대한 응답을 중간에 임시 저장 (다수에 제공하는 관점에서)
•
요청을 받는 측 : 웹 서버
◦
요청에 대한 세부적 추가 작업
▪
요청 변환 : Header 세팅 (예, X-FORWARDED-BY 로 근원 클라이언트 IP 를 서버에게 전달)
▪
요청 전달 : URL/I Mapping (URI 기반 Routing), 로드 밸런싱 (요청 분산)
•
로드 밸런싱 (요청 분산) = 웹 서버 부하 완화
◦
웹 서버 수 동적으로 늘리기 → SRE 의 업무 (고가용성)
▪
서버 은닉 : 서버 고유의 IP 가 외부로 노출되지 않음
▪
서버 접근 제어 (요청 필터)
•
DDoS 방지 : Traffic 제어
◦
Rate Limiting : 짧은 시간(예, 1초) 내 너무 많은 요청이 오는걸 막기위한 정책
▪
참고 : WS 나 WAS 같은 원 서버에서도 적용 가능
◦
WAF (Web Application Firewall)
▪
Honeypot 에 저장된 악성 IP 리스트 활용한 블럭
▪
Custom IP 추가 가능 (예, 악성 크롤링 봇 블럭)
•
Response Max Size 세팅 : 너무 큰 파일을 반환하는 경우 블락 (Nginx 설정)
•
Timeout 세팅 (Nginx 설정)
▪
보안 : HTTPS
•
모든 서버가 Private Key 를 가지고 있어야하는 단점
•
예시 : Nginx 와 같은 WS 를 쓰기도한다, AWS ELB

L1 Reverse Proxy : CDN (Contents Delivery Network)

Proxy 는 캐싱 + 요청에 대한 세부적 추가 작업 를 위해 사용한다.
•
캐싱 : 요청에 따른 응답을 중간 저장해놓은 뒤 동일 요청 시 저장값 반환
•
요청에 대한 세부적 추가 작업 : 요청 변환, 필터 등의 추가 작업 수행
CDN 은 캐싱 + 지역성 해결 을 위해 사용한다.
•
캐싱 : 요청에 따른 응답을 중간 저장해놓은 뒤 동일 요청 시 저장값 반환
◦
원본 데이터를 가진 웹 서버에 문제가 생기면 CDN 가 대신 응답을 반환하여 고가용성 보장
▪
CDN : 고가용성을 보장해주는 버퍼의 역할
◦
원본 데이터를 가진 웹 서버에 DDoS 공격이 가해지는것을 CDN 이 대신 방어
•
지역성 해결 : HTTP Resource 제공 서버와 클라이언트가 멀리 떨어진 경우 클라이언트에 가까운곳에 저장
◦
한국 웹 브라우저에서 미국 웹 서버로부터 응답을 받으려면 긴 응답시간
◦
전세계적으로 캐시 서버를 곳곳에 두어 캐시 서버 내 응답 데이터를 캐싱(저장)한다면 속도 개선
◦
캐시 서버로 동작하는 만큼 원 서버에 문제가 생기면 CDN 이 을 해주기도 함
페어 모의 면접
•
마크업 언어와 마크다운 언어는 무엇인지?
•
VPN 원리를 설명하시오
•
인트라넷은 무엇인지? 인터넷은 무엇인지?
•
HTTP Cache 는 (1) 무엇이며, (2) 왜 사용하나요?
•
CDN 은 어떤 상황에서 사용하는지 2개 정도의 예시를 들어줄 수 있을까요?
•
프록시란 무엇인지 설명해보세요
•
포워드 프록시와 리버스 프록시의 차이는 무엇인가요?
•
HTTP Cache 어떻게 설정해서 사용하는지 아나요?
•
HTTP ETAG 는 무엇인가요?
•
SWR(stale-while-revalidate) 개념이 무엇인가요?
•
CDN 사용 시 다음과 같이 캐시 설정을 하는데 s-maxage=31536000, max-age=0 왜 이렇게 하나요?
•
HMAC 은 무엇인가요?
•
<script defer><script/> 와 <script async><script/> 의 동작 차이는 무엇인가요?
•
모놀리딕 아키텍쳐와 MSA 아키텍쳐의 차이에 대해 말해보세요
•
REST API 를 간단히 설명하고 RESTful 이란 어떤것인가요?
•
웹 브라우저에서 HTML 을 페이지로 렌더하는 과정을 짧게 설명하세요
•
DNS 란 무엇인지 설명하세요
•
검색 엔진의 원리와 SEO 에 대해 설명하세요
•
웹 성능 매트릭(Performance Metrics) 몇개 설명해보세요
•
웹 서버와 웹 어플리케이션 차이에 대해 말해보세요.
•
CGI 란 무엇이며, PHP 는 어떻게 동작하나요
•
정적 웹 페이지와 동적 웹 페이지의 장단점에 말해보세요
•
프로세스와 스레드의 차이는 무엇인가요?
•
MVC 에 대해서 간단히 설명해보세요.
•
웹 페이지 렌더 방식인 SSG, SSR, CSR 의 차이에 대해 서술하시오

[복습] 웹 클라이언트(웹 크롤러 포함)와 웹 서버 사이 구조

로드맵 - L1 웹 동작 흐름

[심화] 공식 커리큘럼이 아닌, 추가 설명 모음

실무에서 어떻게 사용되는지 및 기존 수업 내용 Deep Dive
이 부분은 정상 과정(커리큘럼)에 포함된 내용이 아닌, 깊은 내용을 더 알고싶어하는 자들을 위한것으로
따로 정리본을 제공하진 않습니다만, 해당 심화 수업을 들은 자들의 복습을 위해
•
수업할때 메모한 내용들을 간단히만 게시해드립니다. (깔끔하게 정리해드리지 않습니다.)
•
심화 관련된 질문도 언제든 환영입니다
실제 현업에서 어떻게 활용되는지에 대한 이야기이므로, 누구든 들으시면 좋을테지만
•
심화 수업은 꼭 본 수업에 대해 적어도 조금의 이해라도 가진것을 전제로 들으셨으면 합니다.
◦
개발 및 엔지니어 지식은 불필요하게 과식을 하면 체해서 모든걸 다 토해내버릴겁니다
= 머릿속에 하나도 남지 않는 비극을 맞이할겁니다. 혹은 깊은 자괴감에 빠지거나

(Frontend) React 배포와 (Backend) Java 배포 비교

React 는 번들된 HTML, CSS, JS 들이 웹 브라우저 에서 동작되고, Java 는 JAR 가 웹 서버 에서 동작된다
•
React 배포할때 왜 S3 를 쓰는가?
번들된 HTML, CSS, JS 는 정적 리소스이기에, WS, WAS 에서 제공할수도 있는데 왜?
◦
WS, WAS 는 서버이기에 서버가 떠있는 시간에 따른 과금
◦
S3 는 저장소이기에 호출수에 따른 과금 → 더 비용 효율적!
▪
CDN 을 연결하면 번들된 HTML, CSS, JS 가져올때 S3 직접 호출하지 않아, 호출 수(비용) 감소
= 실제 프론트엔드 배포를 한다면 AWS S3 에 업로드하고 AWS CloudFront (CDN) 연결할 것

Virtual DOM 이란 무엇인가?

•
HTML ~= DOM
HTML 이 변경되면 DOM 이 변경되는것이고, 이는 웹 브라우저 렌더 방식에 의해 Repaint
•
JSON(HTML-like) ~= VDOM
HTML 을 JSON 변환 시 오른쪽 그림과 같다. VDOM 은 이렇게 HTML 을 JSON 으로 표시한 데이터 표현 방식이며, HTML 이 변경되었을떄 Repaint 를 시키지 않고, 변경된 JSON 과 이전 JSON 을 비교하여 변경된 모든 HTML 부분들을 하나의 DOM 으로 합친 뒤 (이렇게 다수의 작업을 단일 작업으로 모아 실행하는걸 ”배치” 라고 한다) Repaint 를 한번만 실행시킨다

React 에서 Hydration 이란 개념은 무엇인가?

React 은 원래 처음에 등장했을때 VDOM 을 통한 SPA (Single Page Application) 과 CSR 지원을 위해 탄생 하지만 React 18 버전부터 SSR 과 CSR 를 결합하여 사용할 수 있도록 확장됨과 동시에, React 개발자와 Next.js 개발자가 사실상 긴밀한 협의체로써 개발을 진행하며, SSR 과 CSR 이 결합된 Next.js 는 React 18 버전을 기반으로 깔끔히 융화되어 최고의 React Framework 로 발돋음
•
Hydration 은 React 18 버전의 개념 (리액트 개념) 이기도하나, 동시에 Next.js 의 개념이기도 하다
•
SSR + CSR 의 결합은 하나의 단일 페이지 라하더라도
◦
(1) 미리 서버에서 작업된것들 받아오는 부분과 = SSR 부분
◦
(2) 웹 브라우저에서 작업할 내용들은 웹 브라우저에서 직접 보완하여 만들도록 하는 부분 = CSR 부분
→ SSR 부분만 완료된 단일 페이지를 웹 페이지가 받아냈을때, 웹 브라우저에서 그려야할 CSR 은 누락되어있음

Serverless 란 무엇이며 현업에선 어떻게 활용되는가?

물리적 서버와 달리 서버를 사고 조립하지 않아도되는 클라우드 서버를 표현하는것이 아니다. 오해하지 말것
물리적 서버든 클라우드 서버이든 우리가 서버를 구매하지 않고도 작업을 수행하는것을 Serverless 라고 한다.
•
물리적 서버 나 클라우드 서버 나 시간에 따른 과금 (서버가 계속 떠있으니까 = 구동되고있으니까)
•
Serverless 는 서버가 존재하지 않기 때문에
◦
요청이 들어오면 기존에 떠있는 서버가 받아서 처리하는게 아니라
◦
요청이 들어오면 처리를 위해 먼저 서버를 만들어서 → 수행하고 → 서버를 죽인다
▪
요청 횟수에 따른 과금
•
실제 Serverless 사용 예는 (1) CDN 에 AWS Lambda 를 연결하여, 이미지 처리
◦
CloudFront가 최종 사용자의 요청을 수신할 때(최종 사용자 요청)
◦
CloudFront가 오리진에 요청을 전달하기 전(오리진 요청)
◦
CloudFront가 오리진의 응답을 수신할 때(오리진 응답)
◦
CloudFront가 최종 사용자에게 응답을 반환하기 전(최종 사용자 응답)
•
다른 Serverless 사용 예로 (2) Vercel 을 통한 Next.js 배포
•
또 다른 Serverless 사용 예로
(3) 백엔드 서버 로직 중 호출 횟수가 적은데, 자원이 생각보다 큰 작업의 경우 Serverless 로 처리
◦
웹 서버에게 필요로 하는 Memory 자원은 100MB 인데
◦
웹 서버 작업 중 이미지 관련 로직(함수)가 써야하는 Memory 자원은 1GB 라면
◦
웹 서버에서 해당 이미지 로직을 수행하기 위해 하루에 단 몇번의 호출을 위해 1GB Memory 로 배포
▪
그래서 이미지 작업만 Serverless Function (1GB Memory) 으로 수행한다면
▪
웹 서버는 불필요하게 높은 자원으로 배포할 필요가 없다.

웹 브라우저에서 Service Worker 는 무엇인가?

•
웹 브라우저 내에서 스레드를 활용하는것
•
스레드간 데이터 통신을 위해서는 MessageChannel (onmessage, postMessage) 을 활용

Daemon 과 Linux Service Management

•
프로세스 : Foreground Process + Background Process
•
Daemon ~= Background Process (MS 윈도우 에서는 Service)
◦
리눅스 예시, 끝에 d 가 붙는 프로세스 : sshd, httpd, mysqld
◦
Background Process 는 부모(프로세스)가 있다
◦
Daemon 은 부모(프로세스)가 없다

리눅스 초기화

운영체제 커널은 부팅 직후 초기화 프로세스를 시작
•
쉽게 말해 시스템에 필요한 프로세스가 자동으로 실행되는 단계
•
이때 초기화 시스템은 구성 파일을 읽고 구성 상태에 따라 서비스와 프로세스를 시작
◦
한마디로 초기화 프로세스는 모든 프로세스의 시작점. 그래서 1번 PID가 부여된다.

Linux Service Management

SysVInit (Unix)

명령어 service (start / stop / restart)
→ One of the main characteristics of this init system is that it is a start-once process and does not track the individual services afterward.
•
특징 : 한번 수행되고나면 그 이후로 각 개별 서비스들을 추적하지 않는다
•
/etc/init.d → 시작 프로세스 처리
◦
초기화 시스템명 = 최상위 트리 (데몬 프로세스의 부모 프로세스명) : init

SystemD (Linux Distributions)

명령어 systemctl (start / stop / status / restart)
→ SystemD continues to run as a daemon process after the initialization is completed. Additionally, they are also actively tracking the services through their cgroups
•
특징 : 한번 수행되고나서 계속 SystemD 는 떠있어서 추적 가능
•
/etc/systemd/system/.service → 시작 프로세스 처리
◦
초기화 시스템명 = 최상위 트리 (데몬 프로세스의 부모 프로세스명) : systemd
▪
리눅스 내 pstree 로 확인해보면, systemd 인지 init 인지 확인 가능
본 콘텐츠(텍스트, 이미지 등)는 저작권법에 의해 보호받고 있습니다. 무단 복제, 배포, 공유가 엄격히 금지합니다. 해당 콘텐츠는 실제 수업에서 사용하는 수업 자료이며, 수강생들에게 제공되고 있습니다.