네트워크

김나율·2022년 10월 5일

http 네트워크

section2

목록 보기

13/15

◎웹 애플리케이션 아키텍처

클라이언트-서버 아키텍처
✍︎클라이언트-서버 아키텍처, 2-Tier 아키텍처
: 상품정보같은 리소스가 존재하는 곳(서버)과 리소스를 사용하는 앱(클라이언트)을 분리시킨 것

case) 카페
손님(클라이언트) ---요청---> 점원(서버)
손님(클라이언트) <--응답---- 점원(서버)

✍︎3티어아키텍쳐
:2티어 아키텍처에서 데이터베이스가 추가된 형태
서버는 리소스를 전달해주는 역할, 데이터베이스는 리소스를 저장하는 공간

case)카페
손님(클라이언트) ---요청--> 점원(서버) ---요청--> 창고(데이터베이스)
손님(클라이언트) <--응답--- 점원(서버) <--응답--- 창고(데이터베이스)
- 프론트엔드와 백엔드
  -프론트앤드 개발자 : 클라이언트처럼 사용자가 직접 눈으로 보고, UI를 클릭 또는 터치하는 등의 상호작용을 할 수 있는 앱을 주로 개발
  -백엔드 개발자 : 서버와 같이 사용자 눈에 보이지 않지만, 상품정보를 API로 노출한다든지, 로그인/로그아웃, 권한 관리등의 사용자 인증을 주로 다루는 개발자
- 클라이언트와 서버 종류
  -클라이언트: 보통 플랫폼에 따라 구분
  1. 웹사이트, 웹앱: 브라우저를 통해 주로 이용하는 웹 플랫폼에서의 클라이언트
  2. IOS나 안드로이드와 같은 스마트폰/태블릿 플랫폼, 윈도우와 같은 데스크탑 플렛폼에서 이용하는 앱
  -서버: 무엇을 하느냐에 따라 종류 구분
  1. 파일서버: 파일을 제공하는 앱
  2. 웹서버: 웹사이트에서 필요로 하는 정보들을 제공하는 앱
  3. 메일서버: 메일을 주고 받을 수 있도록 도와주는 앱
  4. 데이터베이스: 데이터제공자로서 일하므로 일종의 서버
클라이언트-서버통신과 API
클라이언트와 서버간의 통신은 요청과 응답으로 구성
-프로토콜: 통신규약
=> 웹애플리케이션 프로토콜: HTTP
-API(Application Programming Interface)
: 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공
interface의 사전적의미: 의사소통이 가능하도록 만들어진 ‘접점’

case) 카페에서 메뉴판 제공

보통 인터넷에 있는 데이터를 요청할 때에는 HTTP프로토콜을 사용하며, 주소(URL,URI)를 통해 접근할수 있다.

*HTTP API 디자인을 잘하는 방법
HTTP메소드는 CRUD 행동에 따라 목적에 맞게 써야한다.

요청 적절한 메소드
조회(read) get
추가(create) post
갱신(update) put 또는 patch
삭제(delete) delete

요청	적절한 메소드
조회(read)	get
추가(create)	post
갱신(update)	put 또는 patch
삭제(delete)	delete

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

URL과 URI

URL(Uniform Resource Identifier)
: 네트워크 상에서 웹페이지, 이미지, 동영상 등의 파일이 위치한 정보
-scheme: 통신방식(프로토콜) 결정
-hosts: 웹서버의 이름이나 도메인, IP를 사용하며 주소를 나타냄
-url-path: 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명

URI(Uniform Resource Identifier)
: 브라우저의 검색창을 클릭하면 나타나는 주소, URL을 포함하는 상위 개념
(일반적인 URL의 기분요소+query, fragment포함)
-query: 웹 서버에 보내는 추가적인 질문
-fragment: 일종의 북마크 기능을 수행하며 URL에 fragment(#)와 특정 HTML요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤 이동

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

부분 명칭 설명
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)
  : 인터넷상에서 사용하는 주소체계
  =>IPv4: 네덩이의 숫자로 구분된 IP주소체계
  ‣ localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭.
  ‣ 0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소
- PORT
  : IP주소가 가리키는 PC에 접속할 수 있는 통로
  Ex) :3000=> 3000번의 통로를 통해 실행중인 리액트를 확인가능
  포트번호는 0~65535까지 사용
  ‣ 22 : SSH
  ‣ 80 : HTTP
  ‣ 443: HTTPS
도메인과 DNS
- domain name
  : 웹 브라우저를 통해 특정 사이트에 진입을 할때, IP주소를 대신하여 사용하는 주소
  (터미널에서 도메인 이름을 통해 IP주소를 확인하는 명령어 : nslookup)
  
  ex)
  IP 주소: 3.34.153.168
  도메인 이름: codestates.com
- DNS(Domain Name System)
  : 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스시스템
  
  Ex) 검색창에 naver.com을 입력=> DNS에서 IP주소 125.209.222.142 를 찾음

부분	명칭	설명
`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	웹 서버에 전달하는 추가 질문

◎HTTP

: HTML과 같은 문서를 전송하기 위한 프로토콜

HTTP Messages
: 클라이언트와 서버 사이에서 데이터가 교환되는 방식
-요청(requests)
-응답(responses)
=>유사한 구조
- start line : start line 에는 요청이나 응답의 상태를 나타냄. 항상 첫번째 줄에 위치 , 응답에는 status line
- HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
- empty line : 헤더와 본문을 구분하는 빈줄
- body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함. 요청과 응답의 유형에 따라 선택적으로 사용
  (start line과 HTTP headers를 묶어 요청이나 응답의 헤더라고 함 )
  *stateless: 상태를 가지지 않는다.
HTTP Requests
: 클라이언트가 서버에게 보내는 메시지
- start line
  1. 수행할 작업(GET, PUT, POST 등) 이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타냄. 예를 들어 GET method는 리소스를 받아야 하고, POST method는 데이터를 서버로 전송함
  2. 요청대상 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됨. 요청 형식은 HTTP method마다 다름
    -origin형식: ‘?’와 쿼리 문자열이 붙는 절대 경로. method와 함께 사용
    
    POST / HTTP 1.1
    GET /background.png HTTP/1.0
    HEAD /test.html?query=alibaba HTTP/1.1
    OPTIONS /anypage.html HTTP/1.0
    
    -absolute형식: 완전한 URL형식, 프록시에 연결하는 경우 대부분 GET method와 함께 사용
    
    GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
    
    -authority형식 : 도메인 이름과 포트 번호로 이루어진 URL의 일부분. CONNECT와 함께 사용
    -asterisk형식 : OPTIONS와 함께 별표(*)하나로 서버 전체를 표현
    
    OPTIONS * HTTP/1.1
  3. HTTP버전에 따라 HTTP message의 구조가 달라짐.start line에 HTTP버전을 함께 입력
- Headers
  : 기본구조를 따른다. 헤더이름, 콜론(:), 값을 입력
  1. General headers: 메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 관련이 없는 헤더
  2. Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더. User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화합니다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가 가능.
  3. Representation headers : body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더.
- Body
  : HTTP messages 구조의 마지막에 위치, POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용
  1. Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성됩니다.
  2. Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다. 보통 HTML form과 관련이 있습니다.
HTTP Responses
: 서버가 클라이언트에게 보내는 메시지
- status line
  : 응답의 첫 줄
  1. 현재 프로토콜의 버전(HTTP/1.1)
  2. 상태 코드 - 요청의 결과를 나타냅니다. (ex. 200, 302, 404 등)
  3. 상태 텍스트 - 상태 코드에 대한 설명
    
    Ex)HTTP/1.1 404 Not Found
- Headers
  : 요청 헤더와 동일한 구조
- Body
  : HTTP messages 구조의 마지막에 위치, 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않다.

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

AJAX(Asynchronous Javascript And XMLhttprequest)
: avascript, DOM, Fetch, XMLHttpRequests, HTML 등의 다양한 기술을 사용하는 웹 개발 기법
=> 웹페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다는 것
- AJAX의 두가지 핵심 기술
  : javascript와 DOM, Fetch
  -Fetch는 사용자가 현재 페이지에서 작업을 하는 동나 서 버와 통신할 수 있도록 한다.
  -javascript에서 dom을 사용해 조작할 수 있기 때문에 fetch를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 dom에 적용시켜 새로운 페이지로 이동하지않고 기존페이지에서 필요한 부분만 변경
- AJAX의 장점
  1. 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있습니다.
    => AJAX를 사용하면 서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트하여 렌더링 할 수 있습니다.
  2. 표준화된 방법
    => XHR이 표준화되면서부터 브라우저에 상관없이 AJAX를 사용할 수 있게 되었습니다.
  3. 유저 중심 애플리케이션 개발
    => 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 애플리케이션을 만들 수 있습니다.
  4. 더 작은 대역폭
    => 필요한 데이터를 텍스트 형태(JSON, XML 등)로 보내면 되기 때문에 비교적 데이터의 크기가 작습니다.
    (대역폭 : 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기)
- AJAX의 단점
  1. Search Engine Optimization(SEO)에 불리
    => AJAX 방식의 웹 애플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어가기 어렵다.
  2. 뒤로가기 버튼 문제
    => AJAX에서는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 동작하지 않는다.
SSR과 CSR
- SSR(Server Side Rendering)
  : 웹페이지를 서버에서 렌더링한다.
  => 사용
  -SEO(Search Engine Optimization) 가 우선순위인 경우, 일반적으로 SSR(Server Side Rendering) 을 사용합니다.
  -웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우, 단일 파일의 용량이 작은 SSR 이 적합합니다.
  -웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용할 수 있습니다.
- CSR(Client Side Rendering)
  : 클라이언트(브라우저)에서 페이지를 렌더링
  =>사용
  -SEO 가 우선순위가 아닌 경우, CSR을 이용할 수 있습니다.
  -사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공합니다.
  -웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있습니다.

김나율

다음 포스트