[네트워크] 웹을 구성하는 기술

CS 공부/네트워크

[네트워크] 웹을 구성하는 기술

jungha_k 2022. 10. 4. 13:48

웹의 기본적인 개념

웹 사이트와 웹 어플리케이션의 차이점? : "반응형" , 동적 사이트

단순히 링크를 걸어놓은 사이트가 아닌 유저 반응에 따라 상호작용하는 사이트

웹 어플리케이션의 특징 :

데스크탑 애플리케이션처럼 상호작용 가능하다.
특정 기능을 가지고 있다(정보 검색 등).
정보나 자료 등의 콘텐츠 관리 시스템과 함께 작동한다.

클라이언트-서버 아키텍처 (2티어)

클라이언트 = 사용자

ex) 스타벅스라면, 고객(=클라이언트) / 점원(=서버)

주문(=요청)이 들어오면 점원이 그에 맞는 제품을 내줌(=응답)

*3티어 아키텍쳐 = 클라이언트 + 서버 + 데이터베이스(리소스를 저장하는 곳)

웹 애플리케이션 아키텍처

=> 클라이언트 - 서버 간의 연결에 대한 설명 방법

유저가 웹브라우저 에서 요청을 하면 애플리케이션의
다양한 요소들(브라우저, 유저 인터페이스, 미들웨어, 서버, 데이터베이스,)이 상호작용을 함

웹 애플리케이션 아키텍처 = 이러한 요소들이 상호작용을 유지할 수 있도록 서로를 결부시키는 뼈대

웹 애플리케이션 아키텍처 요청흐름

1. 브라우저에 https://wlikeoxy.tistory.com/ 를 입력

2. 브라우저는 URL을 입력 받으면 서버의 주소를 찾기 위해 DNS 서버에 요청

3. IP 주소를 찾으면 해당 주소에 HTTPS 요청을 보냄
-> 이미 방문 기록이 캐시 메모리에 있으면 주소를 캐시 메모리에서 가져옴

4. 웹서버에 요청이 도착

5. 웹서버는 저장소에 요청을 보내 페이지 관련 데이터들을 가져옴

6. 정보 = 가져오는 중에 비지니스 로직이 작용

7. 비지니스 로직들은 각 데이터들을 어떻게 다룰지가 정해져 있음

8. 로직들을 통해 요청 받은 데이터들이 처리되고 브라우저에 응답

9. 요청들이 브라우저에 응답으로 돌아왔을 때, web page 화면에서 출력

Presentation Layer: 유저와 브라우저 등을 이용해 직접적으로 접촉(Web Server, 유저 인터페이스 요소들)

Application Layer = Business Layer, Business Logic, Domain Logic
유저의 요청을 브라우저로부터 받아서 처리
Application Server가 이 계층에 포함되며 또한, 데이터 접근을 위한 경로를 규격화 하는 등의 과정 有

Data access layer = Persistence layer
애플리케이선의 데이터 저장소에 접근하여 데이터를 불러 오거나 저장을 담당
Application Layer 의 로직들 -> 어느 데이터베이스에 접근해서 데이터를 회수하고 혹은 저장할지를 더 최적화 할 수 있음

Cross-cutting: 주로 보안, 통신, 운영 관리등을 위한 요소들

Third-party integrations: 제 3의 API 서비스를 이용하는 것 ex) 결제 api, ...

웹 애플리케이션을 구현하는 방식과 기술들

웹 어플리케이션 구현 방식

Single Page Application
Microservice architecture
Serverless Architectures

Single Page Application : 일부분만 새롭게 바뀌는 웹페이지 형식(필수적인 요소만을 요청)

유저의 입력과 요청에 의한 콘텐츠, 정보의 최신화는
페이지를 새로 불러오지 않고 현재 페이지에서 이루어짐

페이지가 새로 고침 되는 것을 방지해 유저 경험을 극대화

-> AJAX, Asynchronous JavaScript, XML 주로 사용

Microservice architecture : 작고 가벼운 특정한 한가지 기능에 집중한 웹 애플리케이션

Serverless Architectures : 웹 애플리케이션의 서버와 기타 기반 기능들 = 외부의 3자인 클라우드 서비스 제공자에게 의탁

웹 어플리케이션 구현 기술

1. HTTP(HyperText Transfer Protocol) : 웹 브라우저상에서 클라이언트와 서버간의 통신을 담당하는 프로토콜

(웹애플리케이션 작동 : 요청-반복-요청-반복-....)

2. Cookie & Session

세션정보는 쿠키에서 관리하고, 실제 매칭되는 값들은 서버 측에서 관리

쿠키 : 웹 애플리케이션에 유저가 설정했던 항목들에 대해 쿠키에 저장을 함 -> 재접속시 같은 방식으로 작동하게 도와줌

세션 : 서버에 Session-Id 라는 고유 아이디를 할당해서 유저를 식별

3. 사용자 인증 : 사용자 식별용 고유 아이디와 암호, 개인의 신원또한 파악하는 다요소 인증(MFA), ...

SSR 과 CSR의 기본 개념과 그 차이

둘의 차이 : 페이지가 렌더링 되는 위치

SSR - 서버에서 / CSR - 브라우저(클라이언트) 에서

온라인에서 가구를 주문 했을 때 배송 출발지에서 조립을 완료한 상태로 보내는 것

= 서버에서 웹페이지를 브라우저로 보내기 전에, 서버에서 완전히 렌더링

브라우저가 서버의 URI로 GET 요청을 보내면,
서버는 정해진 웹 페이지 파일을 브라우저로 전송
서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링됩니다.

https://kruschecompany.com/ssr-or-csr-for-progressive-web-app/

온라인에서 가구를 주문 했을 때 조립이 완료된 상태로 오는 것이 아니라,
모든 부품이 최대한 나뉘어 운송이 쉬운 상태로 배송이 된 다음 집에서 조립을 하는 경우와 비슷

브라우저의 요청을 서버로 보내면 ->

서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보냅니다.

이때 서버는 웹 페이지와 함께 JavaScript 파일을 보냅니다.

클라이언트가 웹 페이지를 받으면-> 웹 페이지와 함께 전달된 JavaScript 파일은
브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꿉니다.

	SSR	CSR
장점	SEO(Search Engine Optimization) 가 우선순위인 경우, 일반적으로 SSR(Server Side Rendering) 을 사용 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR 이 적합 웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용	SEO 가 우선순위가 아닌 경우, CSR을 이용 사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공 웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공
단점	자원이용이 서버에 집중되기 때문에 애플리케이션 유지비용이 높음 일부 서드파티 자바스크립트 라이브러리의 경우 서버사이드 렌더링이 불가능할 수 있음	느린 렌더링 속도로 사용자 경험이 안 좋아 질 수 있음 모든 렌더링의 부하가 클라이언트 쪽에 집중되기 -> 사용자에 따라서 경험이 달라질 수 있음 search engine bots 와 상성이 좋지 않음. Javascript가 렌더링해야 하는 정보들은 Google 과 같은 search engine index에 포함이 안될 가능성이 매우 높음
사이트 예시	네이버 블로그 (SEO에 유리한 이점이 있기 때문에, 사용자와 상호작용이 비교적 많지 않기 때문에) , 뉴욕 타임즈 (초기 로딩 속도가 빠르기 때문에, 기사가 검색엔진에 노출되는게 중요하기 때문에(SEO))	아고다 (클라이언트에 필요한 정보만 넘겨주기 때문에 서버에 부담이 적음, 빠른 렌더링으로 UX에 유리)