[Network] 웹 브라우저에 www.google.com / www.naver.com 을 입력했을 때 벌어지는 일들에 대해

"브라우저에 www.naver.com 혹은 www.google.com 입력했을 때,
어떤 일이 벌어지는 지 상세히 설명해주세요"

 

백엔드 신입 면접 질문 중 아주 단골 질문이다.

 

나도 몇 번 받은 질문이지만,

눈으로 슥 읽어보며 공부할 때는 다 알 것 같으면서

막상 면접 때 해당 질문을 받으면 제대로 대답을 하지 못하는 경우가 꽤 있었다.

 

이번 기회에 아주 조져보려고 한다.

 

이전에 작성했던 [Network] OSI 7계층 & TCP/IP 모델에 대한 자세한 설명을 읽고 오면 이해가 더욱 쉬우며,

이번 글은 아래 블로그들의 내용을 기반으로 작성했다.

 

- [번역] Browser에 www.google.com을 검색하면 어떤 일이 일어날까?

- What happens when you type a URL in the browser and press enter?

- 브라우저로 웹 사이트에 접속할 때 과정

- [IT 기술면접 준비자료] 당신이 브라우저로 웹사이트에 접속할 때 일어나는 일들 (부제: DNS 이야기)

- [네트워크]google.com을 입력하면 일어나는 일

- Browser에서 Google.com을 검색하면 무슨 일이 발생하나요?

- IP Address와 MAC Address 개념

 

---

 

3줄 요약

1. 웹 브라우저에 원하는 도메인을 입력한다.

(ex. www.naver.com / www.google.com )

 

2. DNS Server에 해당 도메인에 매핑되는 IP 주소를 요청한다.

 

3. DNS Server로부터 받은 IP 주소로 웹 서버에 접속한다.

 

면접에서 지식을 더 뽐내기 위해 각 단계에 대해 좀 더 깊고 자세하게 알아보자.

 

그 전에, 아래 글을 읽기 위해 알면 좋을 DHCP Server와 DNS Server에 대해 먼저 알아보자.

 

DHCP Server?

출처) https://preamtree.tistory.com/35

 

위 그림처럼,

사용자의 PC는 최초 부팅되면서 DHCP Server로부터

사용자 자신의 IP 주소와 가장 가까운 Router의 IP 주소, 가장 가까운 DNS Server의 IP 주소를 받는다.

 

DHCP Server?

이전에 작성했던 아래 글의 "유동 IP 주소" 부분을 참고하면 된다.
[Network] IP 주소에 대해 - (2) IP 주소 분류, 구분 방법

 

이후 ARP(Address Resolution Protocol)을 이용하여

가장 가까운 라우터의 MAC 주소를 알아내면 외부와 통신할 준비가 완료된다.

 

ARP(Address Resolution Protocol) ?

네트워크 상에서 IP 주소를 물리적 네트워크 주소로 대응시키기 위해 사용되는 프로토콜이다.


IP 주소 vs MAC 주소

IP 주소는 통신기기(PC, 스마트폰 등)에 할당된 식별번호다.
통신기기마다 고유하게 할당되어 있는 것이 아니라,
대부분 통신사에 일정 금액을 지불하고 받아오기 때문에 경우에 따라 바뀐다.

MAC 주소도 통신기기의 식별번호를 나타내지만,
임시적으로 다른 주체에 의해 할당되는 IP 주소와는 다르게 통신기기 하드웨어 자체에 부여된 고유한 식별번호다.

제품의 시리얼 넘버라고 봐도 되며, 세상에 단 하나밖에 없는 유니크한 값을 가지고, 변경이 불가능하다.

 

DNS Server?

이전에 작성했던 IP 관련 글들에서 인터넷이라는 거대한 네트워크 망에 연결된 컴퓨터 혹은 모바일 기기, 웹 서버 등은

택배를 받을 주소처럼 "IP 주소"라는 것이 필요하다고 했었다.

([Network] IP 주소에 대해 - (1) IP 주소란? 글 참고)

 

그렇기 때문에 우리가 접속하려는 사이트(www.google.com)의 웹 서버 IP 주소를 알고 있다면,

해당 IP 주소를 웹 브라우저에 입력하여 구글에 접속이 가능할 것이다.

 

하지만 우리가 모든 웹 서버의 IP 주소를 외우거나 메모하여 필요할 때마다 찾고 접속하는 것은 굉장히 무의미하고 멍청한 짓이다.

 

그래서 IP 주소를 알기 쉬운 문자열로 매핑한 도메인(Domain)이라는 개념이 등장했다.

(여러 도메인을 하나의 IP 주소로 매핑 가능하며, 여러 IP 주소를 하나의 도메인으로도 매핑 가능하다, 후자의 경우 DNS 밸런싱이라고도 부른다)

 

이러한 도메인 정보를 담고 있는 서버가 바로 아래 그림과 같은 DNS Server다.

(DNS == Domain Name System)

 

출처) https://preamtree.tistory.com/35

 

위와 같은 DNS Server는 IP 주소와 도메인의 매핑 정보를 관리하며,

도메인 혹은 IP 주소를 묻는 요청이 오면 응답한다.

 

또한 DNS Server에도 캐시가 존재해서 자주 요청을 받는 정보는 캐시로 관리를 한다.

 

1. 웹 브라우저에 원하는 도메인을 입력한다.

1-1. Browser DNS Cache

PC는 가장 먼저 브라우저 내에 존재하는 Browser DNS Cache라는 공간을 뒤져본다.

 

브라우저 종류마다 공간이 다 다른데,

가장 흔히들 쓰는 크롬의 경우 크롬 브라우저 창에 chrome://net-internals/#dns 라고 입력하면 해당 공간으로 들어갈 수 있다.

 

(하지만 다른 기능은 없고 캐시 비우기만 가능하다, 타 브라우저의 Browser DNS Cache의 경로는 여기 사이트 참고)

 

1-2. OS DNS Cache

만약 Browser DNS Cache에서 못 찾으면, OS에 저장된 DNS Cache를 뒤져본다.

 

hosts라 불리우는 이 OS DNS Cache 파일은

윈도우는 C:\Windows\System32\drivers\etc\hosts에, 맥은 /private/etc/hosts에 위치한다.

 

1-3. Router DNS Server

만약 OS DNS Cache에서도 못 찾으면, Router DNS Server라는 곳에서 조회를 한다.

 

Router에서 DNS 기록을 캐싱하고 있기 때문에 접속하려는 도메인의 IP 주소를 얻어올 수 있는 것이다.

 

1-4. DNS Server

만약 Router DNS Server에도 도메인에 대한 IP 주소가 없다면,

이젠 Root DNS Server부터 조회하며 아래에서 소개할 과정을 통해 IP 주소를 알아내야 한다.

 

2. DNS Server에 해당 도메인에 매핑되는 IP 주소를 요청한다.

접속하려는 도메인에 해당하는 IP 주소를 알아내기 위해 DNS Server에 Recursive Query를 진행한다.

 

최종적으로 DNS Server는 해당 도메인에 매핑되는 웹 서버의 IP 주소를 사용자에게 반환하거나

혹은 찾지 못하는 경우 에러를 발생시킨다.

 

아래 그림을 보면 DNS Server는 계층화되어 있기 때문에

도메인의 최상단인 가장 뒷쪽(.com, .kr 등)을 담당하는 DNS Server는 전세계에 13개 뿐이며,

왜 Recursive라는 단어가 붙는지 이해 가능하다.

 

출처) https://nesoy.github.io/articles/2018-06/What-happens-search-google

 

우리가 접속하고자 하는 도메인을 www.google.com 이라고 가정하고,

위 그림을 기억해두며 어떤 식으로 Query가 진행되는지 보자.

 

DNS Server 질의 과정

(1) 사용자의 PC는 가장 먼저 지정된 DNS Server에 DNS Query를 송신한다.

(우리나라의 경우 통신사 별로 지정된 DNS Server가 존재)

 

이때, 이 지정된 DNS Server를 DNS Recursor라고 부른다.

단어 뜻처럼 Recursive Query를 수행하는 녀석이다.

 

(2) 지정된 DNS Server는 Root Name Server에 www.google.com 을 질의하는데,

이때 Root Name Server라는 녀석은

'나는 걔 IP 주소같은 건 모르겠고, .com Name Server IP 주소는 알아, 걔 주소 줄게'

하면서 .com Name Server IP 주소를 넘겨준다.

 

(3) 그럼 PC는 다시 .com Name Server에 www.google.com 을 질의하는데,

이때 .com Name Server라는 녀석은 또,

'아, 나도 걔 IP 주소같은 건 모르겠고, google.com Name Server IP 주소는 아니까, 걔 주소 줄게'

하면서 google.com Name Server IP 주소를 넘겨준다.

 

(4) 마지막으로 PC는 google.com Name Server에 www.google.com 을 질의하는데,

드디어 우리가 원하는 구글의 IP 주소를 받을 수 있다.

 

3. DNS Server로부터 받은 IP 주소로 웹 서버에 접속한다.

DNS Server로부터 웹 서버의 IP 주소를 받았다고 끝난 것이 아니다.

웹 사이트를 브라우저에 띄울 수 있도록 이미지 파일, CSS 등과 같은 컨텐츠를 웹 서버로부터 받아야 한다.

 

그럼 어떻게 정보를 받아올까?

 

HTTP Request를 통해 요청을 하고

HTTP Response를 통해 받아오면 된다.

 

HTTP Request는 그럼 어떻게 이루어질까?

 

인터넷 프로토콜을 사용해서 해당 웹 서버와 연결을 해야 한다.

 

3-1. Browser와 웹 서버 간의 Connection

인터넷 프로토콜은 여러 종류가 있지만,

웹 사이트의 HTTP 요청의 경우 일반적으로 TCP를 사용한다.

 

TCP Connection을 위해 TCP Socket을 개방하고,

TCP 3 Way-Handshake라는 일종의 연결 검증 절차를 무사히 성공해야

데이터를 주고 받을 준비가 끝난다.

 

TCP 3 Way-Handshake?

본격적으로 통신을 하기 전,
Client와 Server가 잘 연결이 되었는지 확인하는 과정이다.

이름처럼 아래와 같은 3단계의 인증 과정을 거친다.

(1) Client -> Server : TCP SYN 패킷을 서버에 보내 connection 요청
(2) Server -> Client : TCP SYN ACK으로 응답
(3) Client -> Server : TCP ACK 패킷을 보냄

(SYN == Synchronize Sequence Numbers, ACK == Acknowledgement)

 

출처) https://nesoy.github.io/articles/2018-06/What-happens-search-google

 

3-2. Browser가 웹 서버에 HTTP Request

TCP로 웹 서버와 무사히 연결이 되었으니,

TCP Socket을 통해 HTTP Request(GET 요청)를 전송한다.

 

요청 시에 비밀 자료를 포함할 수도 있고,

form을 제출하는 경우에는 POST 요청도 사용될 수 있다.

 

또한, 아래와 같은 다른 부가적인 정보들도 함께 전달이 된다.

 

- Browser Identification (User-Agent Header)

- 수신할 Request의 종류 (Accept Header)

- 추가적인 Request를 위해 TCP Connection 유지를 요청하는 Connection Header

- Browser에서 얻은 Cookie 정보

- etc.

 

아래 사진은 GET Request의 샘플 본이며, 노란색 부분이 Header이다.

출처) https://devjin-blog.com/what-happen-browser-search/

 

3-3. 웹 서버의 Request 처리 및 Response 생성

웹 서버는 Browser로부터 받은 HTTP Request를 Request Handler에게 전달하여

Request 내용을 읽고 Response를 생성하게 한다.

 

Request Handler란,

ASP.NET, PHP, Ruby 등으로 작성된 프로그램을 의미하며,

Request와 Request의 Header, Cookie를 읽어서 Request가 무엇인지 파악하고,

필요하다면 웹 서버에 정보를 업데이트 하기도 한다.

 

그 후, HTTP Response를 JSON, XML, HTML 등의 특정 포맷으로 작성한다.

 

3-4. 웹 서버의 HTTP Response 전송

HTTP Response에는 아래 정보가 포함된다.

 

- Browser가 요청한 웹 페이지

- Status Code(현재 Response의 상태)

- Compression Type(Content-Encoding, 인코딩 방식)

- Cache-Control(페이지 캐싱 방법)

- (설정할 Cookie가 있다면) Cookie

- 개인 정보

- etc.

 

아래 사진은 HTTP Response의 샘플 본이다.

출처) https://devjin-blog.com/what-happen-browser-search/

 

첫 줄은 Status Code를 의미하는데, 총 5가지의 종류가 존재한다.

 

- 1xx : 정보만 담긴 메세지

- 2xx : 성공적인 Response

- 3xx : Client를 다른 URL로 Redirect

- 4xx : Client 측 에러 발생

- 5xx : Server 측 에러 발생

 

3-5. Browser의 HTML Content Rendering

Browser는 HTML Content를 단계적으로 보여주는데,

 

(1) HTML의 Skeleton(기본 틀)을 Rendering한다.

 

(2) HTML Tag들을 체크 후, 추가적으로 필요한 Image, CSS, JS 파일 등과 같은 웹 페이지 요소들을 GET으로 요청한다.

정적 컨텐츠들은 Browser에 의해 캐싱이 되어 나중에 해당 페이지를 재방문했을 때,

다시 서버로부터 불러오는 등의 과정이 생략되어 웹 페이지가 띄워지는 속도가 빨라진다

 

(3) 드디어 우리가 원했던 구글의 모습을 볼 수 있다.

 

---

 

쓰다 보니 글이 엄청 길어졌지만, 이 모든 과정들이 1초도 되지 않아 끝난다.

 

 

끝!