[브라우저] 네비게이션- 프로세스와 스레드의 동작

참고 그 이상 : https://d2.naver.com/helloworld/9274593

 

◆ 네비게이션 : 브라우저 주소 표시줄 부터 렌더링 준비까지...

브라우저의 주소 표시줄에 url을 입력하면 브라우저가 인터넷에서 데이터를 가져와 페이지를 표시한다. 

시작은?

■ 브라우저 프로세스 : 탭 영역 밖에 있는 모든 부분 제어

브라우저 프로세스는 UI 스레드와 네트워크 스레드, 스토리지 스레드 등이 있다.

1. UI 스레드 : 브라우저의 버튼과 입력란을 그린다.

2. 네트워크 스레드 : 인터넷에서 데이터를 가져오기 위해 네트워크 스택을 다룬다.

3. 스토리지 스레드 : 파일에 대한 접근 제어

주소 표시줄에 url 입력하면 UI 스레드가 입력을 처리한다. 

브라우저 프로세스가 담당하는 부분(탭 영역 제외)

■ 네비게이션

1. 입력 처리 : 주소창 입력을 분석해서 적당한 처리를 한다.(url인지 검색어인지)

2. 네비게이션 시작 : ui스레드 → 네트워크 스레드 실행 → 요청하고 응답을 받음.

3. 응답 읽기 : 받은 응답(payload)를 읽음 - 어떤 데이터인지 파악하고 처리함(렌더러 프로세스 호출 or 다운로드 )

4. 렌더러 프로세스 찾기

5. 네비게이션 실행

 

+ 초기 로드 완료!

 

1. 입력처리

사용자가 주소 표시줄에 타이핑 시작하면 UI스레드는

'입력되는 내용이 검색어(search query)인지 url인지 ' 확인한다.

검색어이면 검색 엔진으로 이동.

url이면 요청한 사이트로 이동한다.

검색어인지 url인지 확인하는 UI 스레드

* 입력된 문자열이 검색어인지 URL인지 판별하는 것은 어려운 일이기 때문에, 브라우저는 이를 도와줄 서버와 통신하거나 DNS Lookup을 실행하기도 한다. 네이버 브라우저 Whale의 사이트 곧장 가기 기능도 이 단계에서 실행되는 기능이다.

** 사이트 곧장 가기 기능 : '유튜브' 라고 검색창에 입력하면, www.youtube.com으로 이동해주는 기능. 직접 설정해야한다.

2. 네비게이션 시작

url 입력 후 enter를 누르면 콘텐츠를 가져오기 위해 UI스레드가 네트워크 호출을 시작한다. 

로딩 스피너가 탭의 모서리에 표시되고, 네트워크 스레드는 요청에 대한 DNS Lookup및 TLS연결 설정과 같은 적절한 프로토콜을 거쳐 요청을 처리한다.

* TLS(Transport Layer Security) 프로토콜 : SSL(Secure Sockets Layer)라 불리는 이전 암호화 프로토콜에서 발전한 것.

HTTPS는 HTTP 포로토콜 상위에서 TLS암호화를 구현한 것이다. HTTPS를 사용하는 웹사이트는 TLS암호화를 이용한다.

(암호화, 인증, 무결성)

mysite.com으로 이동하기 위해 네트워크 스레드와 통신하는 UI스레드.

3. 응답 읽기 : Content-Type, mime 스니핑, safe browsing

payload : 전송되는 데이터.

페이로드가 들어오기 시작하면 네트워크 스레드는 필요에 따라 스트림의 처음 몇 바이트를 확인한다. 

어떤 데이터인지 Content-Type 헤더가 알려주지만, 정보가 없거나 잘못될 수 있다.

이 때, MIME 스니핑을 실행해 데이터의 실제 형식을 알아낸다. 

 

(렌더러 프로세스가 다룰 수 있는 데이터 타입일 경우)

응답이 HTML이면 데이터를 렌더러 프로세스에 전달하는 단계로 넘어간다.

(렌더러 프로세스가 다룰 수 없는 데이터 타입일 경우)

zip형식 파일 등 다른 파일이라면 다운로드 요청이므로, 다운로드 매니저에 데이터 전달 단계로 넘어가야 한다.

Content-Type이 알려주는 type, 실제 타입.

이 단계는 Safe Browing의 검사가 일어난다. 도메인과 응답 데이터가 악성 사이트로 알려진 것과 일치하는 것 같다면, 네트워크 스레드는 경고 페이지를 표시하라고 알린다. 더불어 CORB(Cross-Origin Read Blockin)기능이 서로 다른 사이트(cross-site)의 민감 데이터가 렌더러 프로세스에서 실행되지 않게 검사한다.

4. 렌더러 프로세스 찾기

모든 검사가 끝나고 브라우저가 요청된 사이트로 이동해야 한다고 네트워크 스레드가 확신하게 되면  UI스레드에 데이터 준비되었음을 알린다. 그러면 UI 스레드는 렌더링을 수행할 렌더러 프로세스를 찾는다.

네트워크 요청이 응답을 받기까지 수백 밀리초가 걸릴 수 있기 때문에, UI스레드가 네트워크 URL요청을 보냄과 동시에 렌더러 프로세스를 찾고 준비하기 시작한다. 이 방식으로, 네트워크 스레드로부터 데이터를 받을 때, 렌더러 프로세스는 이미 준비 상태에 있게 된다. 만약 다른 사이트로 리다이렉션이 이루어져 다른 프로세스가 필요하게 되면, 미리 준비한 프로세스가 사용되지 않을 수도 있다. 

 

5. 네비게이션 실행 : '내비게이션' = '(사이트 간의) 이동'

렌더러 프로세스가 준비되었으므로, 브라우저 프로세스에서 렌더러프로세스로 IPC 메세지를 전송한다. 렌더러 프로세스가 HTML 데이터를 계속 수신할 수 있도록(?) 브라우저 프로세스는 데이터 스트림을 전달한다. 렌더러 프로세스에서 네비게이션이 실행되었다는 것을 브라우저 프로세스가 확인하고 나면 네비게이션이 완료 되고, 문서 로딩 단계가 시작된다.

- 문서 로딩 단계

주소 표시줄이 업데이트 되고 보안 표시와 사이트 설정 UI도 새 페이지의 사이트 정보를 반영해 갱신된다.탭에 대한 세션 기록이 업데이트 되어 뒤로 가기 버튼, 앞으로가기 버튼도 방금 이동한 사이트를 반영해 동작한다.

탭이나 창을 닫은 이후 탭과 세션을 복원할 수 있도록 세션 기록이 디스크 드라이브에 저장된다.(=ctrl+shift +T 기능..)

브라우저 프로세스가 렌더러 프로세스에게 페이지 로딩하라고 일을 준다. 데이터는 브라우저 프로세스의 네트워크 스레드로부터 받는다.

 

+ 초기 로드 완료!

네비게이션이 실행되면, 렌더러 프로세스는 리소스를 계속 로딩하고 페이지를 렌더링한다.(다음 글에서 다룬다고 한다.. 나도...ㅎ)

렌더링을 끝내면 브라우저 프로세스로 IPC메세지를 보낸다. UI스레드는 탭에서 로딩 스피너의 작동을 중지한다.

페이지 로딩되었음을 알리는 IPC 통신.

■ 다른 사이트로 네비게이션 : beforeunload 이벤트

beforeunload이벤트는 탭을 닫거나 이동하려 할때 '이 사이트를 떠나시겠습니까?' 와 같은 경고창을 만들 수 있다.

게시글 작성 중 나가면 작성 글을 잃어버릴 수도 있다는 경고창을 띄우듯이...

이 이벤트 핸들러는 네비게이션 시작 전에 실행되기 때문에, latency가 발생할 수 있으니 필요한 경우에만 사용한다.

(데이터가 날아갈 거라는 둥..)

 

* beforeunload이벤트 핸들러는 경우에 따라 실행되지 않을 수도 있다. chrome://flags/#enable-fast-unload 설정이 활성화되었다면 beforeunload 이벤트 핸들러가 실행되지 않을 가능성이 더 높다고 한다.

 

렌더러 프로세스에서도 네비게이션이 실행될 수 있다. ex) javascript의 winddow.location = 'https://tistory.com"

이 때도 네비게이션 과정을 똑같지만, 네비게이션 요청이 렌더러 프로세스에서 브라우저 프로세스로 넘어간다는 점만 다르다.

* 웹페이지 라이프 사이클 확인 : https://developer.chrome.com/blog/page-lifecycle-api/#overview_of_page_lifecycle_states_and_events

■ 서비스 워커 : 애플리케이션 코드에 네트워크 프락시 작성할 수 있는 수단.

웹 개발자는 무엇을 로컬 캐시에 저장할 지, 언제 네트워크에서 새 데이터를 가져올 지 제어할 수 있다

서비스 워커는 렌더러 프로세스에서 실행되는 Javascript코드이다!

 

네비게이션 요청이 들어왔을 때, 브라우저 프로세스는 사이트에 서비스워커가 있다는 걸 어떻게 알 수 있나?

네트워크 스레드는 등록된 서비스 워커의 범위와 도메인(url의 도메인)을 비교한다. 해당 URL에 등록된 서비스 워커가 있으면, UI 스레드는 서비스 워커 코드를 실행하기 위해 렌더러 프로세스를 찾는다.

 

서비스 워커 스레드(렌더러 프로세스 내부)는 캐시에서 데이터를 가져올 수도 있고, 네트워크에 새 리소스를 요청할 수도 있다.

 

■ 네비게이션 프리로드 (Navigation pre load)

서비스 워커가 캐시에서 데이터를 가져오는 것이 아니라, 네트워크에 요청하기로 하면 지연이 발생된다.(브라우저프로세스→ 렌더러프로세스→브라우저프로세스)

서비스 워커의 시작과 함께 병렬로 리소스를 로딩(네트워크 스레드를 통해 url을 요청)해서 네비게이션 과정의 속도 높임.

이 요청은 헤더에 표시되어 있어, 서버가 이런 요청에 대해서 다른 콘텐츠를 보낼 수 있게한다.

ex) 전체 문서를 보내지 않고, 업데이트 된 데이터만 보낼 수도 있다.(이전에 보낸건 캐시에 저장되어 있고, 그것과 다른 데이터만 전송.)

 

 

 

* 네비게이션 과정이란 결국 주소창에 url입력하고 결과 페이지를 받는데까지의 과정을 의미한다.

 

잘못된 내용 혹은 문제되는 내용이 있으면 알려주세요. 수정하도록 하겠습니다.

감사합니다.