검색창에 www.google.com 을 검색했을 때

이번 포스팅에서는 검색창에 google.com 을 입력했을 때 내부적으로 어떤 일이 벌어지는지 알아보도록 하겠습니다. 

 

이 내용이 면접 단골질문이라고 하더라고요. 알아두시면 잘 써먹을 수 있을 것 같습니다. 특히 OSI 7계층 / TCP 4계층과 엮어서 잘 물어본다고하니 해당 개념에 대해서도 잘 알아두시면 좋을 것 같습니다. OSI 7계층에 대해서는 아래의 링크에서 확인해보세요!

 

https://coding-review.tistory.com/298

OSI 7 계층, TCP / IP 4 계층

 

자 그럼 시작해보도록 하겠습니다. 

 

google.com을 검색하면 생기는 일

1. 브라우저에 google.com을 검색한다

 

2. 브라우저는 DNS 캐시 저장소에서 google.com에 대응되는 IP 주소를 찾는다.

DNS에 대한 포스팅은 아직 하지 않았지만 간단하게 설명하자면 DNS는 특정한 IP 주소와 연결된 URL에대한 정보를 저장하고 있는 데이터베이스입니다. TCP 4계층인 애플리케이션 계층에 해당하기도합니다. 

 

모든 URL은 그에 상응하는 IP 주소를 가지고 있지요. 예를 들어서 google.com의 IP주소는 209.85.227.104입니다. 즉 우리가 원한다면 google.com을 검색하는것 대신에 http://209.85.227.104를 검색해도 똑같이 구글로 들어가집니다. 

 

DNS의 주된 목적은 유저 친화적으로 제공해주는 네비게이션같은 역할입니다. 우리는 DNS를 이용해서 좀 더 쉽게 올바른 IP주소에 접근할 수 있습니다. 뭐 생각해봐도 위에 있는 저 숫자들을 외우는 것보다 google.com을 외우는게 더 쉬우니까요. 

 

브라우저는 이 DNS에 저장된 IP주소를 찾기위해 네가지 캐시를 뒤져봅니다. 

 

1. 첫번째로 브라우저 캐시를 뒤져봅니다. 브라우저는 우리가 이전에 방문했던 웹사이트를 일정 기간동안 DNS 저장소에 저장하고 있습니다. 그래서 첫번째 탐색은 DNS 쿼리를 날려보는 것이죠. 
2. 두번째로 브라우저는 OS 캐시를 뒤져봅니다. 만약 브라우저 캐시에 존재하지 않는다면 브라우저는 우리 컴퓨터에 잠들고있는 OS에 레코드를 가져오기 위해 시스템 콜을 날립니다. 왜냐하면 OS에서도 DNS 레코드에 대한 캐시를 저장하고 있거든요. 
3. 세번째로 라우터 캐시를 체크해봅니다. 우리 컴퓨터 내부(OS)에도 없으면 브라우저는 고유의 DNS레코드를 캐싱하고 있는 라우터와 연결을 시도합니다. 
4. 네번재로 ISP 캐시를 체크합니다. 앞에 모든 캐싱을 했음에도 존재하지 않으면 ISP 캐시로 이동하게 되는데 ISP는 DNS의 고유 서버를 가지고 있습니다. 그리고 ISP는 DNS 레코드에 대한 캐시를 가지고 있죠. 

 

왜 이렇게 많은 캐시를 뒤져보는지 조금 이해가 안되실겁니다. 사실 프라이버시적으로 썩 좋은 유저 경험은 아닙니다. 하지만 그럼에도 이렇게 많은 캐시를 브라우저가 뒤져보는 이유는 유저들은 프라이버시보다도 응답속도에 더 예민하기 때문에 더 나은 응답속도를 위해 캐싱한다고 보시면 될 것 같습니다. 

 

 

3. 만약 요청된 URL이 캐시에 없으면 ISP의 DNS서버는 google.com을 호스팅하고 있는 서버의 IP주소를 찾기 위해 DNS쿼리를 날린다

우리의 컴퓨터는 google.com을 호스팅하고 있는 서버와 연결하기위해 google.com 의 IP주소가 필요합니다. DNS 쿼리의 목적은 우베사이트에 대한 올바른 IP주소를 찾기까지 인터넷에서 여러 DNS서버를 탐색하는 것입니다. 

 

이러한 형태의 탐색은 순환탐색이라고 부르는데 그 이유는 탐색이 DNS서버와 DNS서버를 우리가 원하는 IP주소를 찾을때까지 빙글빙글 돌면서 탐색하기 때문입니다. 

 

이러한 상황속에서 DNS recursor라고 부르는 이놈은 응답을 위해 인터넷에 대한 다른 DNS서버에 물어봄으로써 도메인 이름을 포함하고 있는 적절한 IP주소를 찾는 책임이 있습니다. 

 

더 나은 이해를 위해 다이어그램을 가져와봤습니다. 

 

https://webhostinggeeks.com/guides/dns/

 

많은 웹사이트의 URL들이 세가지 레벨을 가지고 있는데 각각의 레벨은 그들만의 고유 네임서버를 가지고 있습니다. 

 

google.com의 경우 첫번째로 DNS recursor가 루트 네임서버에 연결합니다. 루트 네임서버는 .com 도메인 네임 서버로 리다이렉트합니다. 

 

.com 네임서버는 또 다시 google.com에 리다이렉트합니다. 그리고 google.com에 매칭하는 IP 주소를 웹브라우저에게 리턴해줍니다. 

 

이러한 요청은 IP 주소나 요청에의한 컨텐츠와같은 정보들을 담고있는 작은 데이터 패킷을 사용해서 전달됩니다. 

 

이러한 패킷들은 클라이언트와 서버사이를 올바른 DNS서버에 도착할 때까지 여러 네트워크 장비들을 돌아다닙니다. 그리고 이러한 장비들은 이 데이터들의 목적지에 도착하기위해 패킷들을 가장빠른 방법으로 찾기 위해 라우터 테이블을 이용합니다. 

 

만약 이 패킷을 도중 잃어버리게 되면 우리는 failed error를 만나게 됩니다. 그렇지 않으면 우리는 올바른 DNS서버에 도달할 수 있고 올바른 IP주소를 가지고 브라우저로 돌아올 수 있습니다. 

 

 

4. 브라우저가 서버와 TCP 통신을 시작한다. 

여기서 TCP 4계층인 전송계층이 등장하는데요. 브라우저가 올바른 IP 주소를 받았을 때 정보를 전송하기위해 IP주소와 일치하는 서버와 통신을 시작합니다. 

 

브라우저는 인터넷 프로토콜을 사용해서 연결을 구축하는데 여기에는 몇몇개의 다른 인터넷 프로토콜이 사용되기도합니다만 HTTP요청을 위해 사용되는 TCP가 가장 일반적입니다. 

 

우리의 컴퓨터와 서버 사이에서 데이터 패킷을 전송하기위해 TCP 연결이 필수적으로 수립되어야합니다. 이 연결은 흔히 TCP 3 way handshaking 이라고 불리기도 하는데, 이 부분에 대해서도 아직 포스팅 하지 않았지만 간단하게 설명해드리자면 

 

1. 클라이언트는 난수인 SYN 패킷을 서버에 보냅니다. 
2. 만약 서버에 새로운 연결을 시작하고 수용할 수 있는 포트가 열려있다면, Acknowledment의 앞글자 세개인 ACK 패킷을 만들어서 SYN/ACK 패킷을 보냅니다. 
3. 클라이언트는 SYN/ACK 패킷을 서버로부터 받고 ACK 패킷을 서버에 보냅니다. 

 

SYN 패킷은 무엇의 줄임말인지 모르겠지만 ACK패킷은 "알겠다" 정도로 해석하시면 됩니다. 아마 Synchronize의 약자가 아닐까 조심스럽게 추측해보겠습니다. 

 

자 이제 TCP 통신이 연결되었습니다. 

 

 

5. 브라우저는 웹브라우저에 HTTP 요청을 보낸다. 

TCP 연결이 수립되었을 대 드디어 데이터를 주고받기 시작합니다. 브라우저는 google.com에 필요한 GET 요청을 보냅니다. 

 

TCP 연결이 수립되고 나면 SSL handshake (요즘은 TLS handshake라고 하네요) 를 마치고 인증서를 가지고 해당 인증기관이 신뢰할 수 있는지 공개키와 개인키를 가지고 확인합니다. 

 

그 이후 이 요청에는 추가적인 정보들을 가지고 있는데 예를 들어서 브라우저의 인증서 (User-Agent header), 수용할 수 있는 요청에 대한 정보들 (Accept header), 그리고 추가적인 요청을 위한 TCP 연결을 유지할 것인지에 대한 요청들이 있습니다. 

 

실제로 GET 요청을 날리게 되었을 때 패킷을 한번 보여드리겠습니다. 

 

 

 

6. 서버는 요청과 돌아오는 응답을 핸들링한다

서버는 Apache나 IIS와 같은 브라우저로부터 요청을 받을 수 있는 웹서버를 가지고 있습니다. 그리고 이러한 서버는 응답을 읽고 생성하기위한 request handler를 보냅니다. 

 

이 request handler는 ASP.NET이나 PHP, Ruby와 같은 프로그램인데 이 프로그램들은 쵸엉이 어떤 것인지 체크하기위한 쿠키와 헤더들을 읽을 수 있습니다. 

 

그러고 나면 웹서버는 응답을 특정한 포맷인 JSON이나 XML혹은 HTML의 형태로 응답을 만들어 재조립합니다. 

 

 

7. 서버는 HTTP응답을 보낸다.

서버 응답은 상태코드나 Encoding에 대한 정보, 페이지를 어떻게 캐싱할건지, 쿠키를 세팅할건지 프라이버시에 대한 정보 등등 우리의 요청에대한 웹페이지를 갖고있습니다. 

 

예를 들어 HTTP 서버 응답은 다음과 같습니다. 

 

 

 

만약 우리가 위의 응답을 받았다면 첫번째로 보이는 것은 상태코드입니다. 이 상태코드는 꽤 중요한데 우리가 응답을 잘 보냈나 에러가 났나를 확인하는 중요한 지표가 됩니다. 상태코드에는 다섯가지 종류가 있는데 한번 짚고 넘어가도록 하겠습니다. 

 

• 1xx : 정보에 해당하는 메시지만 지시하고 있음
• 2xx : 성공
• 3xx : 다른 URL로 리다이렉트됨
• 4xx : 클라이언트 측 오류
• 5xx : 서버 측 오류

 

 

8. 브라우저는 HTML 문서를 보여줌

브라우저가 HTML 문서를 페이지에 보여주는 단계입니다. 첫번째로 HTML의 뼈대에 해당하는 몸체를 렌더링하고 그 다음 HTML 태그와 이미지나, CSS stylesheet, JavaScript 파일과 같은 GET요청을 체크합니다. 

 

이러한 정정 파일들은 브라우저에의해 캐싱됩니다. 이렇게 캐싱되면 다음에 다시 방문했을 때 다시 서버에서 이 데이터들을 가져오지 않아도 되기 때문에 굉장히 빠른 속도를 체감할 수 있습니다. 

 

 

 

자 여기까지 검색창에 google.com을 검색했을 때 일어나는 일에 대해서 알아봤습니다. 이게 면접 단골 질문이라고는 알고 있었지만 따로 공부는 안해봤는데 이번 기회에 아주 제대로 공부한 것 같습니다. 

 

시간이 많이 없으신 분들을 위해 빠르게 정리해드리겠습니다. 

 

"google.com을 검색하면 브라우저는 DNS 캐시 레코드에서 URL과 상응하는 IP 주소를 찾습니다. 만약 요청된 URL이 캐시에 없으면 ISP의 DNS서버는 google.com을 호스팅하고 있는 서버의 IP 주소를 찾기위한 DNS쿼리를 날립니다. 그리고 그 후 브라우저는 서버와 TCP 연결을 시작합니다. 연결이 끝난 후 브라우저는 HTTP 요청을 보내고 서버는 요청과 돌아오는 응답을 핸들링합니다. 웹 서버는 HTTP응답을 보내고 브라우저는 HTML문서 결과를 보여줍니다."

 

이렇게 대답함과 동시에 TCP 4계층과 같이 엮어서 대답하시면 좋을 것 같습니다. OSI 7계층 / TCP 4계층에 대한 내용은 아래 링크에서 확인해주세요!

 

https://coding-review.tistory.com/298

OSI 7 계층, TCP / IP 4 계층

 

그럼 여기서 포스팅 마치도록 하겠습니다. 긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요~

 

 

출처

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

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

https://www.quora.com/If-DNS-is-a-layer-7-service-How-does-layer-3-find-out-the-IP-address

If DNS is a layer 7 service? How does layer 3 find out the IP address?