브라우저 아키텍처와 탐색 프로세스
이전 포스트에서 프로세스와 스레드에 대해 알아보았다.
그렇다면 웹 브라우저는 어떤 프로세스와 스레드를 사용하여 빌드될까? 다양한 스레드가 있는 하나의 프로세스이거나 IPC를 통해 통신하는 스레드가 몇 개의 다른 프로세스일 수 있다.
브라우저 아키텍처는 표준이 없어 각 브라우저(Chrome, Firefox 및 Edge)마다 아키텍처가 조금씩 다르다.
이번 포스트는 크롬 브라우저에 대한 아키텍처이므로 다른 브라우저의 아키텍처와 다를 수 있다.
크롬 브라우저는 어떤 프로세스로 구성되어 있고 각 프로세스는 어떤 역할을 하는지, 브라우저에 URL을 입력하면 어떤 방식으로 동작하는지에 대해 알아보자.
브라우저 아키텍처(Chorme)
Chrome 프로세스 구성과 역할
크롬 브라우저의 아키텍처는 위의 그림처럼 Browser, Utility, GPU, Plugin, Renderer 프로세스로 구성되어 있다.
Browser프로세스는 나머지 프로세스들과 다 연결되어 있는 것을 볼 수 있고, Renderer 프로세스와 Plugin 프로세스가 여러개 존재한다.
| 각 프로세스 별 역할 | |
|---|---|
| 브라우저 | 주소 표시줄, 북마크, 뒤로 및 앞으로 버튼을 포함하여 애플리케이션의 ‘chrome’ 부분을 제어 |
| 네트워크 | 요청, 파일 액세스 등 웹브라우저에서 보이지 않고 권한이 있는 부분도 처리 |
| 렌더기 | 웹사이트가 표시되는 탭 내부의 모든 항목을 제어 |
| 플러그인 | 웹사이트에서 사용하는 플러그인(예: 플래시)을 제어 |
| GPU | GPU 작업을 다른 프로세스와 분리하여 처리, GPU가 여러 앱의 요청을 처리하고 동일한 노출 영역에 그리므로 다른 프로세스로 분리된다. |
Chrome 다중 프로세스 아키텍처의 이점
크롬 브라우저의 프로세스 구성에 대해 알아볼 때 Renderer 프로세스와 Plugin 프로세스가 여러개 존재한다고 앞에서 설명하였다.
각 탭에 마다 렌더기 프로세스가 생성되기 때문에 각 탭이 독립적인 렌더기 프로세스에 의해 실행된다.
다중 Renderer 프로세스의 장점으로 한 탭이 응답하지 않을 경우 응답하지 않는 탭을 닫고 다른 탭을 활성 상태로 유지하면서 계속 진행할 수 있다.
즉, 각 탭마다 다른 프로세스이기 때문에 한 탭이 실행되지 않아도 나머지 탭에는 영향을 끼치지 않는다는 것이다.
반면에 모든 탭이 한 프로세스에서 실행 중이라고 가정한다면 한 탭이 응답하지 않을때 모든 탭이 응답하지 않게 될 것이다.
또 다른 이점은 보안과 샌드박스이다.
보안적인 측면에서 각 프로세스는 메모리 영역을 할당받고 있고, 프로세스 별로 독립적이기 때문에 서로 다른 프로세스의 데이터에 접근하기 위해서는 권한을 부여 받아야하므로 보안에서 유리하다.
샌드박스(sandbox)
외부로부터 들어온 프로그램이 보호된 영역에서 동작해 시스템이 부정하게 조작되는 것을 막는 보안 형태
최근에는 사이트 격리는 기능이 도입되어 각 교차 사이트 iframe에 별도의 렌더기 프로세스를 실행한다.
동일한 Renderer 프로세스에서 a.com과 b.com을 실행하는 것은 괜찮아 보일 수 있지만 동일 출처 정책은 웹의 핵심 보안 모델로서, 한 사이트에서 동의 없이 다른 사이트의 데이터에 액세스할 수 없도록 해야 한다.
동일 출처 정책
어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호 작용할 수 있는 방법을 제한하는 중요한 보안 메커니즘
Chrome 아키텍처의 한계와 극복 방법
각 프로세스는 메모리에 할당을 받는데 Renderer 프로세스가 늘어나게 되면 고유한 메모리 영역도 늘어나게 된다.
메모리는 한정적이므로 Renderer 프로세스가 무한정 늘어날 수 없게 된다.
메모리를 절약하기 위해 Chrome은 가동할 수 있는 프로세스 수를 제한한다.
한도는 기기의 메모리 및 CPU 성능에 따라 달라지지만, Chrome에서 한도에 도달하면 같은 사이트의 여러 탭을 한 번에 실행하기 시작한다.
브라우저 탐색 프로세스
우리가 브라우저에 URL을 입력하면 브라우저가 인터넷에서 데이터를 가져와서 페이지를 표시한다.
웹사이트를 표시하기 위해 각 프로세스와 스레드가 어떻게 통신, 어떤 과정이 진행되는지 자세히 알아보자.
브라우저 프로세스의 스레드
UI 스레드: 브라우저의 버튼과 입력 필드
네트워크 스레드: 인터넷에서 데이터를 수신하기 위해 네트워크 스택을 처리
스토리지 스레드: 파일에 대한 액세스를 제어
주소 표시줄에 URL을 입력하면 입력 내용이 브라우저 프로세스의 UI 스레드에 의해 처리된다.
1단계: 입력 처리
사용자가 주소 표시줄에 입력을 시작하면 UI 스레드가 text를 search query인지 URL인지 판단한다.
search query인 경우, 검색 엔진으로 query를 보내서 검색을 준비한다.
URL인 경우, 네트워크 스레드로 URL값을 전달 준비를 한다.
2단계: 탐색 시작
사용자가 주소 표시줄에 입력을 끝내고 Enter 키를 누르면 UI 스레드는 사이트 콘텐츠를 가져오기 위해 네트워크 호출을 시작한다.
로딩 스피너는 탭 모서리에 표시되며 네트워크 스레드는 DNS 조회 및 요청에 대한 TLS 연결 설정과 같은 적절한 프로토콜을 거친다.
이때 네트워크 스레드로 HTTP 301 reponse가 오면 UI 스레드로 redirect를 전달하고 UI 스레드는 다른 URL을 요청한다.
HTTP 301 reponse가 아닌 경우 3단계를 진행
3단계: 응답 읽기
reponse body가 들어오기 시작하면 네트워크 스레드는 필요한 경우 스트림의 처음 몇 바이트를 확인한다.
응답의 Content-Type 헤더는 데이터 유형이 무엇인지 나타내야 하지만 누락되거나 잘못되었을 수 있으므로 여기서 MIME 유형 스니핑이 수행된다.
Content-Type에 따라 다른 작업 수행
a. HTML 파일인 경우 데이터를 Renderer 프로세스에 파일 전달 준비
b. zip 파일이나 다른 파일인 경우 이는 다운로드 요청이므로 Download manager에게 파일 전달 준비
Renderer 프로세스에 파일 전달하기 전에 두 가지 검사가 이루어 진다.
SafeBrowsing 검사
도메인과 응답 데이터가 알려진 악성 사이트와 일치하는 것으로 보이면 네트워크 스레드는 경고 페이지를 표시하도록 경고
CORB(Cross Origin Read Blocking)
크로스 사이트 데이터가 렌더러 프로세스에 전달되지 않도록 하기 위해 CORB 검사가 수행
CORB(Cross-Origin Read Blocking) 부채널 공격(Spectre 포함)의 위협을 완화하는 데 도움이 되는 새로운 웹 플랫폼 보안 기능 이는 민감한 정보가 포함되어 있고 기존 웹 기능에 필요하지 않은 경우 브라우저가 특정 교차 출처 네트워크 응답을 웹 페이지에 전달하는 것을 방지하도록 설계되었다.
4단계: 렌더러 프로세스 찾기
모든 확인이 완료되고 네트워크 스레드가 브라우저가 요청된 사이트로 이동해야 한다고 확신하면 네트워크 스레드는 UI 스레드에 데이터가 준비되었음을 알린다.
그런 다음 UI 스레드는 웹 페이지 렌더링을 계속할 Renderer 프로세스를 찾는다.
네트워크 요청이 응답을 받는 데 수백 밀리초가 걸릴 수 있으므로 UI 스레드는 2단계에서 네트워크 요청과 동시에 렌더러 프로세스를 사전에 찾거나 시작하려고 시도한다.
네트워크 스레드가 데이터를 수신할 때(2, 3단계) 렌더러 프로세스가 이미 대기 위치에 있다.
2, 3단계 중 cross site로 redirect되면 Renderer 프로세스가 아닌 다른 프로세스가 필요할 수 있다.
5단계: 탐색 커밋
이제 데이터와 렌더러 프로세스가 준비되면 탐색 커밋을 위해 브라우저 프로세스안의 UI 스레드가 Renderer 프로세스에게 IPC를 전송한다.
또한 Renderer 프로세스가 HTML 데이터를 계속 수신할 수 있도록 데이터 스트림을 전달한다.
브라우저 프로세스가 렌더러 프로세스에서 커밋이 발생했다는 확인을 받으면 탐색이 완료되고 문서 로드 단계가 시작된다.
이 시점에서 주소 표시줄이 업데이트되고 보안 표시기 및 사이트 설정 UI에 새 페이지의 사이트 정보가 반영된다.
탭의 세션 기록이 업데이트되어 뒤로/앞으로 버튼을 누르면 방금 탐색했던 사이트로 이동하게 되고 탭이나 창을 닫을 때 탭/세션 복원을 용이하게 하기 위해 세션 기록이 디스크에 저장된다.
추가 단계: 초기 로드 완료
탐색이 커밋되면 렌더러 프로세스는 리소스 로드를 계속하고 페이지를 렌더링한다.
Renderer 프로세스가 렌더링을 “완료”하면 IPC를 브라우저 프로세스로 다시 보낸다.(이는 모든 이벤트가 onload페이지의 모든 프레임에서 실행되고 실행이 완료된 후이다).
이 시점에서 UI 스레드는 탭의 로딩 스피너를 중지한다.
* 클라이언트 측의 JavaScript가 추가 리소스를 로드하고 새 보기를 렌더링할 수 있다.
📑 참고 자료
브라우저에 URL 을 입력하면? 크롬 브라우저 아키텍쳐의 장점과 한계점