Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2주차 세미나 과제 #8

Open
sansan20535 opened this issue Oct 26, 2024 · 0 comments
Open

2주차 세미나 과제 #8

sansan20535 opened this issue Oct 26, 2024 · 0 comments
Labels
documentation Improvements or additions to documentation

Comments

@sansan20535
Copy link
Collaborator

⭐️ What is Switch? ⭐️


💡L4 Switch, L7 Switch가 무엇인지 조사해보세요. 💡

💡hint : 비용, 역할, 알 수 있는 정보💡


🧐 스위치(Switch)란?

✅ 컴퓨터 네트워크 상에서 `데이터를 전송하고 연결`하는 장비

✅ OSI 모델의 2계층인 데이터 링크(Datalink Layer) 계층에서 동작  

✅ 여러 개의 데이터 패킷을 전송하며 데이터의 흐름 제어

OSI (Open Systems Interconnection Reference Model)
컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명한 것
⇒ OSI 7계층 : 네트워크에서 통신이 일어나는 과정을 7단계
⇒ Application Layer, Presentations Layer, Session Layer, Transport Layer, Network Layer, Datalink Layer, Physical Layer

vs 라우터(Router)
⇒ 목적지로 가는 적합한 경로를 찾아주는 것
⇒ L3(Network Layer)에서 동작

🧐 로드 밸런서(Load Balancer)란?

✅ 네트워크나 서버에 분산된 작업 부하를 공평하게 분배하는 장치

✅ 네트워크 장치에 들어오는 요청을 받아 해당 요청을 처리할 서버로 전달 

👍 장점

1️⃣ 부하 분산 : 서버에 들어오는 트래픽을 여러 서버로 균등하게 분산하여 각 서버의 부하를 분담. 서버 과부하 방지 및 시스템 성능 향상

2️⃣ 고가용성 : 한 대의 서버에 장애가 발생해도 다른 서버로 요청 전달

3️⃣ 확장성 : 새로운 서버 추가 및 기존 서버 제거 시 트래픽을 새로운 서버로 분배

❗️이러한 로드 밸런서의 역할을 하는 것이 L4 Switch & L7 Switch다.❗️

🧐 L4 Switch란?

✅ Transport Layer에서 동작

✅ TCP/UDP 패킷의 정보(포트)와 IP를 분석하고 전송방향 처리

✅ 패킷의 송수신 모니터링 및 트래픽 제어

🧐 L7 Switch란?

✅ Application Layer에서 동작

✅ TCP/UDP 패킷의 정보(포트) 및 IP뿐만 아니라 페이로드(payload)까지 분석. 즉, 패킷의 내용들(URL, 캐시, 쿠키, HTTP 헤더 등의 실제 데이터 및 컨텐츠) 분석을 통해 전송방향 처리

✅ 애플리케이션 수준에서 보안기능 제공(방화벽 등)

🧐 L4 Switch vs L7 Switch

❓더 많은 기능을 제공하는 L7 Switch만 사용하면 되는 것이 아닌가?

⇒ 그렇지 않음. 단순한 서버 부하분산 목적만 있다면 L7 Switch의 HTTP헤더 해석은 불필요한 리소스 소모
⇒ 불필요한 리소스 소모를 줄이고 각자의 역할에만 집중할 수 있도록 Layer가 분리되어있는 것


⭐️ What is RESTful? ⭐️


💡REST API 에 대해 조사해 와인잔조원들과 논의해보세요.💡

💡본인이 생각하는 클라이언트가 좋아할만한 API path가 뭔지를 고민해보세요💡

💡정답은 없습니다. 밖에서 들은 혹은 그렇다 하드라 말고 본인이 생각하는 restful을 정의해보세요💡


🧐 RESTful API란?

✅ 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스

🧐 API(Application Programming Interface)란?

✅ 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙

✅ 규칙에 따라 요청 및 응답 수행

✅ API는 클라이언트(정보에 접근하려는 사용자)와 리소스(클라이언트에게 제공하는 정보) 사이의 게이트

🧐 REST(Representational State Transfer)란?

✅ API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처

🧐 REST 아키텍처 스타일의 원칙

1️⃣ 균일한 인터페이스

    ✅ 서버가 표준 형식으로 정보를 전송

    ✅ 아키텍처 조건

i) 요청은 리소스를 식별. 균일한 리소스 식별자 사용

ii) 클라이언트는 원하는 경우 리소스를 수정하거나 삭제하기에 충분한 정보를 리소스 표현에서 가지고 있어야 함.

iii) 클라이언트는 리소스를 추가로 처리하는 방법에 대한 정보 수신

iiii) 클라이언트는 작업을 완료하는 데 필요한 다른 모든 관련 리소스에 대한 정보 수신

2️⃣ 무상태

    ✅ 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료

3️⃣ 계층화 시스템

    ✅ 클라이언트는 클라이언트와 서버 사이의 다른 승인된 중개자에게 연결할 수 있으며 여전히 서버로부터도 응답

    ✅ 서버는 요청을 다른 서버로 전달 가능

    ✅ 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계

4️⃣ 캐시 가능성

    ✅ 서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장

5️⃣ 온디맨드 코드

    ✅ 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정

🧐 좋은 RESTful API란?

1️⃣ 리소스 중심 (복수형)

    ✅ ex 

    ⇒ ‘일기’를 조회하는 API

    ⇒ 👍 : /diaries
    ⇒ ❌ : /get/diaries, /find-diaries

2️⃣ 메소드를 통한 표현

    ✅ ex

    ⇒ 일기 삭제 API : [DELETE] /diaries

    ⇒ 일기 조회 API : [GET] /diaries

3️⃣ 리소스가 여러 개일 경우 API에 중심이 되는 리소스 기준

    ✅ ex

    ⇒ ‘게시판’의 ‘키워드’들을 모두 조회하는 API

    ⇒ /titles/keywords
@sansan20535 sansan20535 added the documentation Improvements or additions to documentation label Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

1 participant