클라이언트-서버 아키텍처
리소스를 서버에 저장 및 관리, 앱과 분리시켜 관리, 2티어 아키텍쳐
앱이 클라이언트, 리소스를 제공하는 서버
앱이 리소스를 요청, 서버는 요청을 받아, 창고인 데이터베이스에서 찾아, 제공, 3티어 아키텍쳐
프론트엔드는 클라이언트처럼 사용자가 직접 눈으로 보고, UI를 클릭 또는 터치하는 등의 상호작용을 할 수 있는 앱을 주로 개발
백엔드는 사용자 눈에 보이지 않지만, 상품 정보를 API로 노출한다던지, 로그인/로그아웃, 권한 관리 등의 사용자 인증을 주로 다룸, 서버와 데이터베이스를 관리
클라이언트는 웹사이트 또는 웹 앱, 스마트폰/태블릿/데스크탑 플랫폼용 앱
서버는 무엇을 하느냐에 따라 종류가 달라집니다. 파일 서버는 파일을 제공하는 앱, 웹 서버는 웹사이트에서 필요로 하는 정보들을 제공하는 앱(이후 주로 우리가 만들게 될 서버입니다), 메일 서버는 메일을 주고 받을 수 있도록 도와주는 앱. 데이터베이스도 일종의 서버.
client(browser) <-http-> server(api)
HTTP를 이용한 클라이언트-서버 통신, API
URL은 Uniform Resource Locator의 줄임말로, 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보, scheme, hosts, url-path로 구분
URI는 Uniform Resource Identifier의 줄임말로, 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, bookmark를 포함합니다. query는 웹 서버에 보내는 추가적인 질문
브라우저의 검색창을 클릭하면 나타나는 주소가 URI입니다. URI는 URL을 포함하는 상위개념
scheme: 통신 프로토콜(file://, http://, https://)
hosts: 웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP (127.0.0.1, www.google.com)
port: 웹 서버에 접속하기 위한 통로(:80, :443, :3000)
url-path: 웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로(/search, /Users/username/Desktop)
query: 웹 서버에 전달하는 추가 질문(q=JavaScript)
IP 주소(InternetProtocolAddress): 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
IPv4는 네 덩이의 숫자로 구분, IP version 4, IP 주소체계의 네 번째 버전
localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭
0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소입니다. 서버에서 접근 가능 IP 주소를 broadcast address 로 지정하면, 모든 기기에서 서버에 접근할 수 있습니다.
IPv6는 표기법을 달리 책정하여 2^(128)개의 IP 주소를 표현(IPv4의 43억개 한계를 넘었음)
port: 로컬 PC의 IP 주소인 127.0.0.1 뒤에 :3000과 같은 숫자가 표현됩니다. 이 숫자는 IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)을 의미, 포트 번호는 0~65,535 까지
그 중에서 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있습니다
22 : SSH, 23 : Telnet, 80 : HTTP, 443: HTTPS
1024-49159 : registered
49159-65535 : dynamic
이미 정해진 포트 번호라도, 필요에 따라 사용할 수 있다. 잘 알려진 포트의 경우 URI 등에 명시하지 않지만, 그 외의 잘 알려지지 않은 포트(:3000과 같은 임시 포트)는 반드시 포함해야 함
Domain name: IP주소가 도로명 주소라면, 도메인은 주소의 대표상호명 또는 건물 이름
DNS: Domain Name System, 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템
API란 무엇일까요?
애플리케이션 프로그래밍 인터페이스(Application Programming Interfaces, API)는 애플리케이션 소프트웨어 및 서비스를 통합하는 툴, 정의, 프로토콜의 세트입니다. 이는 새로운 연결 인프라를 지속적으로 구축할 필요 없이 제품 및 서비스가 서로 커뮤니케이션할 수 있도록 도와주는 기능
크롬 브라우저의 에러 메시지를 통해 문제를 파악할 수 있다.
"Aw, Snap!": Chrome 브라우저에서 페이지를 로드하는 데 문제가 발생했습니다.
ERR_NAME_NOT_RESOLVED: 호스트 이름(웹 주소)이 존재하지 않습니다.
ERR_INTERNET_DISCONNECTED: 사용 중인 기기가 인터넷에 연결되지 않았습니다.
ERR_CONNECTION_TIMED_OUT / ERR_TIMED_OUT: 페이지에 연결하는 데 시간이 너무 오래 걸립니다. 인터넷 연결이 너무 느리거나, 웹페이지에 접속한 사용자가 많아서 발생할 수 있습니다.
ERR_CONNECTION_RESET: 웹페이지 연결을 방해하는 요소가 어딘가에 발생했습니다.
ERR_NETWORK_CHANGED: 웹페이지를 로드하는 중에 기기의 네트워크 연결이 해제되었거나, 새로운 네트워크에 연결되었습니다.
ERR_CONNECTION_REFUSED: 웹페이지에서 Chrome 브라우저의 연결을 허용하지 않았습니다.
ERR_CACHE_MISS: 웹페이지로부터 이전에 입력한 정보를 다시 제출하도록 요청받았습니다.
ERR_EMPTY_RESPONSE: 웹페이지에서 데이터를 전혀 전송하지 않았으며, 데이터를 전송할 서버가 다운되었을 수 있습니다.
ERR_SSL_PROTOCOL_ERROR: 페이지에서 전송된 데이터를 Chrome이 해석하지 못했습니다.
ERR_BAD_SSL_CLIENT_AUTH_CERT: 클라이언트 인증서(은행 또는 회사 내부 웹사이트 등)에 오류가 발생하여 웹페이지에 로그인할 수 없습니다.
위의 에러 메시지를 만나면, 다음과 같은 문제가 발생할 수 있습니다.
웹페이지에 연결할 수 없습니다. 웹페이지가 열리지 않습니다. HTTPS가 적용된 웹페이지가 열리지 않습니다. 사진이 로드되지 않습니다. 새 탭이 로드되지 않습니다.
Ajax(Asynchronous JavaScript and XML)
비동기식 자바스크립트와 XML
문서 객체 모델(DOM: Document Object Model)
SPA를 만드는 기술의 핵심
AJAX 구성 요소(기술)
- 웹 페이지 표현을 위한 HTML, CSS
- 데이터에 접근하거나, 화면 구성을 동적으로 조작하는 DOM
- 데이터 교환에 사용되는 JSON 이나 XML
- 웹 서버와 비동기적 통신을 위한 XMLHttpRequest 객체
- JavaScript
SSR vs CSR
CSR과 SSR의 주요 차이점은 페이지가 렌더링되는 위치입니다. SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링합니다. 브라우저는 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고, 동적으로 라우팅을 관리
SSR (Service Side Rendering)
브라우저가 아닌 서버에서 페이지를 렌더링
브라우저가 다른 경로로 이동할 때마다 서버는 작업을 다시 수행
SEO(Search Engine Optimization)가 우선순위인 경우, 일반적으로 SSR을 사용
웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR 이 적합
웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용할 수 있음
CSR (Client Side Rendering)
클라이언트에서 페이지를 렌더링, 일반적으로 SSR과 CSR은 서로 반대로 여겨짐
웹 페이지를 렌더링하는 데에 필요한 데이터를 API 요청으로 해소
CSR에서는 SSR과 다르게, 서버가 웹 페이지를 다시 보내지 않음
브라우저가 요청한 경로에 따라 페이지를 다시 렌더링
이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일
SEO 가 우선순위가 아닌 경우, CSR을 이용할 수 있음
사이트에 풍부한 상호 작용이 있는 경우, CSR은 빠른 라우팅으로 강력한 사용자 경험을 제공
웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공
Browser Secury Model
CORS (Cross-Origin Resource Sharing)
교차 출처 리소스 공유
처음 전송되는 리소스의 도메인과 다른 도메인으로부터 리소스가 요청 될 경우, 해당 리소스는 cross-origin HTTP 요청에 의해 요청된다.
예를 들어, http://domail-a.com으로부터 전송되는 HTML페이지가 < img > src 속성을 통해 http://domail-b.com/image.jpg를 요청하는 경우가 있습니다. 오늘날 많은 웹 페이지들은 CSS 스타일시트, 이미지, 그리고 스크립트와 같은 리소스들을 각각의 출처로부터 읽어옵니다.
예시) https://urclass.codestates.com:3000/course/56/curriculum
예시에 URL의 경우 아래와 같이 구분할 수 있습니다.
1) http -> 프로토콜
2) urclass.codestates.com -> 호스트(도메인)
3) :3000 -> 포트 번호
4) /course/56/curriculum -> URL pathname
위 URL에 구성 중 origin을 구분하는 기준은 "프로토콜", "호스트(도메인)", "포트 번호"이다.
preflight request는 실질적인 요청 전 "OPTIONS"메소드를 통해 사전에 요청이 안전한지 확인하는 방법입니다.
cross origin 요청에는 Simple requests, Preflighted requests, Requests with credentials 등이 있는데
이중 Preflighted requests만 OPTIONS 메소드를 통해 요청을 확인합니다.
XSS(Cross-site Scripting)
CSS와 혼동이 올 수 있어서 XSS로 표기함
SQL injection과 함께[2] 웹 상에서 가장 기초적인 취약점 공격 방법의 일종으로, 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법
CSRF(Cross-site request forgery, CSRF, XSRF)
사이트 간 요청 위조(또는 크로스 사이트 요청 위조)는 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격
