이 페이지는 Cloud Translation API를 통해 번역되었습니다.

최신 웹브라우저 들여다보기 (2부)

Mariko Kosaka

내비게이션 사용 설정

이 글은 Chrome의 내부 작동 방식을 살펴보는 4부로 구성된 블로그 시리즈 중 2부입니다. 이전 게시물에서는 프로세스 및 스레드가 브라우저의 서로 다른 부분을 처리합니다. 이 게시물에서는 각 프로세스와 스레드가 통신하여 웹사이트를 표시합니다.

웹 브라우징의 간단한 사용 사례를 살펴보겠습니다. 브라우저에 URL을 입력한 후 브라우저에 URL을 입력하면 인터넷에서 데이터를 가져와 페이지를 표시합니다. 이 게시물에서는 사용자가 사이트를 요청하고 브라우저가 페이지(탐색이라고도 함)를 렌더링할 준비를 합니다.

브라우저 프로세스로 시작됩니다.

이전에 다룬 1부: CPU, GPU, 메모리 및 다중 프로세스 아키텍처 탭 외부의 모든 것은 브라우저 프로세스에 의해 처리됩니다. 브라우저 프로세스에는 브라우저의 버튼과 입력 필드를 그리는 UI 스레드 같은 스레드가 있습니다. 인터넷에서 데이터를 수신하기 위해 네트워크 스택을 처리하는 네트워크 스레드 파일 등에 대한 액세스를 제어하는 스토리지 스레드입니다. 주소에 URL을 입력하면 UI 스레드가 있으면 입력은 브라우저 프로세스의 UI 스레드에 의해 처리됩니다.

간단한 탐색

1단계: 입력 처리

사용자가 주소 표시줄에 입력하기 시작할 때 UI 스레드가 가장 먼저 묻습니다. "이것이 찾을 수 있습니다. Chrome에서 주소 표시줄은 검색 입력란이기도 하므로 UI 스레드는 은(는) 파싱하고 사용자를 검색엔진으로 보낼지 아니면 사용자가 요청한 사이트로 보낼지 결정해야 합니다.

사용자 입력 처리 — </ph> 그림 1: 입력이 검색어인지 URL인지 묻는 UI 스레드

2단계: 내비게이션 시작

사용자가 Enter 키를 누르면 UI 스레드가 네트워크 호출을 시작하여 사이트 콘텐츠를 가져옵니다. 로딩 스피너 탭 모서리에 표시되고 네트워크 스레드는 다음과 같은 적절한 프로토콜을 통과합니다. DNS 조회 및 요청에 대한 TLS 연결 설정

탐색 시작 — </ph> 그림 2: mysite.com으로 이동하기 위해 네트워크 스레드와 통신하는 UI 스레드

이 시점에서 네트워크 스레드는 HTTP 301과 같은 서버 리디렉션 헤더를 수신할 수 있습니다. 이 경우 네트워크 스레드가 서버가 리디렉션을 요청하는 UI 스레드와 통신합니다. 그런 다음 다른 URL 요청이 시작됩니다.

3단계: 응답 읽기

HTTP 응답 — </ph> 그림 3: Content-Type과 실제 데이터인 페이로드가 포함된 응답 헤더

응답 본문 (페이로드)이 들어오기 시작하면 네트워크 스레드는 처음 몇 바이트를 살펴봅니다. 스트림으로 전송할 수 있습니다. 응답의 Content-Type 헤더에는 어떤 데이터 유형인지 명시해야 합니다. 하지만 누락되거나 잘못되었을 수 있으므로 MIME 유형 스니핑 여기에서 완료됩니다 '까다로운 비즈니스'입니다. 소스 코드에 설명된 대로 수정할 수 있습니다. 이 주석을 읽고 다양한 브라우저가 콘텐츠 유형/페이로드 쌍을 처리하는 방법을 확인할 수 있습니다.

응답이 HTML 파일인 경우 다음 단계는 데이터를 렌더기에 전달하는 것입니다. 하지만 ZIP 파일이나 다른 파일인 경우 다운로드 요청이므로 데이터를 다운로드 관리자에 전달해야 합니다.

MIME 유형 스니핑 — </ph> 그림 4: 응답 데이터가 안전한 사이트의 HTML인지 묻는 네트워크 스레드

여기에서 SafeBrowsing 검사도 이루어집니다. 도메인과 응답 데이터가 알려진 악성 사이트와 일치하는 것 같으면, 네트워크 스레드가 경고 페이지를 표시합니다. 또한 Cross Origin Read Blocking (CORB) 민감한 크로스 사이트에서 데이터가 렌더러 프로세스에 도달하지 못합니다.

4단계: 렌더러 프로세스 찾기

모든 확인이 완료되고 네트워크 스레드가 브라우저가 네트워크 스레드는 UI 스레드에 데이터가 준비되었음을 알립니다. 그러면 UI 스레드가 렌더기 프로세스와 협력하여 웹페이지의 렌더링을 실행합니다.

렌더기 프로세스 찾기 — </ph> 그림 5: UI 스레드에 렌더러 프로세스 찾기를 지시하는 네트워크 스레드

네트워크 요청이 응답을 다시 받는 데 수백 밀리초가 걸릴 수 있기 때문에 이 프로세스의 속도를 높이기 위한 최적화가 적용됩니다. UI 스레드가 이미 알고 있다면 2단계에서 네트워크 스레드가 어떤 사이트로 이동하는지 이미 알고 있습니다. UI 스레드 네트워크 요청과 동시에 렌더러 프로세스를 사전에 찾거나 시작하려고 합니다. 이렇게 하면 모든 것이 예상대로 진행된다면 네트워크 스레드가 수신 대기할 때 렌더러 프로세스가 이미 대기 상태에 있는 것입니다. 데이터 세트를 다운로드합니다. 내비게이션이 크로스 사이트( 다른 프로세스가 필요할 수 있습니다

5단계: 탐색 커밋

이제 데이터와 렌더러 프로세스가 준비되었으므로, IPC는 브라우저 프로세스에서 렌더기 프로세스를 통해 탐색을 커밋해야 합니다. 또한 데이터 스트림을 전달하므로 렌더러가 계속하여 HTML 데이터를 수신할 수 있습니다. 브라우저 프로세스에서 커밋이 실행되었다는 확인을 받으면 탐색이 완료되고 문서 로드 단계가 시작합니다

이 시점에서 주소 표시줄이 업데이트되고 보안 표시기와 사이트 설정 UI에 새 페이지의 사이트 정보입니다. 탭의 세션 기록이 앞/뒤로 업데이트됩니다. 버튼은 방금 이동한 사이트로 이동합니다. 탭/세션 복원을 용이하게 하기 위해 탭이나 창을 닫으면 세션 기록이 디스크에 저장됩니다.

탐색 커밋 — </ph> 그림 6: 브라우저와 렌더러 프로세스 사이의 IPC, 페이지 렌더링 요청

추가 단계: 초기 로드 완료

탐색이 커밋되면 렌더러 프로세스는 리소스 로드를 실행하고 있습니다. 이 단계에서 어떤 일이 발생하는지 다음 게시물에서 자세히 살펴보겠습니다. 렌더러가 프로세스가 '완료'되는 경우 IPC를 브라우저 프로세스로 다시 보냅니다 (이것이 onload 이벤트가 페이지의 모든 프레임에서 실행되고 실행이 완료되었습니다. 이 시점에서 UI 스레드가 탭의 로딩 스피너를 중지합니다.

클라이언트 측 JavaScript가 여전히 로드될 수 있기 때문에 '완료'라고 함 이 시점 이후에는 추가 리소스를 적용하고 새 뷰를 렌더링합니다.

페이지 로드 완료 — </ph> 그림 7: 페이지가 '로드'되었음을 알리기 위해 렌더러에서 브라우저 프로세스까지 IPC

다른 사이트로 이동

간단한 탐색이 완료되었습니다. 그런데 사용자가 주소 표시줄에 다른 URL을 입력하면 어떻게 될까요? 다시 한번 말씀해 주시겠어요? 브라우저 프로세스는 동일한 단계를 거쳐 다른 사이트로 이동합니다. 하지만 그러려면 먼저 현재 렌더링된 사이트에서 beforeunload 이벤트를 수신합니다.

beforeunload에서 '사이트에서 나가시겠습니까?' 탭을 벗어나거나 닫으려고 할 때 경고 알림이 표시됩니다. JavaScript 코드를 포함한 탭 내부의 모든 작업은 렌더러 프로세스에 의해 처리되므로 새 탐색 요청이 들어올 때 브라우저 프로세스가 현재 렌더기 프로세스로 확인해야 합니다.

주의: 비조건부 beforeunload 핸들러는 추가하지 마세요. 지연 시간이 더 길어집니다. 핸들러는 탐색이 시작되기도 전에 실행되어야 합니다. 이 이벤트 핸들러는 필요할 때만(예: 사용자가 보유한 데이터가 손실될 수 있다는 경고를 받아야 하는 경우) 입력되어야 합니다.

beforeunload 이벤트 핸들러 — </ph> 그림 8: 브라우저 프로세스에서 렌더러 프로세스로 IPC가 라우팅되어 다른 사이트로 이동

탐색이 렌더러 프로세스에서 시작된 경우 (예: 사용자가 링크 클릭 또는 클라이언트 측 JavaScript가 렌더기 프로세스 window.location = "https://newsite.com"를 실행함) 먼저 beforeunload 핸들러를 확인합니다. 그런 다음 브라우저 프로세스와 동일한 프로세스를 거칩니다. 내비게이션이 시작되었습니다. 유일한 차이점은 탐색 요청이 렌더러 프로세스를 브라우저 프로세스에 추가합니다.

새 탐색이 현재 렌더링된 사이트와 다른 사이트로 연결되는 경우 별도의 렌더링이 현재 렌더링 프로세스가 유지된 상태에서 새 탐색을 처리하기 위해 프로세스가 호출됩니다. unload와 같은 이벤트를 처리합니다. 자세한 내용은 페이지 수명 주기 상태의 개요를 참조하세요. '이벤트'와 '상호작용' 속성을 사용하여 Page Lifecycle API:

새 탐색 및 언로드 — </ph> 그림 9: 브라우저 프로세스에서 새 렌더기 프로세스까지 페이지 렌더링을 지시하는 2개의 IPC 이전 렌더러 프로세스에 언로드하도록 지시하고

서비스 워커의 경우

최근 이러한 탐색 과정에서 변경된 사항은 서비스 워커 서비스 워커는 네트워크 프록시를 설정하고, 웹 개발자가 캐시 및 네트워크에서 새 데이터를 가져올 시기를 결정하는 데 도움이 됩니다. 서비스 워커가 페이지를 로드하도록 설정된 경우 네트워크에서 데이터를 요청할 필요가 없습니다.

기억해야 할 중요한 부분은 서비스 워커가 렌더기에서 실행되는 JavaScript 코드라는 것입니다. 프로세스입니다 그러나 탐색 요청이 들어올 때 브라우저 프로세스는 사이트에 서비스 워커는 어떨까요?

서비스 워커 범위 조회 — </ph> 그림 10: 서비스 워커 범위를 조회하는 브라우저 프로세스의 네트워크 스레드

서비스 워커가 등록되면 서비스 워커의 범위가 참조로 유지됩니다. 범위에 대한 자세한 내용은 서비스 워커 수명 주기 문서). 탐색이 발생하면 네트워크 스레드가 도메인을 등록된 서비스 워커와 비교하여 확인합니다. 서비스 워커가 해당 URL에 등록되어 있으면 UI 스레드가 렌더러 프로세스를 서비스 워커 코드를 실행할 수 있습니다 서비스 워커가 캐시에서 데이터를 로드할 수도 있으므로 네트워크에서 데이터를 요청할 필요가 없거나 네트워크로부터 새로운 리소스를 요청할 수 있습니다.

serviceworker 탐색 — </ph> 그림 11: 서비스를 처리하기 위해 렌더기 프로세스를 시작하는 브라우저 프로세스의 UI 스레드 근로자 렌더러 프로세스의 작업자 스레드가 네트워크에 데이터를 요청함

탐색 미리 로드

브라우저 프로세스와 렌더러 프로세스 간의 왕복으로 인해 지연이 발생할 수 있음을 알 수 있습니다. 만약 서비스 워커가 결국 네트워크에서 데이터를 요청하기로 결정하는 경우. 탐색 미리 로드는 이 작업의 속도를 높여 주는 메커니즘입니다. 서비스 워커 시작과 동시에 리소스를 로드하여 프로세스 프로세스를 간소화할 수 있습니다. 이러한 요청을 헤더로 표시하므로 서버가 이러한 요청을 전체 문서가 아닌 업데이트된 데이터만 표시할 수 있습니다

마무리

이 게시물에서는 탐색 중에 일어나는 일과 웹 애플리케이션 코드가 클라이언트 측 자바스크립트와 브라우저 간에 상호작용할 수 있기 때문입니다. 단계 브라우저 알기 네트워크에서 데이터를 얻기 위해 거치는 과정을 거치게 되므로 탐색과 같은 API가 사전 로드가 개발되었습니다 다음 게시물에서는 브라우저가 HTML/CSS/JavaScript로 페이지를 렌더링합니다.

게시물이 마음에 드셨나요? 향후 게시물에 관한 질문이나 제안이 있으면 아래 댓글 섹션이나 트위터에서 @kosamari 소식을 알려 주세요.

<ph type="x-smartling-placeholder"></ph> 다음: 렌더러 프로세스의 내부 작동 를 통해 개인정보처리방침을 정의할 수 있습니다.