브라우저의 동작 원리
당연한 건 없다.
필자는 그동안 아무런 궁금증도 갖지 않은채 인터넷과 브라우저를 사용해왔다. 네이버와 구글에 접속하는 것이 너무나도 당연했고, 그냥 물을 마시면 갈증이 해소되는 것과 같이, 이를 하나의 상식이자 명제처럼 당연시 해왔다.
하지만 웹 개발을 시작하며, 내가 개발한 웹사이트가 어떻게 사용자들의 브라우저에 렌더링 되어 보여지는지 궁금해지기 시작했고, 이에 대해 확실히 이해해보고 싶었다.
그렇다면 브라우저 주소창에 https://www.naver.com을 입력했을 때, 어떤 과정을 거쳐서 네이버 페이지가 렌더링 되는걸까?
이 질문에 대답하기 위해선 브라우저, url, 렌더링에 대한 이해가 우선되어야 한다고 생각한다.
결국 질문에 담긴 핵심은 이 세 개념들이기 때문이다.(브라우저 주소창에 url을 입력하면 페이지가 어떻게 렌더링 되는가?)
따라서 차례대로, 브라우저란 무엇이며 어떤 기능을 하는지, url이란 무엇인지, 그리고 마지막으로 렌더링 과정은 어떻게 되는지에 대해 짚고 넘어가보고자 한다.
브라우저란?
웹 브라우저는 웹 서버와의 통신을 통해 HTML, 미디어파일 등을 수신 받아 사용자에게 웹페이지를 렌더링해주는 하나의 응용 소프트웨어다.
조금 더 쉽게 풀어서 설명을 하면, 브라우저가 서버에 데이터를 요청하고 → 서버는 요청받은 데이터를 응답하며 → 브라우저는 응답받은 데이터를 처리하여 사용자에게 웹페이지로써 렌더링 해주는 것이다.
브라우저의 기본 구조
그렇다면 브라우저는 어떤 구성요소들로 구성되어 있으며, 각 요소들은 어떤 기능을 담당할까?
| 구성요소 | 설명 |
|---|---|
| 유저 인터페이스 (UI) | URL 검색창, 뒤로가기 앞으로 가기 버튼, 홈 버튼, 새로고침 버튼 등 |
| 브라우저 엔진 | 중간에서 유저 인터페이스와 렌더링 엔진 사이의 작업과 동작을 제어한다. |
| 렌더링 엔진 | HTML과 CSS 등을 파싱하여 콘텐츠들을 화면에 표시하는 역할을 한다. |
| 통신 | HTTP 요청과 같은 네트워크 호출에 사용 |
| JS 해석기 | 자바스크립트 코드를 해석하여 실행하는 역할을 한다. |
| UI 백엔드 | OS 사용자 인터페이스를 기반으로 기본적인 위젯 및 툴을 표시한다. |
| 자료 저장소 | 쿠키, 로컬스토리지, 세션스토리지와 같이 브라우저 자체의 저장소를 의미한다. |
즉, UI는 기본적인 브라우저의 틀을 구성하고, 렌더링 엔진이 HTTP 통신을 통해 응답받은 데이터를 파싱하여 화면에 표시해주는 것이 기본적인 브라우저 동작 원리의 골자인 것이다.
언뜻 봐도 위 구성요소들 중에 렌더링 엔진이 굉장히 큰 역할을 담당하고 있는 것 같다.
렌더링 엔진
렌더링 엔진은 응답 받은 HTML 문서를 파싱하여 브라우저 상에 페이지를 표시해준다.
참고로 렌더링 엔진의 동작과정을 설명하며 어려운 단어들이 속출될 예정이다. 파싱, DOM 트리, 렌더트리 등등… 모든 용어들을 알기 쉽게 설명하며 자세히 짚고 넘어갈 것이니 너무 겁먹지 말고 차근히 읽어 내려가길 바란다.
렌더링 엔진의 동작 프로세스
우선 여기서 “잠깐!” 이라는 말을 하고싶다. 필자 또한 해당 내용을 공부하면서 딱 이 때부터 글을 읽기가 싫어졌었다. 도통 모르는 단어들 뿐인지라 이해가 되질 않았다…
따라서 위에서도 언급했듯, 사진에 나온 생소할 개념들을 하나하나 차근히 짚어가며 설명을 해보도록 하겠다.
DOM 트리
DOM트리 === DOM이라고 생각해도 된다. DOM은 Document Object Model로, 쉽게 말해 HTML 코드(태그)들이 트리형태로 계층화 + 구조화 된 하나의 문서 또는 객체다.
파싱
브라우저가 코드를 읽고 활용할 수 있도록 데이터를 구조화 하는 것
파싱은 구문 분석으로 정의된다. 이를 풀어 설명하면, 데이터를 분석 및 정제하여 원하는 형태로 가공하는 것이다. 따라서, 위에서 설명했듯, HTML문서(코드)를 DOM 형태로 구조화 또는 가공해야 하는데 이를 “파싱한다”라고 표현한 것이다.
렌더트리
진짜 마지막이다!
일단, 렌더트리는 CSSOM + DOM의 결과물이다. CSSOM이란 CSS Object Model로, CSS 코드가 DOM과 같이 파싱되어 구조화 된 것이라고 생각하면 된다.
따라서, 렌더트리란 HTML이 구조화된 DOM과 CSS가 구조화된 CSSOM이 합쳐진 결과물인 것이다.
자, 이제 DOM 트리가 생성되기 위해 HTML이 파싱되고, CSS코드 또한 파싱되어 CSSOM이 되며, 두 트리가 합쳐져 렌더트리가 된다는 것 까지는 이해했다.
이렇게 렌더 트리의 생성이 끝나면, 각 노드들(렌더트리의 각 요소들)의 배치가 시작된다. 즉, 포지셔닝이 된다는 것이다. 그리고 노드들의 배치가 완료되면 UI 백엔드가 각 노드들의 형상을 그려낸다.
이러한 일련의 과정들을 거치며 우리가 작성한 HTML 및 CSS 코드들이 웹상에 표현되는 것이다.
정리
지금까지 설명한 렌더링 엔진의 동작 과정은 위 그림과 같다.
HTML 및 CSS 코드들이 파싱되어 각자 트리 형태(오브젝트 모델)로 변환되고 → 두 트리가 합쳐져 렌더 트리가 된다 → 그리고 트리의 노드들이 각각 배치되고 그려지며 내가 작성한 코드들이 브라우저에 그려지는 것이다.
이제 마지막으로 URL이 무엇인지, 그리고 그 URL을 통해 서버에 어떻게 요청이 보내지는지에 대해서만 이해한다면, “특정 URL을 브라우저에 입력했을 때 해당 페이지가 어떻게 렌더링 되는가?” 에 대한 대답을 해낼 수 있을 것이다.
URL이란?
url의 구성 요소는 위 사진처럼
스킴 + 호스트 + (패스) + (쿼리)로 이루어져있다.
원래는 포트번호 또한 url의 구성요소이기는 하지만, 스킴에 기본적으로 할당되어 있는 고유 포트번호가 있기 때문에 생략되는 경우가 많다.
스킴 (프로토콜)
한국어에도 문법, 훈민정음, 발음, 상황에 따른 용법 등 다양한 규칙과 기준이 존재하듯, 네트워크 통신에도 이러한 다양한 규칙(프로토콜)들이 존재한다.
즉, 프로토콜은 네트워크 통신을 위한 규약이자 규칙들의 단편들이다. “나는 이런 규칙을 따르며 통신할거야!”
도메인
도메인은 컴퓨터의 주소라고 할 수 있는 IP주소가 기억되기 쉽게 변환된 것이다.
인간의 입장에서 192.16X.X.X등을 외우기는 쉽지 않기 때문에, 이러한 IP주소를 외우고 구분하기 쉽도록 www.naver.com과 같은 형태로 변환한 것이 도메인이다.
Path
Path는 조금 더 세분화된 경로이자 파일의 위치라고 할 수 있다.
즉, 내가 찾는 데이터가 웹서버에 저장된 위치다. 특정 디렉토리 또는 파일의 위치를 찾는 것과 동일하다고 볼 수 있다.
쿼리 (Query)
만약 위의 정보들로는 부족하고, 조금 더 상세한 조건이나 데이터를 담아서 보내주고싶을 때 쿼리를 사용한다.
예를 들어 www.naver.com/place?location=seoul이라고 했을 때, 이는 그냥 place를 통틀어 찾고싶은 것이 아닌 seoul이라는 특정 위치에 대해서만 검색을 하고싶을 때 사용됐을 것이다.
URL을 통해 웹서버에 데이터 요청이 일어나는 과정
그럼 이제 URL이 뭔지에 대해서는 개괄적으로 이해가 됐는데, 이러한 URL을 통해 어떻게 웹 서버에 데이터 요청이 일어나는 걸까?
웹서버에 요청을 보내는 과정은 크게 위의 그림과 같다고 할 수 있다. 이를 조금 더 명료하게 정리를 해보자면 아래와 같이 정리할 수 있을 것이다.
도메인을 IP주소로 변경
DNS 서버에 요청하여 요청 도메인에 대응하는 IP주소를 반환 받는다 (DNS 리졸버)
DNS는 네트워크의 전화번호부 역할을 하는 서버라고 할 수 있다. 따라서 우리는 DNS 서버에 나의 도메인에 대응하는 IP주소를 반환받을 수 있는 것이다.
ARP 프로토콜을 통해 MAC주소 반환
이제 IP 주소를 얻었으니, 서버 또는 컴퓨터의 정확한 물리적 주소를 의미하는 MAC 주소를 알아내야 한다.
IP주소는 하나의 네트워크(계층)에 대한 주소이므로, 정확한 컴퓨터에 요청이 도달하도록 하기 위해서는 MAC주소가 필요하다. 따라서 우리는 ARP 프로토콜을 통해 IP주소에 대응하는 MAC 주소를 반환 받아야 한다.
IP와 MAC주소를 통해 서버로 요청 전달
이제 IP주소를 통해 특정 네트워크에 접근하고, MAC주소를 통해 정확한 컴퓨터에 접근한다.
즉, 네트워크라는 큰 범위 또는 계층에 IP 주소를 통해 접근하고, 해당 네트워크에서 MAC 주소라는 물리적 주소를 통해 특정한 컴퓨터에 접근할 수 있는 것이다. 이를 통해 우리는 특정 웹 서버에 요청을 보낼 수 있는 것이다.
이를 하나의 문장으로 다시 정리하자면, 도메인(www.naver.com)을 통해 IP 주소를 얻어내고, 해당 IP 주소로 내가 원하는 웹서버의 네트워크까지 도달한 후, MAC 주소를 통해 정확한 웹서버의 컴퓨터에 액세스하는 것이다.
사실 이렇게 간단히 요약될 수 있는 부분이 아니긴 하지만, 이번 포스팅에서는 이정도의 설명만으로도 충분할 것이라 감히 생각해본다. 여기서 OSI 7계층, 4계층에 따른 분류와 ARP 프로토콜, DNS 리졸버 등에 대해 다루면 글이 끝도없이 길어질 것이다. 따라서 해당 내용들은 다음 포스팅에서 다뤄보도록 하겠다.
정리 및 요약
자, 이제 하나의 요약된 글로써 https://www.naver.com을 입력했을 때 어떻게 해당 페이지가 렌더링 되는지 설명해보도록 하겠다.
브라우저에 해당 url을 입력하면 렌더링 엔진의 통신 기능을 통해 해당 웹 서버로 GET 요청을 보낸다. 해당 GET 요청이 가는 과정은 DNS 서버에 요청을 보내 URL의 도메인에 대응하는 IP 주소를 반환 받고, ARP 프로토콜을 통해 MAC 주소까지 반환받아 웹서버에 요청을 전달하는 것이다. 이렇게 해당 웹서버로 GET요청이 전달되면, 웹서버는 해당 URL에 대응하는 데이터를 응답으로써 반환해준다. 브라우저는 이 때 반환된 데이터를 파싱하여 DOM트리와 CSSOM을 생성하고, 이를 합쳐 렌더 트리를 생성한다. 그리고 생성된 렌더 트리를 통해 각 노드들을 배치 및 형성하여 페이지가 렌더링 되는 것이다.
추가적으로, HTML의 헤드 부분에 script를 넣지 않는 이유는 DOM이 생성되는 과정에서 JS파일이 실행되거나 너무 큰 JS파일의 크기로 인해 로딩 시간이 길어질 수 있음을 방지하기 위함이라고 한다.
만약 그럼에도 불구하고 헤더 부분에 script를 추가하고싶다면
<script defer src=''>또는<script async src=''>와 같이 비동기 처리를 해줘야 한다!
참조 자료
Javascript Environment | PoiemaWeb
렌더링 트리 생성, 레이아웃 및 페인트 | Web | Google Developers