🧡 웹 애플리케이션 아키텍쳐

• 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 아키텍처, 또는 클라이언트-서버 아키텍처 라고 합니다.

• 리소스를 사용하는 앱이 '클라이언트', 리소스를 제공하는 곳을 '서버'라고 부릅니다.
  

• 클라이언트와 서버는 요청과 응답을 주고받는 관게입니다. 일반적으로 서버는 리소스를 전달해주는 역할만 담당합니다. 저장하는 공간을 별도로 마련해 두는데 이 공간을 '데이터베이스'라고 부릅니다. 이렇게 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부릅니다.

• 클라이언트는 서버로 요청을 보내고, 서버는 요청에 따른 적절한 응답을 클라이언트로 회신합니다. 필요에 따라 서버는 데이터베이스에 요청을 보내고 응답을 활용합니다.

• 클라이언트처럼 사용자가 눈으로 보고 상호작용할 수 있는 앱을 개발하면 프론트엔드 개발자라고 하고, 눈에 보이지 않지만 데이터베이스 등 시스템 설계나 서버를 다루면 백엔드 개발자라고 부릅니다.

• 클라이언트는 보통 플랫폼에 따라 구분됩니다. 브라우저를 통해 주로 이용하는 웹 애플리캐이션과, 스마트폰/태블릿 플랫폼, 데스크탑 플랫폼에서 이용하는 앱 이 있습니다.

• 서버는 무엇을 하느냐에 따라 종류가 달라집니다. 파일 서버는 파일을 제공하는 앱, 웹 서버는 웹 사이트에서 필요로 하는 정보들을 제공하는 앱, 메일 서버는 메일을 주고 받을 수 있게 도와주는 앱입니다. 데이터베이스도 일종의 서버라고 볼 수 있습니다.

💚 클라이언트-서버통신과 API

• 클라이언트와 서버간 통신은 요청과 응답으로 구성되고, 요청이 있어야만 서버가 응답(리소스를 전달)합니다.

• 이때 요청을 위한 약속이 프로토콜입니다. 그리고 그 프로토콜이 'HTTP'입니다. 프로토콜은 다양한 방법으로 존재합니다.

• '규약'이라는 측면에서 각자의 프로토콜 마다 지켜야하는 약속이 존재합니다.

  🎀 OSI 7 Layers : 통신이 일어나는 과정을 단계별로 파악할 수 있습니다.
  

API(Application Programming Interface)

• 컴퓨터에게 요청할 때는, 정확한 주문방법(0과 1로 변환될 수 있는 요청)에 따라 요청합니다.

• 이때 서버에 적절하게 주문하도록 클라이언트에게 리소스 활용 인터페이스를 제공하는 것이 API입니다. 일종의 메뉴판 역할을 합니다. 클라이언트가 엉뚱한 요청을 하지 않도록 합니다.

• Interface 는 '의사소통이 가능'하도록 만들어진 '접점'을 의미합니다. API는 앱이 요청할 수 있고, 프로그래밍 가능한 인터페이스라는 점이 메뉴판과 다릅니다.

• 보통 인터넷에 있는 데이터를 요청할 때에는 HTTP 프로토콜을 사용하며, 주소(URL)을 통해 접근할 수 있습니다. (URL은 파라미터(옵션)을 사용하기 위해 '?'와 '&' 기호를 사용합니다.)

• HTTP 요청에는 메서드가 존재합니다. CRUD 각각의 행동과 일치하는 메서드 종류가 존재하고, HTTP API 디자인에는 Best Practice가 존재합니다.
  -> GET (R.조회), POST(C.추가), PUT or PATCH(U.갱신), DELETE(D.삭제) 메서드를 행동에 맞게 적절하게 사용합니다. (갱신과 삭제는 POST로도 많이 하지만 원칙적으로는 PUT, PATCH, DELETE를 사용합니다.)

🎀 rest API (=best practice)

💚 브라우저

URL 과 URI

• URL은 서버가 제공되는 환경에 존재하는 파일의 위치를 나타냅니다. 그러나 기본적인 보안의 일환으로 외부에서 접근을 허용하지 않습니다.

  🎀 브라우저로 PC폴더와 파일을 탐색하는 URL
  (127.0.0.1 은 로컬 PC를 나타냅니다.)

  • 우분투
    (username 부분에는 사용자 이름을 입력합니다.)
    file://127.0.0.1/home/username/Desktop/
  • macOS
    (username 부분에는 사용자 이름을 입력합니다.)
    file://127.0.0.1/Users/username/Desktop/

• URL(Uniform Resource Locator)은 네트워크 상에서 웹페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냅니다. 가장 먼저 작성하는 scheme은 통신방식(프로토콜)을 결정합니다. hosts는 웹 서버의 이름이나 도메인, IP를 사용해 주소를 나타내고, url-path는 웹서버에서 지정한 루트 디렉토리부터 시작해 웹페이지, 이미지, 동영상 등 위치한 경로와 파일명을 나타냅니다.

• URI(Uniform Resouce Identifier)은 URL에 더해 query, fragment를 포함합니다. query는 웹 서버에 보내는 추가적인 질문입니다. fragment는 일종의 북마크 기능을 수행하며 특정 HTML요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동할 수 있습니다.
  

🎀 동일출처정작 (SOP)

IP와 포트

• 네트워크에 연결된 특정 PC의 주소를 나타내는 체계를 IP address(Internet Protocol address, IP주소)라고 합니다. 인터넷에 연결된 모든 PC는 IP주소를 가집니다.

  🎀 IP주소 확인
  터미널에서 nslookup 주소를 입력하면 만날 수 있습니다.

• 네덩이의 숫자로 구분된 IP주소 체계를 IPv4(Internet Protocol version 4) 라고 합니다. 각 덩어리마다 0~255까지 나타낼 수 있어서 약 43억개의 IP주소를 표현할 수 있습니다.

  🎀 용도가 정해진 IP주소

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

• 인터넷 보급률이 높아지며 IPv4 할당의 한계가 생겨 나온 것이 IPv6 입니다. 2^128개의 주소를 표현할 수 있습니다.

• 터미널에서 리액트를 실행하면 127.0.0.1 뒤에 :3000 같은 숫자가 표현됩니다. 로컬PC의 IP주소로 접근하여 3000번의 통로를 통해 리액트를 확인하는 것입니다. 이미 사용중인 포트는 중복하여 사용할 수 없습니다.

• 포트 번호는 0~65535까지 사용할 수 있습니다. 그 중 0~1024번까지는 주요통신을 위한 규약에 따라 이미 정해져 있습니다.

  🎀 잘 알려진 포트번호

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

도메인과 DNS

• IP주소를 대신하여 사용하는 주소를 말합니다. 일종의 주소의 상호를 가리킵니다.
• 그러나 모든 주소가 도메인이름을 가지는 것은 아닙니다. 보통은 일정 기간 동안 대여하여 사용합니다.
• IP주소와 도메인이름을 확인하는 작업이 필요한데, 네트워크에서 이것을 위한 별도의 서버를 DNS(Domain Name System)이라고 합니다. 호스트의 도메인 이름을 IP로 변환하거나 반대로 수행하도록 개발된 데이터베이스 시스템입니다.

크롬 에러 읽기

💚 HTTP

HTTP Message

• 클라이언트와 서버 사이에 데이터가 교환되는 방식입니다. 요청과 응답 두 가지 유형이 있습니다.
• 구성파일, API, 기타 인터페이스에서 자동으로 완성합니다.
• 요청과 응답은 유사한 구조를 가집니다.
  • start line : 요청이나 응답의 상태 (응답에서는 status line)
  • HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
  • empty line : 헤더와 본문을 구분하는 빈줄
  • body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함, 유형에 따라 선택적으로 사용
• Stateless : HTTP로 통신을 주고받는 과정에서 HTTP는 클라이언트나 서버의 상태를 확인하지 않습니다. 통신규약일 뿐 상태를 저장하지 않아, 필요에 따라 다른 방법으로 상태를 확인해야 합니다.

HTTP Requests

start line

• 수행할 작업이나 방식을 설명하는 HTTP method를 나타냅니다.
• 요청 대상 또는 프로토콜, 포트, 도메인 등의 절대경로가 작성됩니다. HTTP method에 따라 형식이 다릅니다.
  • origint : ?와 쿼리문자열이 붙는 절대경로입니다.
  • absolute : 완전한 URL형식으로, 프록시에 연결하는 경우 대부분 GET 메소드와 함께 사용됩니다.
  • authority : 도메인 이름과 포트번호로 이루어진 URL의 일부분
  • asterisk : options와 함께 *하나로 서버 전체를 표현합니다.
• 버전에 따라 HTTP message의 구조가 달라지므로 버전을 함께 입력합니다.

Headers

• 기본구조를 따릅니다. 헤더이름, 콜론(:), 값을 입력합니다.
• 여러 헤더락 있고, 헤더에 따라 값이 다릅니다.
  • General headers : 메세지 전체에 적용되는 헤더, body를 통해 전송되는 데이터와 무관합니다.
  • Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 정보를 포함합니다.
  • Represnation headers : body에 담긴 리소스의 정보를 포함하는 헤더입니다.

Body

• GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않습니다. POST, PUT같은 일부 요청은 업데이트를 위해 사용합니다.
• 단일 리소스 본문 : 헤더 두개로 정의된 단일 파일로 구성됩니다.
• 다중 리로스 본문 : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다.

HTTP Responses

Status line

• 서버가 클라이언트에게 보내는 메시지입니다. 현재프로토콜의 버전, 상태코드, 상태 텍스트 정보를 포함합니다.
  HTTP/1.1 404 Not Found가 대표적인 예입니다.

Headers

• 요청헤더와 동일한 구조를 가집니다. 사진 상의 두 줄을 유의해서 봅니다.

body

• 201, 204 같은 상태코드를 가지는 응답에는 본문이 필요하지 않습니다.