[TIL] 네트워크 기초

오늘은 페어 프로그래밍 없이 개념 학습만 쭉 하는 날이었다!
마침 주말에 API 파고들기를 했었는데, 관련 내용이 나와서 반가웠던 날 😋

• 네트워크 = 컴퓨터 간의 연결

클라이언트 & 서버

• 클라이언트 : 리소스를 사용하는 애플리케이션이며 프론트엔드 개발자의 영역
• 서버 : 리소스를 제공하는 쪽이며 백엔드 개발자의 영역

위의 두가지만 있을 때는 '2티어 아키텍처'(=클라이언트 서버 아키텍처)라고 하고, 여기에 데이터베이스(리소스 저장하는 공간)가 추가되면 '3티어 아키텍처'라고 부름.

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

• 프로토콜
  : 프로토콜은 통신 규약으로, 웹 어플리케이션 아키텍처에서 클라이언트와 서버는 'HTTP'라는 프로토콜을 이용해 서로 대화가 가능함.
  (다양한 프로토콜 존재. 각 프로토콜마다 지켜야하는 규칙 다름)

  
  

• OSI 7Layers(Open System Interconnection 7 Layers: 개방형 시스템 상호연결)
  : 7개의 계층이 존재하고, 각 프로토콜마다 어떤 계층에 속해있음.
  (ex: HTTP, HTTPS, FTP, SMTP 등은 layer 7인 응용계층에 속한다)

• API (Application Programming Interface)
  : 서버가 클라이언트에게 리소스를 잘 활용할 수 있도록 제공하는 인터페이스.
  서버가 리소스 전달을 위한 메뉴판 역할을 하는 API 문서를 작성해야 클라이언트가 이를 활용 가능.

(*API의 범위는 엄청나게 크고, 다른 문맥에서 다르게 사용될 수 있음. 웹 개발 API가 현재 배우는 서버 API. 그 외에도 fetch API 처럼 여러 인터페이스들을 API라고 함.)

HTTP (HyperText Transfer Protocol)

: HTML과 같은 문서를 전송하기 위한 프로토콜.

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

HTTP 요청시 메소드를 지정하여 리소스와 관련된 행동(CRUD)을 지정할 수 있다. (GET, POST, PUT, PATCH, DELETE)

• HTTP의 Stateless (무상태성)
  : 가장 큰 특징으로 HTTP는 통신규약이기 때문에 상태를 저장하지 않는다. 필요시 다른 방법(쿠키-세션, API)을 통해 상태를 확인함.

• HTTP Messages : 클라이언트와 서버에서 데이터가 교환되는 방식으로 요청과 응답 두 유형이 있음.
  => 요청과 응답은 유사한 구조를 지님
  : start line(status line)/ HTTP headers/ empty line/ body
  => start line/ status line : 요청이나 응답의 상태를 나타냄. 항상 첫번째줄.
  => HTTP headers : 요청을 지정하거나 메시지에 포함된 본문 설명하는 헤더들의 집합.
  => empty line : 헤더와 본문 구분하는 빈줄
  => body : 요청과 관련된 데이터나 응답과 관련된 데이터 or 문서 포함.
  (body는 요청과 응답의 유형에 따라 선택적으로 사용함. GET,HEAD,DELETE,OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않음. )
  => 이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 함.
  => payload는 body라고 함. (페이로드 : 전송되는 데이터)

브라우저 작동 원리

보이지 않는 곳

• URL
  : 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타냄.
  🟡 scheme : 통신방식(프로토콜) 결정. (일반적으로 http(s) 사용)
  🟡 hosts : 웹 서버의 이름이나 도메인, IP를 사용. 주소를 나타냄.
  🟡 url-path : 웹 서버에서 지정한 루트 디렉토리로부터 시작해 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명 나타냄.
  

• URI
  : URL 기본 요소인 scheme, hosts, url-path에 query, fragment가 포함된 개념.
  🟡 query: 웹 서버에 보내는 추가적 질문
  🟡 fragment : 일종의 북마크 기능 수행. #와 특정 HTML요소의 id 전달시 해당 요소 있는 곳으로 스크롤 가능!

• IP 주소
  : 인터넷상에서 사용하는 주소체계 (ex: localhost, 127.0.0 은 로컬 pc 나타냄)
  => IPv4 사용하다 IPv6 체계로 넘어옴.
  => 0.0.0.0, 255.255.255.255 : broadcast address로 로컬 네트워크에 접속된 모든 장치와 소통하는 주소.
  

• PORT
  : IP 주소 뒤에 표현되는 숫자로, PC에 접속할 수 있는 통로(채널) 의미.
  포트 번호는 0~65535까지 사용 가능. 그 중에서 0~1024번까지 포트는 주요 통신 위한 규약에 따라 이미 정해져 있음.
  => 22 : SSH
  => 80 : HTTP
  => 443 : HTTPS

• Domain name
  : 웹 브라우저 통해 특정 사이트 진입할 때 IP주소를 대신해 사용하는 주소.
  한눈에 파악하기 힘든 IP 주소를 보다 간단하게 나타낼 수 있음.
  (ex: naver.com)

• DNS (Domain Name System)
  : 도메인 이름과 매칭된 IP주소를 확인하는 작업을 하는 네트워크 서버.
  도메인 이름은 일정기간 동안 대여해서 사용하는 것이기 때문에 해당 사이트로 이동하기 위해서는 위처럼 확인하는 작업이 필요

보이는 곳

• AJAX (Asynchronous Javascript and XMLHttpRequest)
  : js, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법으로 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있음.
  => Js & DOM 과 Fetch가 AJAX의 핵심 기술. (fetch 이전에는 XHR 사용했었음)

• AJAX 장점
  🟢 서버에서 HTML 완성해 보내지 않아도 웹페이지 만들 수 있음
  🟢 표준화 된 방법
  🟢 유저 중심 애플리케이션 개발
  🟢 더 작은 대역폭
  

• AJAX 단점
  🔴 SEO에 불리
  🔴 뒤로가기 버튼 문제
  

• SSR
  : 웹 페이지를 브라우저로 보내기 전 서버에서 렌더링.
  => 사용자가 브라우저의 다른 경로로 이동시 : 다른 경로로 이동할 때마다 서버는 같은 작업 다시 수행.

❓ SSR는 언제 사용하는가? : SEO 우선순위인 경우, 첫 화면 렌더링 빠르게 필요한 경우, 사용자와 상호작용 적은 경우.

• CSR
  : 클라이언트(대표적으로 웹 브라우저)에서 페이지를 렌더링. 서버는 주로 API응답을 담당함.
  => 사용자가 브라우저의 다른 경로로 이동시 : 페이지 새로고침하지 않고 동적으로 라우팅 관리.

❓ CSR은 언제 사용하는가? : 사용자와 상호작용 많은 경우, 더 나은 사용자 경험 제공 가능.