웹 브라우저 이해와 데이터 저장소

개요 목적

이번 시간에는 HTTP 프로토콜을 사용하고 다양한 웹 검색을 가능하게 해주는 웹 브라우저에 대해서 알아본다.

먼저 웹 브라우저에 대한 이해와 웹 브라우저가 어떻게 웹페이지를 보여주는 과정에 대해 알아본다.

그리고 브라우저에 데이터를 저장하는 Local Storage, Session, Cookie 데이터 저장소 종류와 특징에 대해서 알아본다.

웹브라우저 이해와 브라우저 렌더링 과정 이해

웹브라우저는 다양한 웹 서버(누구의 블로그, 네이버 웹툰 서버)의 다양한 정보들을 검색하고 조회할 수 있도록 도와주는 프로그램을 뜻한다.

대표적 브라우저는 크롬, 웨일, 마이크로엣지가 있다.

브라우저는 유저가 선택한 자원을 서버로 부터 받아와서 유저에게 보여준다.

이 자원은 페이지 외에도 이미지, 비디오 등의 컨텐츠들도 포함된다. 받아온 자원들을 렌더링 과정을 통해 유저에게 보여주게 된다.

브라우저 렌더링 과정

브라우저는 다음과 같이 유저 인터페이스, 브라우저 엔진, 렌더링 엔진, 네트워크 통신부, 자바스크립트 해석기, UI 백엔드, 자료 저장소로 구성된다.

종류	역할
사용자 인터페이스	주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등, 요청 페이지 창을 제외한 브라우저 자체의 GUI를 구성하는 부분이다.
브라우저 엔진	사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어한다. Data Storage를 참조하여 로컬에 데이터를 쓰고 읽는 다양한 작업을 한다.
렌더링 엔진	요청한 콘텐츠를 화면에 출력하는 역할이다. HTML, CSS 등을 파싱하여 최종적으로 화면에 그린다.
통신	HTTP 요청과 같은 네트워크 호출에 사용된다. 플랫폼 독립적인 인터페이스이고 플랫폼 하부에서 실행된다.
자바스크립트 해석기	javascript 코드를 해석하고 실행한다.
UI 백엔드	브라우저가 동작하고 있는 운영체제의 인터페이스를 따르는 UI를 처리한다. Alert이나 SelectBox는 운영체제 별로 다르게 동작한다.
자료 저장소	Local Storage, Indexed DB, 쿠키 등 브라우저 메모리를 활용하여 저장하는 영역이다.

이 중 렌더링 엔진을 통해 요청한 콘텐츠로 렌더링 과정을 거쳐서 화면에 나타낸다. 렌더링 과정을 순서대로 알아보자.

• Parsing - HTML 파일과 CSS 파일을 파싱해서 각각 Tree를 만든다.

HTML 파일을 해석하여 DOM(Document Object Model) Tree를 구성하는 단계이다.

파싱 중 HTML에 CSS가 포함되어 있다면 CSSOM(CSS Object Model) Tree 구성 작업도 함께 진행한다.

• Style - 두 Tree를 결합하여 Rendering Tree를 만든다.

DOM Tree와 CSSOM Tree를 매칭시켜서 Render Tree를 구성한다.

Render Tree는 실제로 화면에 그려질 Tree이다.

그래서 visibility: hidden은 요소가 공간을 차지하고, 보이지만 않기 때문에 Render Tree에 포함이 되지만, display: none 의 경우 Render Tree에서 제외된다.

• Layout - Rendering Tree에서 각 노드의 위치와 크기를 계산한다.

루트부터 노드를 순회하면서 노드의 정확한 크기와 위치를 계산하고 Render Tree에 반영한다.

만약 크기 값을 %로 지정하였다면, Layout 단계에서 % 값을 계산해서 픽셀 단위로 변환한다.

• Paint - 계산된 값을 이용해 각 노드를 화면상의 실제 픽셀로 변환하고, 레이어를 만든다.

Layout 단계에서 계산된 값을 이용해 Render Tree의 각 노드를 화면상의 실제 픽셀로 변환한다.

• Composite - 레이어를 합성하여 실제 화면에 나타낸다.

Paint 단계에서 생성된 레이어를 합성하여 실제 화면에 나타낸다. 우리는 화면에서 웹 페이지를 볼 수 있다.

www.naver.com을 검색하면 화면에 나타나기까지 과정 

이번에는 렌더링을 포함한 전반적인 WEB의 화면 출력 네트워크 과정을 알아보자.

• 대기열

www.naver.com이라는 주소창 입력을 브라우저 요청 대기열에 넣는다.  

• 캐싱

요청된 값을 미리 저장하고 있다면 서버와 통신하지 않고 그 데이터를 바로 제공하는 기술이다.

캐싱의 방법에는 브라우저 캐시와 공유 프록시 캐시 두가지가 있다.

• 브라우저 캐시

브라우저 캐시는 쿠키, 로컬 스토리지 등 브라우저 저장소를 이용한다. 브라우저 자체가 사용자가 HTTP를 통해 다운로드한 문서를 가지고 있어서, 다음 방문 때는 빠르게 화면이 나타나거나, 이미 값이 채워져 있다.

• 공유 프록시 캐시

공유 프록시 캐시는 요청한 서버에서 프록시서버가 캐싱을 하는 것이다. 예를 들어 Node.js로 서버를 구축한다면 앞단의 프록시서버로 nginx서버를 둬서 이 서버를 캐싱 서버로도 사용할 수 있다.

• DNS

브라우저가 DNS를 통해 www.naver.com에 맞는 IP 주소를 확인한다.

www.naver.com에 DNS 쿼리가 오면 오른쪽부터 역순으로 [Root DNS]→ [.com DNS] → [.naver DNS] → [.www DNS] 과정을 거쳐 완벽한 주소를 찾아 IP 주소를 매핑한다.

이 때 바로 DNS서버로 요청을 전달하는 것은 아니라 먼저 컴퓨터 메모리에 있는 호스트 파일 등 캐시를 확인한 후 캐시미스가 일어나면 DNS서버로 요청하게 된다.

• IP 라우팅

IP 라우팅, ARP(IP→MAC주소)과정을 거쳐서 실제 동작하는 물리적 서버를 찾는다.

• 초기 연결

브라우저가 TCP 3웨이 - 핸드셰이및 및 SSL 연결등을 통해 초기 연결 시도한다. 초기 요청을 보낸 후 드디어 해당 요청한 서버로부터 응답을 받아 연결을 확립한다.

• 콘텐츠 다운로드 브라우저 렌더링

브라우저는 서버로 부터 받은 콘텐츠 데이터를 브라우저 렌더링을 거쳐서 화면에 나타낸다.

웹 브라우저 데이터 저장소

로컬 스토리지

로컬스토리지는 웹 스토리지 객체로 브라우저 내에 { key : value } 형태로 오리진에 종속되어 저장되는 데이터를 말한다. 오리진이 같은 브라우저내에서 공유가 된다.

오리진이란, https://www.google.com/부분을 말한다. com/뒤에 추가 URL이 붙어도 같은 오리진 영역이라고 할 수 있다.

https://www.google.co.kr/imghp?hl=ko&ogbl 와 https://www.google.com/?authuser=0 같은 오리진으로 로컬 스토리지를 공유한다.

특징으로는

• 하나의 키에 오로지 하나의 값만 저장된다.
• 만료 날짜가 없다. 사용자가 창이나 탭을 닫아도, 컴퓨터를 종료해도 만료되지 않는다.
• 대략 도메인 당 최대 저장 용량은 5MB이다.
• 보통 사용자의 행위를 기억할 때, 로그인을 유지하기 위한 값 등으로 사용되며 로컬 스토리지 데이터는 자동으로 서버로 전송되지 않는다. (쿠키는 자동 전송됨)

세션 스토리지

세션 스토리지(session Storage)는 로컬 스토리지와 매우 유사하다.

세션 스토리지는 웹 스토리지 객체로 브라우저 내에 { key : value } 형태로 오리진에 종속되어 저장되는 데이터이다. (오리진이 같은 브라우저 내에서 공유 됩니다.)

로컬 스토리지와 차이점은 사용자가 브라우저에서 탭을 닫으면 데이터는 만료 되는 것이다.

쿠키

쿠키는 브라우저에 저장된 데이터 조각입니다.

클라이언트 설정 서버 설정 모두 가능하나 보통은 서버에서 먼저 쿠키를 만들어서 통신에 사용하는 것이 일반적이다.(반면에 로컬 스토리지와 세션 스토리지는 클라이언트에서만 설정할 수 있다.)

서버에서 응답 헤더로 Set-Cookie로 설정해서 쿠키를 보내면 그 때 부터 클라이언트에서 요청 헤더 Cookie에 설정되어 자동으로 서버에 전달되게 되고 브라우저에도 저장되게 된다.

쿠키의 종류

• 세션 쿠키는 Expires 또는 Max-Age 속성을 지정하지 않은 쿠키이다. 브라우저가 종료되면 쿠키도 사라진다.
• 영구 쿠키는 Expires 또는 Max-Age 속성을 지정해서 특정날짜 또는 일정기간이 지나면 삭제되게 만든 쿠키, 브라우저를 닫을 때 만료되지 않는다.

쿠키의 구성 요소

-쿠키의 이름과 값을 설정
Set-Cookie: <cookie-name>=<cookie-value>

-쿠키의 만료시간 설정
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>

-쿠키의 전송할 도메인 이름과 패스를 설정
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>

-https로만 쿠키를 주고받을 수 있게하는 옵션이지만,
chrome 52 이상부터는 안전하지 않은 사이트가 secure 지시문으로 쿠키를
설정하는 것을 금지하기 위해 해당 사양을 무시한다
Set-Cookie: <cookie-name>=<cookie-value>; Secure

-공격자가 자바스크립트로 빼낼 수 없게 설정
(document.cookie로 접근 불가)
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

-요청이 동일한 도메인에서 시작된 경우에만 
쿠키가 애플리케이션으로 전송되도록 허용
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict

쿠키의 시큐어코딩

쿠키-세션으로 로그인을 처리를 한다면 다음 안전 조건 코딩을 실행해야 한다.

1. cookie에 세션ID를 담을 때 이 세션ID기반으로 클라이언트의 개인정보를 유추할 수 없게 해야 한다.
2. 자바스크립트로는 파악할 수 없게 http only 옵션을 걸어야 한다.
3. 일정시간의 세션 타임아웃 걸어야 한다.

쿠키 허용 관련 알림 창

방문 기록을 추적할 때 쿠키가 사용되기 때문에 서비스 운용 시 쿠키를 사용한다면 쿠키 허용 관련 알림창을 만들어야 한다.

방문 기록 추적은 사용자의 데이터 간접 수집에 해당하며 거기에 해당하는 KISA 지침을 준수해야 하기 때문이다.

정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준(KISA) 2019.01
3.1.5 간접수집 보호조치
정보주체(이용자) 이외로부터 개인정보를 수집하거나 제공받는 경우에는 업무에 필요한 최소한의 개인정보만
수집 ․ 이용하여야 하고 법령에 근거하거나 정보주체(이용자)의요구가 있으면 개인정보의 수집 출처, 처리목적,
처리정지의 요구권리를 알려야 한다.
서비스 계약 이행을 위해 필요한 경우로서 사업자가 서비스 제공과정에서 자동수집장치 등에 의해 수집 ․
생성되는 개인정보(통화기록, 접속로그, 결제기록, 이용내역 등)에 대해서도, 해당 서비스의 계약 이행 및
제공을 위해 필요한 최소한의 개인정보만을 수집하여야 한다.
▶ 다만, 서비스 제공 계약 이행과는 무관한 목적으로 이용하기 위해 수집하는 경우에는 선택 동의 항목으로
분류하여 별도의 사전 동의를 받아야 함 (예를 들어, 쿠키를 통해 수집하는 행태정보를 분석하여 개인별
맞춤형 광고에 활용하는 경우 등)

 

---

Reference

https://all-young.tistory.com/22

https://tecoble.techcourse.co.kr/post/2021-10-24-browser-rendering/