Browser

브라우저에 URL을 입력하면 - Navigation

신입 웹 프론트엔드 개발자 기술 면접에 종종 등장하는 질문 중에 ‘브라우저에 URL 을 입력하면 어떤 일이 일어나는가’ 가 있다. 이번 포스트에서는 이 질문에 대해 브라우저, 특히 멀티 프로세스 아키텍쳐를 사용하는 크롬의 관점에서 렌더러 프로세스 이전 시점까지를 기준으로 공부한 내용을 기록해두었다.
 
🛠
개요
  1. Handling Inputs
  1. Start Navigation
  1. Read Response
  1. Find Render Process
  1. Commit Navigation이R
 
이후 renderer Process 작동

1. 입력(Handling Inputs)

유저가 크롬(브라우저)의 URL 창에 텍스트를 입력하고 엔터를 누르면, 크롬의 브라우저 프로세스 내 UI 스레드는 입력된 텍스트가 URL 양식인지 혹은 검색어(search query) 양식인지 판단한다. 전자일 경우 네트워크 스레드로 URL의 값을 전달할 준비를 하고, 후자일 경우 브라우저의 기본값으로 설정된 서치엔진으로 검색어 쿼리를 보내 검색할 준비를 한다. 아래에서는 검색어가 아닌 URL을 입력한 것으로 가정하고 설명을 이어나가겠다.

2. 네비게이션 시작(Start Navigation)

  • UI 스레드가 network call initiates를 하고 동시에 네트워크 스레드에게 URL을 전달한다. 그리고 브라우저 탭의 왼쪽에 Loading Spiner를 표시한다. 네트워크 스레드가 아닌 UI 스레드가 network call initiates를 함으로서 적절하게 Loading Spiner를 표시해줄 수 있게 된다.
  • 이후 네트워크 스레드는 프로토콜(HTTP/HTTPS 등)을 활용해 DNS에 연결한다. 프로토콜이 HTTPS일 경우 TLS(Transfort Layer Security - 보안레이어) connection를 생성한다. DNS와 프로토콜, TLS 등 네트워크 개념에 대해서는 별도의 포스트에서 다루겠다. 이후에는 HTTP response에 따라 발생하는 일이 달라진다. 만약 HTTP 301 response가 도착한다면 네트워크 스레드는 UI 스레드로 redirect를 하라고 전달하고, UI 스레드에서는 다시 한번 network call initiates를 하게 된다. response가 정상적인 응답이라면 응답을 읽게(read response)된다.

3. Read Response

response body가 네트워크 스레드로 들어오면, 네트워크 스레드는 response에서 약간의 데이터(few bytes of stream)을 읽는다.
  • type sniffing
      • 이 때 response header에 있는 contents-type으로 response의 type를 확인하고, 이것을 더 정확하게 확정하기 위해 MIME(Multi-purpose Internet Mail extentions) type를 감지(sniffing)한다. contents-type이 HTML 형식이 아닐 경우 Download manager에게 파일을 전달할 준비를 하고, HTML 형식일 경우 렌더러 프로세스로 파일을 전달할 준비를 한다. 렌더러 프로세스로 파일을 전달하기 전에는 아래 두 가지 과정이 더 수반된다. 하나는 SafeBrowsing이고, 다른 하나는 CORB(Cross Origin Read Blocking)이다.
  • Google SafeBrowsing
      • SafeBrowsing 과정에서는 domain과 data가 악의가 있는지 known malicious site 목록을 확인하여 검증하고, 악의가 있다고 판단되면 Warning page를 보여준다.
  • CORB(Cross Origin Read Blocking)
      • CORB 정책은 브라우저 내장 기능으로 response가 cross-site-data로 판단되는 경우 민감한 데이터를 구분하여 렌더러 프로세스로 전달되는 것을 차단한다. 브라우저는 contents-type 헤더를 확인하여 리소스의 타입을 판단하고 text/html, text/xml, application/json 등 민감할 수 있는 데이터를 포함할 가능성이 있는 콘텐츠 타입에 대해 보다 엄격하게 차단을 시도한다.

4. Find Renderer Process

Find Renderer Process는 UI 스레드가 network call initiates를 하면서 동시에 발생한다. 네트워크 요청의 응답이 도착하는데 일정 시간이 걸리기 때문에, 도착한 데이터의 신속한 렌더링을 위해 렌더러 프로세스를 미리 찾기 시작한다. 네트워크 스레드에서 확인이 끝나면, 브라우저가 사이트를 실제로 이동해야겠다는 판단을 내린다. 이때 네트워크 스레드는 UI 스레드에 data is ready라고 전달한다. 브라우저 프로세스의 UI 스레드는 미리 찾아놓은(혹은 찾기 시작한) 렌더러 프로세스에게 데이터(HTML file)를 전달한다.

5. Commit Navigation

렌더러 프로세스에게 전달할 데이터(HTML file)와 Find Renderer Process가 완료되어 렌더러 프로세스가 준비되어 있다면, Commit Navigation을 위해 브라우저 프로세스의 UI 스레드가 렌더러 프로세스에게 IPC(Inter-Process Communication)를 보낸다. IPC는 크롬 같은 멀티 프로세스 아키텍쳐에서 프로세스 사이의 통신 방식이다. 브라우저 프로세스의 UI 스레드가 렌더러 프로세스에게 보내는 데이터에는 렌더러 프로세스가 html data를 지속적으로 받을 수 있게 하는 통신 채널인 data stream이 포함되어 있다.
브라우저 프로세스의 UI 스레드가 렌더러 프로세스로부터 Commit Navigation이 확인된 것을 확인하면, Navigation은 종료되고, 렌더러 프로세스의 document loading phase가 시작된다. 그 이전에 UI 스레드는 아래 세 작업을 추가로 수행한다.
  • 주소창 업데이트 : 브라우저의 주소창에 Commit Navigation된 URL을 표시한다.
  • 보안 인디케이터 표시 : 브라우저의 주소창 왼쪽에 위치한 보안 인디케이터(자물쇠 아이콘 등)를 적절하게 표시한다.
  • 세션 히스토리 저장 : 브라우저의 앞으로가기, 뒤로가기, 페이지 복구 등에 필요한 세션 히스토리를 저장한다.