• 브라우저에 google.com을 검색하면 무슨 일이 생기나요? (What happens when you type google.com into browser )

    2021. 3. 26.

    by. KimBangg

    본글은 아래의 링크에서 작성된 글을 번역한 글입니다.

    dev.to/antonfrattaroli/what-happens-when-you-type-googlecom-into-a-browser-and-press-enter-39g8

     

    What happens when you type 'google.com' into a browser and press Enter?

    My most favorite interview question ever.

    dev.to

    Intro

    지난 세월동안 제가 인터뷰에서 가장 즐겨했었던 인터뷰 질문은 구글을 브라우저에 검색하면 무슨 일이 일어나는지 아시나요? 였습니다.

    누군가는 이 질문에 대해서 엄청나게 많은 이야기를 할 수는 있겠지만  과연 얼마나 깊게 이 문제를 이해하고 대답 할 수 있을까요? 

    오늘은 제가 생각하는 대답을 이 곳에서 이야기 하려고 합니다. 

     

     

    그래서 무슨 일이 일어나는데 ( So what happens )?

    첫 번째로 브라우저는 주어진 입력 값을 분석합니다. 만약 ".com"이 입력 값안에 포함 되어있다면, 검색을 위해 입력했다고 생각 하지 않을 것입니다. 그렇다는건 이러한 입력값이 URL 이라는 것이기 때문에,  http://가 없다면 URL 앞 쪽에 추가해줍니다. 뿐만 아니라, HTTP protocol 같은 값들이 URL을 통해 넘어 오지 않았다면, 브라우저는 80번 Port & Get Method 와 같은 기본 값들 또는 없음으로 이를 추정하고 처리합니다.

     

    그 다음 브라우저는 HTPP Requset를  구글에게 전송합니다. 전송받은 Requesst를 바탕으로 "google.com" 에 대한 DNS 조회는 수행이 될 것이고, google.com은 자신만의 고유한 ip 주소를 가지고 있지 않기 때문에  아직 캐시화 되지 않은 DNS 서비스가 IP 주소 목록으로 응답합니다.

    브라우저는 제가(=필자) 믿기로는 기본적으로 가장 첫 번째로 온 값을 채택하는데, 그것이 지역적인지 또는 어떻게 그것이 작동하는지 모르고 그 곳에 존재한다는 사실 만을 알고 있습니다. 그래서 HTTP requset는 노드와 노드 사이를 google.com's load balancer의 IP 주소를 얻을 때까지 지나다닙니다. 이 후 비교적 짧은 시간 내에 구글은 당신이 HTTPS를 사용해야 한다고 응답 할 것이고, 301 영구 리디렉션을 사용한다고 가정합니다. 그리하여 이러한 응답 값은 사용자의 브라우저로 되돌아가고, 그러한 응답을 받은 브라우저가 가지고 있던 schem을 HTTPS로 변경하고 기본 포트를 442을 바꾼 후에 응답을 합니다.

     

    TLS가 핸드쉐이킹 하는 이러한 시간은 로드 밸런서와 브라우저 클라이언트 사이에서 발생 하게 됩니다. 어떻게 일어나는지 확실하게 말할 수는 없지만, 그 응답 값을 통해 브라우저가 지원하는 프르토콜 타입을 구글에게 전달 함으로써( TLS 1.0, 1.1. 1.2  etc ). 이를 통해 구글은 1.2버전을 사용하자는 응답을 암호화하여 브라우저에게 전달합니다.

     

    구글이 할 수 있는 다음 일은 웹 어플리케이션을 통해 방화벽의 규칙을 로드밸런스에게 알려줌으로써, 주어진 요청이 악의적인 즉, 시스템을 망칠 수 있는 요청인지를 확인합니다. 이것이 수행 되는 시간에는 보안 연결망은 아마도 끊어질 수 있고, 그 요청은 CDN의 풀에 할당되어, 구글 쪽의 캐시된 홈페이지는 HTTP 응답으로 반환됩니다. 

     

    구글의 응답 헤더는 브라우저에 의해 읽히고, 응답값 캐싱 정책에 따라서 캐시화 되며, 궁극적으로는 body쪽에서 암호화가 해제됩니다.

    구글은 네트워크 요청과 최초 렌더링까지의 시간을 줄이기 위해 미리 렌더링된 많은 컨텐츠, 인라인드 CSS, JavaScript, 이미지 등 매우 최적화되어 있습니다. 그러나 이 요청은 HTTP/2를 실행해야 하기 때문에 동시에 여러 다른 요청을 트리거합니다.  이러한 요청이 이루어지는 동안 JavaScript는 구문 분석됩니다. 태그의 지연 속성을 사용했기 때문에 차단되지 않을 수도 있습니다. 또는 비동기적으로, 개별적으로 수행되는 작업에 대해서는 읽지 않았습니다.

     

    그러나 브라우저는 이미 검색 창을 렌더링 했고 추가적인 네트워크 요청을 요구하는 toolbar를 상단에서 작동시키고 있습니다.

    사용자는 이미 쿠키나 OAuth 토큰이 있는 로컬 스토리지를 가지고 있거나, 크롬을 사용하고 있고, 이미 Chrome은 제가 누구인지 알고 있으며, 이 요청은 Google 검색 페이지 애플리케이션에게 제가 누구인지 알려주는 Google+ API로 전송됩니다.

     

    또 다른 요청은 나의 아바타(이미지) 를 얻어오기 위해 보내집니다.  이 시점에서 구글에서는 내가 크롬을 사용하지 않았는지 여부를 브라우저를 통해 탐지 할 수 있습니다.  [ = 이미 사용한 기록이 있다면, 자신이 설정한 세팅 값이 있을 텐데 그 것을 통해 크롬을 사용했는지 파악한다는 이야기 같습니다 :) ]

     

    마무리

    학교에서 수업을 들을 때는 술술 읽히고 들였던 영어가 점점 불편해지는 기분이 든다.

    주기적으로 번역을 하거나 필요한 정보는 영어를 통해 검색하는 것을 습관화 해야겠단 생각이 들었다.

     

    * 번역상 문제가 있거나 더 나은 표현이 있다면 Comment를 해주세요 :D

    'Develop > FrontEnd' 카테고리의 다른 글

    JWT란?  (0) 2021.07.04
    서버 vs 토큰 기반의 인증 방식  (1) 2021.07.04
    브라우저의 렌더링  (0) 2021.07.02
    [FrontEnd] SPA와 MPA ( 재 정리 )  (0) 2021.06.17
    [ Front-End] Dom & Broweser Rendering  (0) 2021.03.23

    댓글