jun-wiki

View My GitHub Profile

Posts (Latest 10 updated) :
Read all
Contents:
  1. Web to MSA
    1. HTTP
      1. Http 1.1
      2. Http 2.0
    2. Common Gateway Interface (CGI)
    3. FastCGI
    4. 3 layer architecture
    5. Embedded web server
    6. Restful API
    7. API gateway
    8. Load balancer or reverse proxy
    9. Content Delivery Service (CDN)
    10. 모노리식 아키텍처 Monolithic architecture
    11. Microservice architecture

오늘 특강이다

이번주차(웹서버) 관련 강의 말이다

하는 이유는 여럿 있겠지만 정글 감사 내려온다고 해서 살짝 보여주기 식이다


아니란다

원래 매주 운영진 티타임 갖던걸 변형해서 주제를 가지고 이야기하는 시간 갖는거라고 한다

주제 없이 하니까 할 이야기도 없는데 매주 교육생들 얼굴만 보고 할 얘기가 없었다 한다


강의 시작했따


Web to MSA

백엔드, 프론트엔드 개발자란 말듣고 충격이셨다고 한다

웹개발자면 웹개발자지 뭘 그걸 나누냐고 말이다 (※다소오역※)


개발자는 전직 가능한게 잔뜩 있으니 백엔드, 프론트엔드로 나누지 마라

Q. 그럼 웹하지 말아야 하나?

A. ㅈㄹㄴ 웹은 기본이다


네트워크가 기본인 이유

  • 데이터 양 상승
    • 머신 하나로 처리 불가

    • 머신 늘림

    • 머신끼리 연결해줘야 함

    • 네트워크 필요

이거 알고 가란다



HTTP

HTTP는 언어다
딱 두가지만 정해진

  • 요청
  • 응답


웹서버를 통해 데이터만 받아오고
클라이언트에서 이를 볼 수 있게 렌더링

추가로 이미지 정보 같은 거 보내면 이에 대해 추가요청하여 정보 얻어옴


스테이트 풀: 한번 연결시 끊길때까지 계속 데이터 전송 가능

스테이트 리스: 보낼때마다 주소부터 내용 다 적어야 함

각각 장단점은 뻔하니 넘어가겠다


UDP가 신뢰성 없고 TCP가 신뢰성 있는 이유도 나왔다

UDP는 데이터를 끊어 보내서 뭐가 먼저 도착할지 제대로 알 수 없어 순서 바뀔 수 있다

그러나 TCP는 데이터를 이어 보내서 순서가 보장된다


HTTP는 TCP로 데이터를 보내되 스테이트 리스 방식이라고 한다


문제점은 정보 받았을때 또 다른 정보 (예: 이미지 등)를 부르려면 또 요청 보내고 응답에서 또 필요한 정보가 있는게 반복되면 시간이 상당히 늘어난다는 거다

여기까지가 Http 1.0 버전이었다



Http 1.1

1.1에는 여러 기능이 추가되었지만 일단 기존의 스테이트 리스를 개선했다

Keep-alive 라는 방식으로 기존 연결을 유지해서 TCP를 덜 열게 한다

커넥션을 유지해서 불러오는 TCP양을 줄인거라고 한다

그리고 이게 지금 크롬 방식이라고 한다


Http 2.0

대망의 2.0이다

물론 아직까지 대부분 1.1 쓰고 있다

멀티플렉싱이라는 기술이 도입되었다는데

각 html에서 요구하는 사항을 한번에 불러오고 이를 해석한다고 한다

심지어 html읽고 미리미리 필요한 정보들까지 보내준다 (이미지 같은 거)

아직까지도 잘 안쓰이는 최-신 방식이다

물론 나온지는 10년 넘었다


그리고 이번 주차에는 1.0 기반으로 개발한단다

구닥다리 기술을 써야 한다니…


Common Gateway Interface (CGI)

일방적으로 정보를 받는게 아닌 정보를 보내기 위한 방법으로
표준 입출력 방식으로 통합해 이를 관리하는 방식이라고 한다

그치만 요청이 많아지면 그만큼 실행이 늘어나고 텍스트라 더 느려지기까지 한다


FastCGI

데이터 수송신은 바이너리로해 속도 높이고 중간에 쓸때 변형

따로 추가 서술


3 layer architecture

예전의 개발환경에서는 웹말고 앱썼는데 간단하게 숫자 하나 바꾸려 해도 전부 배포해줘야 해서 지랄 났다고 한다

비지니스 로직[^]에서 특히 문제

그러다 웹이 트렌드가 되며

어플리케이션 서버 같은 걸로 이러한 것을 처리


티어: 물리적으로 분할

레이어:

Embedded web server

서버에서 로직 처리하려니 너무 무거워져
클라에서 처리하게 함
-> nodejs

GRPC라는 것도 있다고 한다

Restful API

모듈 호출할때 사용할 표준화된 규칙

API gateway

필요 API찾고 사용자에 따라 접근 제한 걸고 한다

디렉토리 관리용

웹서버의 일종이라고 한다

웹 프록시, 리버스 프록시: API gateway가 리버스 프록시의 하위 개념 (라우터 역할, 부하 분산 등 다양)

포워드 프록시: 나갈 때 관문 역할 (감시 역할)

Load balancer or reverse proxy

Content Delivery Service (CDN)

망사업자, ISP같은 곳에 서버에 연결해 놓으면

그 서버에서 바로 데이터 송수신

상위 서버로 이동 안해도 되기에 비용 ↓

이거 해주는게 리버스 프록시고 이번주차에서 리버스 프록시 구현

모노리식 아키텍처 Monolithic architecture

컴포넌트끼리 밀접할시 일부 수정시 전부 수정해야함

+ 테스트

Microservice architecture

함수나 기능들은 각자 하나의 동작을 해야한다 (독립성 보장)

부분 수정하더라도 다른 곳에 변화를 주지 않기 위해

(배포 줄이려고)

독립적으로 기능을 작성하게 되며 각각 필요한 언어, 프레임 들을 정해줄 수 있음