학습 목표
클라이언트-서버 콘셉트를 이해할 수 있다.
클라이언트-서버 아키텍처를 이해할 수 있다.
HTTP를 이용한 클라이언트-서버 통신을 이해할 수 있다.
API의 개념을 이해할 수 있다.
브라우저의 작동 원리를 이해할 수 있다.
보이지 않는 곳의 통신을 이해할 수 있다.
URL과 URI의 차이를 이해할 수 있다.
IP 주소와 PORT에 대해 이해할 수 있다.
DNS와 IP 주소의 관계를 설명할 수 있다.
크롬 브라우저의 에러 메시지를 통해 문제를 파악할 수 있다.
보이는 곳의 통신을 이해할 수 있다.
AJAX의 개념을 이해할 수 있다.
SSR과 CSR의 차이를 이해할 수 있다.
CORS의 개념을 이해할 수 있다.
HTTP messages의 구조를 설명할 수 있다.
HTTP의 동작 방식을 이해할 수 있다.
HTTP requests와 responses를 구분할 수 있다.
HTTP의 응답 메시지를 찾아볼 수 있다.
Chrome Network Tab을 이해할 수 있다.
Chrome Network Tab 사용 방법을 익히고 사용할 수 있다.
👻클라이언트-서버 아키텍쳐
예를 들어 쇼핑몰의 경우 서버가 없다면 상품 정보를 업데이트 해야할 때마다 앱 업데이트를 해야하는 불편함이 있다.
그렇기에 서버로부터 정보를 전달받아 실시간으로 고객에게 정보를 제공할 수 있다.
이처럼 상품 정보와 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍쳐, 또는 클라이언트-서버 아키텍쳐라고 부른다.
클라이언트(client) == 손님
서버(server) == 서빙하는 사람
서버가 전달해야 하는 리소스를 저장하는 공간을 "데이터베이스"라고 한다. (==창고)
이와 같이 2티어 아키텍쳐에 데이터베이스가 추가된 형태를 3티어 아키텍쳐라고 한다.
👻HTTP를 이용한 클라이언트-서버 통신과 API
웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 대화를 나눈다.
이를 "HTTP 메시지"라고 한다.
식당에서 메뉴판을 제공하듯이 서버에서는 클라이언트가 리소스를 잘 활용할 수 있도록 API(Application Programming Interface)를 제공한다.
보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있다.
HTTP 요청 시에 메서드를 지정하여 리소스와 관련된 (CRUD)를 지정할 수도 있다.
👻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, bookmark를 포함한다.
query는 웹 서버에 보내는 추가적인 질문이다. (구글 검색)
브라우저의 검색창을 클릭하면 나타나는 주소가 URI이다.
따라서 URI는 URL을 포함하는 상위개념 이므로 URL은 URI다.가 참이 된다. (URI는 URL이다.는 거짓)
👻IP와 포트
네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP address(Internet Protocol address, IP 주소)라고 한다.
IPv4는 각 덩어리마다 0부터 255까지 나타낼 수 있고, 2^(32)인 약 43억 개의 IP 주소를 표현할 수 있다.
localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭
0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소
현재는 개인 PC의 보급으로 전 세계의 누구나 PC를 이용하기 때문에 IPv4로 할당할 수 있는 PC가 한계를 넘어섰다.
이를 해결하기 위해 등장한 것이 IPv6(IP version 6, 2^(128)개의 IP 주소를 표현 가능)이다.
PORT
Tomcat started on port(s): 8080을 보면
8080과 같은 숫자를 PORT라고 하며, 이 숫자는 IP주소가 가리키는 PC에 접속할 수 있는 통로(채널)을 의미한다.
포트 번호는 0~ 65,535 까지 사용할 수 있다.
그 중에서 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다.
ex)
22 : SSH
80 : HTTP
443: HTTPS
이미 정해진 포트 번호라도, 필요에 따라 자유롭게 사용할 수 있고, 잘 알려진 포트의 경우 URI 등에 명시하지 않지만, 그 외의 잘 알려지지 않은 포트(:8080과 같은 임시 포트)는 반드시 포함해야 한다.
👻도메인과 DNS
Domain name
우리는 웹 브라우저를 통해 특정 사이트에 접속 할 때, IP주소로 접속하지 않고 별도의 주소를 통해 접속한다.
만약 IP 주소가 지번 또는 도로명 주소라면, 도메인 이름은 해당 주소에 위치한 상호로 볼 수 있다.
DNS
DNS는 Domain Name System의 줄임말로, 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템이다.
만약 브라우저의 검색창에 naver.com을 입력한다면, 이 요청은 DNS에서 IP 주소(125.209.222.142)를 찾아 이 IP주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 해준다.
👻HTTP Messages
HTTP messages 는 클라이언트와 서버 사이에서 데이터가 교환되는 방식이다.
HTTP messages에는 요청(Requests), 응답(Responses)과 같은 두 가지 유형이 있다.
HTTP messages는 몇 줄의 텍스트 정보로 구성되지만 개발자가 직접 작성하는 것이 아닌 구성파일, API, 기타 인터페이스에서 자동으로 완성해준다.
요청(Requests)과 응답(Responses)의 구조
1. start line : start line에는 요청이나 응답의 상태를 나타낸다. 항상 첫 번째 줄에 위치하며 응답에서는 status line이라고 부른다.
2. HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
3. empty line : 헤더와 본문을 구분하는 빈 줄
4. body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함하며, 요청과 응답의 유형에 따라 선택적으로 사용
이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 한다.
👻요청(Requests)
Start line
HTTP 요청은 클라이언트가 서버에 보내는 메시지이다.
Start line에는 세가지 요소가 있다.
1. 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타낸다.
예를 들어 GET method는 리소스를 받아야 하고, POST method는 데이터를 서버로 전송한다.
2. 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성된다.
요청 형식은 HTTP method 마다(origin 형식, absolute 형식, authority 형식, asterisk 형식)다르다.
Headers
요청의 Headers는 기본 구조를 따르며, 값은 헤더에 따라 다르다.
Headers의 그룹
1. General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더이다.
2. Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미한다.
User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 보다 구체화한다.
Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수도 있다.
3. Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더이다.
Body
요청의 본문은 HTTP messages 구조의 마지막에 위치하고, 모든 요청에 body가 필요하지는 않다.
GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다.
POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용한다.
body의 종류
1. Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성된다.
2. Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닌다.(HTML form)
👻응답(Responses)
Status line
응답의 첫 줄은 Status line이라고 부른며, 다음의 정보를 포함한다.
1. 현재 프로토콜의 버전(HTTP/1.1)
2. 상태 코드 - 요청의 결과를 나타낸다. (200, 302, 404 등)
3. 상태 텍스트 - 상태 코드에 대한 설명
Headers
응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있다.
1. General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더이다.
2. Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공한다.
3. Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더이다.
Body
요청의 본문은 HTTP messages 구조의 마지막에 위치하고, 모든 요청에 body가 필요하지는 않다.
201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않다.
body의 종류
1. Single-resource bodies(단일-리소스 본문) :
길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의한다.
길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있다.
2. Multiple-resource bodies(다중-리소스 본문) :
서로 다른 정보를 담고 있는 body
👻Stateless
HTTP의 큰 특징 중 하나인 Stateless는 말 그대로 상태를 가지지 않는다는 뜻이며, HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않는다.
예를들어 쇼핑몰에 로그인하거나 상품윽 카트에 담을 때 이러한 상태를 저장하지 않는다.
따라서, 필요에 따라 쿠키-세션, API등을 통해 상ㅌ채를 확인할 수 있다.
👻AJAX 란?
AJAX의 가장 큰 특징은 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다는 것이다.
ex)구글 추천 검색어, 맨 밑까지 스크롤하면 서버로부터 새로운 정보를 가져와 랜더링하는 무한 스크롤
AJAX를 구성하는 핵심 기술은 JavaScript와 DOM, 그리고 Fetch이다.
전통적인 웹 애플리케이션에서는 <form> 태그를 이용해 서버에 데이터를 전송해야 했다.
또한 클라이언트에서 요청을 보내면 매번 새로 페이지를 이동해야 했다.
이를 해결하기 위해 등장한 것이 Fetch이다.
Fetch는 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있으며, 서버로부터 응답을 받을 떄까지 모든 동작이 멈추는 것이 아닌 계속해서 페이지를 사용할 수 있게 하는 비동기적인 방식을 사용한다.
Fetch 이전에는 XHR(XMLHttpRequest)를 사용했다.
👻AJAX의 장단점
장점
1.
서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있다. (필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트하여 랜더링 할 수 있다.)
2.
표준화된 방법 이전에는 브라우저마다 다른 방식으로 AJAX를 사용했으나, XHR이 표준화되면서부터 브라우저에 상관없이 AJAX를 사용할 수 있게 되었다.
3.
유저 중심 애플리케이션 개발 AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 애플리케이션을 만들 수 있다.
4.
옛날에는 서버로부터 완성된 HTML 파일을 받아와야 했기 때문에 한 번에 보내야 하는 데이터의 크기가 컸다.
그러나 AJAX에서는 필요한 데이터를 텍스트 형태(JSON, XML 등) 보내면 되기 때문에 비교적 데이터의 크기가 작다.
단점
1.
Search Engine Optimization(SEO)에 불리 AJAX 방식의 웹 애플리케이션은 한 번 받은 HTML을 렌더링 한 후, 서버에서 비동기적으로 필요한 데이터를 가져와 그려내는데, 처음 받는 HTML 파일에는 데이터를 채우기 위한 틀만 작성되어 있는 경우가 많아 사이트의 정보를 긁어가기 어렵다.
2.
일반적으로 사용자가 뒤로가기 버튼을 누르면 이전 상태로 돌아가지만, AJAX에서는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 동작하지 않는다. (뒤로가기 등을 구현하고 싶다면 History API를 사용해야 한다.)
👻SSR과 CSR
SSR(Server Side Rendering)이란?
서버에서 랜더링하는 과정
웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR 이 적합하다.
SEO(Search Engine Optimization)가 우선 순위인 경우 사용한다.
웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용할 수 있다.
CSR(Client Side Rendering)이란?
서버가 아닌 클라이언트에서 랜더링 하는 과정
SEO 가 우선순위가 아닌 경우, CSR을 이용할 수 있다.
사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공한다.
웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있다.
SSR의 사용 예시
네이버 블로그 :
블로그 같은 경우 검색엔진에 최대한 노출되는 것이 유리하고, 다른 웹사이트에 비해 사용자와 상호작용 하는 기능이 많지 않기에 SSR이 합리적인 선택이 될 수 있다.
The NewYork Times :
SSR의 대표적인 단점인 많은 사용자가 클릭할 때마다 전체 웹사이트를 다시 서버에서 받아오기 때문에 발생하는 서버 과부하 이슈가 있음에도 불구하고, CSR에 비해 초기 로딩 속도가 빠르기 때문에 구독자가 신문기사를 빠르게 읽을 수 있다는 장점이 있고, 신문 기사가 검색엔진에 노출되는 것이 매우 중요하기 때문에 뉴욕 타임스 홈페이지 또한 SEO에 유리한 SSR을 사용하고 있다.
CSR의 사용 예시
아고다 :
아고다뿐만 아니라 많은 예약 사이트들은 CSR을 사용하고 있다.
상호작용(interaction)이 많아질수록 서버에 부담이 많은 SSR이 아닌 CSR을 사용할 때에 클라이언트에 필요한 데이터만 넘겨주기 때문에 부담이 적다.
하지만 검색엔진 최적화가 필요한 서비스라면 최적화에 좀 더 유리한 SSR을 사용하도록 하자오늘은 브라우저의 원리에 대한 개념을 학습했다.
확실히 알고리즘에 비해 개념을 학습하는 데에는 큰 어려움은 없었던 것 같다. 하지만 깊게 공부할수록 헷갈리는 부분들이 좀 있었고, 내용 또한 셀 수 없이 많이 있었다.
아무래도 네트워크, 데이터베이스 등에 대한 학습은 현업에서 개발을 할 때에도 지속적으로 학습을 해야하지 않을까란 생각이 든다.
오늘도 고생했고 내일도 파이팅!
개발 공부