[Web] 웹 구성 간 흐름

0. 웹 전체 개요 학습의 중요성

웹의 본질은 클라이언트가(웹 브라우저)가 요청을 주고 웹 서버가 그에 맞는 결과는 받는 그 사이의 모든 것이다.

1. 웹의 등장

세계의 여러 대학과 연구기관에서 일하는 물리학자들 상호간 신속한 정보교환과 공동 연구를 위해 개발

• 여러 컴퓨터에 저장된 논문, 실험결과 등의 문서들을 공유하기 위한 기술
  1.  논문, 실험 결과 등의 문서 = 웹 페이지
     • 웹 페이지는 특수한 언어(HTML)로 제작되어 있어서 인간이 바로 읽을 수 없음
  2. 웹 페이지 리더기 = 웹 브라우저
  3. 여러 컴퓨터 = 웹 서버 : 각 컴퓨터는 웹 페이지를 제공한다(serve)는 측면에서 웹 페이지 제공자 = 웹서버라고 할 수 있음

 

1-1. 웹 페이지

• HTML : 문서
• CSS : 서식 - Cascading의 의미는 무엇일까?
  • Selector를 통해 지정하여 스타일을 적용하는데 다음 2개의 우선순위에 따라 적용된다.
    1.  Specificity 명시도에 따라 명료하게 정의될수록(Specific 할수록) 우선순위가 높다.
    2. 아래로 갈수록 우선순위가 높다.
• JS : 이벤트 - 유저와 웹 페이지 사이의 모든 인터렉션
  • 버튼을 누르면 어떤 영역이 색이 변한다거나
  • 어떤 링크를 눌렀을 때 안내창이 뜬다거나

1-1-2. 웹 브라우저

웹 페이지 3개 구성 요소(HTML, CSS, JS) 모두 실행 및 렌더하여, 유저에게 결과 웹 페이지 노출

1. HTML ~= DOM : HTML은 단지 텍스트, DOM은 HTML 조작을 위해 제공되는 API(객체)
2. CSS ~= CSSOM : CSS는 단지 텍스트, CSSOM은 CSS 조작을 위해 제공되는 API(객체)
3. DOM Tree + CSSOM -> Render Tree
4. Render Tree -> Layout(Reflow) -> Paint(Repaint)
   • 매번 HTML이 바뀔때마다 매번 Repaint가 실행된다.
5. HTML + CSS 가 웹 브라우저에서 유저에게 표기가 완료되면, 이제 JS를 통해 인터렉션 이벤트 등을 적용
   • Time to interactive(TTI) : HTML + CSS 로드 뒤 JS를 통해 마우스 이벤트 등 비로소 적용 됬을 때

2. 인터넷

웹의 본질에 대해 설명할 때 어떤 연구실(내부 네트워크)에 있는 연구원 5명의 컴퓨터를 예로 들었다.

논문과 연구 결과를 모두에게 알려주고, 또 세상의 연구들에 접근하기 위해 외부 네트워크와 연결이 필요하다.

• Intranet(인트라넷, 사내망) : 대학, 연구기관, 집과 같이 갇힌 공간에 국한된 네트워크
  • 외부로 트래픽이 나가지 않아 보안을 위해 혹은 개인/단체적 활동을 위해 사용
  • LAN : 블리자드 배틀넷과 같은 온라인 서비스가 불가능한 경우 친구와 단둘이 방을 만들어 플레이하는 것
    • 여기서 단둘이 방을 만든다는 것 = 인트라넷(사내망) 구축이 필요
      • 만약 멀리 떨어져 있어 컴퓨터간 회선을 연결할 방법이 없을 때는 어떻게 해야할까?
      • 가상의 인트라넷을 구축하면 되지 않을까?
      • 가상의 인트라넷 = VPN (VIrtual Private Network)
      • VPN은 대부분 우회 프로그램으로 알고 있지만 정확한 원리는 한국에 있는 내가 미국 네트워크에 연결된 미국에 있는 사람인 척 하는 것이다.
• Internet(인터넷) : (외부와 연결되고자는) 인트라넷들을 외부로 모두 연결한 네트워크
  • 사내 네트워크인 인트라넷이 내부 사용뿐 아니라 외부와 연결되고 싶을 때 게이트웨이를 통해 연결하면 된다.
  • 게이트웨이 : 내부 네트워크(회선)와 외부 네트워크(회선) 연결 통로(톨게이트와 비슷한 의미)

웹 서버 주소 : IP 주소와 도메인 네임

각 물리학자의 컴퓨터를 웹 서버라고 생각했을 때, 모든 웹 서버는 주소를 갖는다. 

• 이 주소의 정식 명칭은 IP 주소라고 하며 아래와 같이 표현한다 | 네트워크 주소라고도 한다.
  • 예) 126.10.1.12
• 하지만 이러한 IP주소를 사람이 읽고 외우기 어려워 영어로 된 별명(Alias 별칭)인 도메인 네임을 사용
  • 예) www.naver.com
• 모든 웹 서버는 IP주소 기반으로 통신되어야 하기 때문에 주소가 아닌 이름인것
• 그말은 웹 서버와의 통신을 위해서는 이름(Alias)의 실제 IP주소를 기반으로 진행되어야 한다.
  • 어떤 도메인 네임이 - 어떤 웹 서버 IP주소인지 알아야 한다.
    • MAP 매핑 : Key-Value 짝꿍(Pair) 집합
    • 도메인 네임 - 웹 서버 IP 매핑 정보 = 전화번호부 = DNS (Domain Name Server)
  • DNS (Domain Name System) : 어떤 도메인 네임이 어떤 IP주소인지 검색 및 변환 과정을 의미
• 이제 우린 웹 브라우저에 www.naver.com이라는 URI을 입력했을 때 어떻게 동작하는지 설명할 수 있다.
  1. 웹 브라우저에 www.naver.com 도메인 네임을 입력하면, 실제 IP 주소가 무엇인지 DNS 절차로 확인
  2. 실제 웹 서버의 IP주소를 알았으니 웹 브라우저는 원래 하고자 했던 요청을 진행(웹 페이지 반환해오기)

4. 웹 검색 엔진 : 구글과 SEO

세계 모든 웹 서버의 웹 페이지 정보들에 접근(조회)하고 싶다면?

세계 모든 웹 서버의 도메인 네임(IP주소)을 통해 직접 일일히 웹 페이지 정보들에 접근(조회)해야 할까?

• 무언가 나 대신 세계 모든 웹 서버의 웹 페이지들을 미리 다 찾아놓고, 분류 및 정리한 뒤에 내 검색어에 따라 그에 적합한 웹 페이지들만 골라 전달해주면 어떨까?
  • 무언가 = 구글, 네이버, 다음과 같은 서비스(검색엔진)
  • 다 찾아놓기 = 웹 크롤링 : 세계 모든 웹 서버의 웹 페이지 정보 수집(봇)
  • 분류 및 정리한 뒤 = 인덱싱 : 앞서 수집한 전체 웹 페이지들을 상관관계별로 분류
    • 구글 검색 엔진 알고리즘의 시초 PageRank
  • 내 검색어에 따라 그에 적합한 웹 페이지들만 골라 전달 = 검색엔진 : 검색 결과 반환

4-1. 검색엔진

검색어와 검색 결과의 연관성이 구글같은 검색엔진을 사용하는 고객들의 만족도 및 검색 엔진의 사명이다.

• 세상 모든 웹 서버의 웹 페이지는 정말 다양하며 각기 가지고 있는 정보도 다 다르다.
• 수 많은 웹 페이지속에서 내 웹 페이지를 관심있는 사람들이 검색했을 때 적절하게 노출시키는 방법
• SEO (Search Engine Optimization) : 검색 시 상위 노출
  • 사용자 입장에서 생각했을 때, 웹 페이지안에 있는 내용도 좋아야하고(관련된 내용), 이벤트 및 페이지 성능도 좋아야함
  • 좋은 내용 = Good Contents
  • Semantic HTML
  • 키워드 및 메타 태그
  • 성능 Performance Metrics
  • 웹 접근성

4-1-1. 웹 페이지의 성능 Performance Metics

웹 페이지의 만족도는 연관된 정보의 질과 양 + 페이지 이동 및 이벤트 반응 속도(성능)

• Load Time
• FCP : First Contentful Paint - 웹 페이지 내 가장 첫 의미있는 정보가 보여지는 순간까지의 시간
• LCP : Largest Contentful Paint - 웹 페이지 내 가장 큰 의미있는 정보가 보여지는 순간까지의 시간
• TBT : Total Blocking Time - 동기 실행 시 멈춘 시간들
• TTI : Time to Interactive - JS 자바스크립트가 모두 동작 가능한 상태로 준비 완료되기까지의 시간
• FID : First Input Delay - 이벤트 버튼 등을 누르고 그 이벤트 반영이 시작하기까지의 지연 시간

 

5.1 웹 서버(WS)

앞서 배운 웹 서버는 외부에 제공하고자 하는 논문, 연구결과 등을 웹 페이지의 형태로 한곳에 모아 요청에 따라 반환했다.

• 미리 만들어진 웹 페이지를 단순히 요청에 따라 반환하기 때문에 정적 웹 페이지라고 한다.(ex. 포장버거)
  • 만약, 문서의 양이 많아짐에 따라 웹 서버의 용량도 많이 필요해진다면?
  • 만약 유저 정보페이지와 같이 반복적인 템플릿에 일부 정보만 변경된다면?
    • 예) 1000명의 유저 정보 페이지 = 웹 페이지 1000내
    • 예) 1개의 유저 정보 페이지 템플릿 = 웹 페이지
      • 1000명의 유저 정보는 데이터베이스에 저장

• 이미 만들어진 것을 반환하는 것이 아니라, 요청에 따라 웹 페이지를 만드는 동적 웹페이지(ex. 수제 버거)
  • 웹 서버가 요청을 받으면, 먼저 동적 웹 페이지 생성을 한 뒤 결과 웹 페이지를 반환
    • 웹 서버 : (1) 요청 -> (2) (웹 페이지) 반환
    • 어플리케이션 : (1) 요청 -> (2) 연산(데이터 CRUD, 변수 설정, 함수 수행 등) -> (3) 반환
      • 어플리케이션은 함수와 동일하다고 생각하자.
      • 동적 웹 페이지를 만드는 주체는 어플리케이션
  • 웹 서버 요청을 받으면 어플리케이션에게 동적 웹 페이지 생성 작업을 위임
    • 웹 서버가 요청을 받아 어플리케이션을 실행하고 페이지 생성을 요청하기 위한 연결고리 = CGI
    • CGI (Common Gateway Interface) : 웹 서버와 어플리케이션을 연결하기 위한 기술
      • 비유하자면 웹 서버와 어플리케이션을 이어 붙인 형태...

• 처음 CGI가 등장했을 때 어플리케이션은 지금 우리가 쉽게 생각하는 Java나 Python이 아닌 Shell, Bash와 같은 스크립트 언어였다. 유명한 서버 스크립트 언어는 PHP, Perl, Ruby가 있다.
  • PHP (Personal Home Page Tools) : 간단히 홈페이지 제작용 서버 스크립트 언어

 

• 동적 웹 페이지의 장점 : 공간 효율, 실시간성
  • 공간 효율 : 수 많은 페이지들을 웹 서버가 들고있을 필요없이 매번 만들어서 반환하면 된다는 것
  • 실시간성 : 요청이 들어온 순간의 데이터로 만들기 때문에 데이터 및 웹 페이지의 신선도가 높다

5-1. 웹 서버에서 웹 어플리케이션 서버 (AWS)로의 변천사

WS, Web Server 웹 서버(Apache, Nginx 등)

• CGI 초기 = 1 요청 : 1 비상주 프로세스
  • 매번 요청에 따라 프로세스가 실행되고 웹 페이지 만들고 반환하고 죽는다
  • Stateless(비상태성) : 매 요청마다 새로운 프로세스가 생성-실행(반환)-죽음 이기에 때문에 요청 간 정보 없음
    
    • 어제 실행된 프로세스와 오늘 실행한 프로세스는 독립적이다.
• FCGI = 1 요청 : 1 상주 프로세스
  • 매번 요청에 따라 이미 열려있던 프로세스가 웹 페이지를 만들어 반환하고, 프로세스는 계속 살아있는다.
    • 프로세스가 계속 상주해있다보니 위 CGI 초기보다 매 프로세스 준비 기간은 줄어든다.
  • Stateful(상태성) : 아무리 많은 요청이 와도 기존 프로세스가 실행(반환)만 하기에 요청간 정보 공유
    • 어제 실행된 프로세스와 오늘 실행된 프로세스는 같은 프로세스라 같은 정보 공유

 

WAS, Web Application Server, 웹 어플리케이션 서버 (Tomcat)

• 1 요청 : 1 스레드 = 상주 프로세스의 Stateful한 장점과 비상주 Stateless한 장점을 스레드를 통해 얻어냄
  • 하나의 요청이 들어오면, 하나의 스레드가 해당 요청에 생성 및 할당
    • 취소선이 들어간 이유 : 매번 요청마다 스레드를 만들기보다 미리 만들어놓고, 필요에 따라 할당만 하자
  • Servlet 서블릿 : 1 요청에 대해 할당되는 1 자바 스레드를 서블릿이라고 부른다
  • Servlet Container 서블릿 컨테이너 : 요청이 오면 가지고 있는 스레드를 할당하고, 완료 뒤 회수하는 주체

 

템플릿 엔진

동적 웹 페이지를 만들기 위해서는 2개가 필요하다. -> 1. 반복적인 템플릿 2. 데이터

• 반복적인 템플릿 = ViewTemplate
• 데이터 = Model
• 동적 웹 페이지 = View(HTML)

MVC (Model - View - Controller)

데이터베이스에서 Model(데이터)를 조회하여 그것들을 기반으로 View(웹 페이지)를 만들어 Controller가 반환

• Controller : 요청을 받고, 그에 따른 연산(로직)을 시작하고, 그 결과를 반환
  • 어플리케이션과 웹 서버의 관계에서, 웹 서버가 Controller와 비슷하다고 생각이 들었다.
  • 요청을 받고, 결과를 반환하기에 URI가 정의되어 있다.
• Model : 데이터에 대한 조회, 조작
• View : Model(데이터)을 기반으로 만들어진 웹 페이지 + 유저의 동작을 받아 Controller에게 요청 전달
  • 유저가 보는 것 : 웹 페이지 -> Controller가 반환한 것
  • 유저가 하는 것 : 자바스크립트 인터렉션 -> Controller 호출하는 것

6. 웹 페이지 렌더링 방식 3가지

• 미리 만들어진 웹 페이지인 정적 웹 페이지를 요청에 따라 반환
  • SSG (Static Site Generation) : Nginx, S3 - 정적 리소스 반환
• 요청에 따라 동적 웹 페이지를 만들어서 반환
  • 반복적인 템플릿 + 데이터 = 동적 웹 페이지 <- 템플릿 엔진의 역할
    • 템플릿 엔진이 웹 어플리케이션 서버 (WAS)에 있다 = 서버 사이드 템플릿 엔진
      • 웹 어플리케이션 서버 (WAS) 가 동적 웹 페이를 생성 후 반환
        
        • SSR (Server Side Rendering) : Spring Thyeleaf, Next.js
    • 템플릿 엔진이 웹 브라우저에 있다 = 클라이언트 사이드 템플릿 엔진
      • 웹 브라우저가 동적 웹 페이지를 생성 후 반환
        • CSR (Client Side Rendering) : React.js

위의 그림을 이해하며 SSR과 CSR의 차이를 알아보고 각 장단점을 정리해보자.

• SSR (Server Side Rendering) : 웹 서버에서 웹 페이지를 다 만들어 전달해준다.
  • 장점 
    1. 웹 크롤러 입장에서 해당 홈페이지가 가진 모든 웹 페이지를 볼 수 있어 SEO가 가능하다.
  • 단점 :웹 페이지를 요청할때마다 웹 서버가 만들어줘야하기 때문에
    1. 웹 페이지를 만들고, 유저가 보기까지 시간이 오래 걸린다.
    2. 웹 서버의 CPU, 메모리 자원이 사용되기 때문에 AWS 같은 클라우드 사용 시 비용이 부담된다.
• CSR (Client Side Rendering) : 웹 브라우저에서 바로 웹 페이지를 만들어 보여준다.
  • 장점
    1. 위의 그림에서 1번 절차(Initial Loading)에서 큰 파일을 받은 이후 웹 페이지 전환이 빠르다
  • 단점
    1. 위의 그림에서 1번 절차(Initial Loading)을 통해 템플릿 엔진(리엑트 자바스크립트) 파일을 가져 오는데 비용이 오래 걸린다.
       • 첫 페이지를 렌더하기 위해 가져와야하는 파일 용량이 너무 크고, 시간이 너무 오래 걸린다.
    2. 웹 크롤러 입장에서 해당 홈페이지에 어떤 웹 페이지가 있는지 알수 없어 SEO가 불가능하다.