● 오늘 공부한 것
- 클라이언트-서버 아키텍처
- 서버란 말그대로 (server)이기 때문에, 클라이언트의 요청에 따라 리소스를 제공합니다.
- 반대로 클라이언트는 서버에게 리소스 요청을 하고, 그에 따른 응답을 받습니다.
- 하지만 서버에게 요청을 하지 않고, 이런 리소스를 클라이언트 자체에서 늘 가지고 있게 된다면 언제나 이 리소스를 관리해야하며, 애플리케이션을 업데이트 해야한다면 애플리케이션 자체를 늘 업데이트 해야할 것입니다. 따라서 이런 서버요청은 필수적입니다.
- 따라서 리소스가 존재하는 곳, 리소스를 사용하는 앱을 분리시킨 것을 2-Tier 아키텍처라고 하며 다른말로는 클라이언트-서버 아키텍처라고 합니다.
- 일반적을 서버는 리소스를 전달해주는 역할을 담당합니다. 리소스를 저장해두는 공간을 마련하는데 이를 데이터베이스라고 합니다. 데이터베이스는 창고 같은 역할이고, 서버는 데이터베이스에서 리소스를 꺼내와 클라이언트에게 전달하는 것이죠. 이러한 구조를 3-Tier 아키텍처라고 합니다.
- 클라이언트-서버 통신과 API
일반적으로 클라이언트가 서버와 통신하기 위해서 요청을 하고 그 응답을 받습니다. 하지만 무작정 요청을 해서는 안되겠죠. 사람과 사람간의 대화를 할 때도 대화의 요청방식이 있듯, 머신과 머신간에도 소통의 방식이 있습니다. 이를 프로토콜이라고 합니다.
프로토콜이란?
1. 한 개체와 한 개체간의 소통 규칙 (rule)이다.
2. 다른 노드의 동일한 계층간의 통신 규칙이다.
3. 복수의 컴퓨터 사이나 중앙 컴퓨터와 단말기 사이에서 데이터 통신을 원활하게 하기 위해 필요한 통신 규약
프로토콜에도 다양한 프로토콜이 있습니다.(라우팅, 네트워크, 전송, 응용프로그램) 웹에서는 클라이언트와 서버가 HTTP 프로토콜을 이용해서 서로 대화를 나누게 됩니다. 이때 주고 받는 대화, 메시지를 HTTP 메시지라고 합니다.
자, 우리는 이제 서버와 소통해보려고 합니다.
하지만 우리는 서버가 어떻게 이루어져있는지 잘 알지 못합니다. . 그리고 어떻게 서버에 접근할 수 있을까요?
- Interface 인터페이스
인터페이스란?
1. 시스템과 시스템을 연결하기 위한 접점
2. 시스템과 전송매체를 연결하기 위한 접점
3. 상호간의 소통을 위해 만들어진 접점
즉, 인터페이스란 상호간의 소통을 위해 만들어진 접점을 이야기합니다. 인터페이스를 통해서 쉽게 소통할 수 있습니다.
예를 들어, 사람과 컴퓨터가 소통하기 위해서는 키보드를 입력해 입력할 수 있고, 또 모니터나 스피커를 통해 그 입력에 대한 출력을 볼 수 있습니다. 즉, 스피커, 키보드가 인터페이스라고 볼 수 있는 것입니다. 이를 사용자 인터페이스(UI)라고 합니다. 스마트폰에서는 버튼을 누르고, 장바구니에 넣고 버튼을 누르고 비밀번호를 입력해 계산하는 등 이런 것들이 모두 인터페이스라고 볼 수 있겠죠?
그렇다면 응용 프로그램, 운영체제 끼리의 인터페이스는 무엇일까요? API란 Application Programing Interface의 약자로 운영체제끼리 소통할 수 있는 인터페이스를 이야기합니다. 쉽게 이야기하면 애플리케이션에서 데이터를 읽거나 쓰기 위해 사용하는 인터페이스입니다.
예를 들어 우리가 날씨 정보를 알려주는 웹 애플리케이션을 만든다고 가정해봅시다. 날씨를 보여주는 html, css 파일들을 만든다고 해도 가장 중요한것은 날씨의 정보를 가져오는 것입니다. 우리는 이 데이터를 가져오기 위해 API를 통해 가져올 수 있습니다.
데이터 서버와 연결된 API서버에 HTTP 요청을 하면 데이터 정보를 가져와 응답해주는 것입니다. 따라서 우리는 어렵게 서버의 모든것을 다 파악해서 데이터정보를 가져올 필요가 없는 것이죠. 이런 편리한 API를 통해 데이터를 가져올 수 있는 것입니다. 위의 예시는 3-Tier 아키텍처겠죠?
HTTP API를 사용하기 위해서는 메서드 4가지가 있습니다(CRUD).
API는 함수, 클래스 수준의 인터페이스일 수도 있습니다. (console.log 이런것도 모두 API라고 보는 것입니다. 왜냐면 웹브라우저와 소통하는 수단이니까!)
HTTP API를 쓰기 위해서는 URL, URI에 대해서 알아합니다. URL은 자원에 대한 정보를 담고 있습니다.
- URL, URI
URL은 Uniform Resource Locator의 줄임말로, 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냅니다. URL은 scheme, hosts, url-path로 구분할 수 있습니다. 가장 먼저 작성하는 scheme은 통신 방식(프로토콜)을 결정합니다. 일반적인 웹 브라우저에서는 http(s)를 사용합니다. hosts는 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타냅니다. url-path는 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타냅니다.
URI는 Uniform Resource Identifier의 줄임말로, 일반적으로 URL의 기본 요소인 scheme, hosts, url-path에 더해 query, fragment를 포함합니다. query는 웹 서버에 보내는 추가적인 질문입니다. 위 그림의 http://www.google.com:80/search?q=JavaScript 를 브라우저의 검색창에 입력하면, 구글에서 JavaScript를 검색한 결과가 나타납니다. 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 | 웹 서버에 전달하는 추가 질문 |
- IP, PORT
IP는 (Internet Protocol)로 각각 하드웨어가 가지고 있는 주소를 이야기합니다.
IPv4 주소체계를 통해 각각 하드웨어마다 IP주소를 가질 수 있었는데, 점점 아이패드나 기기들이 다양해지면서 IPv4 체계로만으로는 모든 장치들이 IP주소를 가지기 어렵게 되었습니다. 이에 따라 IPv6 주소체계가 생기게 되었습니다.
PORT는 PC에 접속할 수 있는 통로를 의미합니다.
IP 주소는 장치를 식별하지만 포트 번호는 해당 장치의 특정 응용 프로그램이나 프로세스를 식별합니다.
PORT를 이해하기 위한 좋은 은유는 내부에서 운영되는 여러 비즈니스가 있는 물리적 건물을 생각하는 것입니다. 건물의 주소(IP 주소와 유사)는 건물의 위치를 식별하지만 각 비즈니스에는 사람들이 직접 연락할 수 있는 자체 전화 번호(포트 번호와 유사)가 있습니다.
- 도메인, DNS
우리는 IP와 포트의 조합을 통해서 다른 컴퓨터의 서버에 접근할 수 있습니다. 하지만 우리는 이런 주소를 모두 기억해서 입력하지 않습니다. 따라서 도메인을 통해서 쉽게 접근할 수 있습니다. IP와 포트를 기억하지 않아도 !! 그리고 네트워크는 이런 도메인과 매칭되는 IP 주소를 확인하는데, 그것을 DNS(Domain Name System)라고 합니다.
- HTTP Message
HTTP Messages는 클라이언트와 서버 사이에서 데이터가 교환되는 방식입니다. HTTP Messages에는 다음과 같은 두 가지 유형이 있습니다.
- 요청(Requests)
- 응답(Responses)
HTTP Messages는 몇 줄의 텍스트 정보로 구성됩니다. 그러나 개발자는 이런 메시지를 직접 작성할 필요가 거의 없습니다. 구성 파일, API, 기타 인터페이스에서 HTTP Messages를 자동으로 완성합니다.
요청(Requests)과 응답(Responses)은 다음과 같은 유사한 구조를 가집니다.
- start line : start line에는 요청이나 응답의 상태를 나타냅니다. 항상 첫 번째 줄에 위치합니다. 응답에서는 status line이라고 부릅니다.
- HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합입니다.
- empty line : 헤더와 본문을 구분하는 빈 줄이 있습니다.
- body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다. 요청과 응답의 유형에 따라 선택적으로 사용합니다.
이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 이야기합니다.
- statelss
Stateless는 말 그대로 상태를 가지지 않는다는 뜻입니다. HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않습니다. 사용자는 쇼핑몰에 로그인하거나 상품을 클릭해서 상세 화면으로 이동하고, 상품을 카트에 담거나 로그아웃할 수도 있습니다. 클라이언트에서 발생한 이런 모든 상태를 HTTP 통신이 추적하지 않습니다. 만약 쇼핑몰에서 카트에 담기 버튼을 눌렀을 때, 카트에 담긴 상품 정보(상태)를 저장해둬야 합니다. 그러나 HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않습니다.
서버에게 요청을 한뒤 응답을 받고, 나 아까 요청받은거 다시 달라고 하면 기억하지 않는다는 것입니다..! 서버는 클라이언트의 상태를 기억하지 않는다!
- ajax
ajax는 비동기적으로 웹 페이지에 필요한 부분만 데이터를 요청해 보여줄 수 있습니다. fetch 이전에는 XMLRequest를 사용했었습니다. 지금은 fetch API로 쉽게 json파일을 불러올 수 있고 비동기적으로 데이터를 가져올 수 있습니다.
- 비동기적으로 필요한 데이터만 가져올 수 있다.
- 대역폭이 작다
- 유저에게 더 좋은 UX를 제공할 수 있다.
● 끝맺음
- 수업이외의 학습
- 네트워크 수업듣기
- useEffect 원리 공부하기
- 알고리즘 문제 1개 풀기
