이 글은 원본을 보고 나름대로 정리한 것입니다.

웹 브라우저 동작 과정 및 원리 (feat. blink)

part 2. 웹 서핑에 대한 각 프로세스와 스레드의 통신 및 동작

탐색(Navigation) : 사용자의 요청을 받아 브라우저가 페이지를 렌더링하는 과정

탐색은 브라우저 프로세스에서 시작한다.
브라우저 프로세스에서는 다음과 같은 스레드들이 동작한다.

• 버튼이나 입력창을 그리는 UI 스레드
• 인터넷에서 데이터를 수신하기 위해 통신 스택을 건드리는 네트워크 스레드
• 파일 같은 것들에 접근하기 위한 스토리지 스레드

주소창에서 URL을 입력하는 순간 UI 스레드가 잡아낸다.

Step 1. 입력 처리

크롬은 주소창에서도 검색이 가능하다.

• 따라서 UI 스레드는 입력된 문자(문구)를 파싱하여 검색 엔진에 보낼 것인지, 요청 페이지로 연결할 지 결정한다.

Step 2. 탐색 시작

탐색을 시작(사용자가 엔터를 누르면)하면 UI 스레드가 해당 사이트의 컨텐츠를 받기 위해 네트워크 요청을 초기화한다.

• UI 스레드가 네트워크 스레드에게 탐색을 알린다.

Step 3. 응답 읽기

요약 : 네트워크 스레드는 응답 데이터가 안전한 사이트에서 받은 HTML인지 확인하고 다음 단계로 넘어간다.(응답 데이터를 다른 프로세스에게 전달한다.)

응답(response)를 받는다.

• 응답 헤더(header) : 응답이 어떤 종류의 데이터인지(Content-Type), 얼마나 긴 지(Content-Length) 등을 알 수 있다.
• 응답 바디(payload) : 실제 데이터가 무엇인지

응답 바디가 들어오기 시작할 때, 필요하면 네트워크 스레드가 스트림의 처음 몇 바이트를 확인한다. 헤더로 데이터 타입을 알 수 있으나, 빠졌거나 틀릴 수 있기 때문에 MIME 스니핑을 수행한다.

MIME 유형 (IANA 미디어 유형) : 미디어 타입 (이라고도 다목적 인터넷 메일 확장 또는 MIME 타입 ) 바이트의 문서, 파일 또는 구색의 성격과 형식을 나타내는 표준

MIME 스니핑 : MIME 유형이 없거나 브라우저가 정확하지 않다고 판단하는 경우 브라우저는 MIME 스니핑을 수행 하여 리소스의 바이트를 확인하여 올바른 MIME 유형을 추측 할 수 있다.

응답이 HTML 파일이면 다음 단계로 렌더러 프로세스에 데이터를 전달하고, zip 또는 다른 형식의 파일이라면 다운로드 매니저에에게 디이터를 넘긴다.

이 과정에서 안전 브라우징 체크도 수행한다.

• 이미 알려진 악성 사이트와 비교하여 일치한다면 네트워크 스레드가 warning 페이지를 보여주어 경고한다.

추가로 Cross Origin Read Blocking (CORB) 체크를 한다.

• 민감한 cross-site 데이터가 렌더러 프로세스에 도달하지 못하게 한다. (cross origin에 대한 건 다른 글에서 다루는 걸로...)

Step 4. 렌더러 프로세스 찾기

확인(응답, 안전 브라우징, CORB 등)이 끝나면 네트워크 스레드가 UI 스레드에게 데이터가 준비되었음을 알린다. UI 스레드는 웹 페이지를 렌더링할 렌더러 프로세스를 찾는다.

아마도 이 렌더러 프로세스는 브라우저의 렌더링 엔진을 뜻하는 듯하다.
웹킷(webkit) 렌더링 엔진 = 블링크(blink) 렌더러 프로세스

Step 2에서 UI 스레드는 네트워크 요청과 병행하여 렌더러 프로세스를 찾거나 찾으려고 시작한다.

정상적으로, 계획대로 진행된다면 네트워크 스레드가 데이터를 수신했을 때 렌더러 프로세스는 이미 대기하고 있을 것이다.(네트워크 스레드가 일을 하는 동안 UI 스라드가 렌더러 프로세스를 찾아낼 것이다.)

탐색 도중 cross-site로 리다이렉트를 시도한다면 준비된 프로세스(렌더러 프로세스)는 사용되지 않을 것이고, 다른 프로세스를 준비해야 할 것이다.

이 부분에 대한 의문
URL 리디렉션 공격에 대한 방어를 뜻하는 건가? 아니면 단순 리다이렉트되는 사이트에 대한 렌더러 프로세스를 준비한다는 뜻인가?

아무래도 후자라고 생각된다. URL 리디렉션으로 악성 사이트에 접속하게 된다면 Step 3에서 경고할 테니...

Step 5. 탐색 수행

탐색을 커밋하기 위해서 브라우저 프로세스에서 렌더러 프로세스로 IPC가 전송된다.

커밋(COMMIT) : 아직 저장되지 않은 데이터를 데이터베이스(DB)에 저장하고 트랜잭션을 종료시키는 것으로 트랜잭션을 제어하는 명령어 중 하나

트랜잭션(Transaction) : 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미

렌더러 프로세스는 데이터 스트림을 통해 HTML 데이터를 지속적으로 받는다.

렌더러 프로세스에서 커밋이 확인되면 브라우저 프로세스는 탐색을 완료하고 문서 로딩 단계를 진행한다.

이 시점에서 일어나는 일.

• 주소창 갱신
• 보안 알리미와 사이트 설정 UI가 새 페이지의 사이트 정보를 반영
• 탭의 세션 이력 갱신(뒤로가기, 앞으로 가기 버튼에 사이트 추가)
  • 세션 이력은 복구 기능을 위해 디스크에 저장

Extra Step: 초기 로딩 완료

• 탐색 커밋이 완료되면 렌더러 프로세스가 리소스 로딩과 페이지 렌더를 지속한다. (세부 동작은 다음 파트에서)
• 렌더러 프로세스가 렌더링을 끝내면 브라우저 프로세스에게 IPC를 반환한다.
• 이 시점에서 UI 스레드는 탭의 로딩 스피너를 정지한다.

이걸로 단순한 탐색이 완료되었다.

다른 사이트 검색

탐색이 완료되고, 해당 사이트에 대한 용무를 끝났다면 브라우저를 종료하거나 다른 사이트로 이동할 것이다.

만약 다른 사이트로 이동한다면 step 1~5를 다시 진행할 것이다. 그런데 여기서 방문하고 있는 사이트에서 "해당 페이지를 벗어나시겠습니까?" 등의 beforeunload 이벤트를 처리할 필요가 있다.

해당 이벤트는 탐색 이전에 실행시켜야 하기 때문에 대기 시간이 발생할 수 있다.
따라서 beforeunload와 같은 이벤트 처리는 꼭 필요한 경우, 데이터의 유시링나 저장되지 않음 등을 사용자에게 경고할 때 써야 할 것이다.

JavaScript 코드를 포함한 탭 안의 모든 것들은 렌더러 프로세스에서 처리하기 때문에 브라우저 프로세스는 종료 혹은 다른 사이트 방문 등의 요청이 발생했을 때 렌더 프로세스를 체크할 필요가 있다.

렌더러 프로세스가 탐색 과정을 초기화 하면? (사용자가 특정 링크 클릭 및 이동, JavaSciprt의 window.location 등을 이용하는 것)

• 렌더러 프로세스는 우선 beforeunload 핸들러 체크
• 이후 탐색 과정을 동일하게 진행
• 새로운 탐색이 현재 렌더링된 사이트와는 다른 곳으로 새로 탐색하게 된다면, 현재 렌더러 프로세스가 unload 같은 이벤트를 처리하는 동안 별개의 렌더러 프로세스가 새 탐색을 처리하기 위해 호출

※ 브라우저 프로세스가 새로운 렌더러 프로세스에겐 렌더링을 요청하고, 이전 렌더러 프로세스에겐 unload하도록 요청한다. (IPC를 통해서)