Unit7 - [HTTP/네트워크] 기초

클라이언트 - 서버 아키텍처

비번한 데이터 업데이트 필요 -> 리소드 존재하는 곳 , 리소스 사용하는 앱을 분리시키는 것(2티어 아키텍처)

클라이언트 : 리소스를 사용하는 앱

서버: 리소스를 제공하는 곳

클라이언트와 서버는 요청과 응답을 주고 받는 관계아다.

 

기존2티어+데이터베이스 추가(3티어)

데이터베이스 : 리소스를 저장하는 공간

데이터베이스는 데이터 제공자로 일종의 서버이다.

 

클라이언트-서버통신과 API

웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눈다.

프로토콜은 통신 규약, 즉 약속

응용계층

HTTP : 웹에서 HTML,JSON등의 정보를 주고받는 프로토콜

HTTPS: HTTP에서 보안이 강화된 프로토콜
FTP: 파일 전송 프로토골
SMTP: 메일을 전송하기 위한 프로토콜
SSH: CLI환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP: Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜

Websocket: 실시간 통신,Push등을 지원하는 프로토콜

 

전송계층

TCP: HTTP,FTP 통신 등의 근간이 되는 인터넷 프로토콜 

UDP:(양방향의 TCP와 다르게) 단방향으로 작동하는 훨씬 더 단순하고 빠르지만 신뢰성이 낮은 인터넷 프로토콜

 

API(Application Programming Interface)

서버는 클라이언트에게 리소스를 잘 활용할수 있도록 인터페이스(Interface : 의사소통 가능)를 제공

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

 

HTTP 요청에는 메서드

CRUD(Create(POST) , read(GET) , update (PUT 또는 PATCH), delete(DELETE))

---

URI와 URL

URL은 Uniform Resource Locator

네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보

scheme, hosts, url-path로 구분

scheme은 통신 방식(프로토콜)을 결정,일반적인 웹 브라우저에서는 http(s)를 사용

ex)file://, http://, https://

hosts는 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타냄

ex)127.0.0.1, www.google.com

url-path는 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명

ex)/search, /Users/username/Desktop

 

URI는 Uniform Resource Identifier

cheme, hosts, url-path + query, fragment를 포함

query는 웹 서버에 보내는 추가적인 질문ex)q=JavaScript

fragment는 일종의 북마크 기능을 수행,

URL에 fragment(#)와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동

 

IP주소와 port

IP address(Internet Protocol address, IP 주소)

네트워크에 연결된 특정 PC의 주소를 나타내는 체계를

 

localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭

0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소

서버에서 접근 가능 IP 주소를 broadcast address 로 지정하면, 모든 기기에서 서버에 접근

 

port  :서버로 진입할 수 있는 통로(IP 주소로 진입)

IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)를  의미

포트 번호는 0~ 65535 까지 사용

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

잘알려진 포트는 생략 가능

ex):80, :443, :3000

 

도메인과 DNS 

nslookup codestates.com -> 도메인이름을 통해 IP주소 확인하는 명령어

IP주소 :3.34.153.168

도메인 이름 : codestates.com

 

DNS

호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템

도메인이름입력하여 해당 사이트 이동 ->해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업이 반드시 필요

ex)브라우저의 검색창에 naver.com을 입력한다면, 이 요청은 DNS에서 IP 주소(ex.125.209.222.142)를 찾고,

IP주소에 해당하는 웹서버로 요청 전달-> 클라이언트와 서버 통신 가능

 

크롬 브라우저 에러 읽기

chrome://network-errors/를 입력하여 확인

Error MessageDescription

"Aw, Snap!" ("앗, 이런!")	Chrome 브라우저에서 페이지를 로드하는 데 문제가 발생
ERR_NAME_NOT_RESOLVED	호스트 이름(웹 주소)이 존재X
ERR_INTERNET_DISCONNECTED	사용 중인 기기가 인터넷에 연결X
ERR_CONNECTION_TIMED_OUT ERR_TIMED_OUT	페이지에 연결하는 데 시간이 너무 오래 걸림 , 인터넷 연결이 너무 느리거나, 웹페이지에 접속한 사용자가 많아서 발생
ERR_CONNECTION_RESET	웹페이지 연결을 방해하는 요소가 어딘가에 발생
ERR_NETWORK_CHANGED	웹페이지를 로드하는 중에 기기의 네트워크 연결이 해제되었거나, 새로운 네트워크에 연결
ERR_CONNECTION_REFUSED	웹페이지에서 Chrome 브라우저의 연결을 허용X
ERR_CACHE_MISS	웹페이지로부터 이전에 입력한 정보를 다시 한번 제출하도록 요청받음
ERR_EMPTY_RESPONSE	웹페이지에서 데이터를 전혀 전송하지 않았으며, 데이터를 전송할 서버가 다운됨
ERR_SSL_PROTOCOL_ERROR	페이지에서 전송된 데이터를 Chrome 브라우저가 해석X
ERR_BAD_SSL_CLIENT_AUTH_CERT	클라이언트 인증서(은행 또는 회사 내부 웹사이트 등)에 오류가 발생하여 웹페이지에 로그인X

 

---

HTTP Messages

클라이언트와 서버 사이에서 데이터가 교환되는 방식

요청(Requests)과 응답(Responses)

구조

start line : start line에는 요청이나 응답의 상태를 나타낸다.

응답에서는 status line

HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합

요청과 응답의 유형에 따라 선택적으로 사용

start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)

 

empty line : 헤더와 본문을 구분하는 빈 줄

body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함

payload는 body

 

Stateless(무상태성)

TTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인X

HTTP는 통신 규약일 뿐이므로, 상태를 저장X

따라서 필요에 따라 다른 방법(쿠키-세션, API 등)을 통해 상태를 확인

 

HTTP Requests

클라이언트가 서버에게 보내는 메시지

Start line

1.수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method

ex) get method : 리소스 받음 , POST method : 데이터를 서버로 전송

2.요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성

이 요청 형식은 HTTP method 마다 다름

origin 형식:리소스의 경로와 서버의 호스트 이름이 포함되어 있는 형식

'?'와 쿼리 문자열이 붙는 절대 경로될수도 있다.

(ex: http://www.example.com/path)

absolute 형식:리소스의 경로, 서버의 호스트 이름, 포트 번호가 포함되어 있는 형식

완전한 URL 형식

http://www.example.com:8080/path)

authority 형식:도메인 이름과 포트 번호로 이루어진 URL의 일부분

(ex: http://www.example.com:8080)

asterisk 형식:요청 대상이 전체 서버에 적용되는 경우에 사용되는 형식 (ex: *).

OPTIONS 와 함께 별표(*) 하나로 서버 전체를 표현

3.HTTP 버전에 따라 HTTP message의 구조가 달라진다.

 

Headers

요청 메타데이터를 제공하는 중요한 요소

헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값을 입력

General headers : HTTP 요청과 응답에서 공통적으로 사용되는 헤더

메시지 전체에 적용되는 헤더

Request headers :HTTP 요청에서만 사용되는 헤더

fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더

Representation headers :HTTP 요청에서만 사용되는 헤더로서, 요청 리소스와 관련된 메타데이터를 제공

body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더

 

Body

HTTP 요청 메시지의 payload에서 전송되는 데이터

HTTP messages 구조의 마지막에 위치

GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요X

POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용

 

Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일

한 명의 사용자 또는 한 개의 항목에 대한 데이터

Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지님

여러 사용자의 데이터가 한꺼번에 전송될 때 다중 리소스 본문이 사용

 

HTTP Responses

서버가 클라이언트에게 보내는 메시지

Status line

1. 현재 프로토콜의 버전(HTTP/1.1)
2. 상태 코드 - 요청의 결과
3. 상태 텍스트 - 상태 코드에 대한 설명

Headers

응답 메타데이터를 제공하는 중요한 요소

HTTP 응답에 대한 정보를 서버에서 클라이언트로 제공, 응답에 대한 추가적인 제어 정보를 제공

대소문자 구분 없는 문자열, 콜론(:), 값을 입력

General headers : HTTP 요청 또는 응답에서 양쪽에서 사용될 수 있는 헤더

메시지 전체에 적용되는 헤더

Response headers : HTTP 응답에서만 사용되는 헤더

위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더

Representation headers:응답의 내용에 대한 정보를 제공하는 헤더.

body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더

 

Body

Single-resource bodies(단일-리소스 본문) :클라이언트에게 하나의 리소스가 제공

길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의

길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정

파일은 chunk로 나뉘어 인코딩

 

Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body

 

AJAX(Asynchronous JavaScript And XMLHttpRequest)

JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법

웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다

 

Fetch를 사용하면, 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있다.

사용자가 현재 페이지에서 작업을 하는 동안 서버와 통신할 수 있다.

 

JavaScript에서 DOM을 사용해 조작할 수 있기 때문에 Fetch를 통해 필요한 데이터만 가져와 DOM에 적용시켜

기존 페이지에서 필요한 부분만 변경

 

XHR과 Fetch

Fetch 이전에는 XHR(XMLHttpRequest)를 사용

Fetch는 XHR의 단점을 보완한 새로운 Web API이며, XML보다 가볍고 JavaScript와 호환되는 JSON을 사용(promise 지원)

XHR는 Cross-Site 이슈 등의 불편함

Fetch는 promise 지원

 

AJAX 장점과 단점장점

서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만든다.

표준화된 방법(XHR이 표준화되면서 브라우저 상관없이 AJAX 사용)

유저 중심 애플리케이션 개발(일부분만 렌더링하기 때문에 빠르고 더많은 상호작용가능)

더 작은 대역폭(데이터 크기가 작다)

 

AJAX 단점

Search Engine Optimization(SEO)에 불리(HTML파일은 뼈대만 있고 데이터는 없어서 사이트 정보를 긁어가기 어렵다)

뒤로가기 버튼 문제(AJAX는 이전을 기억하지 않기 때문에 의도대로 동작X , History API를 사용해야됨)

 

SSR vs CSR

SSR(Server Side Rendering)과 CSR(Client Side Rendering)

 

정의

SSR : 웹 페이지를 브라우저에서 렌더링하는 대신에 서버에서 렌더링,서버에서 전체 페이지의 HTML을 생성하여 브라우저로 전송

서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전히 렌더링

 

CSR :SSR의 반대로 클라이언트에서 페이지를 렌더링,브라우저에서 JavaScript를 사용하여 HTML을 렌더링

클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저의 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.

 

SSR은 서버에서 HTML을 생성하여 전송하는 방식이고

CSR은 클라이언트에서 데이터를 가져와 동적으로 화면을 구성하는 방식

 

차이점

페이지가 렌더링되는 위치

SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링

CSR은 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고, 동적으로 라우팅을 관리

 

SSR사용

SEO가 우선순위인 경우 SSR사용

웹페이지 첫화면 렌더링 빠르게 필요 -> 단일 파일의 용량이 작은 SSR 적합

웹페이지가 상호작용 적다 -> SSR 활용

 

CSR 사용

SEO가 우선순위 아닌경우사이트에 상호작용 많다. -> 빠른 라우팅으로 강력한 사용자 경험 제공하는 CSR웹 애플리케이션 제작하는 경우 -> 더 나은 사용자 경험 제공하는 CSR

 

SSR은 정적인 웹 사이트에 적합하고, CSR은 동적인 웹 애플리케이션에 적합

 

퀴즈

 

localhost"는 로컬 머신을 가리키는 특수 호스트 이름

 

상태 코드 404는 Not Found, 클라이언트가 잘못된 페이지를 서버에 요청하여 페이지를 찾을 수 없을 때 나오는 상태 코드

 

GET 방식은 URL과 함께 전송하는 요청 매개변수를 사용하여 웹 서버에 데이터를 요청한다. 이 방식은 데이터의 요청과 전송이 간단하고 데이터의 전송 량이 적어 속도가 빠르다. 데이터의 전송 내용이 URL에 표시되므로 보안에 취약하다.

POST 방식은 URL과 별개로 요청 매개변수를 전송하여 웹 서버에 데이터를 전송한다. 이 방식에서는 데이터의 전송 내용이 URL에 표시되지 않으므로 보안상 더 좋다. 하지만 데이터의 전송 량이 많은 경우 속도가 느리다.