[05.24] HTTP/네트워크 기초

• 웹 애플리케이션 아키텍처
• 클라이언트-서버 통신과 API
• 브라우저의 작동 원리 (보이지 않는 곳)
• HTTP
• 브라우저의 작동 원리 (보이는 곳)

---

📌 웹 애플리케이션 아키텍처

Client Server Architecture

: 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 2-Tier 아키텍처 혹은 클라이언트 서버 아키텍처

⁉️ 인터넷 연결이 없다면 앱이 사용 가능한가?
⇒ 사용이 불가하다

왜냐면 앱에는 실질적인 정보를 담고 있지 않고 구현된 앱 일뿐이다

⁉️ 그럼 앱에 필요한 정보는 어디에 있는거야?
⇒ 앱에 필요한 정보는 서버라는 곳에 존재한다

인터넷 연결을 해서 서버라는 공간에서 정보를 받아와서 만들어진 틀(앱)에 해당 정보를 보여준다

예를 들어

올리브영 앱을 사용한다 가정하였을때 올리브영에서 판매하는 제품들이 담겨 있는 곳은 server, 정보를 받와서 렌더링 후 화면에 보여지는 곳은 client인거다.

클라이언트-서버 아키텍처(2Tier,3Tier)

• 클라이언트가 서버에게 정보를 달라고 요청함
• 서버는 클라이언트의 요청에 맞는 리소스를 담은 내용으로 응답함
  
• 서버는 리소스를 전달해주는 역할만 담당하고, 리소스 저장공간은 별도로 있음. 그 공간을 데이터베이스라고 부름(창고같은 공간이라고 생각하면 됨)
  [2Tier→3Tier]
  

프론트엔드와 백엔드

• FE : 클라이언트처럼 사용자가 직접 보고 클릭하며 상호작용을 하는 앱 개발
• BE : 사용자 눈에 보이진 않지만 상품정보를 API로 노출,로그인/아웃, 권한 관리등의 사용자 인증을 주로 다루는 앱 개발
  

클라이언트와 서버 종류

• 클라이언트는 보통 플랫폼에 따라 구분됨
  • 브라우저를 통해 주로 이용하는 웹 플랫폼 : 웹사이트 또는 웹 앱
  • iOS or 안드로이드
  • 데스크탑 앱(윈도우)
• 서버는 무엇을 하는냐에 따라 종류가 달라짐
  • 파일을 제공하는 앱
  • 웹사이트에서 필요로 하는 정보들을 제공하는 앱
  • 메일을 주고 받는 앱
    

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

: 클라이언트와 서버 간의 통신은 요청과 응답으로 구성됨

프로토콜(Protocol)

: 통신 규약(약속)

웹 애플리케이션 프로토콜 : HTTP

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

• 대화(응답,요청)을 할 수 있는 방법은 여러가지가 있음
• 각자의 프로토콜마다 지켜야하는 규약이 존재함

주요 프로토콜

: 물리적→데이터→네트워크→전송→세션→표현→응용

• 전송
  
• 응용
  

API(Application Programing Interface)란?

: 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(설명서,틀)를 제공

• 서버는 리소스 전달을 위한 API문서를 작성해야 클라이언트가 이를 활용할 수 있음
• 인터넷에 있는 데이터 요청시 HTTP프로토콜을 이용, 주소(URL,URI)를 통해 접근 가능

HTTP API 디자인을 잘하는 방법

HTTP API 디자인에는 Best Practice가 존재함

• HTTP 요청시 메소드를 지정하여 리소스와 관련된 행동(CRUD)을 지정할 수 있음
  [예시]
  
• HTTP 메소드는 CRUD 행동에 따라 목적에 맞게 써야함
  

API 작성법

[예시]

• (GET요청) : 요청방식(method)→데이터를 달라고 할지, 보낼건지
• comic.naver.com/webtoon/detail : 무슨 자료를 요청할지(endpoint)
• ?id=318995 : 자료요청에 필요한 추가 정보(파라미터)

(GET요청) comic.naver.com/webtoon/detail ?id=318995

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

URL과 URI

• URL(Uniform Resource Locater) : 네트워크 상에서 웹 페이지, 이미지, 동영상 등 파일의 위치한 정보
  • scheme, hosts, url-path로 구분 가능
• URI (Uniform Resource Identifier) : URL의 기본 요소에 query, fragment를 포함
  ⇒ URI는 URL을 포함하는 상위 개념
  

IP와 포트

• IP(Internet Protocol) : 네트워크에 연결된 특정 PC의 주소르 나타내는 체계
• 포트(Port) : 해당 주소에 진입할 수 있는 정해진 통로
  • 포트 번호 : 22(SSH), 80(HTTP), 443(HTTPS)

도메인과 DNS

• 도메인 : 웹 브라우저를 통해 특정 사이트에 진입을 할 때, IP주소를 대신해서 사용하는 주소
• DNS : 브라우저의 검색창에 도메인 입력을 입력하여 해당 사이트로 이동하기 위해 도메인 이름과 매칭되는 IP주소를 확인하는 작업을 해줌

📌 HTTP

HTTP(HyperText Transfer Protocal)란?

: HTML과 같은 문서를 전송하기 위한 프로토콜
→ HTTP는 웹 브라우저와 웹 서버의 소통을 위해 디자인됨

HTTP Messages

: 클라이언트와 서버 사이에서 데이터가 교환되는 방식 (유형 : 요청, 응답)

• start line(응답의 헤드) : 요청이나 응답의 상태/ 항상 첫번째줄에 위치하면 응답에서는 status line이라고 부름
• HTTP headers(응답의 헤드) : 요청을 지정하거나, 메시지에 포함된 본문을 설명
• empty line : 헤더와 본문을 구분하는 빈 줄
• body(payload) : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함
  → 모든 메서드에 필요한건아님/ post, put과 같은 추가 작업이 필요한 메서드에만 작성이 필요
  
  
  
• Stateless(무상태성) : HTTP로 클라이언트와 서버가 통신을 주고 받는 과정에서 HTTP가 클라이언트나 서버의 상태를 확인하지 않음(HTTP의 가장 큰 특징) → HTTP는 통신 규약일뿐 상태를 저장하지 않음
  

📌 브라우저의 작동 원리 (보이는곳)

AJAX란?

: AJAX는 Asynchronous Javascript And XMLHttpREquest의 약자로, Javascript, Dom, Fetch, XMLHttpRequest, HTML등의 다양한 기술을 사용하는 웹 개발 기법

• 가장 큰 특징은 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면을 업데이트 함
• XHR의 단점을 보완한 새로운 Web API, XML(불필요한 태그들도 많이 들어가고 파일들의 사이즈가 큼/가독성도 안좋음)보다 가볍고 Javascript와 호환되는 JSON을 사용

AJAX의 두 가지 핵심 기술

: AJAX를 구성하는 핵심 기술은 Javascript와 Dom, Fetch

• Fetch : Fetch를 사용시 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있음
  사용자가 현재 페이지에서 작업을 하는 동안 서버와 통신가능케함, 서버에 응답 및 요청을 기다리는 순간에도 페이지를 계속 사용할 수 있게 하는 비동기적인 방식을 사용

AJAX의 장단점

1. 장점
   • 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있음
   • 표준화된 방법
   • 유저 중심 앱 개발
   • 데이터의 크기가 작음
     → 이전에는 서버로부터 완성된 HTML을 받아옴으로써 데이터의 크기가 컸는데, AJAX에서는 필요한 데이터를 텍스트 형태(JSON, XML)로 보내면 되기 때문에 데이터의 크기가 작음
2. 단점
   • SEO(검색 엔진 최적화) 불리 → AJAX 방식의 웹 앱은 HTML파일이 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어오기 어려움
   • 뒤로가기 버튼 문제
     → AJAX는 이전 상태를 기억하지 않기 떄문에 사용자가 의도한 대로 동작하지 않음
     그래서 별도의 기능 구현을 위해 History API를 사용
     

SSR과 CSR정의와 설명

1. SSR (Server Side Rendering)
   • 정의 : 웹 페이지를 브라우저에서 렌더링하는 대신에 서버에서 렌더링(초기 로딩 속도가 빠름)
   • 설명
     (1) 서버에서 이미 렌더링 된 html을 클라이언트에게 전달
     (2) 클라이언트가 직접 JS를 다운
     다운받는동안 사용자는 렌더링된 html을 읽을 수 있지만 어떤 동작을 하지는 못함
     (3) JS가 다운이 완료되면 사용자는 페이지의 모든 조작이 가능함
     
     
2. CSR (Client Side Rendering)
   • 정의 : 초기 로딩시 빈 HTML과 로직이 담겨있는 JS가 다운이 되고, 해당 파일에 DOM을 동적으로 생성하여 그리게 됨 → 클라이언트에서 렌더링이 됨
   • 설명
     (1) 서버에게 정보 요청을 보냄
     (2) 클라이언트에게 html,js로 접근가능한 링크를 보내고 클라이언트는 이를 다운을 받고 실행
     (3) 데이터를 위한 API가 호출되고 요청에 응답되어진 뒤에 상호작용이 가능한 페이지가 됨
     

SSR, CSR 사용

• SSR 사용
  • SEO가 우선 순위인 경우
  • 웹 페이지의 첫 화면 렌더링이 우선 순위인 경우
  • 웹 페이지가 사용자와 상호작용이 적은 경우
• CSR 사용
  • SEO가 우선 순위가 아닌 경우
  • 사이트에 많은 상호작용이 있는 경우

SSR, CSR 예시

1. SSR
   • 네이버 블로그 : 검색 엔진에 최대한 노출되는게 유리하고, 다른 웹사이트에 비해 사용자와의 상호작용이 적어서
   • 뉴욕 타임즈 : 전체 웹 사이트를 서버에서 받아오는데 서버 과부하 이슈가 있지만, 초기 로딩 속도가 CSR에 비해 빠르기 때문에 구독자가 빠르게 신문을 읽을 수 있다는 장점이 있음
2. CSR
   • 아고다 : 화면의 일부만 데이터로 변경해주면 되기 때문에 유저 경험에 유리 → SEO가 불리하지만, 구글에서는 이 부분을 보완하기 위해 자바스크립트 코드를 분석,실행시켜 크롤링을 함