TIL 211018 - [HTTP/네트워크] 기초 (스압!)

Achievement Goals

• 클라이언트-서버 콘셉트를 이해할 수 있다.
  • 클라이언트-서버 아키텍처를 이해할 수 있다.
  • 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 사용 방법을 익히고 사용할 수 있다.
• Self Guided Lessons (Advanced)
  • How the internet works
  • DNS

 

Chapter 1 - 클라이언트-서버 아키텍쳐

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

2티어 아키텍처

빈번한 데이터 업데이트가 필요한 경우 

리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시키는 것이 유리

이처럼 리소스 존재하는 곳, 리소스 사용하는 앱을 분리시킨 것을(2-tier 아키텍처 or 클라이언트-서버 아키텍처)

2-tier에 DB가 추가된 형태 3-tier 아키텍처

 

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

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

DB: 리소스를 저장하는 공간

 

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

 

클라이언트 - 프론트엔드 영역 (사용자가 직접 보고 상호작용하는 앱)

서버+DB - 백엔드 영역(API노출, 로그인/아웃, 권한관리, Oauth, 시스템 설계

 

클라이언트 종류 : 웹사이트(웹 앱), 스마트폰/태블리용 앱, 데스크탑 앱

서버 종류:  웹서버, 파일서버, 메일서버, DB서버

 

(2) HTTP를 이용한 클라이언트-서버 통신과 API

클라이언트와 서버간의 통신은 요청과 응답으로 구분.

 

프로토콜 :통신 규약.

HTTP : 웹 애플리케이션 프로토콜

클라이언트와 서버는 HTTP라는 프로토콜을 이용해서 요청과 응답을 주고 받는다.

이 둘 사이의 메세지를 HTTP 메세지라고 한다.(참고: MDN 'HTTP 메세지')

 

API(Application Programming Interfase) 

서버는 클라이언트가 리소를 잘 활용할 수있도록 인터페이스를 제공해줘야 하는데 그것이 API이다.

클라이언트 서버가 어떻게 구성되어 있는지 몰라도 API를 통해 서버에 리소스를 요청할 수 있다.

보통 클라이언트가 데이터를 요청할 때 HTTP라는 프로토콜을 사용하며 주소(URL, URI)를 통해 접근한다.

HTTP API 디지인은 CRUD에 맞춰서 하는 것이 베스트 프랙티스이다.

 

 

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

(1) URL과 URI

브라우저에 입력한 URL은 서버가 제공되는 환경에 존재하는 파일의 위치

하지만 보안의 이유로 외부에서 직접 접근이 가능한 경우는 거의 없다.

 

# macOS: file://127.0.0.1/Users/username/Desktop/

로 접속하면 크롬 브라우저를 파일 탐색기로 사용할 수 있다.

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, bookmark를 포함한다.

 

query는 웹 서버에 보내는 추가적인 질문이다.

위 그림의 http://www.google.com:80/search?q=JavaScript 를 브라우저의 검색창에 입력하면,

구글에서 JavaScript를 검색한 결과가 나타납니다.

 

브라우저의 검색창을 클릭하면 나타나는 주소가 URI이다.

URI는 URL을 포함하는 상위개념입니다. 따라서, 'URL은 URI다.' 는 참이고, 'URI는 URL이다.' 는 거짓입니다.

 

 

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

 

(2) IP와 포트

IP address(internet Protocal address, IP 주소) : 네트워크에 연결된 특정 PC의 주소를 나타내는 체계

웹 브라우저에 닷(.)으로 구분된 네 덩이의 숫자를 입력하면 페이지에 접속 가능

이때 사용되는 네 덩이의 숫자를 IP 주소라고 한다.

nslookup : 도메인 네임의 IP주소 확인

네덩이의 숫자로 구분된 IP 주소 체계를 IPv4라고 한다.

IPv4는 Internet Protocol version 4의 줄임말로, IP 주소체계의 네 번째 버전을 뜻함

 

IPv4는 각 덩어리마다 0 ~255까지 나타낼 수 있음.

2^(32)인 약 43억개의 IP주소 표현 가능

 

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

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

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

 

IPv4로 할당할 수 있는 PC가 많아지지면서 IP주소 부족 해결 위해 IPv6

 

PORT

127.0.0.1 : 3000

뒤에 :3000과 같은 숫자. 이 숫자는 IP주소가 가리키는 PC에 접속할 수 있는 통로.

이미 사용 중인 포트는 사용할 수 없음.

포트 번호 0 ~ 65,535까지 사용 가능

그 중 0 ~ 1024는 통신 규약으로 사용처가 정해져 있음

22: SSH

80: HTTP

443:HTTPS

 

(3) 도메인과 DNS

Domai name

웹 브라우저를 통해 특정 사이트에 진입시 IP주소를 대신하여 사용하는 주소.

IP주소가 지번 또는 도로명 주소라고 한다면 도메인 이름은 해당 주소에 위치한 상호

 

DNS

모든 IP주소가 도메인 이름을 가지고 있지는 않다.

모든 도메인 이름은 일정 기간 동안 대여하여 사용한다.

IP주소와 도메인 이름을 매칭정보가 서버가 따로 있다.

DNS(Domain Name System) 호스트의 도메인 이름을 IP주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 DB시스템

 

(4) 크롬 브라우저 에러 읽기

 

Error Message	Description
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	클라이언트 인증서(은행 또는 회사 내부 웹사이트 등)에 오류가 발생하여 웹페이지에 로그인할 수 없습니다.

 

Chapter 3- 네트워크 탭 사용 방법

Chapter 4 - HTTP

(1) HTTP Messge

HTTP HyperText Transfer Protocal, HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜

HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인

HTTP가 message 양식에 맞춰 요청을 보내면, 서버도 HTTP Message 양식에 맞춰 응답(특징: 무상태성/stateless)

 

• 요청(Request)
• 응답(Response)

1. 요청(Requests)

Start line

1. HTTP 메소드 : GET, PUT, POST / HEAD or OPTIONS. GET(리소를 받는 것), POST(데이터를 서버로 전송)

2. 요청 컨텍스트: 요청 대상(URL, URI), 프로토콜, 포트, 도메인

요청 형식

• origin 형식(?와 쿼리 문자열이 붙는 절대 경로)
• absolute 형식(완전한 URL형식, 프록시 연결의 경우 GET과 함께)
• authority 형식(도메인 이름과 포트번호로 이루어진 URL, HTTP 터널구축 CONNECT와 함께)
• asterisk형식(OPTINS와 *로 서버 전체 표시)

3. HTTP 버전

 

Headers

• Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 정보를 포함. user-Agent, Accet-Type, Accet-Language 포함. 
• General headers : body를 통해 전송되는 데이터와 관련 없음
• Entity headers : body에 담긴 리소스 정보(컨텐츠 길이, MIME 타입) 포함

Body

GET, HEAD, DELETE, OPTION처럼 서버에 리소를 요청하는 경우에는 본문이 필요하지 않음. 데이터 업데이트용으로 필요

• Single-resource bodies(단일 리소스 본문) : 헤더 두개(Content-Type, Content-Length)로 정의된 단일 파일로 구성
• Multi-resource bodies(다중 리소스 본문) : 여러 파트로 구성된 본문에 각 파트마다 다른 정보를 지님. HTML form과 관련 있음

2. 응답(Response)

Status line : 예) HTTP/1.1 404 Not Found

• 현재 프로토콜 버전(HTTP/1.1)
• 상태 코드 - 요청 결과(200, 302, 404 등)
• 상태 텍스트 - 상태 코드에 대한 설명

참고) HTTP 응답 상태 코드

400번대 클라이언트 요청에 문제가 있는 경우

500번대 서버의 응답에 문제가 있는 경우

 

"200 OK"

"302 Found" : 리다이렉트할 URL을 확인함

"404 Not Found" : 클라이언트가 잘못된 페이지를 서버에 요청하여 페이지를 찾을 수 없음

"403 Forbidden"

"406 Not Acceptable" : 클라이언트가 응답 코드를 받을 수 없음

"500 Internal Server Error"

 

Headers

 

Body

201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않음

 

Stateless

HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서 HTTP는 이들의 상태를 확인하지 않는다. 쇼핑몰에 로그인하거나 상품을 클릭해서 상세 화면으로 이동하고 상품을 담거나 로그아웃 할 수 있다. 클라이언트에서 발생한 이런 모든 상태를 HTTP 통신은 추적하지 않는다.

 

하지만 상태 정보를 저장해둬야 한다. 그래서 다른 방법(쿠기-세션, API)등을 통해 상태를 확인할 수 있다.

Chapter 5 - 브라우저의 작동 원리(보이는 곳)

(1) SPA를 만드는 기술: AJAX

1. AJAX란?

AJAX: Asynchronous JavaScript And XMLHttpRequest

AJAX의 가장 큰 특징은 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다는 점이다.

• 검색창의 경우 사용자의 입력 검색어에 따른 추천어 표시
• 무한 스크롤이 발생할 때 Fetch 통해 데이터 가져와서 업데이트/렌더링
• 페이스북 메세지나 네이버 포털 사이트 뉴스 탭 비동기적 데이터 받기

비동기적으로 데이터를 서버에서 받아와 브라우저에 렌더링하는 기법은 AJAX라고 한다.

2. AJAX의 두가지 핵심 기술

JS, DOM, Fetch

 - AJAX 구성요소

• 웹 페이지 표현을 위한 HTML, CSS
• 데이터에 접근하거나, 화면 구성을 동적으로 조작하는 DOM
• 데이터 교환에 사용되는 JSON 이나 XML
• 웹 서버와 비동기적 통신을 위한 XMLHttpRequest 객체
• JavaScript

전통적인 웹 페이지는 <form> 태그를 이용해서 버서에 데이터 전송. 서버는  요청에 대한 응답으로 새로운 웹 페이지 제공

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

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

 

그리고 JS에서 DOM을 사용해 조작가능하기 때문 Fetch를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 DOM적용시켜

새로운 페이지 이동하지 않고 기존 페이지에서 필요한 부분만 변경한다.

 

브라우저는 Fetch가 서버에 요청을 보내고 응답을 받을 때까지 모든 동작을 멈추는 게 아니라 계속해서 페이지를 사용할 수 있게 하는 비동기적인 방식을 사용한다.

 

Fetch 이전 XHR(XMLHttpRequest) 사용.

Fetch는 XHR보다 가볍고 JS와 호환되는 JSON 사용.

3. AJAX의 장점

• 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있습니다. 이전에는 서버에서 HTML을 완성하여 보내주어야 화면에 렌더링을 할 수 있었습니다. 그러나 AJAX를 사용하면 서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트 하여 렌더링 할 수 있습니다.
• 표준화된 방법 이전에는 브라우저마다 다른 방식으로 AJAX를 사용했으나, XHR이 표준화 되면서부터 브라우저에 상관 없이AJAX를 사용할 수 있게 되었습니다.
• 유저 중심 어플리케이션 개발 AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 어플리케이션을 만들 수 있습니다.
• 더 작은 대역폭 (대역폭: 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기) 이전에는 서버로부터 완성된 HTML 파일을 받아와야했기 때문에 한번에 보내야 하는 데이터의 크기가 컸습니다. 그러나 AJAX에서는 필요한 데이터를 텍스트 형태(JSON, XML 등) 보내면 되기 때문에 비교적 데이터의 크기가 작습니다.

4. AJAX의 단점

• Search Engine Optimization(SEO)에 불리 AJAX 방식의 웹 어플리케이션은 한 번 받은 HTML을 렌더링 한 후, 서버에서 비동기적으로 필요한 데이터를 가져와 그려냅니다. 따라서, 처음 받는 HTML 파일에는 데이터를 채우기 위한 틀만 작성되어 있는 경우가 많습니다. 검색 사이트에서는 전세계 사이트를 돌아다니며 각 사이트의 모든 정보를 긁어와, 사용자에게 검색 결과로 보여줍니다. 그런데 AJAX 방식의 웹 어플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어가기 어렵습니다.
• 뒤로가기 버튼 문제 일반적으로 사용자는 뒤로가기 버튼을 누르면 이전 상태로 돌아갈 거라고 생각하지만, AJAX에서는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 동작하지 않습니다. 따라서 뒤로가기 등의 기능을 구현하기 위해서는 별도로 History API를 사용해야 합니다.

(2) SSR과 CSR

SSR: Server Side Rendering. 웹페이지를 서버에서 렌더링하는 것.

브라우저가 다른 경로로 이동할 때마다 서버는 리렌더링

 

CSR: Client Side Rendering.  브라우저의 요청을 받은 서버는 웹 페이지를 렌더링 하는 대신

웹페이지의 골격이 될 단일 페이지를 클라이언트에 보냄. 이때 JS파일도 같이 보냄. 클라이언트가 웹페이지를 받으면

JS파일은 브라우저에 웹페이지를 완전히 렌더링된 페이지를 바꾼다.

 

만일 웹페이지에 필요한 내용이 DB에 저장된 것이라면 브라우저가 DB데이터를 가져와서 렌더링해야 하는데 이때 필요한 데이터를

API 요청을 통해서 한다.

 

브라우저가 다른 경로로 이동하면 브라우저는 브라우저 자신이 요청한 경로에 따라 페이지를 리렌더링

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

Use SSR

• SEO(Search Engine Optimization) 가 우선순위인 경우, 일반적으로 SSR(Server Side Rendering) 을 사용합니다.
• 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR 이 적합합니다.
• 웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용할 수 있습니다.

Use CSR

• SEO 가 우선순위가 아닌 경우, CSR을 이용할 수 있습니다.
• 사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공합니다.
• 웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있습니다.

(3) CORS

Cross-origin Resource Sharing. 다른 오리진 간에 리소스를 공유.

처음 전송되는 리소스의 도메인과 다른 도메인으로 부터 리소스가 요청될 경우 해당 리소스는 CORS HTTP 요청에 의해 요청된다.

브라우저가 자발적으로 브라우저의 애플리케이션을 보호하기 위한 정책

 

XMLHttpRequest, Fetch API, Web Fonts, WebGL. textures

 

접근 제어 시나리오 예제

 

1) Simple requests

GET, HEAD, POST

Cotent-Type : Content-Type 개체 헤더는 리소의 media type을 나타내기 위해 사용. 브라우저는 어떤 경우에는 MIME 스니핑을 해서 이 헤더의 값을 꼭 따르지 않는다. 이를 막기 위해 X-Content-Type-Option헤더를 nosniff로 설정할 수 있다.

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

Client가 GET 요청, origin : https://foo.example

Server가 응답.

Access-Control-Allow-Origin: * ==> 이는 모든 도메인에서 접근할 수 있음 의미

Access-Control-Allow-Origin: https://foo.example ==> https://foo.example의 요청만 리소스에 대한 접근 허용

 

2) Preflighted requests

simple requests와 다른 방식. 먼저 OPTION 메서드를 통해 다른 도메인의 리소스로 HTTP 요청을 보내 실제 요청이 전송하기에 안전한지 확인. 미리 전송(preflighted)

preflighted 요청

요청에 대한 서버 응답

서버는 Access-Control-Allow-Methos로 응답하고 POST, GET이 리소스를 쿼리하는데 유용하다고 알려준다.

또한 Access-Control-Allow-Header의 값을 'X-INGOTHER', 'Content-Type'으로 전송하여 헤더에 요청할 수 있음을 확인

 

3) Requests with credentials

Credential requests는 HTTP cookies와 HTTP Authentication 정보를 인식.

XMLHttpRequest나 Fetch는 호출에서 브라우저는 자격 증명을 보내지 않음.  호출될 때 특정 플래그를 설정

7행에 withCredentials라는 부울값을 갖는다. 브라우저는 Access-Control-Allow-Crendential : true 헤더가 없는 응답은 거부한다.