브라우저(크롬) 단순 탐색(작동 원리) 살펴보기

1.  Chrome의 멀티프로세스 아키텍처

---

Chrome 브라우저는 크게 5가지의 프로세스를 가지고 있고, 그 아래 여러 작업 스레드를 가지고 있습니다.

각 프로세스는 별도의 작업을 하지만 두 프로세스간 통신이 필요하다면 Inter Process Communication (IPC)를 이용합니다. 이렇게 프로세스를 분리하면 하나의 프로세스가 무응답 상태에 빠지더라도 어플리케이션의 다른 부분을 수행하는 프로세스들은 종료할 필요가 없어 해당 프로세스만 재시작할 수 있습니다.

예를 들어 Chrome 브라우저의 여러 탭이 열려있다면 각 탭은 각각의 프로세스로 동작하기 때문에 무응답 상태의 탭이 생겨나도 다른 탭에는 영향을 주지 않습니다.

 

Browser Process : 주소창, 앞으로 뒤로 버튼을 포함한 Chrome을 제어 또한 네트워크 요청 및 파일 엑세스와 같은 웹 브라우저의 보이지 않은 부분을 제어합니다.
Renderer Process : 웹사이트가 디스플레이 될 때 탭 안의 모든 것을 담당. 여러개의 렌더러 프로세스를 사용.
GPU Process : 다른 프로세스의 GPU 작업 요청을 제어합니다.
Plugin Process : 웹사이트가 사용하는 모든 플러그인 담당.
Utility Process : 유틸리티 담당.

 

2. 단순한 탐색

---

1. 1. 브라우저 탭 주소창에 입력을 시작하면 브라우저 프로세스의 UI 스레드가 입력한 단어가 검색어인지 주소(URL)인지 판단합니다. [ 검색어 -> 검색엔진, 주소(URL) -> 네트워크 요청 ]
   
   
2. 2. 사용자가 엔터를 치면 UI 스레드가 사이트 컨텐츠를 받기 위해 네트워크 요청을 초기화합니다.
   (리다이렉션 될 경우 네트워크 스레드는 UI 스레드에게 리다이렉션을 요청하고, 새로운 URL 요청을 초기화합니다.
3. 3. 요청에 대한 응답 바디(payload)가 들어오기 시작할 때, 응답의 Content-Type 헤더 데이터 타입이 빠지거나 틀릴 수 있으므로, MIME Type 스니핑을 수행합니다.
   
   
4. 4. 응답이 HTML이면 렌더러 프로세스에 데이터를 전달합니다. 하지만 zip 또는 다른 형식의 파일이라면 다운로드 요청이라는 뜻으로 다운로드 매니저에게 데이터를 넘깁니다.
   
   
5. 5. 이 시점에서 안전 브라우징 체크도 수행합니다. 도메인과 응답 데이터가 이미 알려진 악성 사이트와 일치 한다면, 네트워크 스레드는 warning 페이지를 보여주어 경고합니다. 추가적으로 Cross Origin Read Blocking (CORB) 체크를 하여 반드시 민감한 cross-site 데이터가 렌더러 프로세스에 도달하지 못하게 합니다.
   
   
6. 6. 모든 확인 작업이 끝나고 네트워크 스레드가 브라우저가 요청한 사이트로 이동해야 함을 확신하면, 네트워크 스레드는 UI 스레드에게 데이터가 준비되었다고 알려줍니다. 그럼 UI 스레드는 웹 페이지를 렌더링을 담당 할 렌더러 프로세스를 찾습니다.
   
   ※ UI 스레드가 네트워크 스레드에게 요청을 보내는 순간 렌더러 프로세스를 찾거나 시작합니다. 그러므로 네트워크 스레드가 데이터를 수신했을 때는 렌더러 프로세스는 이미 대기하고 있습니다. 만약 cross-site로 리다이렉트 된다면 준비된 프로세스는 폐기되고 새로운 프로세스를 준비합니다.
   
   
7. 7. 탐색을 커밋하기 위해 브라우저 프로세스에서 렌더러 프로세스로 IPC가 전송됩니다. 또 데이터 스트림을 전달하여 렌더러 프로세스가 HTML 데이터를 계속 받을 수 있게 합니다. 렌더러 프로세스에서 커밋이 확인되면 브라우저 프로세스는 탐색을 완료하고 문서 로딩 단계를 시작합니다.
   
   이 시점에서 주소창이 갱신되고 보안 알리미와 사이트 설정 UI가 새 페이지의 사이트 정보를 반영합니다.
   탭의 세션 이력이 갱신되어 뒤로/앞으로 가기 버튼에 방금 방문한 사이트가 추가될 것입니다.
   탭/세션 복구 기능을 위해 탭이나 윈도우를 닫을 때, 세션 이력은 디스크에 저장됩니다.
   
   
8. 8. 탐색이 커밋되고 나면, 렌더러 프로세스가 리소스 로딩과 페이지 렌더를 지속합니다. 렌더러 프로세스가 렌더링을 "끝"내면, 브라우저 프로세스에 IPC를 반환합니다. (onload 이벤트가 페이지의 모든 프레임에서 발생하고 실행까지 완료된 후가 됩니다). 이 시점에서, UI 스레드는 탭의 로딩 스피너(로딩시 도는거)를 정지합니다.
   
   탐색이 끝난 뒤에도 클라이언트 사이드 자바스크립트는 이 시점 이후에도 계속 추가적인 리소스를 로드하거나 새로운 뷰를 렌더링할 수 있기 때문입니다. EX) SPA - React, Vue, 등등  
   
   
9. 9. 주소창에 다른 URL를 입력하면 동일한 방법으로 탐색하지만, beforeunload 이벤트를 처리하는지 확인합니다.
   beforeunload 이벤트는 다른 사이트를 방문하거나 탭을 닫을 때 "이 사이트를 나가시겠습니까?" 팝업을 띄울 수 있습니다. 탭 안에 모든 것들은 렌더러 프로세스가 처리하므로, 새 탐색시 렌더러 프로세스를 체크할 필요가 있습니다.
   
   ※ beforeunload 이벤트는 페이지에서 작성한 데이터가 소실될 수 있음 등을 경고할 필요에만 추가하세요.
   
   렌더러 프로세스가 탐색 과정을 초기화 하면(사용자가 링크를 클릭하거나 클라이언트-사이드 JavaScript가 window.location = "https://newsite.com"코드를 돌리는 등) beforeunload 이벤트를 체크합니다.
   그리고 탐색 요청을 브라우저 프로세스에게 토스(kicked off) 합니다. (브라우저 탐색과 유일한 차이점

---

3. 참고.

https://developers.google.com/web/updates/2018/09/inside-browser-part2

모던 웹 브라우저 들여다보기 (파트 2)  |  Web  |  Google Developers