029 | 네트워크 - 웹을 구성하는 기술

💙 웹 애플리케이션 작동원리

🤍 네이티브 애플리케이션

• 특정 기기에 설치해서 사용하는 애플리케이션… 그냥 뭐 어플 다운받는거
• 특정 실행환경에 종속(Apple iOS, Android OS, Windows, …)
  • iOS용으로 나온 애플리케이션은 안드로이드에서 실행 불가

👍🏻 장점

• 웹 애플리케이션보다 빠름
• 애플리케이션이 설치된 기기의 리소스에 접근이 용이 (ex. GPS, 카메라, …)
• 오프라인에서 사용 가능
• 웹 애플리케이션에 비해 안전 (모바일은 앱스토어 승인 필요)

👎🏻 단점

• 웹 애플리케이션에 비해 많이 드는 개발비용 (멀티 플랫폼 개발 등)
• 어려운 빠른 업데이트
• 앱스토어 승인 시 비용 발생, 승인도 힘듦

🤍 웹 애플리케이션

• 웹 브라우저로 접근 가능한 애플리케이션

👍🏻 장점

• 브라우저에서 실행되기 때문에 설치나 다운로드가 필요 없음
• 네이티브 애플리케이션에 비해 만들기가 비교적 간편
• 유지관리 용이
• 앱스토어 승인 필요 없음

👎🏻 단점

• 온라인에서만 사용 가능
• 네이티브 애플리케이션에 비해 느린 속도
• 앱스토어에서 관리되지 않기 때문에 떨어지는 사용자 접근성
  • 검색 말고는 방법이 없기 때문. 그리고 방대함
• 질적으로나 보안상 위험에 노출되기 쉬움

🤍 요즘은,

• 네이티브 | 웹 애플리케이션 서로 가진 기술의 장점을 흡수하고 단점을 보완하면서 발전 ing

💙 웹을 구성하는 기술

🤍 웹(WEB)

• 인터넷에서 제공되는 하이퍼텍스트 시스템
  • 하이퍼텍스트: 문서 안에 다른 문서의 위치정보 등을 포함하여 문서 간의 정보를 서로 연관 지어 참조 할 수 있는 문서

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

• 웹에서 제공되는 서비스
  • 클라이언트: (사용자가 직접) 서비스를 이용
  • 서버: 서비스 제공
  ⇒ 이 구조를 클라이언트-서버 아키텍처라고 부름

🤍 웹 애플리케이션 아키텍처

Website | Web application

• Website: 정적 페이지들의 집합
• Web application: 웹사이트가 정적 페이지 + 동적 페이지 포함

웹 애플리케이션 특징

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

웹 애플리케이션 아키텍처

• 클라이언트-서버 간의 연결에 대한 설명 방법으로, 애플리케이션 내부의 요소들이 상호간에어떻게 소통하는지 설명
• 유저가 웹브라우저 에서 요청을 하면 애플리케이션의 다양한 요소들(브라우저, 유저 인터페이스, 미들웨어, 서버, 데이터베이스)이 상호작용을 하고, 웹 애플리케이션 아키텍처는 이러한 요소들이 상호작용을 유지할 수 있도록 해줌
• 유저가 웹 애플리케이션과 상호작용을 할 때, 응답은 보통 찰나에 이루어지는데, 유저의 수없이 많은 다양한 요청과 입력에 대해 알맞은 응답을 할 수 있는지 생각해봐야됨. 이러한 점 때문에 웹 애플리케이션 서버는 많은 부분 요소와 외부 애플리케이션 또한 공유 하여 설계됨
• 웹 애플리케이션은 인터넷에 공개되는 순간부터 글로벌 네트워크의 트래픽에 노출 될 수 있기 때문에 신뢰성(reliability), 보안성(security), 견고성(robustness), 확장성(scalability) 고려해야함

🤍 웹 애플리케이션 요청 흐름

🌐 https://www.google.co.kr 로 접속

• 브라우저에 https://www.google.co.kr 를 입력
• URL을 입력 받은 브라우저는 서버의 주소를 찾기 위해 DNS 서버에 요청을 보냄
• IP 주소를 찾으면 해당 주소에 HTTPS 요청을 보내는데, 방문 기록이 캐시 메모리에 있으면 주소를 캐시 메모리에서 가져옴
• 웹서버에 요청이 도착하면 웹서버는 저장소에 요청을 보내 페이지 관련 데이터들을 가져옴
• 정보들은 가져오는 중에 비지니스 로직이 작용되고,로직들을 통해 요청 받은 데이터들이 처리되고 브라우저에 응답
  (비지니스 로직들은 각 데이터들을 어떻게 다룰지가 정해져 있음)
• 요청들이 브라우저에 응답으로 돌아왔을 때 web page 화면에서 출력

🤍 웹 애플리케이션 구현 - 구성 방식

Single Page Application

• 유저의 입력과 요청에 의한 콘텐츠나 정보의 최신화가 페이지를 새로 불러오지 않고 현재 페이지에서 이루어짐
• 필수적인 요소만을 요청해서 페이지가 새로 고침 되는 것을 방지해 유저 경험 극대화
• ⇒ AJAX, Asynchronous JavaScript, XML 사용
• 이러한 Single Page Application의 기능을 통해 유저는 페이지가 새로 고침 되지 않고, 요청한 응답을 기다리면서 페이지와 상호작용이 가능

Microservice architecture

• 작고 가벼운 특정한 한가지 기능에 집중한 웹 애플리케이션
• 각 애플리케이션의 기능 요소들은 상호간에 의존적으로 설계되지 않으므로, 개발단계에서도 그리고 개발 완성이후로도 같은 개발 언어를 사용할 필요가 없음
• 개발자는 원하는 언어를 사용해 기능 개발에 유연성을 더 갖게 되고, 개발 과정의 전반적인 속도와 생산성이 향상됨

Serverless Architectures

• 개발자가 웹 애플리케이션의 서버와 기타 기반 기능들에 대해 외부의 3자인 클라우드 서비스 제공자에게 의탁하는 방식으로, 기본적인 서버나 기반 기능들을 걱정할 필요 없이 특정기능의 개발에 집중 할 수 있게 함

🤍 웹 애플리케이션 구현 - 구현 기술

HTTP(HyperText Transfer Protocol)

• 웹 브라우저상에서 클라이언트와 서버간의 통신을 담당하는 프로토콜
• 클라이언트에서의 데이터 요청과 서버에서의 요청에 대한 응답을 반복하면서 웹 애플리케이션을 작동시
• HTTP 요청을 할 때는 하고싶은 처리의 종류를 나타내는 메서드의 이름과 처리 대상의 이름이 포함
• HTTP 응답에는 요청에 대한 처리 결과를 나타내는 상태 코드와 헤더, 실제 처리결과인 메시지가 포함
• 이름처럼 처음에는 주로 문서 전송에 이용 되었지만, 지금은 대용량의 이미지, 음성, 영상, 파일 데이터 등 거의 모든 방식의 데이터 전송을 HTTP를 이용해서 처리함

Cookie

• 웹 애플리케이션을 사용하는 유저의 정보를 클라이언트에 보관하고, 다음 접속부터는 유저의 정보를 클라이언트가 서버로 보내서 유저를 서버가 식별하게 한다. 이후 쿠키에 담긴 내용으로 웹 애플리케이션에 유저가 설정했던 항목들에 대해 저장을 해서 다음에 이어서 같은 방식으로 작동하게 도와준다.

Session

• 서버에 Session-Id 라는 고유 아이디를 할당해서 유저를 식별한다. 단순하고 유출이 되면 안되는 정보는 서버에서 관리를 하면서 세션 ID와 매칭하고 저장해서 관리한다.
• 주로 사용되는 방법은, 세션정보는 쿠키에서 관리하고, 실제 매칭되는 값들은 서버 측에서 관리하는 것이 일반적이다.

사용자 인증

• 사용자 인증은 의도하지 않은 제 삼자가 마음대로 컴퓨터나 시스템의 이용을 차단하기 위해 사용하는데, 웹에서의 인증은 개인정보를 바탕으로 한다.

💙 SSR  |  CSR

🤍 SSR(Server Side Rendering)

• 서버쪽에서 렌더링 준비를 끝낸 상태로 클라이언트에 전달하는 방식
• 서버에서 이미 '렌더 가능한' 상태로 클라이언트에 전달되기 때문에 JS가 다운로드 되는 동안 사용자는 다른 일을 할 수 있음

SSR을 사용할 때

• SEO(serach engine optimization: 검색 엔진 최적화)가 우선순위일 때
• 웹 페이지의 첫 화면 렌더링이 빠르게 필요할 때
• 웹 페이지가 사용자와 상호작용이 적을 때

SSR 위험성

• 자원이용이 서버에 집중되기 때문에 애플리케이션 유지비용이 높음
• 일부 Thrid party JS 라이브러리의 경우 서버사이드 렌더링이 불가능할 수 있음

🤍 CSR(Client Side Rendering)

• 렌더링이 클라이언트측에서 일어남
• 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내주고, 클라이언트는 그것을 받아 렌더링을 시작함
• 서버 처리 없이 클라이언트로 전송하기 때문에 JS가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 할 수 있는게 없음

CSR을 사용할 때

• SEO가 우선순위가 아닐 때
• 사이트에 상호 작용이 있을 때
  CSR은 빠른 라우팅으로 강력한 사용자 경험을 제공
• 웹 애플리케이션을 제작할 때
  CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있음
• 서버에 성능이 좋지 않을 때

CSR 위험성

• 느린 렌더링 속도로 사용자 경험이 안 좋아 질 수 있음
• 모든 렌더링의 부하가 클라이언트 쪽에 집중되기 때문에 UX 호불호 갈림
• Javascript가 렌더링해야 하는 정보들은 Google 같은 search engine index에 포함이 안될 가능성이 매우 높아 search engine bots와 상성이 안 좋음

🤍 SSR  |  CSR 차이점

1. 페이지 로딩 시간

• Initial Load Time: 사용자가 사이트를 처음 로드하는 데 걸리는 평균 시간
  • SSR에서 첫 페이지를 훨씬 빨리 로드할 수 있음
  • CSR을 사용할 때 브라우저는 기본 HTML, CSS 및 필요한 모든 스크립트를 로드한 후 HTML을 브라우저의 사용 가능한 콘텐츠로 컴파일하므로 느림
• Subsequent Load Time: 한 페이지에서 다른 페이지로 이동하는 데 걸리는 시간
  • SSR은 첫 페이지 로드 시간에 대해 동일한 요청 주기를 따르기 때문에 느림
  • CSR은 모든 스크립트가 미리 로드되어 있으므로 페이지 로드 시간 단축

2. 캐싱 임팩트

• 캐싱은 파일 복사본을 캐시(또는 임시 저장 위치)에 저장하여 더 빨리 액세스할 수 있도록 하는 기술로, 브라우저 및 웹 서버는 사용자 컴퓨터에서 재사용 가능한 스크립트에 대한 캐싱 메커니즘을 적용하기 때문에 SSR 및 CSR의 전체 로드 시간이 개선됨
• SSR의 경우 서버에 대한 요청이 항상 전송되므로 로드 시간이 길어짐
  그래도 캐싱 메커니즘은 브라우저가 캐시에서 스크립트를 검색하기 때문에 렌더링 속도를 향상시키는 데 도움이 됨
• CSR 기반 웹 앱은 페이지가 로드되면 서버에 더 이상 요청을 보낼 필요가 없기 때문에 인터넷 없이도 실행 가능

3. SEO에 미치는 영향

• SSR을 사용하면 전체 페이지가 메타데이터로 컴파일됨. 최종 HTML 콘텐츠를 수신한 후 프론트로 전달되므로 SSR을 사용하면 검색 엔진 크롤러의 JS 사용 여부 관계없이 페이지 메타데이터가 정확하게 유지됨
• CSR 사용 시 JS를 통해 사이트의 콘텐츠가 자동으로 생성됨. 한 페이지에서 다른 페이지로 메타데이터를 변경할 때 JS 실행에 의존해야됨. 플러그인이나 라이브러리 모듈을 사용할 때 각 페이지에 대한 메타데이터를 설정하여 클라이언트 측에서 렌더링해야됨

✅ Ref.

SSR vs CSR: Which Method Works Best? - Growth Rocket