Unit7 회고

웹 애플리케이션 아키텍처

🔆 클라이언트-서버 아키텍처

서버의 필요성🤔

서버(server)란 의미 그대로 해석하면 제공하는 주체를 뜻하는데 만약 서버가 존재하지 않고 하나의 앱 안에 모든 정보가 담겨있다면 어떤 상황이 발생할까?
-> 하나의 정보를 수정하거나 추가하기 위해 앱 자체를 업데이트해야하는 상황이 발생할 수 있다!

클라이언트-서버 아키텍처

❓클라이언트-서버 아키텍처란❓
리소스가 존재하는 공간(서버)과 리소스를 사용하는 공간(클라이언트)을 분리시킨 것으로 다른 말로는 2-Tier 아키텍처라고도 부른다. 클라이언트와 서버는 요청과 응답을 주고받는 관계를 갖는다.

• 3-Tier 아키텍처(조금 더 정확한 개념)
  클라이언트-서버 아키텍처에 데이터베이스가 추가된 형태로 데이터베이스는 리소스가 저장되어있는 공간으로 서버는 리소스를 전달해주는 역할을 수행

🔆 클라이언트와 서버가 통신하는 방법: API

프로토콜

• 통신 규약(약속과 같은 개념)
• 웹 애플리케이션의 프로토콜: HTTP
  • 웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 HTTP라는 프로토콜을 이용해 대화를 나눔
• 카페에서 커피를 주문하는 방식에도 다양한 방식이 존재하듯 서버와 통신할 수 있는 방법에도 여러 방법이 있는데 이들 모두 프로토콜이라고 볼 수 있으며 각각의 프로토콜마다 지켜야하는 규약이 존재함

API(Application Programming Interface)

API란❓
리소스 전달을 위한 일종의 메뉴판과 같은 역할을 하는 것이 바로 API인데 서버가 클라이언트에게 리소스를 잘 활용하도록 제공해주는 인터페이스를 말한다.

• 인터넷에 있는 데이터를 요청하는 경우 HTTP라는 프로토콜을 보통 사용하며 URL, URI와 같은 주소를 통해 접근 가능

  • URL은 메서드 개념이 등장

  • HTTP 메서드의 종류

    요청	적절한 메소드
    조회(Read)	GET
    추가(Create)	POST
    갱신(Update)	PUT 또는 PATCH
    삭제(Delete)	DELETE

브라우저의 작동 원리(보이지 않는 곳)

🔆 URL과 URI

• URL(Uniform Resource Locator)
  • 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보
• URI(Uniform Resource Identifier)
  • URL의 기본 요소인 scheme, hosts, url-path에 더해 query, fragment를 포함
  • URL의 상위 개념

URI,URL의 기본 요소

부분	명칭	설명
file://, http://, https://	scheme	통신 프로토콜
127.0.0.1, www.google.com	hosts	웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP
:80, :443, :3000	port	웹 서버에 접속하기 위한 통로
/search, /Users/username/Desktop	url-path	웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치하기까지의 경로
q=JavaScript	query	웹 서버에 전달하는 추가 질문

🔆 IP와 포트

IP(Internet Protocol)

• IP: 인터넷상에서 사용하는 주소체계
  • IPv4: 네 덩이의 숫자로 구분된 IP 주소체계
  • localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭
  • 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소
  • IPv6: IPv4로 할당할 수 있는 PC가 한계를 넘어서 나오게 된 주소체계로 IPv4가 2^32개의 IP 주소를 표현할 수 있었다면 IPv6는 2^128개의 IP 주소 표현 가능

PORT

• PORT: IP주소가 가리키는 PC에 접속할 수 있는 통로
  • 이미 사용 중인 포트는 사용 불가
  • 0~65535까지의 포트 번호가 있으며 그 중 0~1024번까지의 포트 번호는 주요 통신을 위한 규약에 따라 정해져 있음
  • 잘 알려진 포트 번호
    • 22 : SSH
    • 80 : HTTP
    • 443: HTTPS

🔆 도메인과 DNS

Domain Name

• Domain Name: IP주소를 대신하여 사용하는 주소로 한눈에 파악하기 어려움 IP주소를 보다 간단하게 나타낼 수 있음
  • 네트워크 상에 존재하는 모든 PC는 IP주소가 있지만 모든 IP주소가 도메인 이름을 갖는 것은 아니며 특이한 case 이외에 모든 도메인 이름은 일정기간 대여하여 사용함

DNS(Domain Name System)

• 해당 도메인 이름과 매칭된 IP주소를 확인하는 작업을 하는 서버
• 호스트의 도메인 이름을 IP주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템

HTTP

🔆 HTTP Messages

HTTP Messages란❓
HTTP란 HTML과 같은 문서를 전송하기 위한 프로토콜을 의미하는데 HTTP Messages는 클라이언트와 서버 사이에서 데이터가 교환되는 방식을 말한다. 여기에는 요청(Requests)과 응답(Responses)이라는 두 가지 유형이 있다.

• HTTP Messages의 구조
  • start line(status line): 요청이나 응답의 상태를 나타내며 첫 줄에 위치함
  • HTTP Headers: 요청을 지정하거나 메시지에 포함된 본문을 설명하는 헤더의 집합
  • empty line: 헤더와 본문을 구분하는 빈 줄
  • body: 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함하며 요청과 응답의 유형에 따라 선택적으로 사용
    • start line과 HTTP headers를 묶어 요청이나 응답의 헤드라고 하며 payload는 body라고 함

🔆 HTTP Requests

클라이언트가 서버에게 보내는 메시지

• Start line
  • 수행할 작업이나 방식을 설명하는 HTTP method를 나타냄
  • 요청 대상 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성되며 요청 형식은 HTTP method마다 다름
    • origin 형식: '?'와 쿼리 문자열이 붙는 절대 경로입니다. GET, POST, HEAD, OPTIONS 등의 method와 함께 사용
    • absolute 형식: 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용
    • authority 형식: 도메인 이름과 포트 번호로 이루어진 URL의 일부분
    • asterisk 형식: OPTIONS 와 함께 별표(*) 하나로 서버 전체를 표현
  • HTTP 버전에 따라 HTTP message의 구조가 달라지므로 start line에 HTTP 버전을 함께 입력
• Headers
  • 헤더이름, 콜론, 값을 입력
  • 헤더의 종류
    • General headers: 메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 무관
    • Request headers: fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미
    • Representation headers(Entity headers): body에 담긴 리소스의 정보를 포함하는 헤더
• Body
  • HTTP messages 구조의 마지막에 위치
  • POST, PUT과 같이 데이터를 업데이트하는 요청을 하는 경우 필요하며 서버에 리소스를 요청하는 경우 body가 필요하지 않음
  • 바디의 종류
    • Single-resource bodies(단일-리소스 본문): 헤더 두 개로 정의된 단일 파일로 구성
    • Multiple-resource bodies(다중-리소스 본문): 여러 파트로 구성된 본문에서 각 파트마다 다른 정보를 지님

🔆 HTTP Responses

서버가 클라이언트에게 보내는 메시지

• Status line
  • 응답의 첫 줄
  • 포함하는 내용
    • 현재 프로토콜의 버전
    • 상태 코드 -> 요청의 결과
    • 상태 텍스트 -> 상태 코드에 대한 설명
• Headers
  • 요청 헤더와 동일한 구조(대소문자 구문 없는 문자열, 콜론, 값)
  • 헤더의 종류
    • General headers: 메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 무관
    • Response headers: 위치 또는 서버 자체에 대한 정보와 같이 응답에 대한 부가적인 정보를 갖는 헤더
    • Representation headers(Entity headers): body에 담긴 리소스의 정보를 포함하는 헤더
• Body
  • HTTP messages 구조의 마지막에 위치
  • 201, 204와 같이 상태 코드를 가지는 응답에는 본문이 필요 없음
  • 바디의 종류
    • Single-resource bodies(단일-리소스 본문): 길이가 알려진 단일-리소스 본문은 두 개의 헤더로 정의하며 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked로 설정되어 있으며 파일은 chunk로 나뉘어 인코딩 되어있음
    • Multiple-resource bodies(다중-리소스 본문): 서로 다른 정보를 담고 있는 body

브라우저의 작동 원리(보이는 곳)

🔆 SPA를 만드는 기술: AJAX

AJAX(Asynchronous JavaScript And XMLHttpRequest)

AJAX란❓
JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등 다양한 기술을 사용하는 웹 개발 기법으로 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있음

AJAX의 핵심 기술: JavaScipt&DOM, Fetch

• Fetch를 사용하면 페이지 이동 없이 서버로부터 필요한 데이터를 받아올 수 있음
• JavaScript에서 DOM을 사용해 조작 가능하기 때문에 Fetch를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지의 필요한 부분만 변경 가능
• Fetch 이전에는 XHR을 사용했으나 Cross-Site이슈 등의 XHR의 단점을 보완한 새로운 Web API인 Fetch(JSON 사용)를 주로 사용
• AJAX의 장점
  • 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지 생성 가능
    • 필요한 데이터를 비동기적으로 가져와 화면에 필요한 부분만 업데이트하여 렌더링 가능
  • 표준화된 방법
    • 브라우저에 상관없이 AJAX 사용 가능
  • 유저 중심 애플리케이션 개발
    • 필요한 부분만 렌더링 -> 사용자와 빠르게 더 많은 상호작용 가능
  • 더 작은 대역폭
    • 대역폭: 네트워크 통신 한 번에 보낼 수 있는 크기
    • 서버로부터 필요한 데이터를 HTML 파일이 아닌 텍스트 형태로 받으면 되므로 데이터 크기가 비교적 작음
• AJAX의 단점
  • Search Engine Optimization(SEO)에 불리
    • AJAX 방식의 웹 애플리케이션의 HTML 파일은 틀만 작성되어 있고 데이터는 없는 경우가 많기에 검색 엔진 최적화에 불리
  • 뒤로가기 버튼 문제
    • AJAX는 이전 상태를 기억하지 않으므로 뒤로가기 기능 구현을 위해서는 별도로 History API를 사용해야 함

🔆 SSR과 CSR

SSR(Server Side Rendering)과 CSR(Client Side Rendering)

• SSR: 웹 페이지를 서버에서 렌더링
  • 클라이언트에서 요청을 보내면 완전히 렌더링 된 페이지로 클라이언트에 보내어 응답
• CSR: 웹 페이지를 클라이언트(웹 브라우저)에서 렌더링
  - 클라이언트에서 요청을 보내면 JavaScript와 함께 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보내어 응답
  SSR과 CSR의 차이
• 페이지가 렌더링되는 위치
  • SSR은 서버에서, CSR은 클라이언트에서 페이지를 렌더링
  • CSR은 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침하지 않고, 동적으로 라우팅을 관리

적합한 렌더링 사용 방식😎

• SSR 사용
  • SEO(검색 엔진 최적화)가 우선순위일 경우
  • 웹 페이지 첫 화면의 렌더링이 빨라야 하는 경우
    • 단일 파일의 용량이 작으므로
  • 사용자와의 상호작용인 작은 경우
• CSR 사용
  • SEO가 우선순위가 아닌 경우
  • 사용자와 풍부한 상호작용이 있는 경우
  • 웹 애플리케이션을 제작하는 경우

<오늘의 일기>
집중하기 어려운 이번 주. 개인적인 일이 번아웃까지 이어져 능동적으로 공부하는 것에 어려움이 있어서 죄책감이 많이 든다. 이번주는 수동적으로라도 꼭 해야할 공부만 우선 열심히 해보고 마음을 잘 다스리는 시간을 가져 최대한 빠른 시일 내에 회복할 수 있도록 노력해야겠다!