Section 2 Unit7 [HTTP/네트워크]

2023-05-24(수)

 

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

= HTTP에서 사용하는 클라이언트 - 서버 아키텍쳐와 클라이언트와 서버가 통신하는 방법인 API에 대해 학습합니다.

 

학습 목표

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

 

우리가 인터넷 쇼핑몰 앱을 이용할 때 만약 인터넷 연결이 되어있지 않은 상태로 실행을 시키면 어떻게 될까요?

= 정답은 정삭적으로 동작하지 않는다. 입니다

 

이유는 상품 정보를 인터넷 어딘가에 존재하는 서버로부터 받아와야 하기 때문입니다.

보통 어딘가 접속하려고 하는 데 접속이 안되는 경우, 사용이 불가능한 경우를 "서버가 죽었다" 라고 표현합니다.

 

서버가 무엇일까요? 

-> 서버는 영어 단어 그대로 제공(Serve)하는 주체입니다.

 

만약 우리가 쇼핑몰 앱을 사용하는데 판매하려는 상품 정보가 전부 앱안에 담겨있는 경우를 가정해봅시다.

또 이 앱과 연결된 서버가 존재하지 않는다면 어떤 문제가 발생할가요?

 

이 경우에는 끊임없이 앱을 업데이트 해주어야 합니다.

앱 1.0 버전에서는 없는 새로운 상품을 업데이트하기 위해서는 2.0버전을 업데이트하여 사용해야합니다.

이렇게 새로운 정보를 받아들이기 위해서는 끊임없이 업데이트를 해주어야 합니다.

 

이렇게 된다면 실시간으로 상품정보를 전달하기도 어려울 뿐더러, 결제조차 하지 못하게 될겁니다.

 

이러한 경우 이처럼 리소스가 존재하는 곳(상품 정보)과, 리소스를 사용하는 어플을 편리하게 분리시킨것을

2티어 아키텍쳐, 또는 클라이언트 - 서버 아키텍쳐 라고 부릅니다.

 

리소스를 사용하는 앱이 바로 "클라이언트", 리소스를 제공(Serve)하는 곳은 "서버" 라고 부릅니다.

 

클라이언트(손님)와 서버(서빙)라는 단어의 어원을 떠올리면 이해가 쉽습니다.

리소스에 접근하려는 앱은 카페로 치면 손님과 같습니다. 손님은 커피를 마시기 위해 리소스를 가지고 있는

서버에게 요청해야 합니다. 서버는 클라이언트요청에 따라 리소스를 담아 응답하죠

 

이처럼 클라이언트와 서버는 요청과 응답을 주고받는 관계입니다. 

클라이언트 - 서버 아키텍쳐에서는 요청이 선행되고 그 후에 응답이 옵니다.

 

즉 주문을 한 후에 그에 맞는 정보를 응답하는 방식입니다.

 

 

일반적으로 서버는 리소스를 전달해 주는 역할만 담당합니다. 

리소스를 저장하는 공간을 별도로 마련해두는데 이 공간을 "데이터베이스"라고 부릅니다.

데이터베이스는 창고와 같은 역할을 합니다.

 

즉 보통 서버는 리소스를 전달만 해줄 뿐, 리소스를 저장하는 공간은 데이터베이스 라는 창고에 둡니다.

이처럼, 클라이언트 - 서버 아키텍쳐 - 데이터베이스 이렇게 3가지 형태로 이루어진 것을 3티어 아키텍쳐 라고 부릅니다.

 

우리가 배우는 프론트엔드 부분이 여기서 클라이언트개발을 담당합니다. 화면에 보여지는 상품정보들, 결제기능,

상품 조회기능 등등을 담당하죠, 그리고 여기서 백엔드는 서버와 데이터베이스를 담당하고 있습니다.

 

프론트엔드와 백엔드는 눈으로 보이는 영역을 다루느냐 아니냐로 나뉘는데

마찬가지로 클라이언트 앱은 실시간으로 정보를 주고받고 사용자가 눈으로 대면하므로 프론트엔드 영역

서버와 데이터베이스는 사용자가 눈으로 보는 것이 아닌 보이지 않게 뒤에서 작동하므로, 백엔드 영역으로 부릅니다.

 

 

클라이언트와 서버의 종류에는 어떤것들이 있을까요?

 

클라이언트는 보통 플랫폼에 따라 구분됩니다. 브라우저를 통해 주로 이용하는 웹(WEB) 플랫폼에서의 클라이언트는

웹 사이트 또는 웹 앱이라고 부릅니다.

 

iOS나 안드로이드와 같은 스마트폰/태플릿 플랫폼, 그리고 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시

클라이언트가 될 수 있습니다.

 

서버는 무엇을 하느냐에 따라 종류가 달라집니다. 파일 서버는 파일을 제공하는 앱, 웹 서버는 웹사이트에서 필요로 하는

정보들을 제공하는 앱, 게임 서버는 게임 정보를 얻고 자료들을제공해주는 앱입니다.

 

데이터베이스도 일종의 데이터 제공자로서 서버라고 볼 수 있습니다. 

 

 

클라이언트와 서버 아키텍쳐

= 클라이언트-서버 아키텍쳐에서는 서버 마음대로 클라이언트에게 리소스를 전달하지 않습니다.

 

클라이언트와 서버 간의 통신을 알아보기 위해서는 프로토콜이 뭔지 알아야 합니다.

 

웹 애플리케이션 아키텍쳐에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눕니다.

HTTP를 이용해 주고받는 메시지는 "HTTP 메시지" 라고 부릅니다.

 

카페를 예를 들자면 카페에서 주문을 하기 위해서는 직접 주문을하거나, 배달의 민족같은 어플을 이용해 주문하거나,

아니면 카페 안에 키오스크를 통해 주문을 하는 여러가지 방법이 있는데 이러한 다양한 방법들이 모두 프로토콜입니다.

 

그렇지만 우리가 프로토콜을 이해하기 위해서는 "규약" 이라는 측면에서도 알아야 합니다.

우선 가게에서 외계어로 상품 주문을 할 수는 없습니다. 마찬가지로 , 우편을 보낼 때에도 수신자에 대한 표기가 없다면

전송 요청은 갈 길을 잃고 말겠죠.

 

이처럼 우편을 전송하기 위해서나 주문을 하기 위해서는 반드시 지켜야 하는 규약이 있음을 알 수 있습니다.

 

즉 각자의 프로토콜 마다 지켜야하는 약속(규약)이 존재합니다.

 

잠깐 프로토콜에 어떠한 종류들이 있는지 알아봅시다.

전부다 알 필요는 없지만, 상식선에서 알아두면 좋습니다.

 

OSI 7 Layers = [HTTP, HTTPS,FTP,SMTP,SSH,RDP,WebSocket] = 응용 계층

OSI 7 Layers는 컴퓨터 공학이나 네트워크에서 자주 등장하는 개념입니다. 

해당 프로토콜이 어떤 계층에 속해있는지를 알고있으면 좋습니다.

 

 

여기서 API는 무엇일까요? 많이 들어봤지만 실제로 어떤것인지 설명하라고 하면 어려운 부분이 있습니다.

 

예를 들어 보겠습니다.

= 손님이 메뉴를 주문하려면 메뉴판이 있어야 겠죠, 하지만 알아서 맛있는걸로 추천해서 가져다주세요. 라고 할수도 있습니다. 하지만 컴퓨터 세계에서는 " 알아서 맛있게 타와 " 라는 요청은 허용되지 않습니다.

 

오로지 0과 1로 이루어진 요청을 원할 뿐입니다. 즉 정확한 주문 방법을 통해 요청해야 합니다.

 

하지만 우리는 서버가 어떻게 구성되어있는지 어떤 주문방법을 통해 요청해야 하는지 알 수 없습니다.

이렇다면 우리는 어떻게 요청해야 하는지 알 수 있을까요?

 

이럴때 사용해야 하는 것이 API(Application Programming Interface)입니다.

서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공해 줘야 합니다. 이것을 API라고 합니다.

 

즉 API는 의사소통이 가능하도록 만들어진 애플리케이션 프로그래밍입니다.

API는 앱이 요청할 수 있고 프로그래밍이 가능한 인터페이스인데

쉽게 말해 메뉴판 같은 역할을 한다고 생각하시면 됩니다.

 

예를들어 카페에서 제공하는 아메리카노,카페라떼, 프라푸치노 같은 메뉴들을 모르더라도, 설렁탕,참치찌개 같은

메뉴들을 시키지 않게 도와주어야 하며, 커피종류의 메뉴들을 주문해야 한다는 것을 알려줘야합니다.

 

즉 서버가 리소스 전달을 위해 API를 구축해놓아야 클라이언트가 이를 활용하기 편하게 됩니다.

보통 인터넷에 있는 데이터를 요청할 때는 HTTP라는 프로토콜을 사용하며, 주소(URL,URI)를 통해 접근가능합니다.

여기 스타벅스 API 서버에서 제공하는 적절한 URL디자인을 확인해보면 파라미터를 사용하기 위해

물음표와 & 기호를 사용하는것을 참고하면 좋습니다.

 

HTTP API 디자인에는 Best Practice가 존재합니다. 스타벅스 예제와는 다르게 실제로 쓰일법한 API를 소개합니다.

사용자 관리 API인데, URL 디자인은 비교적 단순하나 "메서드"라는 개념이 등장합니다.

HTTP 요청에는 메서드라는 것이 존재합니다. 앞서서 스타벅스에서는 리소스를 그저 달라고 요청 했지만

사용자 관리 API 에서는 사용자를 추가해달라거나, 지워달라거나, 조회해달라는 요청을 할 수 있습니다.

 

여기서 기억해야 하는 다섯가지 메서드는 다음과 같습니다.

               GET , POST , PUT , PATCH, DELETE

각각         조회     추가          갱신             삭제       

 

메서드 설명은 MDN "HTTP 요청 메서드"를 참고하세요.

 

---

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

= 브라우저의 작동 원리를 URL과 URI, IP와 포트, 도메인과 DNS 등 보이지 않는 영역에 대하여 학습합니다.

학습 목표

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

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는 웹 서버에 보내는 추가적인 질문입니다. 위 그림의 http://www.google.com:80/search?q=JavaScript를 브라우저의 검색창에 입력하면, 구글에서 JavaScript를 검색한 결과가 나타납니다. fragment는 일종의 북마크 기능을 수행하며 URL에 fragment(#)와 특정 HTML 요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동할 수 있습니다.

 

브라우저의 검색창을 클릭하면 나타나는 주소가 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	웹 서버에 전달하는 추가 질문

• 127.0.0.1 은 로컬 PC를 나타냅니다.
• port는 서버로 진입할 수 있는 통로입니다.

 

 

서울특별시청을 찾아가기 위해서는 서울특별시청의 주소를 알아야 합니다.

마찬가지로 네트워크 상에서 서울특별시청에 근무하는 김코딩 사무관의 PC에 접속하기 위해서는,

김코딩 사무관의 PC를 가리키는 주소를 알아야 합니다.

 

이렇게 네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP address(Internet Protocol address, IP 주소)라고 합니다. 이번 콘텐츠에서는 네트워크 상에서 특정 PC를 나타내는 IP 주소와 그 주소에 진입할 수 있는 정해진 통로, PORT(포트)에 대해 학습합니다.

 

IP address

공유기를 설치하고 비밀번호를 설정하려면, 공유기 관리 페이지에 접속해야 합니다.

웹 브라우저에 닷(.)으로 구분된 네 덩이의 숫자를 입력하면, 공유기의 관리 페이지로 접속할 수 있습니다.

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

 

IP는 Internet Protocol의 줄임말로, 인터넷상에서 사용하는 주소체계를 의미합니다.

인터넷에 연결된 모든 PC는 IP 주소체계를 따라 네 덩이의 숫자로 구분됩니다.

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

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

 

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

그중에서 몇 가지는 이미 용도가 정해져 있습니다. 특히 다음과 같은 IP 주소는 반드시 기억해야 합니다.

 

• localhost, 127.0.0.1 : 현재 사용 중인 로컬 PC를 지칭합니다.

PORT

터미널에서 리액트를 실행하면 나타나는 화면에는, 로컬 PC의 IP 주소인 127.0.0.1 뒤에 :3000과 같은 숫자가 표현됩니다. 이 숫자는 IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)를 의미합니다. 리액트를 실행했을 때에는 로컬 PC의 IP 주소로 접근하여, 3000번의 통로를 통해 실행 중인 리액트를 확인할 수 있습니다. 이미 사용 중인 포트는 중복해서 사용할 수 없습니다. 만약 다른 프로그램에서 3000번 포트를 사용 중이라면, 다음과 같이 다른 포트 번호(3001)로 리액트가 실행됩니다.

[그림] 3001번 포트로 실행된 리액트

포트 번호는 0~ 65535까지 사용할 수 있습니다. 그중에서 0 ~ 1024번까지의 포트 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있습니다. 반드시 알아야 할 잘 알려진 포트 번호는 다음과 같습니다.

• 22 : SSH
• 80 : HTTP
• 443: HTTPS

이미 정해진 포트 번호라도, 필요에 따라 자유롭게 사용할 수 있습니다. HTTP(:80), HTTPS(:443)과 같이 잘 알려진 포트의 경우, https://codestates.com:443이 아닌 https://codestates.com처럼 포트 번호를 URI에 생략할 수 있지만, 그 외의 잘 알려지지 않은 포트(3000과 같은 임시 포트)는 반드시 포트 번호를 포함해야 합니다.

 

---

Domain name

웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP 주소를 대신하여 사용하는 주소가 있습니다.

만약 IP 주소가 지번 또는 도로명 주소라면, 도메인 이름은 해당 주소에 위치한 상호로 볼 수 있습니다.

택시를 타고 목적지에 도착하는 상황을 가정해 보겠습니다.

서울 중구 세종대로 110이라는 도로명 주소가 있습니다.

 

택시를 타고, 기사님께 도로명 주소를 전달하면, 무사히 목적지에 도착할 수 있습니다.

그러나 도로명 주소 특성상 주소 자체가 상당히 길고, 주소지만 보면 어떤 건물이 있는지 파악하기 어렵습니다.

도로명 주소를 대신해서, 상호나 건물의 이름을 택시 기사님께 전달할 수도 있습니다.

기사님께 서울시청까지 가 달라는 메시지를 전달해도, 무사히 목적지에 도착할 수 있습니다.

 

이와 유사하게 도메인 이름을 이용하면, 한눈에 파악하기 힘든 IP 주소를 보다 간단하게 나타낼 수 있습니다.

다음과 같이, 터미널에서 도메인 이름을 통해 IP 주소를 확인하는 명령어 nslookup으로 codestates.com의 IP 주소를 확인할 수 있습니다.

위 그림에서 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 주소는 어떻게 매칭하는 걸까요?

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

 

네트워크에는 이것을 위한 서버가 별도로 있는데 이를 DNS(Domain Name System)이라고 합니다.

 

DNS는 호스트의 도메인 이름을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템입니다. 만약 브라우저의 검색창에 naver.com을 입력한다면,

이 요청은 DNS에서 IP 주소(ex.125.209.222.142)를 찾습니다.

그리고 이 IP 주소에 해당하는 웹 서버로 요청을 전달하여 클라이언트와 서버가 통신할 수 있도록 합니다.

 

---

Chrome 브라우저를 사용하다 보면 누구나 한 번쯤 에러 메시지를 만날 수 있습니다.

이 에러 메시지는 웹페이지를 제공하는 서버와 Chrome 브라우저가 소통하는 단계,

또는 기기와 네트워크의 연결, Chrome 브라우저가 해석할 수 없는 데이터를 전송받은 경우 발생합니다.

 

아래에서 설명하는 에러 메시지는 Chrome 브라우저를 사용하면 만날 수 있는 잘 알려진 에러 메시지입니다.

Chrome 브라우저를 제공하는 구글은 이런 에러 메시지를 어떻게 핸들링해야 하는지 잘 설명해 두었습니다.

Chrome 브라우저에서 에러 메시지를 만났을 때 어떤 에러인지 알아야 차분히 해결할 수 있을 것입니다.

[그림] Chrome 브라우저의 Aw, Snap! (앗, 이런!) 에러 페이지

Aw, Snap! (앗, 이런!)

웹페이지 대신 '앗, 이런!' 에러 페이지 또는 다른 에러 메시지가 표시된다면, Chrome 브라우저가 웹 페이지를 로드하는 데에 문제가 발생한 경우입니다. 이 경우 페이지가 느리게 로드되거나, 열리지 않을 수도 있습니다.

다음 에러 메시지가 나타난다면, 페이지를 여는 중에 문제가 발생했다는 뜻입니다.

"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/를 입력하여 확인할 수 있습니다.

위의 에러 메시지를 만나면, 다음과 같은 문제가 발생할 수 있습니다.

• 웹페이지에 연결할 수 없습니다.
• 웹페이지가 열리지 않습니다.
• HTTPS가 적용된 웹페이지가 열리지 않습니다.
• 사진이 로드되지 않습니다.
• 새 탭이 로드되지 않습니다.