undefined
WEB CS 기술면접 대비 간단 정리 본문
브라우저 동작 방법
사용자가 선택한 자원을 서버에 요청 ⇒ 브라우저에 표시
자원의 주소는 URI에 의해 결정됨
브라우저는 웹표준기구인 w3c에서 정한 명세에 따라 자원을 해석한다.
- 사용자가 서버에 요청함
- 해당 페이지의 자원이 보내짐
- 렌더링 엔진을 통해 HTML과 CSS를 명세에 따라 해석
- HTML의 파싱을 통해 DOM Tree 구축
- CSS의 파싱을 통해 스타일구조체 생성
- 렌더트리 구축
- 렌더트리 배치
- UI 백엔드의 그리기 시작
렌더링
HTML 파싱 → 콘텐츠 트리 내부에서 태그를 DOM Node로 변환 → CSS와 함께 스타일 파싱 → 렌더링 트리 구축 → 렌더링 트리 배치 (정확한 위치에 표시) → 백엔드 UI가 그리기 시작
모든 렌더링이 끝날 때 까지 대기하는 것이 아니라 실시간으로 받은 내용을 화면에 표시한다
DOM
문서객체모델
웹브라우저가 HTML페이지를 인식하는 방식
파싱: 브라우저가 코드를 이해하고 사용할 수 있도록 DOM tree구조로 변환시키는 것
BOM
브라우저 - 자바스크립트의 소통을 위해 만들어진 모델
다큐먼트 히스토리 등이 있다.
HTTP Request Method
GET
URL 형식으로 서버에 리소스 요청
HEAD
문서에대한 요청이아닌 문서의 정보 요청
Body는 비어있고 Head만 반환
POST
서버에 리소스를 보냄
Body에 반환
PUT
리소스를 갱신
Delete
리소스 삭제
CONNECT
클라이언트와 서버의 중간 경유를 위함
Proxy 의 SSL 통신을 위해 사용
OPTIONS
서버측의 정보에대한 질의를 위함
TRACE
리퀘스트의 경로를 알기위함
PATCH
일부분만 갱신
PUT과 다름
HTTP Status Code
10X → 정보확인
20X → 통신성공
30X → 리다이렉트
40X → 클라이언트오류
50X → 서버오류
Web Server 와 WAS
정적인 페이지 : 요청된 리소스 그대로 반환
동적인 페이지 : 요청된 리소스를 동적인 컨텐츠로 반환
웹서버의 기능
- 정적인 컨텐츠 제공
- 동적인 컨텐츠 제공 = WAS에 전달
WAS = web application server
HTTP 통신을 통해 어플리케이션을 실행하는 미들웨어
WAS의 기능
- 실행환경 및 데이터베이스 접근
- 트랜잭션 관리
- 비즈니스 로직 수행
웹서버가 필요한 이유
정적인 컨텐츠만 처리하도록 하여 서버의 부담을 줄임
WAS가 필요한 이유
WAS를 통해 요청이 들어올 때마다 비즈니스 로직에 따른 동적인 컨텐츠를 반환하여 자원을 효율적으로 사용
*모든 결과값을 미리 만들어 놓지 않아도 된다.
즉, 웹서버와 WAS를 병행하여 서버의 부담을 분산시킴으로써 서버의 부하를 방지시키는 것이 옳다.
WEB SERVER - WAS - SERVLET
웹서버에서 요청을 받고 WAS로 보냄
WAS는 서블릿리퀘스트로 변환하여 서블릿으로 보냄
서블릿은 동적컨텐츠를 WAS에 반환
WAS는 HTTP리퀘스트로 웹서버에 보냄
OAuth
다른 웹사이트에서의 사용자의 정보에 대한 접근권한을 부여할 수 있는 개방형 표준 방법
소비자가 서비스제공자에 요청토큰 요청
서비스제공자가 소바지에게 요청토큰 발급
소비자는 사용자를 서비스제공자로 이동시켜 사용자 인증을 요구
서비스 제공자는 소비자에게 이동시킨다.
소비자는 접근토근 요청
서비스제공자는 접근토큰 발급
소비자는 사용자정보에 접근
JWT
Json Web Token
가볍고 안정성있게 정보를 전달한다.
구성요소
- 헤더
- 페이로드
- 토큰에 담을 정보저장, 정보의 조각 = 클레임
- 등록된 클레임, 공개된 클레임, 비공개된 클레임
- 등록된클레임: 토큰정보, 나머지 : 서비스를 위한 정보
- 시그니쳐
- 해쉬키 생성하여 base64의 형태로 표현
로그인 시의 JWP
Access토큰과 RefreshToken
엑세스 토큰은 말그대로 접근을 위한 토큰 ⇒ 도난 방지를 위한 짧은 만료시간이 특징
리프레시 토큰은 엑세스 토큰을 발급받기 위한 토큰 ⇒ 엑세스 보단 길다
엑세스 토큰이 탈취되어도 짧은 만료시간이 지나면 훔친자는 더는 사용할 수 없다.
다만 사용자는 리프레시 토큰으로 다시 발급받아 사용가능
UI와 UX
UI : 사용자가 앱을 사용할 때 마주하는 인터페이스
UX : 사용자를 더 편리하고 효율적인 방향으로 프로세스를 진행시키는것
데이터와 통계를 바탕으로 앱을 사용하는 사용자를 분석하여 상황에 맞도록 변화시켜야함
CSR vs SSR
csr : 클라이언트 사이드 렌더링
ssr : 서버 사이드 렌더링
csr은 대표적으로 SPA가 있다.
csr은 필요한 데이터만 받아와 서버의 트래픽을 감소시킬 수 있다.
따라서 UX에 도움이 된다.
하지만 SEO에 대하여 크롤러가 데이터 수집을 못할 가능성이 있다.
그리고 자바스크립트가 화면을 그리는 시간까지 기다려야 하기 때문에 초기구동시간이 느리다.
ssr은 렌더링된 html을 초기화면에서 바로 보여줄 수 있으므로 초기구동시간이 빠르다
하지만 유저가 요청할 때마다 JS가 다운로드되어 페이지 전환이 느리다.
SEO에 문제가 없다.
네이티브앱 웹앱 하이브리드앱
네이티브앱
안드로이드 앱, 아이폰 앱이 있으며 성능이 다른 앱보다 가장 뛰어나나 플랫폼에 한정적이다.
모바일 웹앱
웹앱을 모바일의 크기로 줄여놓은것
간편함
플랫폼 API는 X / 브라우저 API만 사용가능 함
친화적 터치앱 제작에 불편
하이브리드 앱
내용을 웹앱의 형식으로 만들고 네이티브앱의 형식으로 배포
플랫폼API + 브라우저API 가능
네이티브 개발지식을 요한다
PWA
progressive web app
앱 수준의 사용자경험을 웹에서 구현하기 위한 환경
OSI 7계층
물리 - 데이터 링크 - 네트워크 - 전송 - 세션 - 표현 - 응용
참고 : https://github.com/gyoogle/tech-interview-for-developer
'CS' 카테고리의 다른 글
디자인 패턴(design pattern)에 대하여 (0) | 2022.10.22 |
---|---|
사용자 로그인 인증 방법 알아보기 - React Authentication (0) | 2022.10.21 |
MVC 아키텍쳐 (0) | 2022.09.11 |
Test Driven Development (TDD) (0) | 2022.09.11 |
REST API (0) | 2022.09.08 |