블로그

다양한 이야기를 공유합니다

이달의 블로그

더보기

컴퓨터 구조 & 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 지움

URL DOMAIN

https://www.example.com:8443/path/to/page.html?search=apple pie&sort=asc#reviews1. URLhttps프로토콜 , 통신규약http, https, ftp, mailtowww.example.com호스트, 도메인:8443포트서버의 어떤 프로세스에 연결할지하나의 서버에 여러 어플리캐이션이 존재하면 그 위치를 찾을때 필요서비스 표준 포트 HTTP 80 HTTPS 443 FTP 21 SSH 22 MySQL 3306 Redis 6379/path/to/page.html경로(path)자원 위치?search=apple쿼리 스트링서버에 전달하는 추가 파라미터2. DNS 조회 → IP 획득브라우저가 위 URL을 서버에 연결하려면 IP 주소가 필요. DNS가 그 변환 담당.3. TCP 연결 시도 → 3-Way HandshakeTCP는 “신뢰성 있는 통신”을 제공하기 때문에 양쪽이 "준비됐는지" 확인하는 과정이 필요4. HTTPS 암호화 세션수립HTTPS일때 TCP 위에 TLS(암호화)를 얹는 것.5. HTTP 요청 전송요청 → 응답 수신6. 리소스별 추가요청js, css, 이미지 등

NETWORK

HTTP브라우저와 서버가 통신하는 규약클라이언트(브라우저)가 url로 서버에게 request, 서버가 클라이언트에 responseRequestMethod (GET/POST/PUT/DELETE)Header (Content-Type, Authorization, Cookie 등)Body (JSON, FormData…)ResponseStatus Code (200, 404, 500…)HeaderBody (HTML, JSON, 이미지 등)HTTPShttp를 더 안전하게 쓰기위함데이터를 암호화했기때문에 패킷을 가로채면 볼수있음

Dynamic Route

Dynamic Route 정의URL에 변하는 값을 넣어서 페이지를 만드는 라우팅 방식/products/[id]/page.tsxDynamic Route 랜더링 방식기존 (route segment, page단위)static Rendering 가정하고 출발컴포넌트 트리생성dynamic route 컴포넌트 등장하나라도 dynamic이 있으면 static rendering 중지dynamic rendering : params 가 static이라도 문제가없었음PPR(partial pre rendering)으로 변경 (component단위)static Rendering 가정하고 출발컴포넌트 트리생성dynamic route 컴포넌트 등장static 중지안하고 해당컴포넌트를 postpone 처리나머지 static 랜더링마지막 postpone 처리했던 컴포넌트를 dynamic rendering—> postpone 처리했기때문에 params를 string이 아니라 promise로 바뀜

Reflow, Repaint

정의브라우저가 픽셀을 실제로 그리는 단계HTML dom생성→ CSSom 트리 생성 → Render Tree 그리기 → Layout 계산 (위치, 크기) → Paint 실제로 그리기 → Composite (레이어 합성)Reflow요소의 크기, 위치가 바뀌어서 브라우저가 레이아웃을 다시 계산하는것비용이 큼, 성능 부담Repaint레이아웃은 그대로두고 시각적인 부분만 다시그리는것reflow보다 가벼움Repaint를 고려한 애니메이션Layout 을 다시 계산해서 전단계로 가는 애니메이션transform으로 위치를 옮기지않고 top, left를 다시 지정CSS 속성별 영향 범위Layout, Paint 발생width, height, top, left, margin, padding, font-sizePaint발생background, color, box-shadow, border-radiusComposite발생tranform, opacity—> 애니메이션은 이 두개로 쓰는게 좋음브라우저에서 Paint확인개발자도구 → 도구 더보기 → 랜더링 → paint flashing체크 → 초록색 박스 확인Composite합성페인트까지 끝난 여러 레이어를 GPU에서 하나의 화면으로 합치는 단계어디에 어떻게 겹쳐서 보여줄지 결정하는 단계will-change : transform ←—- 이 요소 transform 바뀔거라고 미리 명시Reflow, Repaint 고려한 최적화 방법style변경은 한번에el.style.width = "100px"; el.style.height = "100px"; el.style.margin = "10px";...

jwt, httpOnly Cookie

토큰 기반 인증방식json포맷의 데이터를 인코딩한 토큰구성요소Header어떤 알고리즘으로 암호화할지Payload토큰에 담을 유저정보Signatureheader와 payload를 비밀키로 서명한 값 ←— 서버는 이값을 통해서 변조되었는지 판단주의payload는 암호화가 아니라서 중요한 정보를 절대 넣으면 안됨httpOnly Cookie보안목적으로 xss공격방지용으로 만들어진 쿠키브라우저에서 html, javascript로 읽을수 없는 쿠키서버에서 자동으로 저장됨

Browser 저장소

Cookie서버와 클라이언트가 같이 쓰는 통신세션쿠키브라우저 닫으면 사라짐 → 메모리에 저장만료시간없음 켜져있는 동안 유지영구쿠키만료시간까지 디스크에 저장됨DOMAIN 별로 분리서버에서 쿠키저장할때 domain 설정해주면 서브도메인이나 path가 다양해도 쿠키자동으로 들어감Localstorage브라우저에 영구저장되는 key-value 저장소 → 디스크저장새로고침후에도 브라우저를 닫아도 유지됨js전용, 보안에 약함 보안에 관련된건 절대 세팅하면안됨쿠키처럼 자동전송 안됨언어설정, 최근본 상품, 다크모드ORIGIN 별로 분리ORIGIN(프로토콜 + 도메인 + 포트) 별로 localstorage 분리됨쿠키처럼 도메인설정같은게 없음 origin으로 자동 분리Sessionstorage탭단위로 유지되는 저장소새로고침하면 유지되지만 탭 닫으면 유지되지않음 → 메모리 저장js 전용, 보안에 약함 민감한 데이터는 쓰면 안됨새로고침해도 유지되어야하는 데이터탭 기준으로 분리 + ORIGIN으로 분리

공격 & 보안

XSScross site scripting웹사이트에 스크립트 추가해서 사용자의 브라우저에서 실행되는 공격게시판 글 등록하는 영역에 스크립트를 추가 하는 경우URL에 스크립트를 추가방어htmlspecialchars DOMPurify로 이스케이프 ( < → < & → & )특정 태그만 허용dompurify 라이브러리 (안전한 html만 남겨주는 라이브러리)CSRFcross site request forgery로그인된 쿠키를 이용해서 서버에 요청을 보내는 공격자동으로 쿠키가 헤더에 붙기때문에 악용다른사이트에 들어갔는데 쿠키가 저장되어있는 사이트의 쿠키를 사용하여서 송금방어CSRF 토큰을 서버에서 보내서 input hidden에 저장하고 서버에서 비교SameSite쿠키 설정

Hashing

데이터를 임의이 값으로 변환함단방향성: 해시값으로부터 원본 데이터를 복원할 수 없습니다결정론적: 같은 입력은 항상 같은 해시값을 생성합니다md5 ——> 사용 x128 비트 해시값 생성빠르지만 충동가능성 높아 보안에 취약$data = "example data"; $md5Hash = md5($data); echo "MD5: " . $md5Hash . "\\n";...

컴퓨터 구조

CPU중앙처리장치코드가 실행될 때 실제로 연산을 수행하는 곳엄청 빠름, 데이터는 항상 메모리에서 가져옴Core(코어): 실제 일하는 사람Thread(스레드): 한 코어가 동시에 처리하는 작업 흐름Cache(L1/L2/L3): 초고속 메모장RAM 메모리현재 실행중인 데이터 저장CPU가 가져다가 쓸수있는 공간전원끄면 다 날아감디스크 SSD, HDD영구저장프로그램, 이미지, 로그 등느림전원 꺼도 안날아감I/O (Input/Output)Input : 키보드, 마우스, 네트워크 요청 HTTPOutput : 화면출력, 네트워크 응답OS운영체제프로세스실행중인 프로그램독립적인 메모리공간쓰레드프로세스안에 작업단위메모리공유

추천 블로그

더보기

많이 본 블로그

더보기