www.google.com을 검색하면 무슨일이 생길까

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

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

위 글을 참고하여 정리해보았습니다.

어느정도 어렴풋이는 네트워크의 흐름을 배웠지만

정확하게 설명을 하기는 좀 부족하다는 생각이 들어 글을 읽어봤어요

 

1. 사용자는 www.google.com을  을 브라우저 주소창에 입력한다.

사용자는 브라우저의 주소창에 url을 입력합니다.

 

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

Domain Name System은 URL들의 이름과 IP 주소를 저장하고 있는 데이터 베이스입니다.

IP주소는 사람이 외우기 힘들다는 문제점이 있기 때문에

이 IP 주소를 사람이 이해하기 쉽게 문자로 표현한 주소를 도메인 네임이라고 합니다.

따라서 이 도메인 네임을 IP 주소로 변환하는 과정이 필요하며

이때 사용할 수 있도록 데이터를 저장하고 있는 데이터베이스를 DNS라고 부릅니다.

 

이 DNS 기록을 찾아볼 때 브라우저는 4가지의 캐시에서 확인을 진행합니다.

1. 가장 먼저 브라우저 캐시를 확인합니다.

2. OS 캐시를 확인합니다. 브라우저는 systemcall을 통해 OS가 저장하고있는 캐시에 접근합니다.

3. router 캐시를 확인합니다. OS까지 뒤졌는데도 캐시가 없으니 router와 통신해서 찾는 것입니다.

4. ISP 캐시를 확인합니다 ISP는 DNS 서버를 구축하고 있고 브라우저가 마지막으로 DNS 기록이 있기를 바라며 접근하게 됩니다.

ISP는 인터넷 서비스 제공자(Internet Service Provider)의 약어입니다.
ISP는 인터넷에 접속할 때 DNS 서버를 제공하거나 직접 운영하는 제공자에요!!

그런데 대부분의 가정집에서는 DHCP로 인터넷 접속을 하고 있습니다.

DHCP는 다음과 같은 프로토콜입니다!

Dynamic Host Configuration Protocol의 약자입니다.
호스트의 IP 주소 및 TCP / IP 설정을 클라이언트에 자동으로 제공하는 프로토콜입니다.
사용자의 PC는 DHCP 서버에서 사용자 자신의 IP주소와
가장 가까운 라우터의 IP 주소
가장 가까운 DNS 서버의 IP 주소를 받습니다.

이후에 ARP 프로토콜을 사용하여 IP 주소를 기반으로 가장 가까운 라우터의 MAC 주소를 알아냅니다.

https://ko.wikipedia.org/wiki/%EC%A3%BC%EC%86%8C_%EA%B2%B0%EC%A0%95_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

주소 결정 프로토콜 - 위키백과, 우리 모두의 백과사전

또 모르겠는 내용이 나오네요

ARP 프로토콜은 무엇일까요?

ARP는 Address Resolution Protocol의 약자로 주소결정프로토콜을 의미합니다.
네트워크 상에서 IP 주소를 물리적 네트워크 주소로 대응 시키기 위해 사용되는 프로토콜입니다.

이러한 ARP 프로토콜은 2계층 주소 MAC 주소와 3계층 IP 주소간에 관계가 없다는 점에서
생기는 문제를 해결하기 위해 사용됩니다.
MAC 주소는 하드웨어 생산업체가 임시적으로 할당한 주소고 NIC에 종속된 주소입니다.
3계층 IP 주소는 DHCP 를 이용해 자동으로 할당 받습니다.

실제 통신은 IP 주소기반으로 일어나고 MAC 주소는 상대방의 주소를 자동으로 알아내어
통신하게 됩니다.

바로 이때 상대방의 MAC 주소를 알아내기 위해 사용되는 프로토콜이 ARP입니다.

맨 윗문단과 맨아랫문단이 사실상 핵심이네요

결국은 .IP주소와 물리주소를 대응시키기 위해

즉 IP주소와 MAC 주소를 대응시키기 위해 사용하는 프로토콜이 ARP라는 것입니다.

NIC는 Network Interface Card를 의미합니다.

 

3.요청한 URL이 캐시에 없으면 ISP의 DNS 서버가 www.google.com을  을 호스팅하고 있는 서버의 IP 주소를 찾기 위해 DNS query를 날립니다.

www.google.com에  에 접속하고 싶으면 IP 주소를 알아야합니다.

DNS query의 목적은 여러 다른 DNS 서버들을 검색해서 해당 사이트의 IP 주소를 찾는 것입니다.

이런 검색을 recursive Search라고 부릅니다.

IP 주소를 찾을 때 까지 DNS 서버에서 다른 DNS 서버를 오가면서 반복적으로 검색하든지

못찾아서 에러가 발생할 때 까지 검색을 진행합니다.

 

이 상황에서 ISP의 DNS 서버를 DNS Recursor라고 부르고 인터넷을 통해

다른 DNS 서버들에게 물어물어 도메인 이름의 올바른 IP 주소를 찾는 책임을 갖고 있다.

다른 DNS 서버들은 naver server라고 부릅니다.

결국 트리구조처럼 root에서 쭉 파고 내려가는 구조인 것 같네요

 

4. Broswer가 서버와 TCP Connection을 합니다.

브라우저가 성공적으로 올바른 IP 주소를 받게되면 서버와 connection을 빌드합니다.

브라우저는 인터넷 프로토콜을 사용해서 서버와 연결이 됩니다.

일반적으로 HTTP 3부터는 UDP이지만 그 이전 버전은 TCP를 채택하기에

TCP를 사용한다고 인식할 수 있습니다.

 

이 때 TCP의 연결 과정 중 하나인 three way hand shake를 통해

클라이언트와 서버는 TCP connection을 연결한다.

 

5. Broswer가 웹 서버에 HTTP 요청을 합니다.

TCP의 연결과정 three way hand shake가 성공하면 브라우저는

웹서버에 HTTP 요청을 보냅니다.

클라이언트의 브라우저는 GET 요청을 통해 서버에게 도메인네임에 맞는

웹페이지를 요구합니다.

요청을 할 때 비밀 자료들을 포함하던지 form 을 제출하는 상황에서는 POST 요청을 할 수도 있습니다.

 

6. 서버가 요청을 처리하고 response를 생성합니다.

서버는 웹 서버를 가지고 있습니다. 이들은 브라우저로부터 요청을 받고

request handler한테 요청을 전달해서 요청을 읽고 response를 생성하게 합니다.

request handler는 ASP.NET , PHP , Ruby 등으로 작성된 프로그램을 의미합니다.
요청과 요청의 헤더, 쿠키를 읽어서 요청이 무엇인지 파악하고 필요하다면
서버에 정보를 업데이트 합니다.

 

7. 서버가 HTTP Response를 보냅니다.

서버의 response를 요청한 웹페이지 , status code , compression type 등

어떻게 인코딩 되어있는지 어떻게 페이지를 캐싱할지 설정할 쿠키가 있다면 쿠키 등을

http response의 형태로 보냅니다.

 

8. Browser 가 HTML Content 를 보여줍니다.

브라우저는 HTML Content를 단계적으로 보여줍니다.

처음에는 HTML의 스켈레톤을 렌더링하고

그다음에는 HTML Tag들을 체크하고 나서 추가적으로 필요한 웹페이지 요소들

(이미지, css , js 파일) 등을 GET 요청합니다.

이 정적인 파일들은 브라우저에 의해 캐싱이 되서 나중에 해당 페이지를 방문 할 때

다시 서버로부터 불러와지지 않도록 합니다.

이 브라우저 렌더링 과정도 굉장히 복잡하지만 

뭔가 많이 간략하게 설명한 것 같아서 지금은

이정도로만 이해를 하고 좀 더 완성시켜서 글을 작성해봐야겠습니다.

---

제 방식대로 말할 수 있게 정리해보겠습니다.

 

사용자가 브라우저에 도메인 네임을 입력하게되면

DNS를 Ip주소로 변환하기 위해 먼저 브라우저는 사용자의 브라우저에

캐싱된 DNS가 있는지 확인합니다. 브라우저에서 찾지 못하면

OS에 System call을 통해 캐싱된 DNS가 있는지 확인하고

그 다음 router에 캐싱된 DNS가 있는지 네트워크 요청을 통해 확인합니다.

그래도 없으면 ISP 캐시를 확인합니다.

만약 캐시가 있으면 캐시를 그대로 사용하고 캐시가 없다면 

서버의 IP 주소를 찾기 위해 DNS query를 날립니다.

 

이 과정을 통해 캐시 혹은 DNS Query 를 이용하여 매칭되는 IP 주소를 얻었다면

IP 주소를 통해 웹서버와 HTTP 통신을 하기 위해

TCP 프로토콜의 three way hand shake를 진행합니다.

단 이 부분에서 HTTP3는 UDP를 채택하고있기때문에 예외가 생길 수 있습니다.

 

three way handshake까지 성공적으로 마쳤다면 HTTP 통신을 시작합니다.

브라우저는 웹서버에게 우리가 검색한 도메인네임에 맞는 웹페이지를

GET 요청을 통해 요구합니다.

 

서버는 브라우저의 GET 요청을 받게되면 GET 요청에 맞는 Response를 준비하게 됩니다.

그리고 서버가 HTTP Response를 브라우저에게 전송하면

 

이제 브라우저는 서버로부터 전달받은 응답내용을 기반으로 웹페이지를 렌더링합니다.

 

참고문헌

https://github.com/WooVictory/Ready-For-Tech-Interview/blob/master/Network/%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90%20naver.com%EC%9D%84%20%EC%B9%98%EB%A9%B4%20%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94%20%EC%9D%BC.md

GitHub - WooVictory/Ready-For-Tech-Interview: 💻 신입 개발자로서 준비를 하기 위해 지식을 정리하는 공간