블로그
다양한 이야기를 공유합니다
이달의 블로그
컴퓨터 구조
CPU중앙처리장치코드가 실행될 때 실제로 연산을 수행하는 곳엄청 빠름, 데이터는 항상 메모리에서 가져옴Core(코어): 실제 일하는 사람Thread(스레드): 한 코어가 동시에 처리하는 작업 흐름Cache(L1/L2/L3): 초고속 메모장RAM 메모리현재 실행중인 데이터 저장CPU가 가져다가 쓸수있는 공간전원끄면 다 날아감디스크 SSD, HDD영구저장프로그램, 이미지, 로그 등느림전원 꺼도 안날아감I/O (Input/Output)Input : 키보드, 마우스, 네트워크 요청 HTTPOutput : 화면출력, 네트워크 응답OS운영체제프로세스실행중인 프로그램독립적인 메모리공간쓰레드프로세스안에 작업단위메모리공유
컴퓨터 구조 & Browser Rendering
URL 입력 I/OHTML 을 받고 메모리에 저장 (RAM)HTML, CSS 파싱 (CPU)dom 트리 생성css 파싱 → cssom 생성render tree 생성 (dom tree + csssom)Reflow (CPU)cpu가 width, height, 부모자식관계 등을 다 계산함 → 무거움Paint (CPU)색칠, 그림자, border 등 비트맵 생성 (아직 화면에 그리는것은 아님)Composite (GPU)layer 합성transform, opacity 처리reflow 보다 무겁지않음화면출력 I/O
Browser architecture
Browser Processrenderer, gpu, plugin을 관리url 파싱,UI관리, 탭 프로세스관리, 네트워크 요청 관리보안 권한관리(localstorage, cookie)Renderer Process웹페이지 하나를 실제로 실행하는 프로세스 dom tree, csssom 생성render tree 생성reflow, paint, js실행브라우저 탭 하나당 renderer process 하나가 실행됨 → 하나가 응답이 없더라도 다른탭은 작동api 네트워크 접근은 하지않음Plugin Processplugin을 별도의 process로 격리pdf, flash 별도 처리Widevine 와이드바인 (넷플릭스같은 영상스트리밍서비스)GPU Processrenderer process 와는 다르게 탭마다 하나씩이 아닌 모든 탭의 그래픽 작업 담당layer 합성 compositetransform, opacity 등 paint작업
Browser 작동순서
Handling InputURL 입력시, 검색어인지 URL 인지를 먼저 판단browser process안에 search query, url 판단search query 면 구글 검색엔진 이용 url 이면 url전달Start Navigaionloading spinner 탭 왼쪽에 로딩network thread 는 url활용해서 dns 조회301 response 오면 redirect, 아니면 read responseRead responsenetwork thread가 response 읽음header 의 content type 확인 (html, zip, download 등)type sniffing (data를 조금읽어서 형식을 한번더 확인)CORB (corb cross origin blocking 민감한 data 는 renderer prosess에 전달하지않음)Find Renderer ProcessNetwork Thread → UI Thread 에게 data is ready 라고 전미리 Renderer Process를 준비해둠Commit Navigationbrowser process → renderer process 전달document loading phase 시작주소창 업데이트security indicator 보안표시 (https 자물쇠)session history (back button 추가)loading spinner 지움
추천 블로그
많이 본 블로그