1. 웹 애플리케이션 아키텍쳐
1.1 클라이언트 - 서버 아키텍쳐( 2티어 아키텍쳐)
쇼핑몰을 예시로, 상품 정보같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍쳐(2 tier architecture) 또는 클라이언트 - 서버 아키텍쳐(client - server architecture) 라고 부른다.
리소스를 사용하는 앱이 클라이언트, 리소스를 제공하는 곳을 서버라고 부른다.
클라이언트와 서버는 요청과 응답을 주고받는 관계이다. 일반적으로 서버는 리소스를 전달해 주는 역할을 담당한다.
리소스를 저장하는 공간을 데이터베이스라고 부르는데, 이렇게 클라이언트 - 서버 - 데이터베이스 로 연결되는 구조를 3티어 아키텍쳐라고 부른다.
클라이언트처럼 사용자가 직접 눈으로 보고, 클릭하고 터치하는 등의 상호작용을 할 수 있는 앱을 주로 프론트엔드 개발자가 담당한다.
반면, 눈에 보이지 않지만 상품정보를 API로 노출한다든지, 로그인/로그아웃, 권한 관리 등의 사용자 인증을 주로 다루는 것은 백엔드 개발자가 담당한다. 백엔드 개발자는 데이터베이스 등의 시스템 설계까지 맡아서 하는 경우가 많다.
1.2 클라이언트 - 서버 통신과 API
클라이언트와 서버간의 통신은 요청과 응답으로 이루어진다. 요청이 있어야 응답이 돌아온다.
요청과 응답에는 프로토콜(Protocol)이라는 통신 규약이 존재한다.
웹 애플리케이션 아키텍쳐에서는 클라이언트와 서버가 HTTP(HyperText Transfer Protocol)라는 프로토콜을 이용해서 요청과 응답을 주고 받는다.
API(Application Programming Interface)란 일종의 메뉴판이라고 볼 수 있다.
클라이언트가 서버에 요청을 할 때 미리 약속된 규칙에 맞게 요청을 해야 하는데, 클라이언트는 서버에 어떤 리소스가 있고 어떻게 요청해야 하는지 모를 수 있다. 이럴 때 서버는 리소스 전달을 위한 메뉴판인 API를 구축해놓아야 클라이언트가 이것을 활용할 수 있다.
2. 브라우저의 작동 원리(보이지 않는 곳)
2.1 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는 웹 서버에 보내는 추가적인 질문이다.
fragment는 일종의 북마크 기능을 수행하며 URL에 fragment(#)와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동할 수 있다.
브라우저의 검색창을 클릭하면 나타나는 주소가 URI이다. URI는 URL을 포함하는 상위개념이다.
2.2 IP와 포트
IP adress
네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP address(Internet Protocol address, IP 주소)라고 한다.
IP는 Internet Protocol의 줄임말로, 인터넷상에서 사용하는 주소체계를 의미한다. 인터넷에 연결된 모든 PC는 IP 주소체계를 따라 네 덩이의 숫자로 구분된다. 이렇게 네 덩이의 숫자로 구분된 IP 주소체계를 IPv4라고 한다. IPv4는 IP 주소체계의 네 번째 버전을 뜻한다.
* localhost, 127.0.0.1 는 현재 사용 중인 로컬 PC를 지칭한다.
최근에는 IPv6 이 나오면서 2^(128)개의 IP 주소를 표현할 수 있다.
PORT
로컬 PC의 IP 주소인 127.0.0.1 뒤에 :3000과 같은 숫자가 표현된다.
이 숫자는 IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)를 의미한다. 리액트를 실행했을 때에는 로컬 PC의 IP 주소로 접근하여, 3000번의 통로를 통해 실행 중인 리액트를 확인할 수 있다. 이미 사용 중인 포트는 중복해서 사용할 수 없다.
만약 다른 프로그램에서 3000번 포트를 사용 중이라면 다른 포트 번호(3001)로 리액트가 실행된다.
포트 번호는 0~ 65535 까지 사용할 수 있다. 그중에서 0 ~ 1024번 까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있다. 반드시 알아야 할 잘 알려진 포트 번호는 다음과 같다.
- 22 : SSH
- 80 : HTTP
- 443: HTTPS
이미 정해진 포트 번호라도, 필요에 따라 자유롭게 사용할 수 있다. HTTP(:80), HTTPS(:443)과 같이 잘 알려진 포트의 경우, https://codestates.com:443이 아닌 https://codestates.com처럼 포트 번호를 URI에 생략할 수 있지만, 그 외의 잘 알려지지 않은 포트(3000과 같은 임시 포트)는 반드시 포트 번호를 포함해야 한다.
2.3 도메인과 DNS
Domain name
웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소를 Domain name이라고 한다.
위 그림에서 IP 주소는 3.34.153.168 이고, 도메인 이름은 codestates.com 이다.
주소창에 IP 주소(3.34.153.168)를 입력하면, codestates.com으로 이동할 수 있다.
DNS
네트워크 상에 존재하는 모든 PC는 IP 주소가 있다. 그러나 모든 IP 주소가 도메인 이름을 가지는 것은 아니다.
로컬 PC를 나타내는 127.0.0.1 은 localhost 로 사용할 수 있지만, 그 외의 모든 도메인 이름은 일정 기간 동안 대여하여 사용한다.
브라우저의 검색창에 도메인 이름을 입력하여 해당 사이트로 이동하기 위해서는 해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업이 반드시 필요하다. 네트워크에는 이것을 위한 서버가 별도로 있는데 이를 DNS(Domain Name System)라고 한다.
DNS는 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템이다.
만약 브라우저의 검색창에 naver.com을 입력한다면, 이 요청은 DNS에서 IP 주소(ex.125.209.222.142)를 찾는다. 그리고 이 IP 주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 한다.
2.4 크롬 브라우저 에러 읽기
"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 | 클라이언트 인증서(은행 또는 회사 내부 웹사이트 등)에 오류가 발생하여 웹페이지에 로그인할 수 없습니다. |
'코드스테이츠' 카테고리의 다른 글
1/31 일일정리 REST API (0) | 2023.01.31 |
---|---|
1/30 일일정리(2) HTTP/네트워크 기초 (0) | 2023.01.30 |
1/27 일일 정리 States & Props 실습 (0) | 2023.01.27 |
1/26 일일 정리 React States/Props (0) | 2023.01.26 |
1/25 일일정리 SPA (0) | 2023.01.25 |
댓글