옥수수, 기록
HTTP/ 네트워크 기초 정리 본문
들어가기 앞서
인터넷 연결없는 쇼핑몰 앱은 동작하지 않는다. 상품정보를 어딘가에 있는 서버에서 받아오기 때문
앱이 서버와 연결되어 있지 않다면 어떤 문제가?
앱 자체에 상품 정보를 넣어두어야 하는데 상품이 추가, 변경될 때 마다 앱을 업데이트 해줘야해서
상품 관련 정보를 실시간으로 제공하기 어렵다.
결제를 해야하는데 은행 서버와 연동이 되어있지 않아 결제도 불가능하다.
2-Tier 아키텍처 / 클라이언트-서버 아키텍쳐
빈번한 데이터 업데이트가 필요한 경우, 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시키는 것이 유리하다.
그리고 이렇게 분리시킨 것을 2티어 아키텍쳐 or 클라이언트-서버 아키텍쳐라고 부른다.
클라이언트 - 서버
- 클라이언트 - 리소스를 사용하는 앱
- 서버 - 리소스를 제공하는 곳
클라이언트(client, 손님) 서버(server, 서빙하는 사람) 이라는 단어의 어원을 떠올리면 보다 이해가 쉽다.
클라이언트는 서버에게 리소스커피를 달라고 요청하는 손님
서버는 요청이 들어오면 클라이언트에게 리소스커피를 제공한다.
** 클라이언트-서버 아키텍쳐에서는 요청이 선행되고 그 후 응답이 온다.
3-Tier 아키텍처
앞의 2-Tier 아키텍처에 데이터베이스가 추가된 형태이다.
데이터베이스는 리소스를 저장하고 있다.
클라이언트 - 서버 - 데이터베이스
- 데이터베이스 - 리소스를 저장하는 공간(창고)
클라이언트가 서버에게 리소스커피를 달라하고 서버는 데이터베이스에서 리소스를 꺼내와 제공하는 것
클라이언트와 서버의 종류
클라이언트는 보통 플랫폼에 따라 구분된다.
웹 플랫폼 - 웹사이트, 웹 앱(브라우저)
앱 플랫폼 -
서버는 무엇을 하느냐에 따라 종류가 달라진다.
파일을 제공하는 파일 서버, 웹사이트에서 필요로 하는 정보들을 제공하는 웹 서버, 메일을 주고받게 해주는 메일 서버.. 데이터베이스도 일종의 서버라고 볼 수 있다. + WAS 서버도 있다.
** WAS서버란?
web aplication server
일반 웹 서버와 WAS의 차이
웹 서버는 주로 웹 브라우저에서의 하이퍼텍스트 전송 프로토콜(HTTP) 요청에 응답하여 정적 웹 콘텐츠(예: HTML 페이지, 파일, 이미지, 동영상)를 제공한다.
애플리케이션 서버는 웹 서버가 하는 일을 포함하면서 주로 동적인 컨텐츠를 요청받아 처리한다.
사실상 WAS가 웹 서버의 역할도 같이 할 수 있지만 부하가 많은 작업을 한다면 굳이 WAS하나로 동적,정적 컨텐츠를 동시에 처리하게해 서버 부하를 늘릴 필요가 없다.
클라이언트-서버 통신과 API
클라이언트와 서버가 어떤 식으로 통신하는가, 이때 등장하는 API라는 것을 무엇을 의미?
프로토콜(Protocol)
클라이언트가 서버에게 리소스를 요청할 때 지켜야 하는 통신규약, 약속이다.
프로토콜에 대한 쉬운 이해
커피 주문할 때 :
프로토콜1 - 카운터
프로토콜2 - 앱
프로토콜3 - 키오스크
우편을 보낼 때 :
프로토콜1 - 우표를 붙이고 보내는사람, 받는 사람을 정확히 기재
이때 우표를 붙이지 않으면 반송이 될 것 = 규약이 존재한다
이런 모든 방법들이 전부 프로토콜이다.
주요 프로토콜
API(Application Programming Interface)
클라이언트가 서버에 리소스커피를 주문해야하는데 정확한 주문방법을 따라 주문해야 하는데 메뉴를 모르는데 주문할 수는 없다. 그 때 메뉴판처럼 리소스를 잘 활용할 수 있게 제공하는 인터페이스, 이것을 API라고 한다.
API는 카페로 따지면 메뉴판과 같은 역할을 한다.
클라이언트가 서버가 제공하는 커피(자원)의 종류(아아, 뜨아, 라떼, 리저브)를 모를 경우 엉뚱한 메뉴(햄버거)를 시키지 않도록 도와주어야 한다.
서버도 클라이언트가 API활용을 할 수 있게 구축을 해놓아야 한다.
보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용, 주소(URL, URI)를 통해 접근할 수 있게 된다.
HTTP API 디자인
HTTP 요청에는 메서드라는 것이 존재한다. 앞서 카페의 예에서는 리소스를 그저 달라고(GET) 요청했지만 사용자 관리 API에서는 사용자를 추가해달라고 요청(CREATE), 지워달라고 요청(CREATE)할 수 있다.
HTTP 메서드는 리소스를 이용, 하려는 행동에 맞게 적절하게 써야 한다
부적절한 예) 생성해달라고 요청하는데 지워지는 경우
브라우저의 작동원리(보이지 않는 곳) 개요
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를 포함한다
query: 웹 서버에 보내는 추가적인 질문이다.
ex) http://www.google.com:80/search?q=JavaScript 입력시 google에 JavaScript를 검색한 결과가 나타난다.
fragment: 일종의 북마크 기능을 수행한다.
ex) 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 address (Internet Protocol address, IP 주소)
네트워크에 연결된 특정 PC의 주소를 나타내는 체계
IP는 Internet Protocol의 약자로 인터넷상에서 사용하는 주소체계를 의미한다.
인터넷에 연결된 모든 PC는 IP 주소체계를 따라 네덩이의 숫자로 구분되는데 이렇게 구분된 주소체계를 IPv4라고 한다.
IPv4: Internet Protocol version 4의 약자로, IP주소체계의 네 번째 버전을 뜻한다.
터미널에 nslookup naver.com을 입력하면 네이버의 IPv4 주소를 확인할 수 있다.
기억해 두어야 할 IP 주소
- localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭
- 0.0.0.0, 255.255.255.255: broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소 > 서버에서 접근가능 IP 주소를 broadcast address로 지정하면 모든 기기에서 서버에 접근 가능
PORT
터미널에서 리액트를 실행하며 나타나는 화면에는 127.0.0.1뒤에 :3000같은 숫자가 나타나는데 이 숫자가 바로 PORT, IP주소가 가리키는 PC에 접속할 수 있는 통로(채널)을 의미한다.
잘 알려져 있는 포트번호
- 22 : SSH
- 80 : HTTP
- 443: HTTPS
HTTP(:80), HTTPS(:443)과 같이 잘 알려진 포트의 경우
https://naver.com:443 이 아닌 https://naver.com 처럼 포트번호를 생략할 수 있지만 잘 알려지지 않은 포트는 반드시 포트 번호를 포함해야 한다.
Domain name
IP address가 주소면 Domain name은 상호라고 할 수 있다. Domain name을 사용하면 엄청 긴 IP 주소를 보다 간단하게 나타낼 수 있다.
터미널에 nslookup naver.com 을 치면 Domain name을 볼 수 있다. (네이버의 Domain name은 naver.com)
DNS(Domain Name System)
모든 IP address가 Domain name을 가지는 건 아니다. 로컬 IP는 localhost로 사용할 수 있지만 그 외 모든 Domain name을 일정 기간 동안 대여해 사용하는데 이렇게 대여한 Domain name과 IP address를 확인해보는 매칭작업이 필요하다. 네트워크에 이것을 위한 서버가 별도로 있는데 이걸 DNS(Domain Name System)라고 한다.
DNS는 호스트의 Domain Name 을 IP address로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템이다.
ex) 검색창에 naver.com 입력 > DNS가 IP주소를 찾음 > IP주소에 해당하는 웹 서버로 요청을 전달해 클라이언트- 서버 통신을 가능하게 함
크롬 브라우저 에러 읽기
브라우저를 사용하다보면 에러가 날 수 있다. 크롬 브라우저에서는 에러가 발생한 경우 다양한 에러메세지를 설정해두어 어떤 에러인지 잘 설명해두었다.
| Error Message | Description |
| "Aw, Snap!" ("앗, 이런!") | Chrome 브라우저에서 페이지를 로드하는 데 문제가 발생했습니다. |
| ERR_NAME_NOT_RESOLVED | 호스트 이름(웹 주소)이 존재하지 않습니다. |
| ERR_INTERNET_DISCONNECTED | 사용 중인 기기가 인터넷에 연결되지 않았습니다. |
| ERR_CONNECTION_TIMED_OUTERR_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/
HTTP
HyperText Transfer Protocol의 약자이며 HTML과 같은 문서를 전송하기 위한 프로토콜이다.
HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인되었으며 클라이언트-서버 모델에서 클라이언트가 HTTP Messages 양식에 맞춰 요청을 보내면 서버도 HTTP Messages 양식에 맞춰 응답해준다.
HTTP Messages
클라이언트와 서버 사이에서 데이터가 교환되는 방식이다.
두가지 유형이 있다.
- 요청(Requests)
- 응답(Responses)
요청과 응답은 유사한 구조를 가진다.
- start line : start line에는 요청이나 응답의 상태를 나타낸다. 항상 첫 번째 줄에 위치하고 응답에서는 status line이라고 부른다
- HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
- empty line : 헤더와 본문을 구분하는 빈 줄이 있다.
- body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함한다. 요청과 응답의 유형에 따라 선택적으로 사용한다.
이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload 는 body라고 한다.
Stateless
HTTP의 가장 큰 특징으로 말 그대로 상태를 가지지 않는다 라는 뜻이다.
HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서 HTTP는 클라이언트나 서버의 상태를 확인하지 않는다. ex) 스벅앱에 로그인하거나 원하는 메뉴를 클릭해 옵션 선택창으로 이동하고, 장바구니에 담거나 로그아웃할 수 있는데 클라이언트에서 발생한 이런 모든 상태를 HTTP 통신이 추적하고, 상태를 저장하고 있지 않는다. (HTTP는 통신 규익일 뿐이므로) 필요에 따라 쿠키-세션, API 등을 통해 상태를 확인할 수는 있다.
HTTP Requests
start line(시작줄)
HTTP Requests는 클라이언트가 서버에게 보내는 메세지이다. Start line에는 3가지 요소가 있다.
- 첫 번째는 HTTP 메소드로 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 사용해 서버가 수행해야 할 동작을 나타낸다.
- ex) GET 은 리소스를 클라이언트로 가져다 달라는 것을 뜻하고 , POST는 데이터를 서버로 전송한다는 것을 의미한다.
- 두 번째로 오는 요청 타겟은 주로 URL, 프로토콜, 포트, 도메인의 절대 경로로 나타낼 수도 있으며 요청 컨텍스트에 의해 특정지어진다. 요청 타겟 포맷은 HTTP 메소드에 따라 달라진다.
- origin 형식 : '?'와 쿼리 문자열이 붙는 절대 경로. GET, POST, HEAD, OPTIONS 등의 method와 함께 사용한다. POST / HTTP 1.1GET /background.png HTTP/1.0HEAD /test.html?query=alibaba HTTP/1.1OPTIONS /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 버전에 따라 HTTP message(응답 메시지)의 구조가 달라지기도 해서 HTTP의 버전을 알려줄 목적으로 start line에 HTTP 버전을 함께 입력한다.
Headers(헤더)
요청에 들어가는 Headers는 HTTP 헤더의 기본 구조를 따른다 헤더 이름(대소문자 구분이 없는 문자열) 다음 콜론( ‘ : ’ )이 붙고 값을 입력한다. 값은 헤더에 따라 다르다.
ex) 헤더이름 : 헤더에따라달라지는값
Access-Control-Allow-Origin: *, Server: Apache, Vary: Cookie, Accept-Encoding
여러 종류의 헤더가 있고, 다음과 같이 그룹을 나눌 수 있다
- General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더이다.
- Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미한다. User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화한다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있다.
- Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더이다. 요청 내 body가 없을 경우 전달되지 않는다.
Body(본문)
Body는 요청의 마지막에 들어가며 모든 요청에 Body가 필요하지는 않다.
ex) GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다.
일부 요청은 업데이트를 하기위해 서버에 데이터를 전송하는데 POST와 PUT과 같은 요청이 그러하다.
Body는 크게 2가지 종류로 나뉜다
- Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성된다.
- Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지니는데 보통 HTML form과 관련이 있다.
HTTP Responses(응답)
status line(상태줄)
HTTP Response는 서버가 클라이언트에게 보내는 메세지이다. 응답의 첫 줄을 status line이라고 부르며 다음과 같은 정보를 포함하고 있다.
- 프로토콜 버전 : 보통 HTTP/1.1이다
- 상태 코드 : 요청의 결과를 나타낸다. (ex 200, 404, 302 등)
- 상태 텍스트 : 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내 사람들이 HTTP 메세지를 이해할 때 도움을 준다.
status line은 일반적으로 HTTP/1.1 404 Not Found. 같이 생겼다.
Headers(헤더)
응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있다.
ex) 헤더이름(대소문자구분x 문자열) : 헤더에따라달라지는값
Access-Control-Allow-Origin: *, Server: Apache, Vary: Cookie, Accept-Encoding
요청의 헤더와 마찬가지로 몇몇 그룹으로 나눌 수 있다.
- General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더이다.
- Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같은 헤더는 status line에 넣기에는 공간이 부족했던 추가 정보를 제공한다.
- Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더이다. Content-Length와 같은 헤더는 요청 본문(body)에 적용되는데 당연히 요청 내 본문이 없을경우 전송되지 않는다.
Body(본문)
본문은 응답의 마지막에 위치한다. 모든 응답에 body가 필요한 것은 아닌데 특히 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않습니다. 응답의 body는 다음과 같이 두 종류로 나눌 수 있습니다.
- Single-resource bodies(단일-리소스 본문) :
- 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의한다.
- 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩 되어 있다.
- Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body이다.
AJAX(Asynchronous JavaScript And XMLHttpRequest)
AJAX의 가장 큰 특징은 변경할 부분을 갱신하는데 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다는 점이다.
이로인해 불필요한 데이터 통신이 발생하지 않고 변경할 필요가 없는 부분은 다시 렌더링하지 않아 화면이 깜빡이는 현상이 발생하지 않는다.
ex)구글의 검색창(글자입력시 추천검색어 뜨게함), 페이스북 메세지, 네이버의 뉴스탭
AJAX의 2가지 핵심 기술
JavaScript와 DOM / Fetch
전통적인 웹 애플리케이션에서는 <form> 태그를 이용해 서버에 데이터를 전송했다. 또 서버는 요청에 대한 응답으로 새로운 웹페이지 (.html파일, .css파일, .js파일)을 불러와야했다.
하지만 Fetch를 사용하면 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아오고 현재 페이지에서 작업을 하는 동안 서버와 통신도 할 수 있게 해준다. 즉 브라우저는 Fetch가 서버에 요청을 보내고 응답을 받을 때까지 모든 동작을 멈추고 기다리는게 아니라 계 속 페이지를 사용할 수 있게 비동기적인 방식을 사용한다.
또 JavaScript에서 DOM을 사용해 조작할 수 있기 때문에 Fetch를 통해 필요데이터만 가져와 DOM에 적용시켜서 기존 페이지에서 필요한 부분만 변경할 수 있다.
XHR과 Fetch
Fetch 이전에는 XHR(XMLHttpRequest)을 사용했다. 그러나 XHR은 Cross-Site 이슈 등 불편함이 있었다. Fetch는 XHR의 단점을 보완한 새로운 Web API이고 XML보다 가볍고 promise를 지원하며 JavaScript와 호환되는 JSON을 사용한다. 그래서 오늘날 XHR보다 Fetch를 더 많이 사용한다.
AJAX의 장점
- 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있다.
- 이전에는 서버에서 HTML을 완성하여 보내주어야 화면에 렌더링을 할 수 있었다. 그러나 AJAX를 사용하면 서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트하여 렌더링 할 수 있다.
- 표준화된 방법
- 이전에는 브라우저마다 다른 방식으로 AJAX를 사용했으나, XHR이 표준화되면서부터 브라우저에 상관없이 AJAX를 사용할 수 있게 되었다.
- 유저 중심 애플리케이션 개발
- AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 애플리케이션을 만들 수 있다.
- 더 작은 대역폭
- 대역폭: 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기
- 이전에는 서버로부터 완성된 HTML 파일을 받아와야 했기 때문에 한 번에 보내야 하는 데이터의 크기가 컸다. 그러나 AJAX에서는 필요한 데이터를 텍스트 형태(JSON, XML 등)로 보내면 되기 때문에 비교적 데이터의 크기가 작다.
AJAX의 단점
- Search Engine Optimization(SEO)에 불리
- AJAX 방식의 웹 애플리케이션은 한 번 받은 HTML을 렌더링 한 후, 서버에서 비동기적으로 필요한 데이터를 가져와 그려냅니다. 따라서, 처음 받는 HTML 파일에는 데이터를 채우기 위한 틀만 작성되어 있는 경우가 많다. 검색 사이트에서는 전 세계 사이트를 돌아다니며 각 사이트의 모든 정보를 긁어와 사용자에게 검색 결과로 보여줍니다. AJAX 방식의 웹 애플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어가기 어렵다.
- 뒤로가기 버튼 문제
- 일반적으로 사용자는 뒤로가기 버튼을 누르면 이전 상태로 돌아갈 거라고 생각하지만, AJAX에서는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 동작하지 않는다. 따라서 뒤로가기 등의 기능을 구현하기 위해서는 별도로 History API를 사용해야 한다.
SSR(Server Side Rendering)
- 웹 페이지를 브라우저에서 렌더링하는 대신, 서버에서 렌더링한다.
- 브라우저가 서버의 URI로 GET요청을 보내면
- 서버는 정해진 웹 페이지 파일을 브라우저로 전송한다.
- 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링된다.
위 과정처럼 서버가 웹 페이지를 브라우저로 보내기 전 서버에서 완전히 렌더링했기 떄문에 Server Side Rendering이라고 한다.
웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우, 서버는 데이터베이스의 데이터를 불러온 다음(1번 과정 앞으로 들어감), 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보낸다.
사용자가 브라우저의 다른 경로로 이동할 경우, 같은 작업을 반복한다.
CSR(Client Side Rendering)
일반적으로 CSR은 SSR의 반대로 여겨진다. SSR이 서버측에서 페이지를 렌더링한다면, SCR은 클라이언트에서 페이지를 렌더링한다.
- 브라우저의 요청을 서버로 보내면 서버는 웹 페이지의 골격이 될 단일 페이지(Single Page)를 클라이언트에 보낸다. 이때 서버는 웹 페이지와 JavaScript 파일을 같이 보낸다.
- 클라이언트가 웹 페이지를 받으면, 함께 전달된 JavaScript 파일은 브라우저의 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.
웹 페이지에 필요한 내용이 데이터베이스에 저장된 데이터인 경우, 브라우저는 데이터베이스에 저장된 데이터를 가져와 웹 페이지에 렌더링 해야 한다. 이를 위해 Fetch와 같은 API가 사용된다.
또 브라우저가 다른 경로로 이동하게되면 SSR과 다르게, 서버가 웹 페이지를 다시 보내지 않고 브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링한다.
이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일이다.
SSR과 CSR의 차이점
주요 차이점은 페이지가 렌더링되는 위치이다.
SSR - 서버에서 페이지 렌더링, 경로 요청시마다 새로고침
CSR - **브라우저(클라이언트)**에서 페이지 렌더링 + 경로 요청시 새로고침 X + 동적으로 라우팅 관리
SSR을 사용하면 좋을 환경
- SEO(검색엔진최적화)가 우선순위인 경우
- 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우 - 단일 파일의 용량이 적은 SSR 유리
- 웹 페이지가 사용자와 상호작용이 적은 경우
- ex) 네이버 블로그, 티스토리, 뉴욕타임즈
CSR을 사용하면 좋을 환경
- SEO가 우선순위가 아닌 경우
- 사이트에 풍부한 상호 작용이 있는 경우 - CSR은 라우팅이 빨라 강력한 사용자 경험을 제공
- 웹 애플리케이션을 제작하는 경우 - CSR이 더 나은 사용자 경험(빠른 동적 렌더링)을 제공
- ex) 상호작용이 많은 아고다를 비롯한 예약 사이트들