🌊 TIL : 2023년 3월 28일 </span ></span >
오늘 배운 것
Client Server Architecture
클라이언트 - 서버 아키텍처 - 데이터베이스 (3티어 아키텍처)
- 클라이언트 :
리소스를 사용하는 앱 (요청) - 서버 :
리소스를 제공하는 곳 (응답)
일반적으로 리소스를 전달해 주는 역할만을 담당 - 데이터베이스 :
리소스를 저장하는 별도의 공간
클라이언트 | |
웹 플랫폼 | 웹사이트, 웹 앱 |
스마트폰/태블릿 플랫폼 (IOS, 안드로이드), 데스크탑 플랫폼 |
앱 |
클라이언트 - 서버 통신과 API
프로토콜 : 통신 규약, 즉 약속. 요청을 하기 위해서 꼭 지켜야 하는 약속
HTTP : 웹 애플리케이션 프로토콜
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP
라는 프로토콜을 이용해서 서로 대화를 나눈다.
HTTP를 이용해 나눈 메시지를 "HTTP 메시지"
라고 부른다.
OSI 7 Layers
응용 계층 프로토콜
프로토콜 이름 | 설명 |
HTTP | 웹에서 HTML, JSON 등의 정보를 주고 받는 프로토콜 |
HTTPS | HTTP에서 보안이 강화된 프로토콜 |
FTP | 파일 전송 프로토콜 |
SMTP | 메일 전송 프로토콜 |
SSH | CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜 |
RDP | Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜 |
Websocket | 실시간 통신, Push 등을 지원하는 프로토콜 |
전송 계층 프로토콜
프로토콜 이름 | 설명 |
TCP | HTTP, FTP 통신 등의 근간이 되는 인터넷 프로토콜 |
UDP | (양방향의 TCP와는 다르게) 단방향으로 작동하는 인터넷 프로토콜 훨씬 더 단순하고 빠르지만 신뢰성이 낮다. |
API (Application Programming Interface)
: 서버는 클라이언트에게 리소스를 잘 활욯알 수 있도록 인터페이스를 제공해줘야 한다.
API는 메뉴판과도 같다.
요청 | URL 디자인 예제 |
아메리카노 한 잔 주세요 | /coffee/americano |
망고 프라푸치노 한 잔 주세요 | /frapppuccino/mango |
콜드브루 두 잔 주세요 | /coffee/coldbrew?quantity=2 |
아메리카노 두 잔 전부 헤이즐럿 시럽 넣어주세요. | /coffee/americano?quantity=2&syrup=hazelnet |
인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하여 주소(URL, URI)를 통해 접근할 수 있게 된다.
헤이즐럿 시럽 같은 옵션을 파라미터
라고 부르며, 파라미터를 사용하기 위해 물음표(?)
와 앰퍼샌드(&)
를 이용한다.
HTTP 요청시 메서드를 지정하여 리소스와 관련된 행동 (CRUD; create/read/update/delete)를 지정할 수 있습니다.
URL과 URI
URL (Uniform Resource Locator) : 네트워크 상에서 웹페이지, 이미지, 동영상 등의 파일이 위치한 정보. scheme, hosts, url-path로 구분할 수 있다.
- scheme : 통신 방식 (프로토콜)을 결정한다. 일반적인 웹 브라우저에서는 http(s)를 사용한다.
- hosts : 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타낸다.
- url-path : 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타낸다.
URI (Uniform Resource Identifier) : 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, fragment를 포함한다. 브라우저의 검색창을 클릭하면 나타나는 주소가 URI. URI는 URL을 포함하는 상위개념. UIL은 URI지만 URI는 URL이 아니다
- query : 웹 서버에 보내는 추가적인 질문
- fragment : 일종의 북마크. URL에
fragment(#)
와 특정 HTML 요소의 id를 전달하면 해당 요소가 잇는 곳으로 스크롤 할 수 있다.
부분 | 명칭 | 설명 |
file://, http://, https:// | scheme | 통신 프로토콜 |
127.0.0.1, www.google.com | hosts | 웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP</span > |
:80, :443, :3000 | port | 웹 서버에 접속하기 위한 통로 |
/serach, /User/username/Desktop | uri-path | 웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로</span > |
q=JavaScript | query | 웹 서버에 전달하는 추가 질문 |
IP와 포트
IP(Internet Protocol) adress : 네트워크에 연결된 특정 PC의 주소를 나타내는 체계
IPv4(Internet Protocol version 4) : 네 덩이의 숫자로 구분된 IP 주소 체계
localhost
,127.0.0.1
: 현재 사용 중인 로컬 PC를 지칭0.0.0.0
,255.255.255.255
: broadcast address. 로컬 네트워크에 접속 된 모든 장치와 소통하는 주소. 서버에서 접근 가능 IP주소를 broadcast address로 지정하면 모든 기기에서 서버로 접근할 수 있다
IPv6 : IPv4로 할당 할당 할 수 있는 수보다 PC의 수가 많아져 고안 된 표기법. 2^(128)개의 IP주소를 표현 가능 x:x:x:x:x:x:x:x</b > </span >
터미널에서 IPv4 주소 확인하는 법 :
nslookup <URL>
PORT : localhost:3000
처럼 IP 주소 뒤에 붙은 :숫자.
이 숫자는 PC에 접속할 수 있는 통로를 의미한다. 포트 번호는 0~65535까지 사용 가능하며 0~1024번까지는 주요 통신을 위한 규약에 따라 이미 정해져 있다.
- 22 : SSH
- 80 : HTTP
- 443 : HTTPS
도메인과 DNS
도메인(Domain) : IP주소가 지번 또는 도로명 주소라면, 도메인 이름은 해당 주소에 위치한 상호라고 할 수 있다.
DNS(Domain Name System) : 호스트의 도메인 이름을 IP로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템. 주소창에 도메인을 입력시 DNS에서 IP주소를 찾고 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있게 한다.</span >
크롬 브라우저 에러
크롬 전체 에러메세지 목록 : chrome://network-errors/
을 검색창에 입력하여 확인할 수 있다.</span >
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 (HyperText Transfer Protocol)
: HTML과 같은 문서를 전송하기 위한 프로토콜. 웹 브라우저와 웹 서버의 소통을 위해 디자인 되었다.
HTTP Messages : 클라이언트와 서버 사이에서 데이터가 교환되는 방식
- 요청 (Requests)
- 응답 (Response)
- start line : 요청이나 응답의 상태 (응답에서는 status line)
- HTTP headers : 요청을 지정하거나 메세지에 포함된 본문을 설명하는 헤더의 집합
- empty line : 헤더와 본문을 구분하는 빈 줄
- body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함. 요청과 응답의 유형에 따라 선택적으로 사용한다.
Stateless : 상태를 가지지 않았다는 뜻. HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않는다. Stateless(무상태성)가 HTTP의 큰 특징이다.
HTTP Requests
: 클라이언트가 서버에 보내는 메세지
Start line
- 수행할 작업 (GET, PUT, POST 등)이나 방식 (HEAD or OPTIONS)을 설명하는 HTTP method를 나타낸다.
Get 메서드는 리소스를 받아야 하고, POST 메서드는 데이터를 서버로 전송한다. - 요청 대상 (일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성된다. 이 요청 형식은 HTTP 메서드마다 다르다.
- origin 형식 :
'?'
와 쿼리 문자열이 붙는 절대 경로. GET, POST, HEAD, OPTIONS등의 메서드함께 사용한다.POST / HTTP 1.1</s >
GET / background.png HTTP/1.0
HEAD / test.html?query=oguogu HTTP/1.1</s >OPTIONS / anypage.html HTTP/1.0
- authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 일부분. HTTP 터널을 구축하는 경우
CONNECT
와 함께 사용 가능CONNECT developer.mozilla.org:80 HTTP/1.1</s > - asterisk 형식 :
OPTIONS
와 함께 별표(*) 하나로 서버 전체를 표현한다.OPTIONS * HTTP/1.1
- origin 형식 :
- HTTP 버전에 따라 HTTP Message의 구조가 달라진다. start line에 HTTP 버전을 함께 입력한다.
Headers : 기본 구조를 따른다. 헤더 이름(대소문자 구분이 없는 문자열), 콜론(:), 값을 입력한다. 값은 헤더에 따라 다르며 여러 종류의 헤더가 있고, 다음 같이 그룹을 나눌 수 있다.
- General headers : 메세지 전체에 적용되는 헤더. body를 통해 전송되는 데이터와는 관련이 없다.
- Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화한다. - Representation headers : 이전에는 Entity headers로 불렸다. body에 담긴 리소스의 정보(콘텐츠의 길이, MIME타입 등)을 포함하는 헤더
Body : HTTP message의 마지막에 위치한다. GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 body가 빌요하지 않다. POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용한다.
- Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type, Content-Length)로 정의된 단일 파일로 구성
- Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서 각 파트마다 다른 정보를 가진다.
HTML form
과 관련이 있다.
HTTP Responses
: 서버가 클라이언트에게 보내는 메세지다.
Status line : 예시로 HTTP/1.1 404 Not Found
가 있다.
- 현재 프로토콜의 버전(HTTP/1.1)
- 상태 코드 - 요청의 결과 (ex. 200, 302, 404 등)
- 상태 텍스트 - 상태 코드에 대한 설명
Headers : 응답에 들어가는 HTTP headers는 요청헤더와 동일한 구조를 가지고 있다. 대소문자 구분 없는 문자열, 콜론(:), 값을 입력한다. 값은 헤더에 따라 다르며 몇 그룹으로 나눌 수 있다.
- General headers : 메시지 전체에 적용되는 헤더. body를 통해 전송되는 데이터와는 관련이 없는 없다.
- Response headers : 위치 또는 서버 자체에 대한 정보 (이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공한다.
- Representation headers : 이전에는 Entity headers로 불렀으며 body에 담긴 리소스의 정보(콘텐츠의 길이, MIME 타입 등)을 포함하는 헤더.
Body : 201, 204와 같은 상태 코드를 가지는 응답에는 body가 필요하지 않다.
- Single-resource bodies(단일-리소스 본문) :
- 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-length)로 정의
- 길이를 모르는 단일 파일로 구성된 단일 리소스 본문은 Transfer-Encoding이 Chunked로 설정되어 있으며, 파일은 chnuk로 나뉘어 인코딩된다.
- Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body이다.
Ajax
: Asynchronous JavaScript And XMLHttpRequest의 약자로, JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법</span >
특징 : 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다.
인스타그램이나 네이버 포털사이트의 뉴스 탭 역시 비동기적으로 데이터를 서버에서 받아와 브라우저에 렌더링하는 것이고, 이러한 기법을 AJAX
라고 부른다.
장점
- 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있다.
- 표준화된 방법
- 유저 중심 어플리케이션 개발 (일부만 렌더링 하기 때문에 더 빠르고 많은 상호작용이 가능하다)
- 더 작은 대역폭
대역폭 : 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기
단점
- SEO에 불리
- 뒤로가기 버튼 문제 (별도의 History API를 사용하여야 한다.)
XHR과 Fetch
: Fetch 이전에는 XHR(XMLHttpRequest)를 사용하였다. Fetch는 XHR의 단점을 보완한 새로운 Web API이며 XML보다 가볍고 JS와 호환되는 JSON을 사용한다.
어려웠던 부분
: HTTP 메세지 읽는 법
더 공부할 것
: HTTP
'🐹 TIL > Daily' 카테고리의 다른 글
[코드스테이츠/33DAY] S2U8 - [HTTP/네트워크] 실습 (4) | 2023.03.30 |
---|---|
[코드스테이츠/32DAY] S2U8 - [HTTP/네트워크] 실습 (2) | 2023.03.29 |
[코드스테이츠/30DAY] S2U6 - [React] React State & Props (3) | 2023.03.27 |
[코드스테이츠/29DAY] S2U6 - [React] React State & Props (2) | 2023.03.24 |
[코드스테이츠/28DAY] S2U5 - [React] React SPA (2) | 2023.03.23 |