5. 브라우저의 기본 구조
- User Interface: 주소 표시줄, 이전/다음/새로고침 버튼 등 사용자와 상호작용 하는 부분 입니다.
- Browser Engine: 사용자 인터페이스와 렌더링 엔진을 연결하며 그 사이의 동작을 제어합니다.
- Rendering Engine: 요청한 콘텐츠를 표시합니다.
- Networking: HTTP요청과 같은 네트워크 호출에 사용됩니다.
- Javascript Interpreter:자바스크립트 코드를 해석하고 실행합니다.
- UI Backend: 콤보박스와 창 같은 기본적인 위젯 장치를 그립니다.
- Data Persistance: 자료를 저장하는 계층으로 LocalStorage나 Cookie와 같이 보조기억장치에 데이터를 저장하는 파트 입니다.
6. 내비게이션 과정 설명
브라우저의 주소 표시줄에 URL 입력시 브라우저가 인터넷에서 데이터를 가져와 페이지를 표시 합니다.
사용자가 사이트를 요청하고 브라우저가 페이지 렌더링 준비하는 과정인 내비게이션 과정에 대해 이야기를 하겠습니다.
우선 브라우저 프로세스에서 시작됩니다.
브라우저 프로세스는 탭 영역 밖에 있는 모든 부분을 제어합니다. 해당 프로세스에는 그림과 같이 UI쓰레드, 네트워크 쓰레드, 스토리지 쓰레드 등이 있습니다.
주소 표시줄에 URL을 입력하면 이 UI쓰레드가 입력을 처리합니다.
UI스레드 : 브라우저의 버튼과 입력란을 그림
네트워크 스레드 : 인터넷에서 데이터를 가져오기 위해 네트워크 스택을 다룸
스토리지 스레드 : 파일에 대한 접근 제어
1단계: 입력 처리
사용자가 주소 표시줄에 타이핑을 시작하면 UI쓰레드는 입력 되는 내용이 검색인지 URL인지 확인 합니다.
이 스레드는 입력되는 내용을 파싱해서 검색 엔진으로 이동할지 요청한 사이트로 이동할지 이를 도와줄 서버와 통신하거나 DNS Lookup을 실행해서 결정합니다.
2단계: 내비게이션 시작
사용자가 Enter키를 누르면 그 사이트의 콘텐츠를 가져오기 위해 UI쓰레드가 네트워크 호출을 시작합니다.
네트워크 쓰레드는 요청에 대한 DNS Loockup 및 TLS연결 설정과 같은 적절한 프로토콜을 거쳐 요청을 처리합니다.
DNS 란
DNS(Domain Name System)는 범국제적 단위로 웹사이트의 IP 주소와 도메인 주소를 이어주는 환경/시스템
TLS 연결
TLS(Transport Layer Security), TLS 프로토콜은 인터넷을 통한 통신 보안을 제공하며 클라이언트/서버 애플리케이션이 비밀이 유지되고 안정적인 방식으로 통신할 수 있도록 해줍니다.
3단계: 응답 읽기
응답 본문인 페이로드가 들어오기 시작하면 네트워크 쓰레드는 페이로드가 어떤 형식의 데이터인지 응답 헤더와 Content-Type 헤더를 확인 합니다.
이 응답이 렌더러 프로세스가 다룰 수 있는 데이터 형식이라면 렌더러 프로세스에 전달을, 렌더러 프로세스가 다룰 수 없는 데이터라면 다운로드 매니저에 데이터를 전달하는 단계로 넘어갑니다.
HTML 파일 같은 경우는 렌더러 프로세스가 다룰 수 있지만, 응답이 ZIP 형식 파일 같은 다른 형식의 파일들은 다룰 수 없습니다.
또한 이 단계에서 응답 데이터가 안전한 사이트인지 Safe Browsing 의 검사가 실행되기도 합니다. 만약 도메인과 응답 데이터가 악성 사이트로 알려진 사이트와 일치 하다면 경고 페이지를 표시하라고 알립니다.
뿐만 아니라 CORB 기능이 서로 다른 사이트의 민감한 데이터가 렌더러 프로세스에서 실행되지 않게 검사하기도 합니다.
이때 CORB (Cross-Origin Read Blocking) 은 Ajax 호출을 필요로 하는 기능에서 보안상 이유로 동일 서버 이외에는 접근 할 수 없도록 한 것을 의미합니다.
4단계: 렌더러 프로세스 찾기
검사가 끝나고, 요청된 사이트로 이동 할 때에는 네트워크 쓰레드가 UI쓰레드에게 데이터가 준비 되었음을 알립니다.
UI쓰레드는 웹 페이지의 렌더링을 수행할 렌더러 프로세스를 찾게 됩니다.
내비게이션 실행
데이터와 렌더러 프로세스가 준비되었다면 내비게이션을 실행하도록 브라우저 프로세스에서 렌더러 프로세스로 IPC 메세지를 전송 합니다.
또한 렌더러 프로세스가 HTML데이터를 계속 수신 할 수 있도록 브라우저 프로세스는 데이터 스트림을 전달합니다. 렌더러 프로세스에서 내비게이션이 실행 되었다는 것을 브라우저 프로세스가 확인하고 나면 내비게이션이 완료 되고 문서 로딩 단계가 시작됩니다.
다른 사이트로 내비게이션
사용자가 주소 표시줄에 다른 URL을 다시 입력하면 어떻게 될까요?
브라우저 프로세스는 동일한 단계를 거쳐 다른 사이트로 이동을 처리하기 전에 현재 렌더링 된 사이트에서 "이 사이트를 떠나시겠습니까?" 라고 경고창을 만드는 beforeunload 이벤트를 확인 합니다.
이 이벤트는 웹 페이지의 렌더링을 수행하는 렌더러 프로세스를 확인합니다.
자바스크립트 코드를 포함하여 탭 안의 모든 것은 렌더러 프로세스에 의해 처리 되기 때문입니다.
처음 주소 표시줄에 URL 입력한 단계와의 유일한 차임점은 내비게이션 요청이 렌더러 프로세스에서 시작되어 브라우저 프로세스로 넘어간다는 점이 있습니다.
현재 렌더링 된 사이트와 다른 사이트로 이동하는 새로운 내비게이션이 발생하면 별도의 렌더러 프로세스가 새로운 내비게이션을 처리합니다.
이때 현재 렌더링 된 사이트를 처리한 렌더러 프로세스는 unload 와 같은 이벤트를 처리하기 위해 유지 되기도 합니다.
서비스 워커
어플리케이션의 코드에 네트워크 프록시를 저장할 수 있는 수단 입니다.
서비스 워커를 통해 웹 개발자는 무엇을 로컬캐시에 저장할지, 언제 네트워크에서 새로운 데이터를 가져올지 제어 할 수 있습니다.
즉, 서비스 워커가 캐시에서 페이지를 로드하도록 설정 되었다면 네트워크에서 데이터를 가져오도록 요청 할 필요가 없습니다.
서비스 워커가 등록되면 서비스 워커의 범위는 참조범위로 유지됩니다.
네트워크 쓰레드는 도메인을 등록되어있는 서비스 워커의 범위와 비교하고, 해당 URL에 등록된 서비스 워커가 있다면 UI쓰레드가 서비스 워커 코드를 실행하기 위해 렌더러 프로세스를 찾습니다.
이러한 과정을 통해 서비스 워커는 캐시에서 데이터를 가져오거나 네트워크에 새로운 리소스를 요청할 수 있습니다.
내비게이션 프리로드
브라우저 프로세스와 렌더러 프로세스 사이를 왕복해야 하는 상황에서 서비스 워커가 네트워크에서 데이터를 요청하기로 하면 지연이 발생 할 수 밖에 없습니다.
이를 보완하기 위해 내비게이션 프리로드는 서비스 워커의 시작과 병렬로 리소스를 로딩해 내비게이션 과정의 속도를 높이는 메커니즘 입니다.
이 요청은 헤더에 표시되어 서비스가 이러한 요청에 대해 다른 콘텐츠를 보낼 수 있게 합니다. 즉, 전체 문서를 보내지 않고 업데이트 된 데이터를 보낼 수 있습니다.
해당 사진은 프리로드를 활성화 하지 않고 서비스 워커에게 while 루프를 사용하여 의도적으로 지연 시킨 화면 입니다.
프리로드를 활성화 시키고 다시 페이지 새로고침을 하여 반응속도를 비교해보면, 시작 지연은 여전히 존재하지만 네트워크 요청을 차단하지 않으므로 사용자는 더 빨리 콘텐츠를 받을 수 있다는 것을 확인 할 수 있습니다.
출처
브라우저는 어떻게 동작하는가?
최신 브라우저의 내부 살펴보기
최신 브라우저의 내부 살펴보기 원문
마지막 프리로드에 대한 이야기는 영상을 시청하였는데, 어떤 영상을 보았는지 기록하지를 않아 찾기가 어렵네요..🥲
