브라우저의 동작구조

zmin·2022년 7월 1일

NAVER D2 브라우저는 어떻게 동작하는가?

브라우저의 기본 구조

사용자 인터페이스 : 직접적으로 사용자와 상호작용하는 부분, 실제로 사용자는 이부분을 보고 웹을 사용
브라우저 엔진 : UI와 렌더링 엔진 사이의 동작을 제어하게 됨
렌더링 엔진 : 요청한 콘텐츠를 파싱하여 화면에 렌더링함
통신 : 네트워크 관련 작업 → 플랫폼마다 독립적인 인터페이스
UI 백엔드 : 콤보 박스와 창 같은 기본적인 장치, OS에 따라 달라질 수 있음
→ 그럼 렌더링 엔진에서 만들어진 콘텐츠를 브라우저 위에 그려주는 역할?
자바스크립트 해석기 : 컴파일러 같은 느낌인 듯(물론 인터프리터 언어라 컴파일러가 딱히 없지만)
자료 저장소 : 쿠키 저장과 같이 하드디스크에 관련 자원을 저장

요청해서 받아온 HTML CSS 파일들을 파싱하고 렌더링해서 브라우저 화면에 표시해주는 중요한 역할

요청해서 받은 파일을 바탕으로

각 과정이 모두 끝날 때 까지 기다렸다가 다음 과정을 수행하여 한 차례로 렌더링을 끝내는 것 X

네트워크에서 오면 오는대로 렌더링 수행

우리가 아는 코드 → 브라우저가 이해할 수 있는 구조(보통 트리 구조)

작성된 언어나 형식에 따라 문맥 자유 문법(일대일 변환)에 맞추어 파싱함

파싱의 과정은 어휘 분석(토큰)과 구문 분석(구문 규칙, 문법)으로 구분

문서(소스코드) → 어휘 분석(어휘 분석기) → 구문 분석(파서)→ 파싱트리 → 기계코드

하지만 HTML은 문맥 자유 문법이 아니고, 스크립트에 의해 파싱이 수정될 수 있기 때문에 일반적인 파싱을 적용할 수 없어 따로 파서를 생성하여 사용

태그< > 를 기준으로 토큰을 생성하며 오류를 수정하기도 함

문맥 자유 문법이기 때문에 일반적인 파서를 이용하여 파싱 가능

파서가 DOM 트리를 구축하는 동안 완료된 부분에 대해 브라우저는 렌더 트리를 구축
→ 자식 요소를 어떻게 배치하고 그려낼지 정의

이런 렌더 트리의 구성요소 들을 렌더러라고 부름

렌더 객체들은 DOM 노드에 대응하지만 일대일 대응 관계도 아니고 트리 상 위치도 다름

렌더 트리는 문서 구조 뿐만 아니라 시각적인 요소(색, display여부 등)를 포함하여 이용자에게 어떻게 보여질지 나타내는 것

이때 스타일을 결정할 때 규칙 트리라는 것을 이용

앞서 만들어진 렌더 트리에는 크기와 위치 정보가 포함되어 있지 않음

기본적인 HTML 배치는 위→아래, 왼→오

최상위 렌더러의 위치는 (0,0)으로 왼쪽 상단이며 창의 크기, 즉 뷰포트 만큼의 면적을 가짐

이런 렌더러는 최상위 렌더러부터 반복되어 배치되며 배치해야할 자식 렌더러의 배치 메소드를 불러오고 다시 또 불러오고 불러오고….(재귀의 느낌이 있는 것 같음)

배치가 필요한 요소를 더티라고 표시 → 더티 비트라는 것을 이용하여 더티 상태를 표시함

보통 다음과 같이 배치가 진행

부모의 위치와 부모의 너비 결정
자식의 배치 메소드 호출
1. 자식 렌더러의 위치 결정
2. 자식의 너비 결정 & 자식의 높이 결정 (필요하다면 또 그 자식을 배치하는 메소드 호출)
자식들의 높이에 기반하여 부모의 높이 결정
더티 비트 플래그 제거

배치가 끝난 렌더 트리를 탐색하며 각 렌더러의 paint 메서드를 호출

렌더러들은 스택에 쌓이는 순서대로 그려지기 때문에 뒤→앞으로 그려지게 됨

사용자가 브라우저 주소 표시줄에 URL을 입력
브라우저 엔진이 이를 받아 자료 저장소에서 해당 자원을 가지고 있는지 탐색
1. 만약 있다면 해당 자원 바로 렌더링 엔진으로 전달
2. 없다면 URL을 렌더링 엔진으로 전달
렌더링 엔진은 받은 자원에 따라 통신을 진행하거나 바로 자원을 렌더링함
1. HTML → DOM tree, CSS → CSSOM 으로 파싱
  1. 자바스크립트의 경우 자바스크립트 해석기로 전달하여 파싱
  2. 이후 결과를 DOM tree에 적용
2. 렌더 트리 생성 및 배치
3. 화면에 그리기
그려진 화면을 UI 백엔드가 브라우저 위로 그림