웹 애플리케이션 아키텍처
🔆 클라이언트-서버 아키텍처
서버의 필요성🤔
서버(server)란 의미 그대로 해석하면 제공하는 주체를 뜻하는데 만약 서버가 존재하지 않고 하나의 앱 안에 모든 정보가 담겨있다면 어떤 상황이 발생할까?
-> 하나의 정보를 수정하거나 추가하기 위해 앱 자체를 업데이트해야하는 상황이 발생할 수 있다!
클라이언트-서버 아키텍처
❓클라이언트-서버 아키텍처란❓
리소스가 존재하는 공간(서버)과 리소스를 사용하는 공간(클라이언트)을 분리시킨 것으로 다른 말로는 2-Tier 아키텍처라고도 부른다. 클라이언트와 서버는 요청과 응답을 주고받는 관계를 갖는다.
- 3-Tier 아키텍처(조금 더 정확한 개념)
클라이언트-서버 아키텍처에 데이터베이스가 추가된 형태로 데이터베이스는 리소스가 저장되어있는 공간으로 서버는 리소스를 전달해주는 역할을 수행
🔆 클라이언트와 서버가 통신하는 방법: API
프로토콜
- 통신 규약(약속과 같은 개념)
- 웹 애플리케이션의 프로토콜:
HTTP
- 웹 애플리케이션 아키텍처에서는 클라이언트와 서버가
HTTP
라는 프로토콜을 이용해 대화를 나눔
- 카페에서 커피를 주문하는 방식에도 다양한 방식이 존재하듯 서버와 통신할 수 있는 방법에도 여러 방법이 있는데 이들 모두 프로토콜이라고 볼 수 있으며 각각의 프로토콜마다 지켜야하는 규약이 존재함
API(Application Programming Interface)
API란❓
리소스 전달을 위한 일종의 메뉴판과 같은 역할을 하는 것이 바로 API인데 서버가 클라이언트에게 리소스를 잘 활용하도록 제공해주는 인터페이스를 말한다.
브라우저의 작동 원리(보이지 않는 곳)
🔆 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을 완성하여 보내주지 않아도 웹페이지 생성 가능
- 필요한 데이터를 비동기적으로 가져와 화면에 필요한 부분만 업데이트하여 렌더링 가능
- 표준화된 방법
- 유저 중심 애플리케이션 개발
- 필요한 부분만 렌더링 -> 사용자와 빠르게 더 많은 상호작용 가능
- 더 작은 대역폭
- 대역폭: 네트워크 통신 한 번에 보낼 수 있는 크기
- 서버로부터 필요한 데이터를 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가 우선순위가 아닌 경우
- 사용자와 풍부한 상호작용이 있는 경우
- 웹 애플리케이션을 제작하는 경우
<오늘의 일기>
집중하기 어려운 이번 주. 개인적인 일이 번아웃까지 이어져 능동적으로 공부하는 것에 어려움이 있어서 죄책감이 많이 든다. 이번주는 수동적으로라도 꼭 해야할 공부만 우선 열심히 해보고 마음을 잘 다스리는 시간을 가져 최대한 빠른 시일 내에 회복할 수 있도록 노력해야겠다!