18. [HTTP/네트워크] 기초

문도연·2022년 6월 9일

http 네트워크 코드스테이츠

코드스테이츠 부트캠프 - FE

목록 보기

19/44

Chapter1. 웹 애플리케이션 아키텍처

1-1. 클라이언트 - 서버 아키텍처
1-2. 클라이언트 - 서버 통신과 API

Chapter2. 브라우저의 작동 원리(보이지 않는 곳)

2-1. URL과 URI
2-2. IP와 포트
2-3. 도메인과 DNS
2-4. 크롬 브라우저 에러 읽기

Chapter3 HTTP

3-1. HTTP Messages
3-2. HTTP Requests
3-3. HTTP Responses

Chapter4. 브라우저의 작동 원리(보이는 곳)

4-1. SPA를 만드는 기술 : AJAX
4-2. SSR과 CSR

Chapter1. 웹 애플리케이션 아키텍처

클라이언트-서버 아키텍처를 이해할 수 있다.
HTTP를 이용한 클라이언트-서버 통신을 이해할 수 있다.
API의 개념을 이해할 수 있다.

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

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

리소스(정보)가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 설계 방식

=> 2티어 아키텍처 라고도 불림
=> 데이터베이스가 추가된 형태를 3티어 아키텍처라 부름

클라이언트 <-> 인터넷 <-> 서버 <-> 데이터베이스

역할	이름	하는 일	예시	영역
리소스를 사용하는 앱	클라이언트	요청	결제 기능,상품 조회 기능	프론트엔드
리소스를 전달하는 앱	서버	응답, 요청	상품 정보 노출,사용자 인증	백엔드
리소스를 저장하는 공간	데이터베이스	응답	상품 목록 저장	백엔드

프론트엔드와 백엔드

프론트엔드 혹은 백엔드는 아키텍처에서 어떤 분야를 다루는지에 따라 구분됨
프론트엔드 개발자
=> 유저가 직접 눈으로 보고, UI를 클릭 또는 터치하는 등의 상호작용을 할 수 있는 앱을 주로 개발
백엔드 개발자
=> 사용자 눈에 보이지 않지만, 상품 정보를 API로 노출하거나, 로그인/로그아웃, 권한 관리 등의 사용자 인증을 주로 다룸

클라이언트와 서버 종류

클라이언트는 플랫폼에 따라 구분됨

플랫폼	클라이언트
웹	웹 앱(웹사이트)
iOS, 안드로이드	스마트폰/태블릿용 앱
윈도우 등 데스크탑	데스크탑 앱

서버가 하는 일에 따라 구분됨

서버	하는 일
웹 서버	웹사이트에서 필요한 정보를 제공하는 앱
파일 서버	파일을 제공하는 앱
메일 서버	메일 주고받는 것 도와주는 앱
데이터베이스 서버	데이터 제공하는 앱

퀴즈

웹 개발에서 클라이언트는 브라우저를 말한다.(o)
클라이언트는 서버에 요청을 보내고, 응답을 받는다.(o)
서버는 데이터베이스에 요청을 보내고, 응답을 받는다.(o)
-> 클라이언트는 서버로 요청을 보내고, 서버는 요청에 따라 적절한 응답을 클라이언트로 회신합니다.
-> 필요에 따라 서버는 데이터베이스에 요청을 보내고, 회신 받은 응답을 활용합니다.
클라이언트: 웹 브라우저를 통해 원하는 정보를 요청합니다. 서버로부터 받은 응답에 따라 다른 화면을 표시합니다.

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

클라이언트와 서버의 통신

클라이언트와 서버 간의 통신은 요청과 응답으로 구성됨
요청이 있어야만 응답이 옴

프로토콜(Protocol)

클라이언트와 서버 간의 통신을 알려면 먼저 프로토콜이라는 개념을 이해해야 함
프로토콜은 통신 규약, 즉 약속임
->리소스를 요청하기 위해서 꼭 지켜야 하는 약속이 몇 가지 존재함

웹 앱 프로토콜 : HTTP

웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 HTTP라는 프로토콜을 이용해서 대화함
-> HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부름

프로토콜 사례 : 스타벅스 커피 주문하는 방법

프로토콜1. 직접 카운터로 찾아감
프로토콜2. 모바일 앱 이용
프로토콜3. 키오스크

커피를 주문할 수 있는 방법이 여러가지
=== 서버와 통신할 수 있는 다양한 방법이 존재한다는 의미

프로토콜 사례2_규약 : 우편

커피를 외계어로 주문할 수 없듯이, 우편을 보낼 때 '보내는 사람'은 '좌측 상단'에 표기, '받는 사람'은 '우측하단'에 표기, 우표 붙여야만 함.

"우편 전송"이라는 행동을 하기 위해 반드시 지켜야 하는 규약이 있음을 의미합니다. 각 프로토콜마다 지켜야 하는 규약이 존재함

주요 프로토콜(OSI 7 Layers)

OSI 7 Layers는 프로토콜이 어떤 계층(layer)에 속해있는지를 표시

7.응용 계층

프로토콜 이름	설명
HTTP	웹에서 HTML, JSON 등의 정보를 주고받는 프로토콜
HTTPS	HTTP에서 보안이 강화된 프로토콜
FTP	파일전송 프로토콜
SMTP	메일을 전송하기 위한 프로토콜
SSH	CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP	Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WebSocket	실시간 통신, Push 등을 지원하는 프로토콜

4.전송 계층

프로토콜 이름	설명
TCP	HTTP, FTP 통신의 근간이 되는 인터넷 프로토콜
UDP	(양방향의 TCP와는 다르게)단방향으로 작동하는 인터넷 프로토콜 -> 훨씬 더 단순하고 빠르나 신뢰성이 낮음

API

클라이언트가 서버에게 리소스를 요청하는 방법이 적힌 문서 === API
->API를 보고 서버로부터 요청가능한 자원을 파악, 요청할 수 있어야함

서버도 클라이언트에게 리소스를 잘 활용할 수 있도록 API(Application Programming Interface)를 제공해야함

API 사례 : 커피 주문

API는 메뉴판과 같은 역할을 함
메뉴판은 해당 카페에서 주문 간으한 메뉴를 안내함
-> 손님이 엉뚱한 메뉴(설렁탕)를 시키지 않도록 함

마찬가지로

서버는 리소스 전달을 위한 메뉴판, 즉 API문서를 구축해놓아야 클라이언트가 이를 활용할 수 있음

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

URL 예제

호스트 http://starbucks.com

요청	URL 예제
아메리카노 두잔	/coffee/ameicano
아메리카노 두 잔에 전부 헤이즐럿 시럽 넣어주세요	/coffee/americano?quantity=2&syrup=hazelnet

파라미터를 사용하기 위해 물음표(?)와 & 기호를 사용함

HTTP API 디자인하기

HTTP 요청에는 메서드라는 것이 존재함
-> HTTP 요청시 메소드를 지정하여 리소스와 관련된 행동(CRUD; create/read/update/delete)을 지정할 수 있음

요청	적절한 메소드
조회(Read)	GET
추가(Create)	POST
갱신(Update)	PUT 또는 PATCH
삭제(Delete)	DELETE

-> HTTP 메서드는 CRUD 행동에 맞게 적절하게 써야 함

Chapter2. 브라우저의 작동 원리(보이지 않는 곳)

브라우저의 작동 원리를 이해할 수 있다.
보이지 않는 곳의 통신을 이해할 수 있다.
URL과 URI의 차이를 이해할 수 있다.
IP 주소와 PORT에 대해 이해할 수 있다.
DNS와 IP 주소의 관계를 설명할 수 있다.
크롬 브라우저의 에러 메시지를 통해 문제를 파악할 수 있다.

2-1. URL과 URI

URL ?

Uniform Resource Locator의 줄임말로, 서버가 제공되는 환경(네트워크상)에 존재하는 파일의 위치를 나타냄

슬래시(/)를 이용해 서버의 폴더에 진입하거나 파일을 요청

URL 예시

http://www.google.com:80/search?q=JavaScript
-> 구글 검색창에 검색어 JavaScript 쳤을 때 주소

file://127.0.0.1/Users/username/Desktop/
-> 위 URL을 크롬 브라우저에 입력하면, 크롬 브라우저를 파일 탐색기로 쓸 수 있음

URL의 기본요소 : scheme, hosts, url-path

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

127.0.0.1 은 로컬 PC를 나타냄

URI의 구성요소 : URL 3요소 + query, fragment

Uniform Resource Identifier의 줄임말

fragment는 일종의 북마크 기능을 수행하며 URL에 fragment(#)와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동할 수 있음

-> 즉, URI는 URL을 포함하는 상위개념임
브라우저의 검색창을 클릭하면 나타나는 주소가 URI입니다.

2-2. IP와 포트

IP

Internet Protocol의 줄임말로 인터넷상에서 사용하는 주소체계를 말함
-> 인터넷에 연결된 모든 PC는 IP 주소체계를 따라 네 덩이의 숫자로 구분

IP address

Internet Protocol address, IP 주소
-> 네트워크에 연결된 특정 PC의 주소를 나타내는 체계

IPv4

네 덩이의 숫자로 구분된 IP 주소체계
Internet Protocol version 4의 줄임말로, IP 주소체계의 네 번째 버전

IPv4는 각 덩어리마다 0부터 255까지 나타낼 수 있음
2^(32)인 약 43억 개의 IP 주소를 표현할 수 있음

기억해 둘 IP 주소

localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭
0.0.0.0, 255.255.255.255 : broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소
-> 서버에서 접근 가능 IP 주소를 broadcast address 로 지정하면, 모든 기기에서 서버에 접근할 수 있음

IPv6

인터넷 보급률이 낮았던 초기에는 IPv4로 네트워크에 연결된 PC에 주소를 할당하는 일이 가능했으나, 개인 PC의 보급과 각종 서비스를 위해 서버를 생산하면서 IPv4로 할당할 수 있는 PC가 한계를 넘어섬
-> 그래서 나타난게 IPv6
-> 표기법을 달리 책정하여 2^(128)개의 IP 주소를 표현할 수 있음

PORT

PC에 접속할 수 있는 통로(채널)

http://127.0.0.1:3000 http://localhost:300	설명
http	프로토콜
127.0.0.1 localhost	내 컴퓨터의 IP주소 현재 사용 중인 로컬PC
:3000	포트 IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)

-> 이미 사용 중인 포트는 중복해서 사용할 수 없음
-> 포트 번호는 0~ 65535 까지 사용할 수 있음
-> 그중에서 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있음

잘 알려진 포트 번호

22 : SSH
80 : HTTP
443: HTTPS

-> 'HTTP는 80번 포트를 사용해 통신한다.'
-> 이미 정해진 포트 번호라도, 필요에 따라 자유롭게 사용할 수 있음
-> 잘 알려진 포트는 URI 등에 명시하지 않지만, 그 외의 잘 알려지지 않은 포트(3000과 같은 임시 포트)는 반드시 포함해야 함

2-3. 도메인과 DNS

Domain name

알아보긴 힘든 IP 주소를 간단하게 나타낸 주소
-> 웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용

터미널 명령어 nslookup : 도메인 이름을 통해 IP 주소를 확인할 수 있음

예시

IP주소: 서울 중구 세종대로 110
도메인: 서울시청

DNS(Domain Name System)

브라우저의 검색창에 도메인 이름을 입력하여 해당 사이트로 이동하기 위해서는 해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업이 반드시 필요. 그걸 해주는 애가 DNS

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

예시

유저가 브라우저의 검색창에 naver.com을 입력
-> 이 요청은 DNS에서 IP 주소(ex.125.209.222.142)를 찾는다.
-> 이 IP 주소에 해당하는 웹 서버로 요청을 전달
-> 해당 웹서버가 클라이언트에게 응답
-> 이런 식으로 클라이언트와 서버의 통신을 도움

모든 IP주소가 도메인 이름을 가질까? NO

네트워크 상에 존재하는 모든 PC는 IP 주소가 있음.
그러나, 모든 IP 주소가 도메인 이름을 가지는 것은 아님
즉, 모든 도메인 이름은 일정 기간 동안 대여하여 사용함

DNS 구성 : sub-domain.domain.TLD.

sub-domain	.domain	.TLD
www	.naver	.com
서브도메인 호스트 이름이라고도 불림	root 도메인	최상위(탑레벨)도메인
www, m, store	co, ac kr, us 등의 국가코드	.com, .kr, .net
웹 사이트의 특정 부분을 나눠서 보여줘야하는 경우 사용함

Domain Name Server(zone)

도메인을 관리함

Domain Name Server 구성

모든 도메인을 관리하는 Root 네임 서버,
TLD를 관리하는 TLD 네임 서버,
권한 있는 네임 서버로 구성됨

도메인 네임의 서버는 서버 하나로 구성되진 않음

안정성을 위해 최소한 두 개 이상의 서버가 하나의 도메인 네임을 담당함
하나의 서버로 운영될 경우 생길 수 있는 과부하 및 서비스 거부 공격에 대해 효율적으로 대응가능

Root 네임 서버는 각 최상위 도메인 네임 서버들의 주소를 알고 있으며,
최상위 도메인 네임 서버는 권한 있는 네임 서버의 주소를 알고 있습니다.
권한 있는 네임 서버는 example.com 등의 도메인 IP 주소 및 도메인 정보를 관리하는 권한을 가진 서버입니다.

중간에 정리하다 말았음 노잼. 그러나 중간부터 다시읽어라,,

2-4. 크롬 브라우저 에러 읽기

에러가 발생하는 경우

웹페이지를 제공하는 서버와 Chrome 브라우저가 소통하는 단계
기기와 네트워크의 연결
Chrome 브라우저가 해석할 수 없는 데이터를 전송받은 경우

에러 메시지 종류

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

전체 에러 메시지 목록은 크롬 브라우저의 검색창에 chrome://network-errors/를 입력하면 확인가능

Chapter3 HTTP

HTTP의 동작 방식을 이해할 수 있다.
HTTP Messages의 구조를 설명할 수 있다.
HTTP Requests와 Responses를 구분할 수 있다.
HTTP의 응답 메시지를 찾아볼 수 있다.

3-1. HTTP Messages

HTTP Messages

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

HTTP Messages 유형

요청(Requests)
응답(Responses)

HTTP Messages 구성

몇 줄의 텍스트 정보로 구성되는데 개발자는 이런 메시지를 직접 작성할 필요가 거의 없음.
구성 파일, API, 기타 인터페이스에서 HTTP Messages를 자동으로 완성하기 때문

HTTP Messages 구조

start line : 요청이나 응답의 상태를 나타냄. 항상 첫 번째 줄에 위치.
*응답에서는 status line
HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
empty line : 헤더와 본문을 구분하는 빈 줄
body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함함. 요청과 응답의 유형에 따라 선택적으로 사용

여기서
start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고,
payload는 body라고 함

Stateless(무상태성)

상태를 가지지 않는다는 뜻
-> 무상태성은 HTTP의 큰 특징임
-> HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지는 않는다.는 의미

Stateless 예시

만약 쇼핑몰 앱에서 카트에 담기 버튼을 눌렀을 때, 카트에 담긴 상품 정보(상태)를 저장해둬야 함. 그러나 HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않음

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

3-2. HTTP Requests

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

Start line

Start line은 3가지 요소로 구성됨

HTTP method
수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명
ex) GET method는 리소스를 받음
ex) POST method는 데이터를 서버로 전송
요청대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로
-> 요청 형식은 HTTP method 마다 다름
- origin 형식 : '?'와 쿼리 문자열이 붙는 절대 경로
  -> GET, POST, HEAD, OPTIONS 등의 메서드와 함께 사용함
  POST / HTTP 1.1
  GET /background.png HTTP/1.0
  HEAD /test.html?query=alibaba HTTP/1.1
  OPTIONS /anypage.html HTTP/1.0
- absolute 형식 : 완전한 URL 형식
  ->프록시에 연결하는 경우 대부분 GET method와 함께 사용
  GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
- authority 형식 : 도메인 이름과 포트 번호로 이루어진 URL의 일부분
  ->HTTP 터널을 구축하는 경우, CONNECT와 함께 사용할 수 있음
  CONNECT developer.mozilla.org:80 HTTP/1.1
- asterisk 형식 :OPTIONS 와 함께 별표(*) 하나로 서버 전체를 표현
  OPTIONS * HTTP/1.1
HTTP 버전
버전에 따라 HTTP message의 구조가 달라짐. 따라서 start line에 HTTP 버전을 함께 입력함

Headers

기본 구조
: 헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값

헤더 그룹

General headers
: 메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 관련이 없는 헤더
Request headers
: fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
->User-Agent, Accept-Type, Accept-Language 와 같은 헤더는 요청을 구체화함
-> Referer: 컨텍스트 제공
-> If-None: 조건에 따라 제약을 추가
Representation headers
: 이전에는 Entity headers로 불림
: body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더

Body

HTTP messages 구조의 마지막에 위치함
모든 요청에 body가 필요하지는 않음
->GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않음
->POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용

Body 종류

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

3-3. HTTP Responses

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

Status line

응답의 첫 줄, 아래의 정보를 포함

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

예시
HTTP/1.1 404 Not Found

Headers

기본 구조
요청 헤더와 동일한 구조
-> 대소문자 구분 없는 문자열, 콜론(:), 값
-> 값은 헤더에 따라 다름

예시
Access-Control-Allow-Origin: *, Server: Apache, Vary: Cookie, Accept-Encoding

헤더 그룹

General headers
- 메시지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와는 관련이 없는 헤더
Request headers
- 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더.
- Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공
Representation headers
- 이전에는 Entity headers로 불림
- body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더

Body

HTTP messages 구조의 마지막에 위치
모든 응답에 body가 필요하지는 않음
201, 204와 같은 상태 코드를 가지는 응답에는 본문 필요없음

Body 종류

Single-resource bodies(단일-리소스 본문)
- 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의
- 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩돼 있음
Multiple-resource bodies(다중-리소스 본문)
- 서로 다른 정보를 담고 있는 body입니다.

Chapter4. 브라우저의 작동 원리(보이는 곳)

보이는 곳의 통신을 이해할 수 있다.
AJAX의 개념을 이해할 수 있다.
SSR과 CSR의 차이를 이해할 수 있다.

4-1. SPA를 만드는 기술 : AJAX

AJAX

서버와 비동기적으로 데이터를 주고받는 자바스크립트 기술
Asynchronous JavaScript And XMLHttpReques 의 약자.
JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법

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

AJAX 예시 : 구글 검색창

검색창은 유저의 요구에 따라 반응하며 변화함.
검색창에 한 글자를 입력할 때마다, 해당 글자로 시작하는 단어들을 서버로부터 받아와, 아래에 추천검색어를 보여줌.
-> 즉, 필요한 데이터만 비동기적으로 받아와 렌더링 되며, 여기에 AJAX가 사용됨

AJAX 핵심 기술 2가지

JavaScript와 DOM, + Fetch

Fetch를 사용하면, 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있음
-> Fetch는 사용자가 현재 페이지에서 작업을 하는 동안 서버와 통신할 수 있도록 함
-> 즉, 브라우저는 Fetch가 서버에 요청을 보내고 응답을 받을 때까지 모든 동작을 멈추는 것이 아니라 계속해서 페이지를 사용할 수 있게 하는 비동기적인 방식을 사용함

Fetch를 통해 전체 페이지가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있음

XHR과 Fetch

Fetch 이전에는 XHR(XMLHttpRequest)를 사용했음
Fetch는 XHR의 단점을 보완한 새로운 Web API로, XML보다 가볍고 JavaScript와 호환되는 JSON을 사용함

XHR은 Cross-Site 이슈 등의 불편함이 있었고, 그에 비해 Fetch는 promise 지원 등의 장점을 가지고 있기 때문에 이제는 Fetch를 많이 사용함

Fetch 예제

// Fetch 
fetch('http://52.78.213.9:3000/messages')
	.then (function(response) {
		return response.json();
	})
	.then(function (json) {
		...
});

XMLHttpRequest 예제

// XMLHttpRequest
var xhr = new XMLHttpRequest();
xhr.open('get', 'http://52.78.213.9:3000/messages');

xhr.onreadystatechange = function(){
	if(xhr.readyState !== 4) return;
	// readyState 4: 완료

	if(xhr.status === 200) {
        // status 200: 성공
		console.log(xhr.responseText); // 서버로부터 온 응답
	} else {
		console.log('에러: ' + xhr.status); // 요청 도중 에러 발생
	}
}

xhr.send(); // 요청 전송

AJAX의 장점

서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있음
- 이전에는 서버에서 HTML을 완성해 보내주어야 화면에 렌더링을 할 수 있었음.
- 그러나 AJAX를 사용하면 서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트하여 렌더링 할 수 있음
표준화된 방법임
- 이전에는 브라우저마다 다른 방식으로 AJAX를 사용했으나, XHR이 표준화되면서부터 브라우저에 상관없이 AJAX를 사용할 수 있게 됨
유저 중심 애플리케이션 개발
- AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 애플리케이션을 만들 수 있음
더 작은 대역폭

대역폭: 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기
- 이전에는 서버로부터 완성된 HTML 파일을 받아와야 했기 때문에 한 번에 보내야 하는 데이터의 크기가 컸음
- 그러나 AJAX에서는 필요한 데이터를 텍스트 형태(JSON, XML 등)로 보내면 됨 -> 비교적 데이터의 크기가 작다

AJAX의 단점

검색 엔진 최적화 Search Engine Optimization(SEO)에 불리
- AJAX 방식의 웹 앱은 한 번 받은 HTML을 렌더링 한 후, 서버에서 비동기적으로 필요한 데이터를 가져와 그려냄
- AJAX 방식의 웹 애플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 검색 로봇이 사이트의 정보를 긁어가기 어려움
뒤로가기 버튼 문제
- 일반적으로 사용자는 뒤로가기 버튼을 누르면 이전 상태로 돌아갈 거라고 생각하지만, AJAX에서는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 동작하지 않음.
- 따라서 뒤로가기 등의 기능을 구현하기 위해서는 별도로 History API를 사용해야 합

4-2. SSR과 CSR

실시간 세션

프로젝트 시작할 때 rest API 부터 짠다
-> 이거로 백엔드 개발자랑 소통한다. 중요함
현업에서 현재 많이쓰이는게 3 티어 아키텍쳐
-> 이 개념이 대박났대.
버너스 리가 HTTP 만듦 -> 대박남
1 번의 요청에는 1번의 응답이 있다.
->요청을 안 했는데 응답이 오는 경우도 있다. socket.io
ex) 광고, 푸쉬알람
네트워크는 저 재미없는 리퀘스트, 리스폰스 계속봐야하므로 저 구조에 익숙해져라
요청
-스타트라인:
http 메서드 = GET, POST, PUT , PATCH, DELETE, OPTIONS
CRUD 대응시키기 = read create update update delelte -
/ : url-path 자리, 간과하지 말것
http headers 는 몰라도 된대 : host, content-type 만 알아둬
body : post 할때 서버에 전달할 정보 담는다
응답
-스타트라인- 403 forbidden = 상태코드, 상태메세지 -> 이것의 의미는?
200 -> 성공
300 -> 리다이렉션
400 -> 클라이언트 실패(유저 잘못)(내 잘못)
500 -> 서버 실패(서버 잘못)(니 잘못)
-바디 : 요청에 대한 응답(바디에 데이터 실어보낸다
API : 굉장히 중요한 문서
->프로젝트에서 줴윌 중요함.
->프엔개발자와 백엔개발자는 얘만 가지고도 소통할 수 있어야한다
인터페이스 ->추상화 개념과 유사
-> 왜API에 I가 존재의의 ?
-> GET /users 라는 코드 한줄로 서버로부터 모든사용자를 조회하는 모든 일이 단순하게 한번에 작동함 !!
그래서 REST API 가 뭐냐?
URL, URI
-> 엄밀히 말하면 지금 우리가 사용하는 것은 다 uri!
-> url 쓰다가 uri가 나왔음
port 는 사이트에 들어가기위한 문!(door)
-생략하는 이유 :너무 자주쓰니까 생략ㅎ 달달 외울 필요 없음
-https는 443
-http는 80
ajax = fetch(xhr)+ DOM
-프로그래밍 기법
-언제쓰나? 펫치로 받아와서 부분렌더링하는 것이 ajax
-펫치로 받아만 오는 것은 ajax라고 할 수 없음.
-구글검색어 한글자ㄹ한글자칠때마다 xhr 이 서버에 있는 추천검색어를 브라우저에 뿌려준다
-state가 바뀔때마다 리렌더링 -> CSR
-프로젝트할때 무조건 쓴다.!!!
-xhr로 뜨는 거 fetch로 보면 됨
리액트 상태관리 라이브러리 뭐써야하나요
하나 기본기만 제대로 하면 응용해서 쓰는거 문제도 아님
-npm weekly downloads-많이 쓴다 ? 좋은거임
-라이브러리남용하지마세요->내가내세울게없음->직접만들어본게없는게 됨->면접가서 ㄴ
개발 잘하려면 하나의 언어, 하나의 API, react 정복하면됨.

문도연

중요한건 꺾이지 않는 마음이 맞는 것 같습니다

이전 포스트

17. [React] - React State & Props

다음 포스트