Chrome 웹 브라우저 내부 아키텍처 및 동작 살펴보기 (2부)

이전 브라우저 아키텍처에 대한 내용은 아래 글 참고바랍니다.

2022.08.18 - [Frontend] - Chrome 웹 브라우저 내부 아키텍처 및 동작 살펴보기 (1부)

Chrome 웹 브라우저 내부 아키텍처 및 동작 살펴보기 (1부)

 

Browser Process

이전 글에서 살펴봤듯이 탭 외부의 모든 것은 Browser Process에 의해 처리됩니다.

 

Browser Process는 아래와 같은 스레드를 포함합니다.

• UI Thread: 브라우저의 버튼과 입력 필드를 그림 (예: 주소 표시줄에 URL을 입력하면 UI Thread에서 입력을 처리)
• Network Thread: 인터넷에서 데이터를 수신하기 위해 네트워크 스택을 처리
• Storage Thread: 파일에 대한 액세스를 제어

 

1단계: 입력 처리

사용자가 주소창에 입력을 하면 UI Thread 는 가장 먼저 "검색어"인지 "주소 URL"인지 확인합니다. UI Thread 는 구문을 분석하고 사용자를 검색엔진 또는 요청한 사이트로 보낼지 결정합니다.

 

UI Thread 는 구문 분석을 통해 검색어 또는 URL을 판단하여 사용자를 검색엔진 또는 요청한 사이트로 보낼지 결정

 

2단계: 탐색 시작

사용자가 Enter를 누르면, UI Thread가 네트워크 호출을 합니다.

Loading Spinner는 탭 모서리에 표시되며, Network Thread는 요청에 대한 DNS 조회 및 TLS 연결 설정과 같은 적절한 프로토콜을 거쳐서, 사이트의 콘텐츠를 가지고 옵니다.

 

UI Thread와 Network Thread에 의해 사용자가 요청한 사이트로 보내줌

 

3단계: 응답 읽기

서버로부터 응답 본문(payload)이 들어오기 시작하면, Network Thread는 스트림의 처음 몇 바이트를 확인하여 Response의 Header를 확인합니다. (Content-Type 등을 확인)

 

응답이 HTML 파일인 경우, 데이터를 Renderer Process에 전달합니다. 반면, zip 파일 또는 다른 파일인 경우 "다운로드 요청"이므로 "다운로드 관리자"에 전달합니다.

 

Safe Browsing 검사가 일어나는 곳이기도 한데, 도메인 및 응답 데이터가 악성 사이트와 일치하는것으로 보이면 Network Thread는 경고 페이지를 표시하여 사용자에게 경고합니다. 또한 중요한 교차 사이트 데이터가 Renderer Process에 전달되지 않도록 Cross Origin Read Blocking (CORB) 검사를 합니다.

응답 데이터가 안전한 사이트인지 확인

 

4단계: Renderer Process 찾기

모든 검사가 완료되면, Network Thread는 데이터가 준비되었음을 UI Thread에 알립니다. 그리고, UI Thread는 웹 페이지 렌더링을 위해 Renderer Process를 찾습니다.

 

 

성능 향상을 위해 UI Thread는 2단계(탐색시작)에서 Renderer Process를 사전에 찾거나 시작하려고 시도합니다. 모든것이 예상한대로 진행되면 Network가 응답 데이터 검사가 완료된 시점에 Renderer Process는 이미 대기 위치에 있게됩니다.

 

5단계: 탐색 커밋

이제 데이터와 Renderer Process가 준비되었으므로, Browser Process에서 Renderer Process로 IPC를 통해 데이터가 전송됩니다.

 

Renderer Process가 HTML 데이터를 계속 수신할 수 있도록 데이터 스트림으로 전달합니다. Browser Process가 Renderer Process에서 커밋이 발생했다는 확인을 듣고 나면 탐색이 완료되고 문서 로드 단계가 시작됩니다.

 

이때 주소 표시줄이 업데이트되고 보안 표시기 및 사이트 설정 UI에 새 페이지의 사이트 정보가 반영됩니다. 탭에 대한 세션 기록이 업데이트되어 뒤로/앞으로 버튼이 방금 탐색한 사이트로 이동합니다. 탭이나 창을 닫을 때 탭/세션 복원을 용이하게 하기 위해 세션 기록이 디스크에 저장됩니다.

 

Browser Process가 Renderer Process에 페이지 렌더링을 요청

 

추가 단계: 초기 로드 완료

탐색이 커밋되면 Renderer Process는 리소스 로드를 계속하고 페이지를 렌더링합니다.

 

이 단계에서 일어나는 일에 대한 자세한 내용은 아래글을 참고해주세요.

2022.08.22 - [Frontend] - Chrome 웹 브라우저 내부 아키텍처 및 동작 살펴보기 (3부)

 

Renderer Process가 렌더링을 완료하면, IPC를 통해 Browser Process로 다시 보냅니다 (모든 onload이벤트가 페이지의 모든 프레임에서 발생하고 실행이 완료된 이후). 이 시점에서 UI Thread는 탭에서 로딩 스피너를 중지합니다.

렌더링이 완료되었음을 Browser Process에 알리는 Renderer Process

 

다른 사이트로 이동

만약 사용자가 주소 표시줄에 다른 URL을 입력하면, 위의 동일한 단계를 거쳐 다른 사이트로 이동합니다. 그러나 그전에 현재 사이트에서 beforeunload 이벤트가 있는지 확인합니다.

 

beforeunload는 "이 사이트를 나가시겠습니까?"와 같이 다른 곳으로 이동하거나 탭을 닫으려고 할 때 경고합니다.

주의. beforeunload 이벤트 핸들러를 무조건 추가하지 마세요. 탐색 시작 전에 핸들러를 실행하기 때문에 대기 시간이 더 길어집니다. 해당 이벤트 핸들러는 필요한 경우에만 추가해야 합니다. (예를 들어 사용자가 페이지에 입력한 데이터가 손실될 수 있다는 경고를 하기 위한 경우)

 

다른 사이트로 새 탐색이 수행되면, 새 탐색을 처리하기 위해 별도의 Renderer Process가 호출되고, 반면 현재 Renderer Process는 unload와 같은 이벤트를 처리하기 위해 유지됩니다. (페이지 life cycle 참고: https://developer.chrome.com/blog/page-lifecycle-api/#overview_of_page_lifecycle_states_and_events)

 

Service Worker의 경우

서비스 워커가 캐시에서 페이지를 로드하도록 설정되어 있으면 네트워크에서 데이터를 요청할 필요가 없습니다.

 

Network Thread는 등록된 Service Worker Scope에서 도메인을 확인하고, 해당 URL에 Service Worker가 등록되어 있으면 UI Thread는 Service Worker 코드(Javascript 코드)를 실행하기 위해 Renderer Process를 찾습니다.

Service Worker는 네트워크에서 데이터를 요청할 필요가 없이, 캐시에서 데이터를 가져올 수 있게 할 수 있습니다. 또는 네트워크에서 새 리소스를 요청할 수 있습니다.

 

Service Worker가 결국 네트워크에서 데이터를 요청하기로 결정하면, Browser Process와 Renderer Process 간의 이 왕복이 지연됩니다.

Navigation Preload 는 Service Worker 시작과 동시에 리소스를 로드하여, 성능을 향상시키는 메커니즘입니다. 헤더로 이러한 요청을 표시하여 서버가 다른 콘텐츠를 보낼 수 있도록 합니다. (예를 들어 전체 문서 대신 업데이트된 데이터만)

 

다음 글

2022.08.22 - [Frontend] - Chrome 웹 브라우저 내부 아키텍처 및 동작 살펴보기 (3부)

Chrome 웹 브라우저 내부 아키텍처 및 동작 살펴보기 (3부)

 

Reference

https://developer.chrome.com/blog/inside-browser-part2/

Inside look at modern web browser (part 2) - Chrome Developers