23.12.12 CS_렌더링

우리가 인식하지 못할 뿐 웹페이지는 미리 만들어진 것을 가져오는 게 아니라 실시간으로 그려지는 것에 가깝습니다.

실시간으로 웹사이트가 그려지는 과정을 웹 브라우저의 '렌더링 과정'이라고 말합니다.

 

대부분의 인터넷 웹 브라우저들을 분해해보면 그 안에는 아래와 같이 두 개의 엔진이 들어가 있습니다.

1. 렌더링 엔진 : 사용자가 볼 화면을 그려내는 역할

2. 자바스크립트 엔진 : 자바스크립트 코드를 읽어내 기능을 작동시키는 역할

 

웹 브라우저가 웹페이지를 여는 과정은 마치 압축파일을 열어 실행하는 과정과 비슷합니다.

압축된 파일을 해제하면 그림과 영상 게임이나 영화 파일을 실행할 수 있듯이 웹페이지도 텍스트・이미지 리소스 파일로 이뤄진 자료들을 완성된 웹페이지 화면에 그려줍니다. 그리고 이 과정을 돕는 것이 바로 웹 브라우저의 '렌더링 엔진'입니다.

 

일반적으로 사용하는 크롬(Chrome), 엣지(Edge) 브라우저는 크롬의 블링크(Blink) 렌더링 엔진을 사용합니다.

'렌더링 엔진'은 웹사이트의 소스코드를 읽어 실제 어떤 요소들이 어떤 크기 너비로 배치되는지 텍스트는 얼마나 커야 하는지 색상은 어때야 하는지 간격은 얼마나 되어야 하는지 등을 계산해 실시간으로 그려줍니다.

사이트에 대한 설명서를 보고 새로운 화면을 만들어내는 것이라고 할 수 있습니다.

https://blog.naver.com/wishket/222323638655

∙ 렌더링 엔진이 다루는 언어

- HTML이 문서에 들어갈 텍스트 내용이나 추가 이미지, 파일 등을 다룬다면

- CSS는 문서가 어떻게 생겼고, 그림이나 파일을 어떻게 배치할지를 다룹니다

- 자바스크립트는 HTML 구조를 변형하거나, 기능적인 내용을 담고 있습니다

 

∙ 렌더링 과정은 너무나 빨리 처리되기 때문에, 그 과정을 눈으로 확인하기는 어렵습니다. 하지만 렌더링 과정을 확인하고 싶다면 구글의 라이트 하우스(Light House) 기능을 이용해 보면 됩니다.

https://blog.naver.com/wishket/222323638655

' 구글 라이트 하우스(Light House) ' 

- 웹페이지가 열리는 시간, 모바일 최적화 수준, 코드 사용 등 여러 기준점을 정해 웹페이지에 점수를 매겨줍니다. 화면이 렌더링 되는 과정과 로딩 시간 등을 분석하기에 시간의 흐름에 따라 웹페이지가 어떻게 보이는지를 직접 체크할 수 있습니다. 그리고 이 과정에서 로딩 속도가 너무 오래 걸리는 요소가 있다면 그 내용을 삭제하거나 고쳐서 렌더링 속도를 개선할 수 있습니다.
- 실제로 웹 개발자들은 이런 개발자 도구를 통해 서비스의 로딩 속도를 체크하고, 문제가 되는 파일을 더 가볍게 처리하거나 때로는 불필요한 파일을 삭제해 속도를 늘리기도 합니다. 포탈 서비스처럼 복잡하고 다양한 기능이 들어가 있는 서비스일수록 로딩 시간 체크와 소스코드 경량화 작업은 매우 중요해집니다.

⎣  렌더링 요약  ⎤
∙ 모든 웹 브라우저는 렌더링 엔진과 자바스크립트 엔진을 갖고 있다.
∙ 렌더링 엔진은 HTML, CSS 문서를 읽어내 실제 웹사이트의 모습을 그려내준다.
∙ 일반적인 웹사이트는 0.5초에서 1초 안에 내용을 읽어 화면을 그려낸다.
∙ 웹사이트의 로딩 속도를 느리게 만드는 건 대부분 이미지나 웹 폰트, 첨부파일 등이다.
∙ 전 세계의 인터넷 속도는 평균 30Mbps가 넘지 않는다. 그래서 경량화가 매우 중요하다.

 

---

 

 

SW 엔지니어 인터뷰에서 나오는 단골 질문으로 웹 브라우저, PC의 운영 체제, 인터넷 서비스 제공업체, 웹 사이트를 호스팅하는 서버, 해당 서버에서 실행되는 서비스에 대한 지식 등이 필요하고 실제 문제가 발생할 수 있는 위치와 성능 문제를 찾을 수 있는 위치를 파악해야 한다.

 

웹 브라우저에서 https://www.naver.com과 같은 URL을 입력하면 브라우저는 인터넷에서 사이트를 호스팅하는 서버를 파악하는데, 이때 www.naver.com 도메인을 검색해서 주소를 찾는다. 고유한 IP주소를 가지고 있지만 숫자보다 도메인이 기억하기 쉽다.

DNS는 휴대폰 연락처와 같이 브라우저가 인터넷에서 서버를 찾는데 도움을 준다.

DNS 조회를 수행하여 도메인 이름(www.naver.com)을 기반으로 서버의 IP주소를 찾을 수 있다.

https://aws.amazon.com/ko/route53/what-is-dns/?nc1=h_ls

DNS란 무엇입니까? – DNS 소개 - AWS

 

⌜  웹 브라우저에 URL을 입력하면 어떤 일이 생기는가?  ⌟

 

 

1. 웹 브라우저에 URL을 입력

2. 웹 브라우저가 도메인의 IP주소를 조회 (먼저 캐시를 찾고, 그 다음 DNS를 검색한다)

3. 웹 브라우저가 찾은 IP주소를 기반으로 서버와의 TCP 연결 시작

4. 웹 브라우저가 HTTP(S) 요청을 서버로 전송

5. 웹 서버가 요청을 처리하고 응답을 다시 웹 브라우저로 전송

6. 웹 브라우저가 전송 받은 컨텐츠를 렌더링

위의 순서를 고려하여 문제가 발생한 위치, 웹 사이트의 성능 문제를 찾을 위치 파악하여야 한다.

1. 웹 브라우저에 URL을 입력
∙ 통신 규약(Protocol) https:// 는 통신 프로토콜 이다. 이 스키마는 브라우저에 전송 계층 보안 (TLS=Transfer Layer Secure)을 사용하여 서버에 연결하도록 지시한다. HTTPS를 사용하면 암호와 같이 위험한 정보들이 브라우저와 서버가 데이터를 교환할 때 암호화 된다. ftp:// 나 file:// 은 브라우저가 다른 방식으로 연결하도록 하는 프로토콜들이다.
∙ 도메인(Domain) www.naver.com은 웹 사이트의 도메인 이름이다. 기억하기 쉬운 주소로 특정 서버의 IP 주소를 가리킨다.

2. 웹 브라우저가 도메인의 IP주소를 조회
URL을 가지고 인터넷에서 연결할 서버를 파악하기 위해 입력한 도메인을 사용하여 DNS를통해 웹 사이트를 호스팅하는 서버의 IP주소를 알아낸다. 

DNS는 복잡하고 매우 빨라야 하기 때문에 DNS 데이터는 웹 브라우저 사이의 서로 다른 계층과 인터넷의 다양한 위치에 임시로 저장된다. 이를 캐시(Cache)라고 부르며 웹 브라우저는 고유한 캐시 → 운영 체제 캐시 → 라우터의 로컬 네트워크 캐시 → 회사 네트워크 또는 인터넷 서비스 제공업체(ISP)의 DNS 캐시를 확인한다.

만약 웹 브라우저가 캐시계층에서 IP주소를 찾을 수 없는 경우, 회사 네트워크 또는 ISP의 DNS서버가 재귀적 DNS 조회를 수행
- 재귀적으로 인터넷에 있는 여러 DNS 서버를 요청하며, 검색될 때까지 많은 DNS 서버에 요청한다.
- 웹 브라우저가 IP 주소로 DNS 레코드를 가져오면 인터넷에서 서버를 찾아 연결을 설정한다.

특정 웹 브라우저는 사용자가 링크를 따라가기 전에 미리 도메인 네임을 확인하는 DNS Prefetch 기능을 가지고 있다.
웹 페이지 내에 도메인명이 미리 확인되면 DNS 확인 시간으로 인한 지연이 발생하지 않는다.
DNS Prefetch가 도움이 될 수 있는 경우는 검색 결과 페이지와 같이 다양한 도메인명의 링크가 있는 페이지를 보고 있을 때이다.

3. 웹 브라우저가 찾은 IP주소를 기반으로 서버와의 TCP 연결을 시작

인터넷에 연결된 웹 브라우저 요청 패킷은 일반적으로 TCP/IP 전송 제어 프로토콜을 사용하여 라우터 장비, 인터넷 서비스 제공회사 교환기를 통해 이동되어 통신 회사간 경로인 라우팅 테이블을 따라서 연결할 IP 주소가 있는 웹 서버를 찾는다.

 

하지만 웹 서버에 직접 도달하는 방법은 가끔 효율적이지 않을 수 있어서 요즘에는 직접 서버에 연결하지 않고 콘텐츠 전송 네트워크(CDN)을 사용하여 정적 및 동적 컨텐츠를 웹 브라우저에 가까이 위치 시킨다. 

'가까이 위치'를 이해하기 위해 아래 예시를 보자.

예) 동영상이나 음악을 들을 때, 이 내용들은 거리가 먼 외국에 있는 웹사이트에서 제공하지 않고 내가 사용하는 인터넷 서비스 제공자들의 데이터 센터에 있는 콘텐츠 배포 서버에 위치해 있을 확률이 크다. 버퍼링 없이 서비스를 즐길 수 있기 때문이다.

 

웹 브라우저가 인터넷에서 서버를 찾으면 웹 서버와 TCP 연결을 설정하고, HTTP를 통해 통신을 시작한다.

하지만 요새는 대부분이 HTTPS를 사용하고, HTTPS는 주고 받는 데이터의 암호화를 위한 TLS 핸드셰이크 과정을 수행한다.

이는 암호화를 할 상호 대상을 확인하는 것이다.

4. 웹 브라우저가 HTTP(S) 요청을 서버로 전송
웹브라우저가 서버와의 연결을 설정했으면 다음에는 리소스 또는 페이지를 가져오기위해 HTTP요청을 전송한다.

웹 브라우저가 서버에 연결되면(TCP), HTTPS 프로토콜에 대한 통신 규칙을 따른다. 

웹 브라우저가 페이지의 콘텐츠를 요청하기 위해 HTTP 요청을 전송하는데
HTTP 요청에는 요청 라인, 헤더(또는 요청에 대한 메타데이터) 및 본문이 포함된다.

∙요청 라인_ 클라이언트(브라우저)가 수행하려는 작업을 서버가 확인하는 데 사용하는 정보가 포함되어 있다.
∙요청 헤더(Request Header)_ 요청을 라우팅하는데 도움이 되는 추가 정보를 전달하고, 어떤 유형의 클라이언트(사용자 에이전트)가 요청을 수행했는지 나타내며 블루/그린 배포나 카나리 배포를 지원하는데 사용할 수 있다.
∙본문_ 대부분 GET 요청일 때는 비어있고 POST, PUT 또는 PATCH와 같이 리소스를 조작하는 경우 생성하거나 업데이트할 데이터를 포함한다. 요청 본문의 형태를 서버는 요청 헤더인 Content-Type을 기반으로 이해한다.

Content-Type는 application/json, application/x-www-form-urlencoded, multipart/form-data 등 다양하다.

5. 웹 서버가 요청을 처리하고 응답을 다시 웹 브라우저로 전송
웹서버가 클라이언트로 부터 요청을 받으면 서버는 요청을 처리하고 응답을 다시 전송한다.

웹 서버는 요청을 받고 요청 라인, 헤더 및 본문의 정보를 기반으로 요청을 처리한다.

컨텐츠를 가져오고 응답을 생성하여 클라이언트로 다시 전송을 하며 응답에는 다음이 포함된다.

- 클라이언트에게 요청 상태를 알려주는 상태 라인 (200, 404 등)

- 브라우저에 응답 처리 방법을 알려주는 응답 헤더 (text/html, application/json 등)

- 해당 경로에서 요청된 리소스 (이미지 파일과 같은 콘텐츠 또는 데이터, HTML, CSS, JS)

지금까지는 서버→브라우저 전송을 위한 응답 구축 방법이었고, 이제 웹 브라우저가 응답을 어떻게 처리하는지 확인하자.

6. 웹 브라우저가 전송 받은 컨텐츠를 렌더링
웹 브라우저가 서버로부터 응답을 받으면 응답 헤더를 검사하여 렌더링 하는 방법에 대한 정보를 확인한다.

전체 브라우저를 띄우는 관점에서 보면, GET 요청은 페이지의 구조인 HTML을 반환한다.
웹 브라우저 개발 도구를 사용하여 페이지의 HTML을 검사하면 다른 Javascript, CSS, 이미지 리소스를 참조하고 웹 페이지를 설계된 대로 렌더링하기 위해 추가 데이터를 요청하는 것을 확인할 수 있다.

브라우저가 HTML을 파싱하고 렌더링 할 때 JS, CSS, 이미지 및 데이터를 가져오라는 추가 요청을 하는데 항상 병렬로 수행할 수 있는 것은 아니다.

HTML은 CSS나 JS 파일 리소스를 참조하는데 웹 브라우저가 이미지 리소스를 요청하면 Content-Type 헤더가 브라우저에 이미지임을 알려주고 그에 따라 랜더링 하도록 지시한다.

* 랜더링(Rendering)? 서버로부터 HTML 파일을 받아 브라우저에 뿌려주는 과정이다. 

 https://sunrise-min.tistory.com/entry/웹-브라우저에-URL을-입력하고-사용자에게-보여주기까지-과정