TIL 31일차 - [HTTP/네트워크] 기초

• 클라이언트-서버 아키텍처를 이해할 수 있다.

  o
  클라이언트와 서버만을 의미할 때는 2-Tier Architecture 라고 하며,
  클라이언트, 서버와 데이터 베이스를 의미할 때는 3-Tier Architecture 라고 한다.

  클라이언트는 서버에 필요한 리소스를 요청할 수 있고,
  서버는 클라이언트에 요청에 대한 정확한 응답을 전달해야 한다.
  이때, 서버는 필요한 리소스에 대해 데이터베이스에 요청하고 응답 받을 수 있고, 받은 응답을 클라이언트에 전달하여 응답한다.

• HTTP를 이용한 클라이언트-서버 통신을 이해할 수 있다.

  o
  클라이언트와 서버가 요청을 보내고 응답을 하며,
  서로 소통하기 위해서는 정해진 규약이 필요하다.
  이러한 규약을 프로토콜(통신 방법)이라고 하며,
  대표적인 프로토콜에는 HTTP, HTTPS 등이 있다.

  이렇게 HTTP로 주고 받는 메시지를 'HTTP 메시지'라고 부른다.

• API의 개념을 이해할 수 있다.

  o
  API는 Application Programming Interface의 약자로
  두 애플리케이션이 서로 소통할 수 있도록 만는 인터페이스를 의미한다.
  API는 앱이 요청할 수 있고, 프로그래밍이 가능한 인터페이스다.

  따라서 서버가 클라이언트에게 리소스를 잘 활용할 수 있도록
  명확한 API를 디자인하여 구축해야
  클라이언트가 이를 활용하여 명확한 요청을 할 수 있다.

• 브라우저의 작동 원리를 이해할 수 있다.

  o
  브라우저의 작동 원리에는 보이지 않는 곳과 보이는 곳이 있다.
  보이지 않는 곳은 서버가 제공하는 환경에 존재하는 파일의 위치 즉, 주소를 나타내는 URL과 URI이 있고, 보이는 곳은 비동기적으로 데이터를 서버에서 받아와 브라우저에 렌더링하는 AJAX가 있다.

• 보이지 않는 곳의 통신을 이해할 수 있다.

  o
  브라우저의 주소창에 입력한 URL은 서버가 제공되는 환경에 존재하는 파일의 위치 즉 주소를 나타낸다. 슬래시(/)를 이용하여 서버의 폴더에 진입하거나 파일을 요청할 수 있다.

  브라우저의 보이지 않는 곳의 통신에는
  URL, URI, IP주소, PORT, 도메인, DNS가 있다.

• URL과 URI의 차이를 이해할 수 있다.

  o
  주소창에 입력한 URL, URI는 다음과 같은 특징을 가지고 있다.

  URL은 Uniform Resource Locator의 약자로
  네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다.

  URL은 통신 방식을 나타내는 scheme,
  웹 서버의 이름이나 도메인, IP주소를 사용하여 주소를 나타내는 hosts,
  웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한
  경로와 파일명을 나타내는 url-path로 구분할 수 있다.

  URI는 Uniform Resource Identifier의 약자로
  URL의 기본요소인 scheme, hosts, url-path에 추가적으로
  웹 서버에 보내는 추가적인 질문인 query와 북마크 기능을 하는 fragment를 포함한다.

  따라서 URI는 URL을 포함하는 상위 개념으로 "URL은 URI다."는 맞는 설명이지만,
  "URI는 URL이다."는 틀린 설명이다.

• IP 주소와 PORT에 대해 이해할 수 있다.

  o
  IP 주소(=Internet Protocol address)는
  네트워크에 연결된 특정 PC의 주소를 나타내는 체계로
  전세계 네트워크에서 각 주소를 식별하기 위한 고유번호다.
  이러한 IP 주소는 터미널에서 nslookup을 이용하여 IP 주소를 확인할 수 있다.

  이러한 IP 주소는 네 덩어리의 숫자로 구분되고,
  이렇게 네 덩어리의 숫자로 구분된 IP 주소체계를 IPv4라고 한다.

  IPv4는 Internaet Protocol version 4의 약자로
  IP 주소체계의 4번째 버전을 의미한다.
  IPv4는 각 덩어리마다 0~255까지 나타낼 수 있어
  약 43억 개의 IP 주소를 표현할 수 있다.

  이 중 몇 개는 이미 용도가 정해져 있는데
  대표적으로 localhost, 127.0.0.1은
  현재 사용중인 로컬 PC를 의미한다.

  그러나 개인 pc 보급률이 높아지면서 IPv4로는
  주소를 표현하기가 부족해지면서 IPv6가 등장하였다.

  PORT는 IP 주소가 가리키는 PC에 접속할 수 있는 통로(채널)을 의미한다.
  즉, 데이터가 각 기능에 따라 라우팅(분기,전달)되도록 하기 위함이다.

  이미 사용중인 포트는 중복해서 사용할 수 없다.
  만약 3000번 포트로 이미 리액트를 실행 중이라면,
  해당 프로세스를 종료하거나 3001번과 같은 다른 포트 번호로 프로세스를 실행해야한다.

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

  대표적으로는 22(:SSH), 80(:HTTP), 443(:HTTPS)가 있다.

• DNS와 IP 주소의 관계를 설명할 수 있다.

  o
  도메인 이름은 웹 브라우저를 통해 특정 사이트에 진입할 때,
  IP주소를 대신하여 사용하는 주소로
  사람이 식별할 수 있도록 자연어(알파벳)로 표시된 주소 이름이다.
  이 또한 터미널에서 nslookup 명령어로 확인해 볼 수 있다.

  모든 IP주소가 도메인 이름을 가지는 것은 아니며,
  영구적으로 사용할 수 있는 것이 아니므로
  일정 기간 동안 도메인 이름을 대여하여 사용한다.
  때문에 해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업이 필요하다.

  이러한 작업을 DNS라 하며 DNS는 Domain Name System의 약자로 해당 도메인 이름과 매칭된 IP 주소를 확인하는 작업하는 서버를 의미한다.

  이러한 DNS는 호스트의 도메인 이름을 IP주소로 변환하거나
  반대의 경우를 수행할 수 있도록 개발된 데이터베이스시스템이다.

• 크롬 브라우저의 에러 메시지를 통해 문제를 파악할 수 있다.

  o
  프론트엔드 개발자에게는 200번대, 400번대가 중요하다.

• HTTP의 동작 방식을 이해할 수 있다.

  o

• HTTP Messages의 구조를 설명할 수 있다.

  o
  HTTP Messages는 클라이언트와 서버 사이에서 데이터가 교환되는 방식으로
  몇 줄의 텍스트 정보로 구성된다.

  Start line, HTTP headers, empty line, body로 구분되며,
  Start line, HTTP headers는 부가 정보를 나타내는 head 부분이고,
  body는 전송되는 정보를 나타내는 body(payload) 부분이다.

• HTTP Requests와 Responses를 구분할 수 있다.

  o
  HTTP Requests는 클라이언트가 서버에 보내는 메시지로
  Start line, Headers, Body로 구분된다.

  HTTP Responses는 서버가 클라이언트에 보내는 메시지로
  HTTP Requests와 마찬가지로 Start line, Headers, Body로 구분된다.

• HTTP의 응답 메시지를 찾아볼 수 있다.

  o
  MDN HTTP 상태코드를 참고한다.

• 보이는 곳의 통신을 이해할 수 있다.

  o
  브라우저의 보이는 작동원리에는 대표적으로 AJAX가 있다.

• AJAX의 개념을 이해할 수 있다.

  o
  AJAX는 Asynchronous JavaScript And XmlHttpRequest의 약자다.

  AJAX는 사용자가 필요로 하는 부분에 필요한 데이터만 비동기적으로 받아와
  화면에 렌더랑하는 기법으로 JavaScript, DOM, Fetch, XML HttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법이다.

  대표적인 예로는 웹 사이트의 검색창이 있다.
  검색창에 글자를 입력할 때마다 해당 글자로 시작하는 단어들을
  서버로부터 받아와서 검색창 아래에 추천 검색어로 보여준다.
  이렇듯, 검색창에서는 필요한 데이터만 비동기적으로 받아와 렌더링되며,
  여기에 AJAX가 사용된다.

• SSR과 CSR의 차이를 이해할 수 있다.

  o
  SSR은 Server Side Rendering의 약자로
  웹 페이지를 브라우저에서 렌더링하는 대신에 서버에서 렌더링하는 방식이다.

  브라우저가 서버의 URI로 GET 요청을 보내면,
  서버는 정해진 웹 페이지 파일을 브라우저로 전송한다.
  만약 웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우에
  서버는 데이터베이스의 데이터를 불러온 다음,
  웹페이지를 완전히 렌더링된 페이지로 변환한 후에 브라우저에 응답으로 보낸다.

  CSR은 Client Side Rendering의 약자로
  클라이언트에서 페이지를 렌더링하는 방식이다.

  브라우저의 요청으로 서버를 보내면, 서버는 웹 페이지를 렌더링하는 대신,
  웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보낸다.
  이때, 서버는 웹 페이지와 함께 JavaScript 파일을 보낸다.
  클라이언트가 웹 페이지를 받으면,
  웹 페이지와 함께 전달된 JS파일은
  브라우저의 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.

  따라서 SSR은 검색 엔진 최적화에 상대적으로 유리하며,
  초기 로딩 속도가 빠르다. 또한 눈에 보이는 시점인 TTV(Time To View) 와 상호작용하는 시점인 TTI(Time To Interact)간의 공백이 있을 수 있다.

  CSR은 Single Page Application를 기반으로 화면의 일부만 바꿔주는 것으로 AJAX를 통해서 서버로부터 필요한 데이터만 받는다.

• SEO(Search Engine Optimization)에 대해 학습하기

  o
  SEO는 검색 엔진 최적화를 의미한다.
  네이버나 구글과 같은 검색 엔진 크롤러가 HTML에 접근하여
  HTML에 담긴 내용을 쉽게 가져갈 수 있는 검색 엔진으로
  완성된 HTML 파일을 받아와서 렌더링한다.
  그 HTML 파일 안에 해당 내용이 그대로 담겨 있는 상태이므로
  검색 엔진 크롤러가 내용을 수집하기 용이하다.

  SSR은 서버로부터 완전히 렌더링 된 후 브라우저에서 받기 때문에
  이러한 SEO에 유리하다.

  다만, 서버로부터 HTML의 골격만 받아오는 CSR의 경우에는
  검색 엔진 크롤러가 접근하여 읽을 HTML의 파일 내용이 부족하므로
  SEO가 불리하다.

소감

🔡➡️💻➡️🤓👍

네트워크 통신을 배우면서
인터넷을 하면서 무심코 당연하게 여겨졌던
서비스들이 새삼 신기하게 느껴졌다.

어떻게 개발자들이 이 복잡하고 거대한 네트워크를 형성하고
연구하고 이러한 이론들이 생겨나고 아직도 개발되는지 신기할 따름이다.

앞으로 사이트를 이용하면서
이전보다 하나 하나 눈에 들어올 것 같다.

역시 배운 만큼 보이는 것 같다.