WEB CS 기술면접 대비 간단 정리

브라우저 동작 방법

사용자가 선택한 자원을 서버에 요청 ⇒ 브라우저에 표시

자원의 주소는 URI에 의해 결정됨

브라우저는 웹표준기구인 w3c에서 정한 명세에 따라 자원을 해석한다.

 

1. 사용자가 서버에 요청함
2. 해당 페이지의 자원이 보내짐
3. 렌더링 엔진을 통해 HTML과 CSS를 명세에 따라 해석
4. HTML의 파싱을 통해 DOM Tree 구축
5. CSS의 파싱을 통해 스타일구조체 생성
6. 렌더트리 구축
7. 렌더트리 배치
8. 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