TIL 30일차

클라이언트-서버 아키텍처
2티어 아키텍처(클라이언트-서버 아키텍처) :

• 클라이언트(리소스를 사용) <-> 서버(리소스를 제공)
• 클라이언트가 직접 서버의 DB에 접속하여 자원을 활용
• 편리하지만 보안에 취약, 유지보수 여러움

3티어 아키텍처 :

• 클라이언트(리소스를 사용) <-> 서버(리소스를 전달) <-> DB(리소스를 저장)
• 보안측면에서 유리, 2티어에 비해 대용량 서비스에 유리함

프로토콜 : 통신 규약

웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 통신함
클라이언트와 서버 간의 통신은 요청과 응답으로 구성됨(요청이 있어야 응답이 옴)

주요 프로토콜

7. 응용 계층(OSI 7 Layers)

프로토콜 이름	설명
HTTP	웹에서 HTML, JSON 등의 정보를 주고받는 프로토콜
HTTPS	HTTP에서 보안이 강화된 프로토콜
FTP	파일 전송 프로토콜
SMTP	메일을 전송하기 위한 프로토콜
SSH	CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP	Windows계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WebSocket	실시간 통신, Push 등을 지원하는 프로토콜

4. 전송 계층

프로토콜 이름	설명
TCP	HTTP, FTP 통신의 근간이 되는 인터넷 프로토콜(양방향으로 작동)
UDP	단방향으로 작동하는 훨씬 더 단순하고 빠르지만 신뢰성이 낮은 인터넷 프로토콜

API(Application Programming Interface) :
어플리케이션 소프트웨어 및 서비스를 통합하는 툴, 정의, 프로토콜의 세트, 의사소통이 가능하도록 만들어진 접점

HTTP 메소드는 CRUD 행동에 따라 목적에 맞게 써야함

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

URL과 URI
URL(Uniform Resource Locator) : 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냄

• scheme : 통신방식(프로토콜)을 결정, 일반적인 웹 브라우저는 http(s)를 사용
• hosts : 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타냄
• url-path : 웹 서버에 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타냄

URI(Uniform Resource Idenrifier) : 일반적인 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, bookmark를 포함

http://www.google.com:80/search?q=JavaScript

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

IP와 PORT
IP : 네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP address(Internet Protocol address)라고 함
※ 꼭 기억해야 할 IP주소
localhost, 127.0.0.1 : 현재 사용중인 로컬 PC를 지칭
0.0.0.0 , 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소, 서버에서 접근 가능 IP주소를 broadcast address로 지정하면 모든 기기에서 서버에 접근 가능

PORT : IP주소가 가리키는 PC에서 접속할 수 있는 통로(채널)
포트번호는 0~65, 535 까지 사용할 수 있음 그중 0~1024번까지의 포트번호는 주요 통신을 위한 규약에 따라 이미 정해져 있음
※ 반드시 알아야 할 포트번호

• 22 : SSH
• 80 : HTTP
• 443 : HTTPS

이미 정해진 포트 번호라도 필요에 따라 자유롭게 사용 가능, 잘 알려진 포트의 경우 URI등에 명시하지 않지만, 그외의 잘 알려지지 않은 포트(:3000 과 같은 임시포트)는 반드시 포함

도메인과 DNS
웹 브라우저를 통해 특정 사이트에 진입할 때, IP 주소를 대신하여 사용하는 주소가 있음(IP주소가 지번 또는 도로명 주소라면, 도메인은 해당 주소에 위치한 상호로 볼 수 있음)
DNS(Domain Name System) : 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템

크롬 브라우저 에러 읽기

HTTP 메세지
HTTP의 특징 : Stateless(무상태성)
HTTP Message : 클리아이너트와 서버 사이에서 데이터가 교환 되는 방식, 두가지 유형을 가지고 있음

• 요청(Request)
• 응답(Response)

요청과 응답은 유사한 구조를 가짐
1. start line : 요청이나 응답의 상태를 나타냄, 항상 첫번째 줄, 응답에서는 status line이라고 부름
2. HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
3. empty line : 헤더와 본문을 구분하는 빈 줄이 있음
4. body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함, 요청과 응답의 유형에 따라 선택적으로 사용

요청(Requests)

Start line
HTTP 요청은 클라이언트가 서버에 보내는 메시지
1.수행할 작업이나 방식을 설명하는 HTTP method를 나타냄
2.요청 대항 또는 프로토콜, 포트, 도메인의 절대경로는 요청 컨텍스트에 작성, 요청 형식은 HTTP method마다 다름

• origin 형식 : ?와 쿼리 문자열이 붙는 절대경로, POST, GET, HEAD, OPTIONS등의 method와 함께 사용
• absolute 형식 : 완전한 URL 형식으로 프록시에 연결하는 경우 대부분 GET method와 함께 사용
• authority 형식 : 도메인 이름과 포트번호로 이루어진 URL의 authoruty component, HTTP터널을 구축하는 경우 CONNECT와 함께 사용가능
• asterisk 형식 : OPTIONS와 함께 별표(*)하나로 서버 전체를 표현

3.HTTP 버전은 메시지의 다른 구조를 결정함

Headers
요청의 headers는 기본구조를 따름, 대소문자 구분없이 문자열과 콜론, 값을 입력, 값은 헤더에 따름, 여러종류의 헤더가 있음

• General headers : 메시지 전체에 적용
• Request headers : User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화함
• Entity headers : Content-Length와 같은 헤더는 body에 적용됨, body과 비어있는 경우 entity headers는 전송되지 않음

Body
HTTP messages 구조의 마지막에 위치, 모든 요청에 필요하지 않음, POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용

• Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성됨
• Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다. 보통 HTML form과 관련있음

응답(Response)

Status line
응답의 첫 줄은 Status line이라고 부름
1. 현재 프로토콜의 버전(HTTP/1.1)
2. 상태 코드 - 요청의 결과를 나타냄(200, 302, 404 등)
3. 상태 텍스트 - 상태 코드에 대한 설명

Headers
요청 헤더와 동일한 구조를 가짐

• General headers : 메시지 전체에 적용됨
• Response headers : Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공함
• Entity headers : Content-Length와 같은 헤더는 body에 적용됨, body가 비어있는 경우, entity headers는 전송되지 않음

Body
HTTP messages 구조의 마지막에 위치, 모든 응답에 필요하지 않음

• Single-resource bodies(단일-리소스 본문) :
  - 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의
  - 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있음
• Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body

AJAX
AJAX(Asynchronous JavaScript and XML) : 자바스크립트를 이용해 서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신 기능

AJAX로 할 수 있는것 : 클라이언트에서 서버로 데이터를 요청하고 그에 대한 결과를 리턴받을 수 있음

SSR vs CSR
SSR : 웹 페이지를 서버에서 렌더링
CSR : 웹 페이지를 클라이언트에서 렌더링

Use SSR

• SEO(Search Engine Optimization)가 우선순위인 경우, 일반적으로 SSR을 사용
• 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR이 적합
• 웹 페이지가 사용자와 상호작용이 적은 경우

Use CSR

• SEO가 우선순위가 아닌 경우
• 사이트에 풍부한 상호작용이 있는 경우, CSR은 빠른 라우팅으로 강력한 사용자 경험을 제공
• 웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링등)을 제공

CORS
CORS(Cross-Origin Resource Sharing) : 교차 출처 리소스 공유, 추가 HTTP헤더를 사용하여, 한 출러에서 실행중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제

CORS가 생겨난 이유 : SOP(Same-Origin Policy) 2011년 등장한 보안 정책으로 "같은 출처에서만 리소스를 공유할 수 있다"라는 규칙을 가진 정책 그러나 웹이라는 오픈스페이스 환경에서 다른 출처에 있는 리소스를 가져와서 사용하는 일은 굉장히 흔한 일이라 무작정 제한할 수 없어 몇가지의 예외조항을 두게 됨 그 중 하나가 바로 CORS

같은 출처와 다른 출처의 구분법
두 URL의 구성 요소 중 Scheme, Host, Port가 동일하면 같은 출처