2티어 아키텍처라고도 불리는 설계 방식
상품정보와 같은 resource가 존재하는 곳(서버)과 resource를 사용하는 앱(클라이언트)을 분리시킨 것.
2티어 아키텍처에 데이터베이스가 추가되면 3티어 아키텍처라고 부른다.
웹 플랫폼에서의 클라이언트: 웹사이트, 웹앱. 브라우저를 통해 이용
스마트폰/태블릿 플랫폼
데스크탑 앱
파일서버: 파일을 제공하는 앱
웹서버: 웹사이트에서 필요로 하는 정보 제공하는 앱
메일 서버: 메일을 주고받을 수 있도록 도와주는 앱
데이터베이스 서버: 데이터제공자로서 일종의 서버
프로토콜: 통신 규약
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 HTTP(프로토콜) 을 이용해서 통신한다.
영어로 되어있기 때문에 어떤 단어의 약자인지, 무슨 뜻인지 생각해보면 이해하기 쉽다.
OSI 7 Layers ::
1계층: Physical, 물리계층. 전기신호를 주고받는다.(리피터: 전기신호를 증폭. 원래 신호로 복원한다.)
2계층: Data Link, 인접 시스템 간 데이터를 전송한다.(브리지)
3계층: Network, 단말 간 데이터 전송을 위해 최적의 경로를 제공한다.(라우터)
4계층: Transport, 종단시스템 간 투명한 데이터(신뢰성있는) 전송.
5계층: Session, 대화...라고 했는데ㅎ
6계층: Presentation, 표현계층. 데이터의 형식을 어떻게 표현하느냐 하는 문제. 보안관련.
7계층: Application, 응용계층. 사용자와 네트워크 간 연결, 데이터 생성.
HTTP(HyperText Transfer Protocol): html, json 등의 정보 주고받음
HTTPS : 뒤에 붙은 s가 Secure(보안)
FTP(File Transfer..): 말그대로 파일전송
SMTP(Simple Mail..): 아니지만 send mail 이라고 생각하면 이해하기 쉽다.
SSH: CLI환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP: 윈도우 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WebSocket: 실시간 통신, Push등을 지원하는 프로토콜
TCP: HTTP, FTP 통신의 근간이 되는 인터넷 프로토콜. 연결형 서비스로 양방향으로 작동한다.
UDP: 비연결형 서비스. 단방향으로 작동하기 때문에 단순하고 빠르지만 신뢰성이 낮다.
라이브러리를 쉽게 이용할 수 있도록 규칙 등을 정의해놓은 인터페이스
인터페이스: 의사소통이 가능하도록 만들어진 접점
API 예시
요청: 아메리카노 두잔 헤이즐넛 시럽 넣고
url: /coffee/americano?quentity=2&syrup=hazelnet
HTTP API
메서드로 CRUD(Create, Read, Update, Delete)작업 요청
요청 URL 디자인 사용하는 메서드 모든 사용자 Read /users GET 새 사용자 Create /users POST 1번 사용자 정보 Update /users/1 PUT 1번 사용자 정보 Delete users/1 DELETE 1번 사용자 정보 Read /users/1 GET
file://127.0.0.1/Users/username/Desktop/
127.0.0.1은 로컬 PC를 나타낸다.
URL: Uniform Resource Locator
네트워크상에서 파일이 위치한 정보를 나타낸다.
scheme, hosts, url-path로 구분한다.URI: Uniform Resource Identifier
url을 포함하는 상위 개념이 uri이다.
url + query, fragment(+) fragment: 일종의 북마크 기능. URL에 fragment(#)와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤 이동 가능.
부분 명칭 설명 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 웹 서버에 전달하는 추가 질문
네트워크에 연결된 특정 PC의 주소
nslookup codestates.com
코드스테이츠의 IPv4주소를 확인할 수 있다.IPv4
IPv4는 8비트씩 총 32비트(4바이트)로 표시한다.
0.0.0.0 ~ 255.255.255.255 : 2의 32승인 43억개
- localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC.
- 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소. 서버에서 접근 가능 IP주소를 broadcast address로 지정하면 모든 기기에서 서버에 접근할 수 있다.
IPv4 주소가 동나서 대신 IPv6로 가는 추세이다.
ip주소가 가리키는 pc에 접속할 수 있는 통로를 의미한다.
이미 사용중인 포트는 중복해서 사용할 수 없다.
포트번호는 0~65535까지 사용할 수 있다.
그중 0~1024번까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져있다.
모든 IP주소가 도메인을 가지는 것은 아니다. 도메인은 일정기간동안 대여해 사용한다.
해당 도메인 이름과 매칭된 IP주소를 확인하는 서버를 DNS라고 한다.
전체 에러 메시지 목록
chrome://network-errors/
Error Message | Description |
---|---|
"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 | 클라이언트 인증서(은행 또는 회사 내부 웹사이트 등)에 오류가 발생하여 웹페이지에 로그인할 수 없습니다. |
클라이언트와 서버 사이에서 데이터가 교환되는 방식.
요청과 응답 두가지 유형이 있다.
HTTP Messages는 인터페이스에서 자동으로 완성되기 때문에 개발자가 작성할 필요가 거의 없다.
요청과 응답의 구조는 유사하다.
1. Head: start line
요청이나 응답의 상태를 나타낸다. 응답에서는 status line
2. Head: HTTP headers
요청을 지정하거나 메세지에 포함된 본문을 설명하는 헤더의 집합
3. empty line
헤더와 본문을 구분함
4. payload: body
요청 혹은 응답과 관련된 데이터 또는 문서를 포함. 요청과 응답의 유형에 따라 선택적으로 사용
HTTP는 상태를 가지지 않는다. 클라이언트나 서버의 상태를 확인하거나 추적하지 않는다.
클라이언트가 서버에 보내는 메세지
수행할 작업이나 방식을 설명. (GET, PUT, POST..)
GET 메서드는 리소스를 받아야하고 POST 메서드는 데이터를 서버로 전송함
?
와 쿼리 문자열이 붙는 절대경로. GET POST HEAD OPTIONS 사용POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
CONNECT
와 함께 사용할 수 있다.CONNECT developer.mozilla.org:80 HTTP/1.1
OPTIONS
와 함께 *
하나로 서버 전체 표현OPTIONS * HTTP/1.1
HTTP 버전에 따라 HTTP message 구조가 달라지기 때문에 start line에 버전을 같이 입력해준다.
요청의 Headers는 기본구조를 따른다. 헤더이름, 콜론, 값을 입력한다. 값은 헤더에 따라 다르다.
요청의 본문은 HTTP messages 구조의 마지막에 위치한다. 모든 요청에 바디가 필요한 건 아니다. 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다. POST 나 PUT과같은 일부 요청은 데이터를 업데이트하기 위해 사용한다.
HTML form
과 관련이 있다.서버가 클라이언트에게 보내는 메세지
응답의 첫줄.
HTTP/1.1 404 Not Found
요청 헤더와 동일한 구조.
응답의 본문은 메세지 마지막에 위치한다. 역시 모든 응답에 필요하지는 않다.
Asynchronous JavaScript XMLHttpRequest
비동기적으로 필요한 부분만 데이터를 받아와 화면에 보일 수 있다.
Javascript와 DOM, Fetch
Fetch를 이용하면 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있다.
자바스크립트에서 돔을 사용해 조작할 수 있기 때문에 Fetch를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있다.
Fetch 예제
fetch('http://52.78.213.9:3000/messages') .then (function(res) { return response.json(); }) .then(function(json){...})
Fetch이전에는 XHR(XML Http Request)를 사용했다.
XHR은 Cross-Site 이슈 등의 불편함이 있었음.XHR 예제
var xhr = new XMLHttpRequest(); xhr.open('get', 'http://52.78.213.9:3000/messages'); xhr.onreadystatechange = function(){ if(xhr.readyState !== 4) return; // readyState 4: 완료 if(xhr.status === 200) { // status 200: 성공 console.log(xhr.responseText); // 서버로부터 온 응답 } else { console.log('에러: ' + xhr.status); // 요청 도중 에러 발생 } } xhr.send(); // 요청 전송
장
서버에서 HTML을 완성해서 보내주지 않아도 렌더링이 가능하다.
표준화된 방법.
유저 중심의 상호작용이 가능한 애플리케이션 개발
필요한 데이터를 텍스트 형태(JSON)로 보내면 되기 때문에 대역폭(데이터크기가)이 작다.
단
SEO에 불리하다. 사이트의 정보를 긁어가기 어려움.
뒤로가기 버튼 문제. AJAX는 이전 상태를 기억하지 않기 때문에 뒤로가기 기능을 구현하기 위해서 별도의 History API를 사용해야 한다.
웹페이지를 서버에서 렌더링한다.
서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링하기 때문에 서버사이드 렌더링이라고 한다.
브라우저의 다른 경로로 이동할 때마다 서버는 같은 작업을 다시 수행한다.
클라이언트(대표적으로 웹 브라우저)에서 페이지를 렌더링한다.
브라우저의 요청을 서버로 보내면 서버는 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보낸다. 이때 웹페이지ㅘ 함께 자바스크립트 파일을 보낸다.
브라우저의 다른 경로로 이동할 때 서버가 웹페이지를 다시 보내지 않는다. 브라우저가 경로에 따라 페이지를 다시 렌더링한다.