브라우저에서 네이버를 검색하고 화면이 출력 될 때 까지 내부적인 동작 (DNS 작동)

1. 웹 브라우저 주소창에 www.naver.com을 친다.

2. Browser는 캐싱된 DNS 기록들을 통해 www.naver.com에 대응되는 IP주소가 있는지 확인한다.

DNS(Domain Name System)은 URL들의 이름과 IP주소를 저장하고 있는 데이터 베이스이다. 인터넷에 있는 모든 URL들에는 고유 IP 주소가 지정되어있다. 이 IP 주소를 통해서 해당 웹사이트를 호스팅하고 있는 서버 컴퓨터에 접근을 할 수 있다. 예를 들어 www.naver.com의 IP주소를 알아보기 위해서는 터미널에 nslookup www.naver.com을 입력하면 해당 사이트의 IP주소를 알 수 있다. 현재 내가 있는 지역에서 해당 명령어를 작성하였을 때 다음과 같이 IP주소가 223.130.195.95로 나왔고 해당 IP주소로 브라우저에 검색했을때 www.naver.com으로 이동한것을 확인 할 수 있다.

(터미널에 nslookup www.naver.com을 입력한 결과. 여기서, Non-autoritative answer란, Name 서버가 도메인에서 만든 원본 소스 파일을 갖고 있지 않다는 뜻이다. 이 서버에는 다른 DNS들에서 얻어진 도메인 파일을 캐싱 형태로 갖고있다.)

Naver를 사용하는 사용자가 매우 많기 때문에 네이버의 서버 IP주소는 여러개가 있고 nslookup으로는 그 중 내가 접근이 가능한 IP주소를 보여주는 것이다. 이처럼 DNS는 전호번호부와 비슷한 역할을 한다. 웹사이트의 이름들과 웹사이트를 접근하기 위해 필요한 IP주소를 저장하고 있다.

 

* DNS의 가장 큰 목적

숫자로 된 IP주소를 작성해도 원하는 웹사이트에 접속할 수 있지만, 매번 랜덤해보이는 숫자들을 검색하는 것은 매우 복잡한 일이다. 네이버, 다음, 구글 처럼 이름을 외오는 것이 더 편하기 때문이다. DNS는 이처럼 사람들의 웹사이트 주소에 쉽게 접속할 수 있게 매핑을 해주는 역할을 한다.

 

* 웹사이트 이름을 브라우저에 검색하면 브라우저는 DNS 기록을 4개의 캐시를 순차적으로 확인한다.

1.  가장 먼저 브라우저 캐시를 확인한다. 브라우저는 일정기간 동안(유저가 이전에 설정한)의 DNS 기록들을 저장하고 있다. DNS Query가 이곳에서 가장 먼저 실행이 된다.
2. 그 다음 브라우저는 OS 캐시를 확인한다. 브라우저 캐시에 웹사이트 이름의 IP주소가 발견되지 않았다면, 브라우저는 System Call을 통해서 OS가 저장하고 있는 DNS 기록들의 캐시에 접근한다.
3. Router 캐시를 확인한다. 
4. 마지막으로 ISP(통신사)캐시를 확인한다. ISP는 DNS 서버를 구축하고 있고 브라우저가 마지막으로 DNS 기록이 있기를 확인하기 위해 접근하게 된다. 이렇게 여러곳에 캐시를 저장하는 이유는 캐시가 네트워크 트래픽을 조절하고 데이터 전송시간을 줄이기 위해 매우 중요한 요소이기 때문이다.

 

3. 요청한 URL이 캐시에 없으면, ISP의 DNS서버가 www.naver.com을 호스팅하고 있는 서버의 IP주소를 찾기위해 DNS Query요청을 보낸다

DNS Qeury의 목적은 여러 다른 DNS 서버들을 검색해서 해당 사이트의 IP주소를 찾는 것이다. 이러한 검색을 Recursive Search라 부른다. IP주소를 찾을 때 까지 DNS 서버에서 다른 DNS 서버를 오가면서 반복적으로 검색하던고 만약 못찾게 된다면 오류를 전송한다. 이 상황에서, ISP의 DNS 서버를 DNS Recursor라고 부르고 인터넷을 통해 다른 DNS 서버에게 물어 도메인 이름의 올바른 IP 주소를 계속 찾는다. 이 때 다른 DNS 서버들을 Name Server라 부른다. 이들은 웹 사이트 도메인 이름의 구조에 기반하여 검색을 하기 때문이다.

 

여기서 도메인 구조에 기반한다는 것이란, 우리가 마주하는 웹 사이트 URL들은 Third-level domains, Second-level domains, Top-level domains를 가지고 있다. 각 레벨별로 자신들만의 Name 서버가 있고 여기서 DNS lookup 프로세스 중에 쿼리가 진행된다. www.naver.com에 대해서, 처음에 DNS Recursor가 Root Name 서버에 연락을 한다. Root Name 서버는 .com domain Name 서버로 다이렉트한다. .com Name 서버는 naver.com Name 서버로 리다이렉트 한다. naver.com에 매칭되는 IP주소를 찾고 DNS Recursor로 보내게 된다.

도메인 구조 (https://webhostinggeeks.com/guides/dns/)

 

이 모든 요청들은 작은 데이터 패킷들을 통해서 보내진다. 패킷 안에는 보내느 요청의 내용과 DNS recursor의 IP 주소가 포함되어 있다. 이 패킷들은 원하는 DNS 기록을 가진 DNS 서버에 도달할 때 까지 클라이언트와 서버를 여러번 오간다. 패킷들이 움직이는 것도 Routing table에 기반한다. Routing table을 통해서 어떤 길로 가야 빠른지 확인 할 수 있다. 만약 패킷이 도중에 loss되면 request fail error가 발생하게 된다.

 

4. Browser가 서버와 TCP connection을 한다.

브라우저가 올바른 IP주소를 받게되면 서버와 connection을 빌드하게 된다. 브라우저는 인터넷 프로토콜을 사용해서 서버와 연결이 된다. 인터넷 프로토콜의 종류는 여러가지가 있지만, 웹사이트의 HTTP 요청의 경우에는 일반적으로 TCP를 사용한다.

 

클라이언트와 서버간 데이터 패킷들이 오가려면 TCP connection이 되어야 한다. TCP/IP three-way handsahke라는 프로세서를 통해서 클라이언트와 서버간 connection이 이뤄지게 된다. 단어 그대로 클라이언트와 서버가 SYN과 ACK메세지들을 가지고 3번의 프로레스를 거친 후에 연결이 된다

• 클라이언트 머신이 SYN 패킷을 보내고 connection을 열어달라 물어본다.
• 서버가 새로운 connection을 시작할 수 있는 포트가 있다면 SYN/ACK 패킷으로 대답을 한다.
• 클라이언트는 SYN/ACK 패킷을 서버로부터 받으면 서버에서 ACK 패킷을 보낸다.

이 과정이 끝나면 TCP connection이 완선되는 것이다.

 

5. Browser가 웹 서버에 HTTP 요청을 한다.

TCP로 연결이 되었다면, 데이터를 전송하면 된다. 클라이언트의 브라우저는 GET요청을 통해 서버에서 www.naver.com 웹페이지를 요구한다. 요청을 할 때 비밀 자료들을 포함하던지, form을 제출하는 상황에서는 POST 요청을 사용할 수도 있다. 이 요청을 할 때 다른 부가적인 정보들도 함께 전달이 된다.

• browser identification(User-Agent 헤더)
• 받아들일 요청의 종류(Accept 헤더)
• 추가적인 요청을 위해 TCP connection 유지를 요청하는 connection 헤더
• 브라우저에서 얻은 쿠키 정보
• 기타 등등

< www.naver.com GET 요청 >
:authority: www.naver.com
:method: GET
:path: /
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
accept-encoding: gzip, deflate, br
accept-language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
cache-control: max-age=0
cookie: NNB=RGFESFGBUFLGE; NDARK=Y; _fbp=fb.1.1659795270779.1858704414;

 

6. 서버가 요청을 처리하고 Response를 생성한다.

서버는 웹서버를 가지고 있다. 이들은 브라우저로부터 요청을 받고 request handler한테 요청을 전달하여 요청을 읽고 response를 생성하게 한다. Request handler란 ASP.NET, PHP, Ruby 등으로 작성된 프로그램을 의미한다. 이 request handler는 요청과 요청의 헤더, 쿠키를 읽어서 요청이 무엇인지 파악하고 필요하다면 서버에 정보를 업데이트 한다. 그 다음에 response를 특정한 포맥(JSON, XML, HTML)작성한다.

 

7.  서버가 HTTP Response를 보낸다

서버의 response에는 요청한 웹페이지, status code, compression type(Content-Encoding), 코딩방식, 캐싱방식 쿠키, 개인정보 등이 포함된다.

< www.naver.com GET 요청에 대한 응답 >
ache-control: no-cache, no-store, must-revalidate
content-encoding: gzip
content-type: text/html; charset=UTF-8
date: Wed, 28 Sep 2022 17:04:13 GMT
p3p: CP="CAO DSP CURa ADMa TAIa PSAa OUR LAW STP PHY ONL UNI PUR FIN COM NAV INT DEM STA PRE"
pragma: no-cache
referrer-policy: unsafe-url
server: NWS
strict-transport-security: max-age=63072000; includeSubdomains
x-frame-options: DENY
x-xss-protection: 1; mode=block

 

8. Browser가 HTML content를 보여준다.

브라우저는 HTML content를 단계적으로 보여준다. 처음에는 HTML의 스켈레톤(기본 틀)을 렌더링한다. 그 다음에는는 HTML tag들을 체크하고 나서 추가적으로 필요한 웹페이지 요소들을(이미지, CSS 스타일시트, Javascript 파일, 등) GET으로 요청한다. 이 정적인 파일들은 브라우저에 의해 캐싱이 되서 나중에 해당 페이지를 방문할 때 다시 서버로부터 불러와지지 않도록 한다. 그 다음에는 그토록 원했던 www.naver.com의 모습이 보이게 된다.

 

 

참조.

https://medium.com/@maneesha.wijesinghe1/what-happens-when-you-type-an-url-in-the-browser-and-press-enter-bb0aa2449c1a