Chrome의 내부 동작 #2

 

* 이 글은 Inside look at modern web browser을 참고해 정리한 글입니다. 

최신 웹브라우저 들여다보기 (2부)  |  Blog  |  Chrome for Developers

 

1. 핵심 컴퓨팅 용어와 크롬의 다중 프로세스 아키텍처

2. 웹 사이트를 표시하기 위해 각 Process와 Thread가 통신하는 방법

3. renderer process 내부에서 발생하는 일

4. Chrome의 내부 동작

 

총 4부작으로 구성된 글 중 이번 글은 2번째  웹 사이트를 표시하기 위해 각 Process와 Thread가 통신하는 방법이다. 바로 알아보자. 

1. Browser Process

Browser Process에서 동작하는 3가지 Thread

1부에서 이야기했듯이 탭 외부에 모든 것은 Browser Process에서 처리된다. Browser Process에는 총 3가지 Thread가 존재하는데 이는 다음과 같은 역할을 지닌다. 

 

UI thread: 브라우저 버튼(뒤로, 앞으로 가기, 새로고침 등)과 주소 창 입력 필드를 제어

Network thread: 인터넷에서 데이터를 수신하기 위해 네트워크 스택 처리

Storage thread: 파일에 대한 접근을 제어

 

간단한 예시를 통해 이를 더 자세하게 탐구해보자.

( 주소 창에 주소를 입력하고, 해당 화면을 브라우저에 출력하는 예시)

---

2. Navigation (간단한 예제)

2.1 사용자가 주소 창에 입력

사용자가 주소창에 입력

사용자가 주소창에 주소를 입력하였을 때 UI thread는 "검색인가요? URL 인가요?" 라는 질문을 던진다. 이는 주소 표시창에서도 검색이 가능하기 때문인데, UI thread는 구문을 분석하여 이후 처리를 실행한다. 

2.2 검색 시작

UI thread와 Network thread의 통신

사용자가 엔터를 누르는 순간 UI thread는 사이트의 정보를 가져오기 위해 Network thread에게 요청한다. 이때 Network thread는 DNS 조회 및 요청에 대한 처리를 시작한다. 만약 HTTP 301과 같은 redirect 헤더를 수신하는 경우 Network thread는 redirect를 요청하는 UI thread와 통신을 시작한다. 

2.3 응답 조회

header와 payload 영역

응답에 대한 본문이 들어오면, Network thread는 총 5가지를 수행합니다. 

 

1. stream의 처음 몇 바이트를 확인 (필요한 경우)

2. header와 payload 등 들어오는 값에 대한 확인

- header에 있는 Content-Type(데이터 유형)의 값이 중요한데, 누락되거나 잘못된 값이 들어오는 경우가 있을수 있으므로, 표준화된 MIME 타입을 따른다.

3. 파일 종류 확인

- 응답이 HTML 파일이면 Renderer process에 역할을 전달하면 되지만, 그 외 파일(.zip, image 등등)인 경우 다운로드 요청이기에 바로 download manager에게 데이터를 넘긴다.

4. SafeBrowsing 검사

- 도메인과 응답 데이터가 알려진 악성사이트라면 경고 페이지를 표시한다.

5. CORS 검사

- 크로스 사이트 데이터가 다음 process에 전달되지 않도록 검사한다.

2.4 Renderer process  찾기

Network thread는 UI thread에게 Renderer Process를 찾아달라고 요청

 

 

모든 준비가 끝났다면, Network thread는 UI thread에게 데이터가 준비되었다고 알린다. 네트워크 요청에 대한 응답을 반환하는 시간을 예측할 수 없으므로 UI thread는 2.2 검색시작을 할 때 renderer process를 사전에 찾아놓는다.  그렇기에 UI thread는 웹 페이지를 렌더링 할 (사전에 찾아놓아 대기 상태에 놓여있는) renderer process를 선택한다. 만약 리다이렉션 된다면 대기 상태에 놓여있는 renderer process는 필요하지 않게된다.

2.5  Navigation Bar에 데이터 적용

Browser Process와 Renderer Process간의 IPC

 

네트워크 요청에 대한 응답으로 준비된 데이터, 그리고 선택된 renderer process가 있다면 탐색에 대한 결과를 Commit하기 위해 IPC 를 통해 Browser process에서 Renderer process로 데이터를 스트림으로 전송한다. Renderer process에서 Commit를 확인하면 Browser process에서는 탐색이 완료된다. 동시에 Renderer process에서는 문서 로드를 시작한다.

이 시점이 주소 표시줄이 업데이트 되고 보안 표시가 UI에 반영 될 때이다. 또한 탭간의 세션 기록이 업데이터 되어 뒤로/앞으로 버튼이 활성화 됩니다.  

2.6  Load 완료

page load가 완료되었다고 알려주기 위한 IPC

 

Renderer process에서 문서 로드가 완료(onload 이벤트가 완료되는 시점)되면 IPC를 Browser process에게 다시 보낸다. 그리고 Browser process 내에 UI thread는 로딩 스피너를 중지한다. 

 

자 이제 Navigation 탐색의 한 사이클을 완료했다.

하지만 사용자가 다른 사이트를 탐색한다면 어떤 일이 발생할까?

물론 지금까지 언급한 동일한 단계를 거치겠지만, 이전 하나의 이벤트(beforeunload) 가 추가된다. 다른 페이지를 이동하거나 탭을 닫으려 할때 해당 이벤트를 통해 원하는 행동을 가져갈 수 있다.

(탐색을 시작하기 전 핸들러를 실행해야 하므로 지연 시간이 발생한다. 정말 필요한 경우에만 사용하는 것이 좋다.)

 

Old Renderer process에서는 unload 이벤트를 처리하고, 이후 앞서 설명한 흐름(Browser process --> Renderer process)대로 새로운 탐색을 시작한다. 

이전(첫 페이지 Load)과 달라지는 점은 단지 Old Renderer process --> Browser process --> New Renderer process로 흘러간다는 것이다.

 

탐색 프로세스의 하나인 서비스 워커에 대한 설명은 생략하려고 한다. 자세한 설명은 여기를 클릭하면 좋을 것 같다. 

---

3. 결론

웹사이트를 표시하기 위해 각 Process와 Thread가 어떤 역할을 가지고 상호작용하는 방법을 살펴보았다. 브라우저가 Network thread를 통해 데이터를 가져오는 단계를 알면 preload와 같은 API가 왜 탄생하게 되었는지에 대해 쉽게 이해할 수 있을 것이다. 

다음 Chrome의 내부 동작 #3에서는 renderer process 내부에서 발생하는 일에 대해 살펴보겠다.

---

< 참고자료 >

[사이트] # Inside look at modern web browser (part 2)

최신 웹브라우저 들여다보기 (2부)  |  Blog  |  Chrome for Developers

<기타> Chrome의 내부 동작 #2 end