Web개발의 이해 - FE/BE

개발공부, 부스트코스, 웹 프로그래밍

Web개발의 이해 - FE/BE

HTTP 프로토콜

인터넷 (네트워크 통신)의 이해

  • internet != WWW(World Wide Web)
    • WWW가 인터넷의 전부는 아니다
      • 컴퓨터 하나에 여러 개의 서버 동작 가능
        • 각각의 서버는 포트로 구분되어 동작
          • web : 80
          • email : 25
          • FTP : 21
  • internet
    • TCP/IP 기반의 네트워크가 전세계적으로 확대되어 하나로 연결된, 네트워크들의 결합체

HTTP(Hypertext Transfer Protocol)

  • 웹 브라우저(클라이언트)와 웹 서버 간 서로 통신하기 위한 규약

  • 어떤 종류의 데이터라도 전송할 수 있도록 설계

  • HTTP/2까지 버전이 등장한 상태

장단점

장점
  • 불특정 다수를 대상으로 하는 서비스에 적합
  • 클라이언트와 서버가 계속 연결된 형태가 아니기 때문에 클라이언트와 서버 간의 최대 연결 수보다 훨씬 많은 요청과 응답을 처리 가능
단점
  • 무상태 프로토콜
    • 응답 후 연결을 끊어버리기 때문에, 클라이언트의 이전 상황을 알 수가 없다
    • 정보를 유지하기 위해 Cookie 등이 등장

연결 순서

  • 클라이언트가 서버에게 요청(request)
  • 서버는 클라이언트에게 응답(response)
connect

클라이언트와 웹 서버가 연결

request
요청 헤더
  • 요청 메서드
    • GET : 정보를 요청하기 위해서 사용한다. (SELECT)
    • POST : 정보를 밀어넣기 위해서 사용한다. (INSERT)
    • PUT : 정보를 업데이트하기 위해서 사용한다. (UPDATE)
    • DELETE : 정보를 삭제하기 위해서 사용한다. (DELETE)
    • HEAD : (HTTP)헤더 정보만 요청한다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용한다.
    • OPTIONS : 웹서버가 지원하는 메서드의 종류를 요청한다.
    • TRACE : 클라이언트의 요청을 그대로 반환한다. 예컨데 echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로 사용한다.
  • 요청 url
  • http 프로토콜의 버전
    • 웹 브라우저가 사용하는 프로토콜의 버전 명시
요청 바디
  • 요청 메서드가 POST나 PUT을 사용할 때 들어온다
response
응답 헤더
  • 응답 http 프로토콜의 버전
  • 응답 코드
  • 응답 메시지
  • 응답 날짜
  • 웹 서버 이름
  • 웹 서버 버전
  • 콘텐츠 타입
  • 캐시 제어 방식
  • 콘텐츠 길이
  • etc..
응답 바디
  • 실제 응답 데이터 송출

URL (Uniform Resource Locator)

  • 특정 웹 서버의 특정 파일에 접근하기 위한 경로 혹은 주소

  • 접근프로토콜://IP 주소 or 도메인, 포트 주소/파일 경로/파일명 형식으로 이루어져있다

    • 물리적 서버를 찾기 위해서는 반드시 IP, 도메인 주소가 필요하다
    • 물리적 서버를 찾았다면 그 안의 소프트웨어 서버를 찾기 위해서 포트 값이 필요하다

browser의 동작

크로미움

V8 + Blink을 포함한 구글 브라우저 오픈소스 어플리케이션

해당 단원은 이전에 내가 공부한 내용이 더 자세한 것 같아서, 그 부분으로 마저 정리

브라우저

  • WWW에서 정보를 검색, 표현하고 탐색하기 위한 소프트웨어

    • 사용짜 인터페이스
      • 주소 입력창
      • 이전/다음 버튼
      • 북마크 메뉴 등
      • 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분
    • 네트워크 모듈
      • 서버와 HTTP로 정보를 주고 받는 용도
    • Parser
      • 서버에서 받은 문서를 해석하고 실행해 화면에 렌더
    • 자바스크립트 해석기
      • 자바스크립트 코드를 해석하고 실행
    • UI
      • 기본적인 장치를 그림
      • 플랫폼에서 명시하지 않은 일반적인 인터페이스로 OS 사용자 인터페이스 체계를 사용
    • 브라우저 엔진
      • 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어
      • 소스코드를 실행해 화면에 보여주는 역할
    • 렌더링 엔진
      • 화면에 위치를 잡고 색을 칠하는 역할
      • 요청한 콘텐츠를 표시

    렌더링이란

    화면에 어떻게 보여줘야 할 지를 결정하는 것

    • 자료 저장소
      • 자료를 저장하는 계층
      • 쿠키를 저장하는 것과 같이 모든 종류의 자원을 하드 디스크에 저장할 필요
      • HTML5 명세에는 브라우저가 지원하는 웹 데이터 베이스가 정의

렌더링 엔진 처리 과정

  1. 서버에서 응답으로 받은 HTML 데이터를 파싱한다.

  2. HTML을 파싱한 결과로 DOM Tree를 만든다(빌드한다). (“무엇을” 그릴지 결정한다.)

    • 바이트 → 문자 → 토큰 → 노드 → 객체 모델

      • 변환
        • 브라우저가 HTML의 원시 바이트를 디스크나 네트워크에서 읽어와서, 해당 파일에 대해 지정된 인코딩(예: UTF-8)에 따라 개별 문자로 변환한다
      • 토큰화
        • 브라우저가 문자열을 W3C HTML5 표준에 지정된 고유 토큰으로 변환
      • 렉싱
        • 방출된 토큰은 해당 속성 및 규칙을 정의하는 객체로 변환
      • DOM 생성
        • 생성된 객체는 트리 데이터 구조 내에 연결

  3. 파싱하는 중 CSS 파일 링크를 만나면 CSS 파일을 요청해서 받아온다.

  4. CSS 파일을 읽어서 CSSOM(CSS Object Model)을 만든다(빌드한다). (“어떻게” 그릴지 결정한다.)

  5. DOM Tree와 CSSOM이 모두 만들어지면 이 둘을 사용해 Render Tree를 만든다. (“화면에 그려질 것만” 결정)

  6. Render Tree에 있는 각각의 노드들이 화면의 어디에 어떻게 위치할지 계산하는 Layout과정을 거쳐서 (“Box-Model” 생성)

  7. 화면에 실제 픽셀을 Paint한다.

렌더링 엔진은 좀 더 나은 사용자 경험을 위해 가능하면 빠르게 내용을 표시하는데 모든 HTML을 파싱할 때까지 기다리지 않고 배치와 그리기 과정을 시작한다. 네트워크로부터 나머지 내용이 전송되기를 기다리는 동시에 받은 내용의 일부를 먼저 화면에 표시한다.

출처

browser에서의 웹 개발

HTML

브라우저는 한 라인씩 해석한다

<DOCTYPE>

  • 해당 문서의 타입 정의

    1
    <DOCTYPE html>

  • html의 시작을 알린다

    • 브라우저가 doctype을 읽고 해석을 한다

<head>

  • html 문서에 대한 추가적인 설명을 담는다
  • 해당 태그 안 자손 요소들은 가시적인 것을 정의하지 않는다
<meta>

이 문서가 브라우저에게 어떤 것인지 알려주는 태그

<title>

javascript

  • html이 끝나는 부분에 넣어주는 게 일반적

    • 위쪽에 넣어주는 경우 브라우저가 html을 해석하는 동안 javascript 코드를 다운로드하고 해석하느라 html 해석이 느려질 여지가 있기 때문

  • javascirpt 파일이 있을 경우, 서버에서 요청을 보내 받아오고, 해당 파일을 바로 해석을 한다.

    • 해석 결과 즉시 실행되야 할 코드가 있다면 먼저 실행된다.

웹 서버

  • 소프트웨어를 보통 지칭
  • 웹 서버 소프트웨어가 동작하는 컴퓨터
  • 클라이언트가 요청하는 html 문서나 각종 리소스 전달이 가장 중요한 목표
  • 요청되는 리소스는 정적 데이터이거나
    • html
    • css
    • javascript
  • 동적 데이터일 수도 있다
    • 웹 서버에 의해 실행되는 프로그램을 통해 만들어진 결과물

웹 크롤러

검색 사이트에서 다른 웹사이트의 정보를 읽어갈 때 사용하는 소프트웨어

종류

  • Apache
    • Apache Software Foundation에서 개발한 웹서버
    • 오픈소스 소프트웨어
    • 거의 대부분 운영체제에서 설치 및 사용이 가능
  • Nginx
    • 차세대 웹서버
    • 더 적은 자원으로 더 빠르게 데이터를 서비스하는 것을 목적으로 만들어진 서버
    • 오픈소스 소프트웨어
  • Microsoft IIS

웹 브라우저와 웹 서버

  • 브라우저는 웹 서버로부터 전송 받은 html 를 읽어들인 후 해석
  • 렌더하는데 필요한 img, css, javascript 리소스는 url을 추출
  • 웹 서버에게 해당 url의 리소스 요청
    • 해당 작업은 각 파일마다가 아니라, 동시에 발생
  • 웹 서버는 모든 요청을 받아들인 후 그 결과를 브라우저에 전송
  • 웹 브라우저는 해석한 html 문서와 여러 개의 리소스를 종합해 결과를 화면에 렌더

WAS

미들웨어

  • 클라이언트 쪽에 비즈니스 로직이 많을 경우

  • 클라이언트 관리에 비용이 많이 발생하는 문제

    DBMS 는 보통 서버 형태로 서비스를 제공하기 때문에, 이전에는 DBMS에 직접 접속해 동작하는 클라이언트 프로그램이 많았음

    • 클라이언트 프로그램의 크기가 커짐
    • 로직이 변경되면 매번 새로 배포
    • 클라이언트 단에 로직이 포함되어있어 보안이 나쁨

  • 클라이언트와 DBMS 사이에서 비즈니스 로직을 동작하게 하는 서버의 필요성 대두

    WAS는 일종의 미들웨어인데

  • 최초의 웹 등장 시

    • 정적 데이터만 보여주면 되었던 웹 브라우저

    CGI

    • 웹 서버에 프로그래밍 기능이 들어가는 방식

    • 단순한 프로그래밍의 경우 요구사항 충족 가능

    • 하지만 웹 복잡도 증가로 인해 사용이 어려워짐

  • 사용자의 요구사항 증가

    • 웹 브라우저 단에서 동적 기능 요구
      • DBMS와 연관된 로직 필요

  • WAS 등장 이후

    • 클라이언트는 입력과 출력만 담당

    • DBMS는 데이터 조작 업무만을 주로 수행

    • 클라이언트 단 요청이 데이터 조작 업무라면, DBMS에게 요청

장점

  • 클라이언트의 복잡한 로직 감소
    • 크기가 매우 작아짐
  • 로직 변경 시 모든 클라이언트 재배포 필요 없음

기능

  • 프로그램 실행 환경과 DBMS 접속 기능 제공

  • 여러 개의 트랜잭션 관리

    트랜잭션

    논리적인 작업 단위

  • 비지니스 로직 수행

웹 서버와 다른 점

  • WAS는 보통 자체적인 웹 서버 기능을 내장

    웹 서버의 역할

    정적 콘텐츠를 웹 브라우저에게 전송하는 역할

    WAS의 역할

    프로그램의 동적인 결과를 웹 브라우저에게 전송하는 역할

  • 어플리케이션 규모가 클 수록, 웹 서버와 WAS를 분리하는 게 일반적

    • 사실 웹 서버 없이 WAS만 있어도 정적 콘텐츠, 동적 콘텐츠 모두 제공 가능
    • 그러나
      • 웹 서버는 WAS 보다 상대적으로 간단한 구조
        • 대용량 웹 어플리케이션의 경우 트래픽이 많으면 서버가 여러 대일 확률이 높다
          • 만약 WAS 자체의 오작동으로 재시작을 해야한다면
          • 웹 서버가 문제가 있는 WAS를 이용하지 못하도록 한 뒤
          • WAS 를 복구
          • 사용자의 입장에서는 문제 발생 여부를 알 수 없음
            • 무중단 운영 가능
      • 자원 이용의 효율성, 장애 극복, 배포 및 유지보수의 편의성 때문

그래서 보통

웹 서버가 앞단에 위치하고, 뒤에 WAS 가 위치하는 경우가 잦다

  • 정적인 데이터는 앞의 웹 서버 담당
  • 동적인 데이터는 뒷단의 WAS 담당