www.google.com을 입력했을 때
👉 www.google.com 입력.
👉 브라우저 >> 캐싱된 DNS 기록을 토대로 IP 주소 확인.
👉 캐시에 없다면? ISP의 DNS 서버 >> DNS query 날림.
(www.google.com을 호스팅하고 있는 서버의 IP 주소를 찾기 위함)
👉 브라우저 >> 서버 TCP connection.
👉 브라우저 >> 서버에 HTTP request.
👉 서버 >> 브라우저의 요청 처리 및 response 생성.
👉 서버 >> 브라우저에 HTTP response.
👉 response 결과를 파싱해 화면에 렌더링.
우리는 주소 하나 입력했을 뿐인데
그 뒤에선 많은 일들이 일어나고 있었다. 너무 좋다.
하나씩 공부해 보자.
1. www.google.com 입력
2. 브라우저 >> 캐싱된 DNS 기록을 토대로 IP 주소 확인.
DNS는 Domain Name System의 약자로 인터넷에 있는
모든 URL들의 이름과 IP 주소를 저장하고 있는 데이터베이스를 뜻한다.
사용자들은 IP 주소를 통해 해당 웹사이트를 호스팅하고 있는
서버 컴퓨터에 접근할 수 있는데
구글 같은 경우 이용자가 많다 보니 여러 개의 IP를 갖고 있고
내가 접속하는 지역에서 접근 가능한 IP를 통해 통신할 수 있게 된다.
이처럼 숫자로 이루어진 IP 주소를 입력해도
원하는 웹사이트에 접속할 수 있는데
숫자를 외워서 이용하기는 복잡하고 어렵다.
이용자는 구글 외에도 네이버, 다음, 카카오 등
수많은 사이트를 이용하는데
모든 접속을 IP를 통해 한다면 헷갈리고 편의성이 떨어질 수밖에 없다.
여기서 우리는 DNS의 가장 큰 목적을 찾을 수 있다.
DNS는 숫자로 된 IP에 이름을 매핑해서
편하게 웹사이트를 이용할 수 있게 해 준다.
다시 돌아가서,
www.google.com처럼 웹사이트의 이름을 브라우저에 입력하면
브라우저는 일단 DNS 기록을 4가지 캐시에서 확인한다.
-
브라우저 캐시
브라우저는 일정 기간 동안 DNS 기록을 저장하고 있는데
DNS query가 이곳에서 가장 먼저 실행된다. -
OS 캐시
systemcall을 통해 OS가 저장하고 있는 DNS 기록의 캐시에 접근한다. -
라우터 캐시
브라우저와 OS 모두 내 컴퓨터의 영역인데 이곳에서 발견하지 못한다면
다음으로 라우터와 통신을 해서 찾기 시작한다. -
ISP 캐시
라우터에서도 찾을 수 없다면 마지막으로 ISP에 접근해 확인한다.
❗ 네트워크상 트래픽 조절과 데이터의 전송 시간을 줄이기 위해서
여러 곳에 캐시를 저장한다.
3. ISP의 DNS 서버 >> DNS query 날림.
DNS query는 다른 DNS 서버들을 검색해서 내가 원하는 사이트의
IP 주소를 찾는 일을 한다.
이러한 작업을 recursive search라고 한다.
DNS 서버들을 오가며 못 찾아서 에러가 발생할 때까지 계속 검색하는데
이때 ISP의 DNS 서버를 DNS recursor라고 부르고
다른 DNS 서버들은 name server라고 부른다.
❗ name server라 부르는 이유는 이 DNS 서버들은
웹사이트의 도메인 이름의 구조에 기반해 검색하기 때문이다.
www.google.com에 대해
DNS recursor(ISP의 DNS)가 root name server로 연락을 하며
root name server는 .com 도메인의 name server로 리다이렉트한다.
또 .com name server는 google.com name server로
리다이렉트를 한다.
이 모든 요청들은 작은 데이터 패킷을 통해 이루어지는데,
패킷 안에는 요청 내용과 DNS recursor의 IP 주소가 포함되어 있다.
❗ 패킷들이 움직이는 것은 Routing Table에 기반하는데
이를 통해 목적지로 가는 가장 빠른 길을 확인하게 된다.
4. 브라우저 >> 서버 TCP Connection.
이제 www.google.com의 IP를 받았다면
해당 서버와 TCP를 사용해 connection 하게 된다.
❗ 일반적으로 웹사이트의 HTTP 요청은 TCP를 사용한다.
❗ TCP Connection의 과정은 TCP/IP Three-way Handshake라는 프로세스를 통해 진행되는데 아래와 같은 절차를 거친다.
- 클라이언트가 SYN 패킷을 서버로 보내고 connection port를 묻는다.
- 서버는 새로운 connection을 할 수 있는 port가 있을 시
SYN/ACK 패킷으로 응답한다. - 클라이언트는 SYN/ACK 패킷을 서버로부터 받으면 잘 받았다고
ACK 패킷을 서버로 보낸다.
5. 브라우저 >> 서버 HTTP Request
TCP로 연결이 완료되면 데이터를 전송한다.
브라우저는 GET 요청을 통해
서버에게 www.google.com의 웹페이지를 요구하는데
필요에 따라 POST 요청을 할 수도 있다.
6. 브라우저의 요청 처리 및 Response 생성
서버들은 아파치, 톰캣, IIS 등의 웹서버를 가지고 있는데
이들은 브라우저로부터의 요청이 오면
Request Handler에게 요청을 전달해서 response를 생성하도록 한다.
Request Handler는 요청, 요청의 헤더, 쿠키를 읽어서
필요하다면 서버에 정보를 업데이트시킨 다음
JSON, XML, HTML 등의 포맷으로 response를 작성하게 된다.
7. 서버 >> 브라우저 HTTP Response
서버는 요청한 웹페이지, status code,
compress type(Content-Encoding), Cache-Control,
쿠키, 개인정보 등의 데이터를 브라우저에게 응답한다.
8. Response 결과를 파싱해 화면에 렌더링
이 부분은 이제 프론트엔드단에서 주로 처리하게 되는데
대략적인 루틴은 아래와 같다.
👉 HTML, CSS 파일 >> 렌더링 엔진의 HTML, CSS 파서에 의해 파싱.
👉 파싱 후 DOM, CSSOM 트리로 변환 후 렌더 트리로 결합.
👉 자바스크립트의 경우 자바스크립트 엔진으로 실행.
❗ 자바스크립트는 렌더링 엔진이 아닌 자바스크립트 엔진이 처리한다.
HTML 파서는 script 태그를 만나면 자바스크립트 코드를 실행하기 위해
DOM 생성 프로세스를 중지하고 자바스크립트 엔진으로 제어 권한을 넘긴다.
제어 권한을 넘겨 받은 자바스크립트 엔진은 script 태그 내의
자바스크립트 코드 또는 script 태그의 src 어트리뷰트에 정의된
자바스크립트 파일을 로드하고 파싱하여 실행한다.
자바스크립트의 실행이 완료되면 다시 HTML 파서로 제어 권한을 넘겨서
브라우저가 중지했던 시점부터 DOM 생성을 재개한다.
❗이와 같은 동기적 처리 방식은 스크립트 태그의 위치에 따라
DOM 생성에 영향을 줄 수 있다.
❗ 자바 스크립트 이슈로 인한 렌더링 지연과
DOM 생성 이전 자바 스크립트의 조작 시도에 의한 오류를 막기 위해
body 요소 가장 아래에 자바 스크립트를 위치시키는 경우가 많다.
