🌈 [Section2] 9. 네트워크2

📕 오늘 배운 내용!

• 2-Tier Architecture
• HTTP
• SSR / CSR

---

✏️ 웹(WEB)

• 인터넷에서 제공되는 하이퍼텍스트 시스템

• HTML로 대표되는 하이퍼텍스트 언어와 인터넷이 융합하여 탄생

✔️ 하이퍼텍스트
- 문서안에 다른 문서의 위치정보 등을 포함하여 문서 간의 정보를 서로 연관 지어 참조 할 수 있는 문서

✔️ HTML
- 운영체제와 애플리케이션이 달라도 브라우저만 있으면 모두가 동일한 정보를 볼 수 있는 일정한 형식 기준

---

✏️ 클라이언트 - 서버 아키텍쳐 (2-Tier Architecture)

• 리소스가 존재하는 곳(서버)과 리소스를 사용하는 앱(클라이언트)을 분리시킨 것
• 클라이언트가 서버에게 데이터를 요청하면 서버는 리소스를 전달해주는 역할을 함

 

✏️ 3티어 아키텍쳐 (3-Tier Architecture)

• 기존 2티어 아키텍쳐에 데이터베이스가 추가된 형태
• 클라이언트가 서버에게 데이터를 요청하면 서버는 데이터베이스에서 저장된 리소스를 빼내와 전달

❗ 데이터베이스는 리소스를 저장하는 창고같은 역할

 

✏️ 웹 애플리케이션 아키텍처

• 클라이언트-서버 간의 연결에서 어떻게 애플리케이션 내부의 요소들이 상호 소통하는지 설명하는 방법
• 유저가 웹브라우저에서 어떠한 요청을 할 때, 애플리케이션의 다양한 요소들의 상호작용을 유지할 수 있도록 서로를 결부시키는 뼈대
  
  
• 인터넷에 공개되는 순간 막대한 트래픽에 노출될 수 있기 때문에 고려해야할 요소들이 있음 ⬇️

- 신뢰성 (reliability)
- 확장성 (scalability)
- 보안성 (security)
- 견고성 (robustness)

 

✔ 웹 애플리케이션 요청 흐름

1. 브라우저에 url 입력
   
   
2. 브라우저가 서버 주소 찾기 위해 DNS 서버에 요청 보냄
   
   
3. IP 주소 찾으면 해당 주소에 HTTPS 요청 보냄
   ➜ 이미 방문 기록이 캐시 메모리에 있으면 주소를 캐시 메모리에서 가져옴
   
   
4. 웹서버에 요청이 도착
   
   
5. 웹서버가 저장소에 요청을 보내 페이지 관련 데이터들 가져옴
   ➜ 정보들은 가져오는 중에 비지니스 로직이 작용
   ( 비지니스 로직들은 각 데이터들을 어떻게 다룰지가 정해져 있음 )
   
   
6. 로직들을 통해 요청 받은 데이터들이 처리되고 브라우저에 응답
   
   
7. 요청들이 브라우저에 응답으로 돌아왔을 때, web page 화면에서 출력

 

❗ 모든 애플리케이션은 client-side와 server-side로 작동하기에 유저가 요청하면 크게 아래의 두 프로그램이 작동함 ⬇️

1. 유저의 입력에 따라 브라우저에서 작동하는 프로그램 ( client-side )
   ➜ 이를 개발하면 front-end
   ➜ 주로 개발을 위해 HTML, CSS, and JavaScript 조합
   ➜ 코드는 브라우저에 의해 분석되어 처리됨
   ➜ 서버와 소통은 HTTP 요청을 통해 이루어짐

2. HTTP 요청에 따라 서버에서 요청을 처리하는 프로그램 ( server-side )
   ➜ 이를 개발하면 back-end
   ➜ 서버사이드에서 실행 가능하고 HTTP 요청에 응답할 수 있는 언어들이 사용

 

✔ 웹 애플리케이션의 요소

1. 유저 인터페이스 요소

➜ 웹 애플리케이션의 기능적인 부분 외의 요소들
Ex. 알림, 환경설정 등

 

2. 구조 요소

➜ 웹 애플리케이션의 기능적인 부분 (전체적인 구조)
➜ 웹 브라우저나 클라이언트, 웹 애플리케이션 서버, 데이터베이스로 이루어져 있음

 

✔ 웹 애플리케이션의 3단계 계층 구조

✔️ Presentation Layer

➜ 유저와 브라우저 등을 이용해 직접적으로 접촉
➜ Web Server, 유저 인터페이스 요소들이 이 계층에 포함

✔️ Application Layer

➜ Business Layer, Business Logic 혹은 Domain Logic 이라고 불리기도 함
➜ 유저의 요청을 브라우저로부터 받아서 처리
➜ Application Server가 이 계층에 포함
➜ 데이터 접근을 위한 경로를 규격화 하는 등의 과정이 이 계층에 작성됨

✔️ Data access layer

➜ Persistence layer 라고도 불림
➜ 애플리케이선의 데이터 저장소에 접근하여 데이터를 불러 오거나 저장을 담당
➜ 이 단계를 통해 Application Layer 의 로직들이 '어느 데이터베이스에 접근해서 데이터를 회수하고 혹은 저장할지'를 더 최적화 가능

✔️ 주 3개 계층에 속하지 않는 요소들
- Cross-cutting
   주로 보안, 통신, 운영 관리등을 위한 요소들

- Third-party integrations
  제 3의 API 서비스를 이용하는 것
   Ex. OAuth 2.0을 이용한 소셜 로그인, PG사를 이용한 결재기능 등

 

✔ 웹 애플리케이션 구현방식

1. Single Page Application

• 웹 페이지에서 일부분만 바꾸고 싶을 때 사용
  Ex. 같은 화면에서 광고 배너만 바뀌는 것
• 페이지가 새로 고침 되지 않고, 요청한 응답을 기다리면서 유저와 페이지의 상호작용이 가능하게 함
• 주로 AJAX, Asynchronous JavaScript, XML가 사용됨
  
  

2. Microservice architecture

• 작고 가벼운 특정한 한가지 기능에 집중한 웹 애플리케이션
• 원하는 언어를 사용해 기능 개발에 유연성을 더 갖게 되고, 개발 과정의 전반적인 속도와 생산성이 향상
  
  

3. Serverless Architectures

• 개발자가 웹 애플리케이션의 서버와 기타 기반 기능들에 대해 외부의 3자인 클라우드 서비스 제공자에게 의탁하는 방식
• 개발자가 서버 걱정 없이 특정 기능 개발에 집중할 수 있게 함

✔️ AJAX ( Asynchronous JavaScript And XMLHttpRequest )
- JS, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하여, SPA(Single Page Application)를 만드는 기술
- 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있음
   Ex. 검색창에 한글자씩 입력할 때마다 아래 추천 검색어가 바뀜

✔️ 핵심 기술
- JS / DOM / Fetch
   ➜ Fetch를 사용하여 페이지 이동이 없어도 서버로부터 필요한 데이터 받아오기 가능
  ( ➜ Fetch가 서버에 요청을 보내고 응답을 받을 때까지 계속해서 페이지를 사용할 수 있게 하는 비동기적인 방식 )


✔️ 장점
- 서버에서 HTML을 완성하여 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 일부만 업데이트하여 웹페이지를 만들 수 있음
- 브라우저에 상관없이 사용 가능
- 빠르고 더 많은 상호작용 가능 ( 일부만 렌더링하기 때문에 )
- 더 작은 대역폭 ( 데이터의 크기가 작음 )

✔️ 단점
- SEO(검색엔진 최적화)에 불리 ( 뼈대만 있고 데이터는 없기 때문에 정보 긁어가기 어려움 )
- 뒤로가기 버튼 문제 ( 이전 상태를 기억하지 않기 때문 )
   ➜이때는 별도로 History API 사용해야함

---

✔️ Fetch
- XHR의 단점을 보완한 새로운 Web API
- XML보다 가볍고 JavaScript와 호환되는 JSON을 사용
   ➜ 오늘날 XHR보다 Fetch를 많이 사용

---

✏️ API(Application Programming Interface)

• 서버가 클라이언트에게 리소스를 잘 활용할 수 있또록 제공하는 인터페이스(interface)

✔️ 인터페이스 (interface)
의사소통이 가능하도록 만들어진 접점

---

✏️ HTTP (HyperText Transfer Protocol)

• 웹 애플리케이션 구현을 위해, 웹 브라우저상에서 클라이언트와 서버간의 통신을 담당하는 프로토콜
• 데이터를 요청하고 요청에 대한 응답을 전송하는 무상태성의 프로토콜
• 월드 와이드 웹(WWW)에 내재된 프로토콜
• 클라이언트에서의 데이터 요청과 서버에서의 요청에 대한 응답을 반복하면서 웹 애플리케이션 작동시킴

 

✔ HTTP의 특징

1. 클라이언트 서버 구조

2. 무상태성 프로토콜 ( Stateless)
➜ 서버가 클라이언트 상태를 보존하지 않음

Ex. 클라이언트가 서버에게 "저녁에 치킨먹자" 라고 말하고 서버가 "그래"라고 대답함. 저녁에 클라이언트가 서버에게 "먹으러 가자" 라고 말하면 서버는 "뭘?"이라고 대답함.
⠀
➜ 모든 요청을 한번에 얘기해야함
( 장점 : 서버가 누구든 클라이언트의 요청을 항상 처리할 수 있음 (서버 확장 편리 ))
⠀
[참고] https://www.inflearn.com/questions/223034

3. 비 연결성 (Connectionless)
➜ 빠른 응답 가능

4. HTTP 메세지

5. 단순함, 확장 가능

[참고] https://hanamon.kr/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-http-http%EB%9E%80-%ED%8A%B9%EC%A7%95-%EB%AC%B4%EC%83%81%ED%83%9C-%EB%B9%84%EC%97%B0%EA%B2%B0%EC%84%B1/

---

✔ HTTP Messages

• HTTP를 이용해 주고받는 메시지
• 클라이언트-서버 사이에서 데이터가 교환되는 방식
• 요청(Requests), 응답(Responses)의 두가지 유형이 있음
• 직접 작성할 필요가 없고, 구성 파일, API, 기타 인터페이스에서 자동으로 완성함

 

✅ Requests / Responses의 공통된 구조

• start line
  ➜ 요청이나 응답의 상태 나타냄
  ➜ 항상 첫 번째 줄에 위치
  ➜ 응답에서는 status line이라고 부름
  
  
• HTTP headers
  ➜ 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
  ➜ start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 함
  
  
• empty line
  ➜ 헤더와 본문을 구분하는 빈 줄
  
  
• body
  ➜ 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서 (페이로드)
  ( 요청과 응답의 유형에 따라 선택적으로 사용 )

✔ 페이로드
- 사용에 있어서 전송되는 데이터

 

1. 요청 (Requests)

• Start line
  1. 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method
     
     
  2. HTTP 버전은 메시지의 다른 구조를 결정
     ( 이를 위해 HTTP 버전을 함께 입력 )
     
     
  3. 요청 대상(일반적으로 URL이나 URI) / 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성
     (이 요청 형식은 HTTP method 마다 다름 ⬇️ )
     

✔️ origin 형식
➜ ?와 쿼리 문자열이 붙는 절대 경로
➜ POST, GET, HEAD, OPTIONS 등의 method와 함께 사용
POST / HTTP 1.1GET /background.png HTTP/1.0HEAD /test.html?query=alibaba HTTP/1.1OPTIONS /anypage.html HTTP/1.0
⠀
✔️ absolute 형식
➜ 완전한 URL 형식
➜ 프록시에 연결하는 경우 대부분 GET method와 함께 사용
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
⠀
✔️ authority 형식
➜ 도메인 이름과 포트 번호로 이루어진 URL의 authority component
➜ HTTP 터널을 구축하는 경우, CONNECT와 함께 사용 가능
CONNECT developer.mozilla.org:80 HTTP/1.1
⠀
✔️ asterisk 형식
➜ OPTIONS 와 함께 별표() 하나로 서버 전체를 표현
OPTIONS * HTTP/1.1

•  

 

• Headers
  
  
  
  ➜ 기본 구조 따름
  ➜ 대소문자 구분 없는 문자열과 콜론(:), 값을 입력
  ➜ 여러 종류의 헤더가 있고, 값은 헤더에 따라 다름
  
  
  1. General headers (Reponses와 동일)
     ➜ 메시지 전체에 적용
     ➜ body를 통해 전송되는 데이터와는 관련이 없는 헤더
     
     
  2. Request headers
     ➜ fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
     ➜ User-Agent, Accept-Type, Accept-Language과 같은 헤더는 요청을 구체화
     ➜ Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약 추가 가능
     
     
  3. Representation headers (Responses와 동일)
     ➜ 이전에는 Entity headers로 불림
     ➜ body에 담긴 리소스의 정보를 포함하는 헤더
     Ex. 콘텐츠 길이, MIME 타입 등
     
     
• Body
  ➜ 요청의 본문은 HTTP messages 구조의 마지막에 위치
  ➜ 모든 요청에 body가 필요한 것은 아님 (선택적)
  ➜ 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않음

Ex. GET, HEAD, DELETE, OPTIONS

➜ 일부 요청은 데이터를 업데이트하기 위해 사용

Ex. POST, PUT

 

1. Single-resource bodies (단일-리소스 본문)
   ➜ 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성
   
   
2. Multiple-resource bodies (다중-리소스 본문)
   ➜ 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지님
   ➜ 보통 HTML form과 관련이 있음

 

2. 응답 (Responses)

• Status line
  HTTP/1.1 404 Not Found.
  1. 현재 프로토콜의 버전(HTTP/1.1)
     ⠀
  2. 상태 코드 - 요청의 결과를 나타냄
     Ex. 200, 302, 404 등
     ⠀
  3. 상태 텍스트 - 상태 코드에 대한 설명
     
     
• Headers
  
  

➜ Request Headers와 동일한 구조
➜ 대소문자 구분 없는 문자열과 콜론(:), 값을 입력
➜ 값은 헤더에 따라 다름

1. General headers (Requests와 동일)
   ➜ 메시지 전체에 적용
   ➜ body를 통해 전송되는 데이터와는 관련없는 헤더
   ⠀
2. Response headers
   ➜ 응답에 대한 부가적인 정보를 갖는 헤더

Ex. 위치 / 서버 자체에 대한 정보(이름, 버전 등) 등

➜ 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공

Ex. Vary, Accept-Ranges

 

1. Representation headers (Requests와 동일)
   ➜ 이전에는 Entity headers로 불림
   ➜ body에 담긴 리소스의 정보를 포함하는 헤더

Ex. 콘텐츠 길이, MIME 타입 등

 

• Body
  ➜ 응답의 본문은 HTTP messages 구조의 마지막에 위치
  ➜ 모든 응답에 body가 필요한 것은 아님
  ➜ 201, 204와 같은 상태 코드를 가지는 응답에는 본문 필요 X
  
  
  1. Single-resource bodies (단일-리소스 본문)
     ➜ 길이가 알려진 단일-리소스 본문 ➜ 두 개의 헤더(Content-Type, Content-Length)로 정의
     ➜ 길이를 모르는 단일 파일로 구성된 단일-리소스 본문 ➜ Transfer-Encoding이 chunked로 설정되어 있고, 파일은 chunk로 나뉘어 인코딩되어 있음
     ⠀
  2. Multiple-resource bodies (다중-리소스 본문)
     ➜ 서로 다른 정보를 담고 있는 body

---

✏️ 쿠키 vs 세션

✔ 쿠키

• 웹 애플리케이션을 사용하는 유저의 정보를 클라이언트에 보관하고, 다음 접속부터는 유저의 정보를 클라이언트가 서버로 보내서 유저를 서버가 식별하게 하는 역할
  ( 쿠키에 담긴 내용으로 웹 애플리케이션에 유저가 설정했던 항목들에 대해 저장을 해서 다음에 이어서 같은 방식으로 작동하게 도와줌 )

 

✔ 세션

• 서버에 Session-Id 라는 고유 아이디를 할당해서 유저 식별하는 역할
  단순하고 유출이 되면 안되는 정보는 서버에서 관리를 하면서 세션 ID와 매칭해서 저장해 관리
  주로 사용되는 방법 ➜ 세션정보는 쿠키에서 관리하고, 실제 매칭되는 값들은 서버 측에서 관리

---

✏️ SSR (Server Side Rendering)

• 서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에게 전달하는 방식

Ex. 배민에서 음식 주문했을 때 조리가 완성된 상태로 보내는 것

✔ 렌더링
- 2차원에 표시된 물체를 3차원에 표시된 물체처럼 보이게 하는 것

• 페이지 자체가 새로고침되어 나타남 !
• 웹 에이전시 / SI 쪽에서 많이 사용

 

✔ SSR 단계

1. 브라우저가 서버의 URI로 GET 요청 보냄
2. 서버가 정해진 웹 페이지 파일을 브라우저로 전송
3. 섯버의 웹 페이지가 브라우저에 도착하여 완전히 렌더링

 

✔ SSR이 사용되는 경우

• SEO(Search Engine Optimization(검색엔진 최적화))가 우선순위인 경우
• 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우 ( 단일 파일의 용량이 적기 때문 )
• 웹 페이지가 사용자와 상호작용이 적은 경우

Ex. 네이버 블로그, 뉴욕 타임즈
➜ 최대한 검색엔진에 많이 노출되는 게 유리하기 때문

 

✔ SSR의 단점

• 애플리케이션 유지비용이 높음 ( 자원이용이 서버에 집중되기 때문 )
• 일부 서드파티 자바스크립트 라이브러리의 경우 서버사이드 렌더링이 불가능할 수 있음

 

✏️ CSR (Client Side Rendering)

• 렌더링이 클라이언트 쪽에서 일어남
• 서버가 요청을 받고 클라리언트에게 HTML과 JS 보내주면 클라이언트가 그것을 받아 렌더링 시작

Ex. 배민에서 음식 주문했을 때 조리되어있지 않은 밀키트만 오는 것

• 화면이 새로고침되어 돌지 않고, 같은 화면에 데이터만 바뀜 !

 

✔ CSR 단계

1. 브라우저가 서버로 요청 보냄
2. 서버가 웹페이지의 골격이 될 단일 페이지 + JS를 클라이언트에게 보냄
3. 클라이언트가 웹페이지 받으면, 브라우저에서 JS 파일이 웹페이지를 완전히 렌더링 된 페이지로 바꿈

💡 웹 페이지에 필요한 내용이 DB에 저장된 데이터인 경우,
API 요청으로 DB에 저장된 데이터를 가져와 웹페이지에 렌더링

---

💡 브라우저가 다른 경로로 이동한 경우,
CRS는 SSR과 다르게, 서버가 웹 페이지를 다시 보내지 않음
브라우저가 원래 요청했던 경로에 따라 페이지를 다시 렌더링
(앞서 전달받은 파일과 동일한 파일)

 

✔ CSR이 사용되는 경우

• SEO(검색엔진 최적화)가 우선순위가 아닌 경우
• 사이트에 풍부한 상호 작용이 있는 경우 ( 라우팅이 빠르기 때문 )
• 웹 애플리케이션을 제작하는 경우

Ex. 예약 사이트
➜ SPA(Single Page Application)를 기반으로 화면의 일부만 받아온 데이터로 변경해 주기 때문

 

✔ CSR의 단점

• 느린 렌더링 속도 ( 모든 렌더링의 부하가 클라이언트 쪽에 집중되기 때문 )
• search engine bots 와 상성이 안좋음
  ➜ JS가 렌더링해야 하는 정보들은 Google 과 같은 search engine index에 포함이 안될 가능성이 매우 높dma

---

🌈 느낀점

휴 많은 내용이었지만 그래도 잘 끝냈다
블로그에 정리하면서 머릿속에서도 흐름이 많이 잡힌 느낌!
확실히 정리를 하니까 좋다

 

( 본 게시물은 2022/10/03에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90