브라우저 URL 입력하면? 톺아보기
멀티프로세서
OS가 프로레스 별로 메모리 줌
여러개 프로세스가 띄워지고 Inter Process Communicate (IPC)로
각 프로세스끼리 메모리 공유함
브라우저 아키텍처
- 브라우저 아키텍처는 표준이 없음
- 각 브라우저마다 아키텍처가 조금 씩 다름
크롬브라우저 아키텍처
장점
탭 1 : 렌더러 프로세스 1
GPU 프로세스 : 전체화면 그리는거 담당
아이프레임 당 하나의 랜더러 프로세스가 생성된다
단점 & 한계점
고정된 메모리 영역이 프로세스가 생길때마다 늘어나면서 영역을 먹는데,
크롬브라우저는 리밋을 정해놨음
각각의 랜더러 프로세스가 여러개 있을 때,
메모리 다 점유당하면 렌더러 다 점유하고있다가 브라우저가 알게되면
두개 렌더러 프로세스를 하나로 통합시켜버림
한계치를 알고 있음
분리되어있는 프로세스를 통합시켜서 메모리 합쳐버림
브라우저 프로세스 간 대화 형식
UI 스레드:
"유저가 엔터 키를 눌렀어. 이제 스타트 네비게이션을 시작해야 해. 이걸 (1) 핸들링 인풋이라고 부르지."
UI 스레드:
"네트워크 콜을 시작해야지. 내가 네트워크 콜을 이니시에이트해.
왜냐면 로딩 스피너를 띄워줘야 하니까."
네트워크 스레드:
"알겠어, 이제 DNS 조회를 하고, TLS 연결을 설정할게. 응답을 기다려볼게."
네트워크 스레드:
"응답이 왔어! 301 리다이렉트가 아니네. 이제 (3) 응답 읽기를 해야 해. HTML 형식인지 확인하고, 아니라면 다운로드 매니저에 전달할 거야."
응답 처리
네트워크 스레드:
"응답 본문을 확인해볼게. Content-Type을 보고, HTML인지 아닌지 체크해보자. (4) MIME 타입 확인."
네트워크 스레드:
"타입이 HTML이네. 이건 렌더러 프로세스에 넘겨줘야 해."
네트워크 스레드:
"그런데 잠깐! 세이프 브라우징을 해야 돼. 이 도메인이 악성 사이트인지 확인해야 해. (5) 악성 사이트 체크."
네트워크 스레드:
"악성 사이트가 아니야. 이제 Cross Origin Read Blocking을 확인해서 민감한 데이터를 막아야지. (6) CORS 처리."
렌더러 프로세스 확인
네트워크 스레드:
"데이터가 준비됐어! UI 스레드, 이제 데이터가 준비됐다고 알려줘."
UI 스레드:
"좋아! 렌더러 프로세스, 이제 데이터를 넘겨줄게. 미리 찾아놨으니까 바로 가져가."
렌더러 프로세스:
"잘 받았어! (7) 커밋 네비게이션을 시작할 준비 완료!"
커밋 네비게이션
UI 스레드:
"HTML이 여기 있어! 렌더러 프로세스, 받아가!"
렌더러 프로세스:
"감사해! 그런데, 이거 IPC로 받았다는 거죠? (8) IPC 처리"
UI 스레드:
"그럼! 당연히 IPC로 넘겨야지."
렌더러 프로세스:
"알았어. 이제 커밋 네비게이션을 끝냈어. 이제 렌더링을 시작할게!"
렌더링 시작
렌더러 프로세스:
"HTML, CSS, JS 로딩 완료! 이제 아이프레임도 다 로드됐어. 렌더링을 시작할게."
렌더러 프로세스:
"렌더링 끝났어! 페이지 로드 완료!"
브라우저 프로세스 (UI 스레드):
"로딩 끝났으니까 UI 스피너 없애자! (9) 로딩 스피너 종료"
이제 뒤로가기 세션이랑 탭 꺼도 다시 킬 수 있다!
시리즈 정독하면서 대화 형태로 정리해보기 !
UI스레드랑 네트워크스레드는 브라우저 프로세스 내부에 있다
다시 한번 개념 톺아보기
