URL에 tistory.com을 입력하여 응답이 오기까지의 과정 정리

개발자는 과정을 이해하는 사람이기에 어디에서 문제가 생겨서, 어디를 고쳐야 할지를 알아야 한다.

갑자기 페이지가 안켜지면, 어디에서부터 문제가 생긴건지 역추적을 해낼 줄 알아야 한다. 

오늘은 URL을 입력했을 때, 요청이 가서 응답이 오기까지 어떤 과정이 있는지를 알아보고자 한다.

 

요약은 이렇다. 

리다이렉트, 캐싱, DNS, IP라우팅, TCP 연결 구축을 거쳐 요청, 응답이 일어나는 TTFB(Time to First Byte)가 시작되고 이후 컨텐츠를 다운받게 되고 브라우저 렌더링 과정을 거쳐 화면이 표시된다.

 

1. 리다이렉트

리다이렉트가 있다면 리다이렉트를 진행하고 없다면 그대로 해당 요청에 대한 과정이 진행된다.

 

2.캐싱

해당 요청이 캐싱이 가능한지 가능하지 않은지를 파악한다. 캐싱이 이미 된 요청이라면 캐싱된 값을 반환하며 캐싱이 되지 않은 새로운 요청이라면 그 다음단계로 넘어간다. 캐싱은 요청된 값의 결과값을 저장하고 그 값을 다시 요청하면 다시 제공하는 기술이다. 이는 브라우저 캐시와 공유 캐시로 나눠진다.

 

2-1. 브라우저 캐시

쿠키, 로컬스토리지 등을 포함한 캐시이며, 개인 캐시라고도 한다.

브라우저 자체가 사용자가 HTTP를 통해 다운로드 하는 모든 문서를 보유하는 것을 말한다.

 

2-2. 공유 캐시

클라이언트와 서버 사이에 있으며 사용자 간에 공유할 수 있는 응답을 저장 할 수 있다.

대표적인 예로 요청한 서버 앞단에 프록시서버가 캐싱을 하는 것을 말한다. 이를 리버스 프록시를 둬서 내부 서버로 포워드한다고도 말한다.

예시로, 보통 Node.js 서버를 만든다면,  Ngmx라는 캐싱 할 수 있는 프록시 서버를 만든다.

공유캐시는 서버 요청을 줄인다.

 

만약에 캐시가 없다면 사용자가 요청 할 때마다 오리진 서버에 요청이 간다.

캐시를 사용하면 서버에 대한 요청을 줄일 수 있다.

 

3. DNS

계층적인 도메인 구조와 분산된 데이터베이스를 이용한 시스템으로 FQDN 을 인터넷 프로토콜인 IP로 바꿔주는 시스템이다. 이는 DNS 관련 요청을 네임서버로 전달하고 해당 응답값을 클라이언트에게 전달하는 리졸버, 도메인을 IP로 변환하는 네임서버 등으로 이루어져 있다.

 

FQDN이란 호스트와 도메인이 합쳐진 완전한 도메인 이름을 말한다.

www는 호스트, tistory.com은 도메인이다.

 

www.tistory.com 에 DNS 쿼리가 오면 오른쪽부터 역순으로 ROOT DNS, .com DNS, .tistoryDNS, www DNS 과정을 거쳐 완벽한 주소를 찾아 IP 주소를 매핑한다.

 

DNS도 캐싱 서버가 있다.

미리 해당 도메인 이름을 요청했다면 로컬PC에 자동적으로 저장되며, 브라우저캐싱과 OS캐싱이 있다.

 

4. IP 라우팅

IP를 기반으로 라우팅, ARP 과정을 거쳐 실제  서버를 찾아간다.

 

5. TCP 연결 구축

브라우저가 TCP 3웨이 - 핸드셰이 및 SSL 연결등을 통해 연결을 설정한다.

이후 요청을 보낸 후 해당 요청한 서버로부터 응답을 받는다.

 

6. 콘텐츠 다운로드

요청한 컨텐츠를 서버로부터의 다운받는다.

 

7. 브라우저렌더링

받은 데이터를 바탕으로 브라우저 엔진이 브라우저 렌더링 과정을 거쳐 화면을 만든다.