[모던 브라우저 공부]브라우저 하이레벨 아키텍처

https://cabulous.medium.com/how-browser-works-part-i-process-and-thread-f63a9111bae9

How browser works (part I) — process and thread

 

• 지금 버전 브라우저의 동작과 다를 수 있음. 개념적으로 이해하자.

브라우저를 블랙박스라 생각하고 하나하나 까내려보자

 

1. 브라우저의 하이 레벨 아키텍처

• 브라우저는 기능 별로 다양한 프로세스를 사용함

Shift + Exit를 눌러보면 다양한 프로세스가 떠있다.탭 하나를 띄워도 이만큼이다

프로세스와 스레드

단일 프로세스 단일 스레드 모델

• 스레드는 프로세스 안에 존재한다
  • 프로세스는 데이터, 코드, 파일 등의 정보를 갖고 있다.
• 프로세스 하나에 스레드 하나만 존재하면?
  • 태스크 하나 처리 중에 문제가 생기면 전체 프로세스가 죽는다

단일 프로세스 멀티 스레드 모델

• 멀티 스레드의 경우도 동일한가?
  • 테스크 하나에 문제가 생기면 전체 스레드와 프로세스가 죽는다

초기 브라우저

초기 단일 프로세스 브라우저

• IE6과 같은 브라우저는 싱글 프로세스다
  • 탭도 없음
  • 하나의 프로세스가 수행하는 작업
    • 렌더링
    • 레이아웃 + 페인팅 (디스플레이)
    • 자바스크립트 실행
    • 플러그인 실행
  • 스레드 하나가 충돌하면 브라우저가 멈춤
    • 플래시 플레이어와 JS는 쉽게 깨짐
  • 성능 문제
    • 화면 시각 정보를 위해 자바스크립트 처리가 필요 시 페이지 렌더 스레드를 블록함

멀티 프로세스 브라우저

멀티 프로세스 브라우저

• 브라우저를 실행하면 여러 프로세스가 동작함
  • 각각 프로세스는 IPC를 통해 통신함
  • 각각의 프로세스는 여러 스레드를 사용함

브라우저의 다양한 프로세스

• 오늘 날에는 브라우저에 다양한 프로세스가 존재한다.
  • Browser process
  • Renderer process
  • Plugin process
  • GPU process
  • Network process
  • Device process
  • Video process (one of the utility processes)
  • Audio process (one of the utility processes)
• 이후 게시물에서 브라우저 기능 수행을 위한 협력 과정을 배울 것

 

가장 중요한 3개의 프로세스와 영역

• 브라우저 프로세스에서 렌더러 프로세스와 플러그인 프로세스를 분리.
• 렌더러 및 플러그인 프로세스 샌드박스 처리
  • 샌드박스 처리된 프로세스는 CPU 주기와 메모리만 자유롭게 사용할 수 있음.
  • Chromium에서 샌드박싱은 메인(브라우저) 프로세스를 제외한 대부분의 프로세스에 적용됩니다.
    • 렌더러 프로세스와 오디오 서비스, GPU 서비스 및 네트워크 서비스와 같은 유틸리티 프로세스가 포함됩니다.
    • 참조 : https://www.electronjs.org/docs/tutorial/sandbox

멀티 프로세스 브라우저가 해결한 문제들

• 불안정성
  • 탭 하나 렌더러 프로세스 하나
    • 렌더러 프로세스가 죽으면 해당 탭만 꺼짐
    • 브라우저 프로세스는 영향받지 않음
  • 플러그인 별 프로세스 하나
    • 하나의 플러그인이 이상해도 브라우징에 영향주지 않음
• 성능
  • 각 탭별 분리된 렌더러 프로세스
    • 자바스크립트 실행 및 렌더링이 탭별 실행 (병렬처리)
    • 탭이 종료되면 가비지 컬렉션이 실행됨
• 보안
  • HTML 구문 분석, JavaScript 가상 머신 및 DOM(문서 객체 모델)을 포함하여 모든 고위험 구성 요소는 렌더러 프로세스로 이동되어 샌드박스에서 실행됨.
  • 한편, 시스템 기능(지속성 저장소, 사용자 상호 작용 및 네트워킹)은 브라우저 프로세스에서 실행됨
  • 렌더러 및 플러그인 프로세스의 악성 코드는 운영 체제를 건드리기 어려움
    • 렌더러 프로세스 또는 플러그인 프로세스는 샌드박스에서 직접 네트워크 및 파일 시스템의 리소스를 요청할 수 없습니다.
  • 좀 더 알아보기
    • http://seclab.stanford.edu/websec/chromium/chromium-security-architecture.pdf

렌더러 프로세스의 책임

• HTML parsing
• CSS parsing
• Image decoding
• JavaScript interpreter
• Regular expressions
• Layout
• Rendering
• SVG
• XML parsing
• XSLT

브라우저 프로세스의 책임

• Cookie database
• History database
• Password database
• Window management
• Location bar
• Safe Browsing blacklist
• Network stack
• SSL/TLS
• Disk cache
• Download manager
• Clipboard

사이트 격리

• 교차 출처 iframe이 동일한 렌더러 프로세스를 공유하면 동일 메모리 공간에 엑세스하게 됨
  • Same Origin Policy 우회 가능
    • https://developers.google.com/web/updates/2018/02/meltdown-spectre
    • https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
• Chrome 67부터 모든 교차 사이트 iframe은 독립적인 렌더러 프로세스를 사용함

렌더러 프로세스를 공유하여 iframe을 이용해 정보를 탈취 가능한 문제를 해결

동일 사이트는 렌더러 프로세스를 공유함.

각 렌더러 프로세스가 메모리에 공유 인프라(사이트 정보 등)의 복사본을 보유해 더 많은 리소스를 필요로 함.

새 탭을 여는 사이트의 링크를 클릭하면 동일한 렌더러 프로세스를 재사용

새 탭을 열고 URL을 입력하는 경우는 새 랜더러 프로세스를 사용.

2021년의 크롬

크롬은 더 많은 독립적인 프로세스를 사용한다.

브라우저 프로세스에서 GPU, 네트워킹 및 유틸리티 프로세스를 분리하였다.

이는 SOA 아키텍처의 사상이다.

SOA 참고 : https://www.samsungsds.com/kr/insights/msa.html

해당 아키텍처의 다양한 프로세스는 샌드박스(SandBox)

• 외부로부터 받은 파일을 바로 실행하지 않고 보호된 영역에서 실행시켜 봄으로써 외부로부터 들어오는 파일과 프로그램이 내부 시스템에 악영향을 주는 것을 미연에 방지하는 기술.
• 프로세스 별 점진적 성능 저하와 같은 기능 적용

요점은?

브라우저는 다양한 프로세스와 스레드들로 구성되어있다.