URI(위치지정자) 또는 URL(식별자)를 치고 엔터를 누르면
- 리다이렉트 여부 확인
- host 파일 확인
- 이미 캐싱된 요청이라면 캐싱된 데이터를 반환
- 브라우저 캐시 (private cache)
- 쿠키, 로컬스토리지
- 사용자가 HTTP를 통해 다운로드하는 모든 문서를 브라우저가 보유 (HTTP 304)
- 공유 캐시
- 클라이언트와 서버 사이에서 응답을 저장 (서버까지 도달하는 요청을 줄이기 위해)
- 서버 앞단에서 프록시 서버가 캐싱
- “리버스 프록시를 둬서 내부서버로 포워드한다.”
- ex) Nginx, AWS cloud front, cloudflare
- DNS 캐시 확인
- 브라우저 캐싱
- OS 캐싱
- DNS 캐시에 없으면 서버의 IP 주소를 얻기 위해 DNS에 질의, FQDN을 IP로 변환
- 구성
- 리졸버 - 요청을 네임서버로 전달하고 응답을 클라이언트로 반환
- 네임서버 - 도메인을 IP로 변환
- DNS 설정에 따라… 공유기가 이 역할을 대신 해주기도 함
- IP 라우팅
- 얻어낸 IP 주소를 기반으로 ARP 과정을 거쳐 실제 서버를 찾음
- TCP 구축
- HTTP 통신을 하기 위해
- 3웨이 핸드셰이크 및 SSL 연결
- 성공하면 HTTP Request
- HTTP Response
- 콘텐츠 다운로드(TTFB, Time To First Byte) 및 브라우저 렌더링
짧은버전
- 리다이렉트, 캐싱, DNS, IP 라우팅, TCP연결을 거쳐 TTFB가 시작되고,
이후 컨텐츠를 다운받고 브라우저 렌더링 과정을 거쳐 화면이 나타나게 됩니다.
- 네이버나 구글 정도면 GSLB가 구현되어있다
- CDN을 구축한 경우
- IP주소가 그때그때 달라질 수 있다!
- 접속자의 IP주소를 보고 위치를 파악 후
- Health Check(어느 서버가 살아있나) 후
- 가장 빠른 위치의 CDN 연결