Today Seungjae Learned
Hits bn

# Web

# 브라우저 렌더링 원리

  1. 사용자가 특정 페이지에 접속하여 HTML을 서버로부터 내려받으면, 브라우저의 렌더링 엔진이 파싱 진행
  2. HTML 파싱을 진행하며 DOM 트리를 만든다.
  3. StyleSheet를 내려받으면 CSS 파싱을 통해 CSSOM 트리를 만든다.
  4. 두 트리를 결합하여 Render 트리를 만든다.
  5. 레이아웃 작업을 통해 사용자에게 그려줄 영역을 계산하고 화면에 뿌려준다.
  6. 중간에 javascript 만나면 javascript runtime환경에 수행권한을 넘겨 결과값을 받는다.(DOM 중단)
  7. 생성된 DOM 노드의 레이아웃 값(너비, 높이, 위치) 변경시 영향받은 모든 노드의 수치 재 계산
  8. 렌더트리 재 생성(reflow), 재 생성된 렌더 트리를 다시 그림(repaint)
  9. reflow가 이루어졌다고해서 반드시 repaint가 일어나는것은 아님. 레이아웃 수치에 영향을 미치지 않으면 repaint만 수행(ex: bg-color, visibility)

# HTML Body 최하단에 script태그를 두어야 하는 이유

  • script 태그를 처리할때 DOM 파싱이 중단되므로 사용자에게 화면이 늦게 그려질 수 있다.
  • 따라서 최하단에 두어 모든 DOM 노드가 그려진 뒤 javascript를 수행될 수 있도록 하는것이 일반적으로 좋다.
  • 브라우저 저장소는 쿠키가 있으며, HTML5에서 추가된 WebStorage(LocalStorage, SessionStorage)가 있다
  • 웹 애플리케이션에서 쿠키를 설정하면, 이후 모든 웹 요청은 쿠키정보를 포함하여 서버로 전송
  • WebStorage는 클라이언트에만 존재하고 서버로 전송하지 않아 네트워크 트래픽 비용을 줄여준다.
  • 단순 문자열만 저장할 수 있으며 용량 제한이 있다.
  • 데이터가 영구적이지 못하다.(만료기간이 있음)

# Local Storage

  • key/value 형태로 데이터 저장
  • 데이터를 영구적으로 저장할 수 있다.

# Session Storage

  • key/value 형태로 데이터 저장
  • 브라우저가 종료되면 데이터도 같이 저장되는 특성

# margin / padding

  • margin / border / padding

# REST API

  • HTTP URI를 통해 Resource를 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD를 정의
  • API란 데이터와 기능의 집합을 제공하여 서로 정보를 교환 가능하도록 하는것

# 필요한 이유

  • 다양한 클라이언트가 등장하면서 멀티 플랫폼의 지원을 위한 아키텍쳐가 필요해짐

# 장점

  • HTTP 프로토콜 인프라를 그대로 사용하여 REST API 사용을 위한 별도 인프라 구축필요x
  • HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능
  • 서버와 클라이언트의 역할 명확히 분리 가능

# 단점

  • 구형 브라우저는 PUT, DELETE를 지원하지 않아 사용할 수 있는 HTTP Method가 제한적

# SPA / MPA / SSR / CSR

# SPA : Single Page Application

  • 처음에만 페이지를 받아오고 이후에는 새로운 페이지를 받아오지 않음
  • 페이지가 한번 로딩된 이후 데이터를 수정하거나 조회할 때, 페이지가 새로고침되지 않음
  • SPA를 CSR 방식으로 렌더링한다.

# SPA 장점

  1. 자연스러운 UX (깜빡거림x)
  2. 필요한 리소스만 부분적으로 로딩하기때문에 성능이 좋다.
    • 서버에게 정적리소스 1번만 요청하고 받은 리소스는 전부 저장(캐시)
  3. 서버의 템플릿 연산을 클라이언트로 분산하여 성능에 좋음
  4. 컴포넌트별 개발이 용이하다.
  5. 모바일 앱 개발을 염두에 둔다면 동일한 API를 사용하도록 설계 가능

# SPA 단점

  1. JavaScript 파일을 번들링해서 한번에 받기 때문에 처음 구동속도가 느리다.
  2. SEO가 어렵다
  3. 보안 이슈
    • SSR에서는 사용자에 대한 정보를 서버측에서 세션으로 관리.
    • CSR 방식에서는 클라이언트 측의 쿠키말고 사용자 정보를 저장할 공간이 마땅치않음

# MPA : Multi Page Application

  • 서버로부터 완전한 페이지를 받아오고 이후에 데이터를 수정하거나 조회할때, 다른 완전한 페이지로 이동
  • 새로운 페이지를 요청할 때마다 정적 리소스 다운로드. 매번 페이지가 다시 렌더링된다.
  • MPA를 SSR 방식으로 렌더링한다.

# MPA 장점

  1. SEO 관점에서 유리
    • 완성된 형태의 HTML 파일을 서버로부터 전달받기때문에 검색엔진이 페이지를 크롤링하기 적합
  2. 첫 로딩시간이 매우 짧다.
    • 서버에서 이미 렌더링해서 가져오기 때문.
    • 클라이언트가 JS파일을 모두 다운로드하고 적용하기 전까지 각각의 기능은 동작하지 않음.

# MPA 단점

  1. 새로운 페이지를 이동하면 깜빡인다.
  2. 페이지 이동시 불필요한 템플릿도 중복해서 로딩
  3. 서버 렌더링에 따른 부하
  4. 모바일 앱 개발시 추가적인 백엔드 작업 필요

# CORS 뜻과 대처 (SOP와 연관지어서)

# Same-Origin Policy

  • 브라우저가 동일 출처 정책(SOP)를 지켜서 다른 출처의 리소스 접근을 금지하기 때문.
  • 실제 웹페이지는 자주 다른 출처의 리소스를 사용해야함
  • 이에 따른 예외 조항이 CORS임
  • XSS나 XSRF 등의 보안 취약점을 노린 공격을 방어할 수 있다.

# CORS란?

  • Cross Origin Resource Sharing의 약자로 브라우저에서 다른 출처의 리소스를 공유하는 방법에 대한것
  • Origin : Protocol + Host + Port를 합친 것 (location.origin으로 확인 가능)
  • Access-Control-Allow-Origin 헤더에 작성된 출처만 브라우저가 리소스를 접근할 수 있도록 허용

# CORS 동작원리

  • 단순요청 / 예비요청을 먼저 보내보는 방법 2가지가 있다.
  1. Simple Request
  • 단순 요청은 서버에 API를 요청하고, 서버는 Access-Control-Allow-Origin 헤더를 포함한 응답을 브라우저에 보냄.
  • 브라우저는 Access-Control-Allow-Origin 헤더를 확인해서 CORS 동작을 수행할지 판단.
    요청메시지는 GET, HEAD, POST 중에 1개
  1. Preflight request
  • 서버에 예비 요청을 보내서 안전한지 판단한 후 본 요청을 보냄
  • 실제 리소스를 요청하기 전에 OPTION 메소드를 통해 실제 요청을 전송할지 판단.

# CSRF (Cross Site Request Forgery)

  • 참고자료 (opens new window)
  • 특정 웹사이트가 사용자의 브라우저를 신용하여 발생하는 공격
  • 사용자가 자신의 의지와 무관하게 공격자가 의도한 행위(수정, 삭제, 등록)을 웹사이트에 요청하게 만드는 공격
  • 사용자가 로그인한 상태에서 XSS 공격코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격이 믿을 수 있는 사용자로부터 발송된것으로 판단하여 노출

# 방어법

  1. Referrer 검증
  • back-end단에서 request의 referrer를 확인하여 domain이 일치하는지 검증하는 방법
  • 하지만 같은 domain내에 XSS 취약점이 있다면 CSRF 공격에 취약해짐
  1. Security Token (CSRF Token 사용)
  • 사용자 session에 임의의 난수 값 저장하고 사용자 요청마다 해당 난수값 포함시켜 전송
  • 세션에 저장된 토큰값과 요청 파라미터에 전달되는 토큰값 검증
  • 하지만 같은 domain내에 XSS 취약점이 있다면 CSRF 공격에 취약해짐
  1. Double Submit Cookie 검증
  • 웹 브라우저의 Same Origin 정책으로 자바스크립트에서 타 도메인의 쿠키 값을 확인/수정하지 못한다는것 이용
  • 스크립트 단에서 요청시 난수 값을 생성하여 쿠키에 저장
  • 동일한 난수 값을 요청 파라미터 or 헤더에도 저장하여 서버로 전송
  • 서버에서는 쿠키의 토큰값이랑 파라미터의 토큰값이랑 일치하는지만 검사하면됨

# 이벤트 버블링

  • 특정 화면에서 이벤트가 발생했을 때, 해당 이벤트가 상위의 요소들로 전달되어가는 특징
  • 이벤트 위임의 동작 매커니즘
  • 막기 위해서는 stopPropagation(); 의 web API를 사용한다.

# 이벤트 캡쳐링

  • 기본적으로 이벤트 버블링은 child -> parent인데 반대로 구현한것을 이벤트 캡쳐링이라 한다.
  • addEventListener 옵션에 capture : true로 설정한다.

# display 속성

Last Updated: 5/2/2022, 9:05:28 PM

←