[Part1-CH1] Network 기본

Back end Chain·2022년 10월 26일
BitcoinCH1. Blockchain 1.0 - BitcoinPart1. 블록체인의 모든 것블록체인패스트캠퍼스한 번에 끝내는 블록체인 개발 A to Z
0

패스트캠퍼스, 한 번에 끝내는 블록체인 개발 A to Z

목록 보기
5/17
  • 네트워크에 대한 배경 이해와 기본지식이 부족. 비트코인이 분산화된 네트워크.
  • Client-Server
    • 요청을 보내는 Client → Gateway(도메인에 해당하는 IP, 라우터 역할) → Server → DB
      • single point of failer 단일점 공격. → 라우터역할을 하는 Gateway가 한개일 때 공격 당하면 모든 서버에 연결 불가.
  • P2P Network
    • 서버 한개가 죽더라도 연결. 모든 서버가 동일 한 정보를 가지고 있음.
    • Bitcoin과 torrent.
  • Client-Server VS P2P Network
    • Client-Server
      • 서버 및 클라이언트 서버에 연결
      • 서비스에 대한 클라이언트 요청에 대해 서버가 응답하는 형식
      • 정보 공유 (한개의 DB를 사용)
      • 데이터는 중앙 집중식 서버에 저장
      • 여러 클라이언트가 동시에 서비스 요청 시 서비스 병목 현상 발생 가능
        • 요청이 집중 되었을 때 DDOS같은 공격 취약.
      • 구현 비용이 비싸다
        • 하나의 운영 주체가 운영하기 때문.
      • 안정적이며 확장 가능
        • gateway나 server를 scale out 해서 확장 할 수 있음.
    • P2P Network
      • 클라이언트와 서버 규별 없이 활용
      • 각 노드가 서비스를 요청하고 제공할 수 있음
      • 연결성(하나의 노드가 끊기더라도 다른 노드에 연결할 수 있음)
      • 각 노드가 자체 데이터 보유
      • 분산 된 서버에 의해 제공되므로 병목 현상 발생 가능성이 낮음.
      • 구현 비용이 저렴하다.
      • 노드의 수가 증가하면 문제 발생 가능성 증가
    • TCP
      • 서버와 Client 간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜
      • 데이터 전송을 위한 연결을 만드는 연결지향 프로토콜
      • 데이터 전송 과정에서 손실이나 순서가 바뀌는 경우 교정 및 순서 재조합 지원
      • IPC(Inter Process Communication)에서 Socket 통신 방법으로 보통 지원
        • 이터리움의 통신 방법에 IPC, HTTP, Web socket
      • 7계층과 TCP
        • Application 계층의 HTTP.
        • Transport 계층의 TCP
          • TCP는 요청을 보내고 수신을 했는지 응답을 보내줌. 안정
          • UDP는 응답을 보내주지 않음. 빠름
  • HTTP
    • 서버와 Client간에 데이터를 송수신을 위한 프로토콜
    • Allication Layer 레벨 Protocol로 TCP/IP위에서 동작
    • Client 요청(Request)에 따라 서버가 응답(Response) 제공
    • 요청 Method (http:// 로 시작하는 URL)
      • GET : 존재하는 데이터에 대한 조회 요청
      • POST : 새로운 데이터에 대한 생성 요청
      • PUT : 존재하는 데이터에 대한 수정 요청
      • DELETE : 존재하는 데이터에 대한 삭제 요청
      • HEAD : 서버 헤더 정보 획득 요청
      • OPTIONS : 서버 옵션 확인 요청
    • http:// wallet에서 node로 요청을 보낼때 가장 많이 사용.
  • Http Version
    • http1.0
      • 하나의 요청을 보내고 응답이 와야 다음 요청을 보낼 수 있음.
    • http1.1
      • 요청을 보내도 응답이 오지 않아도 다음 요청을 보낼 수 있음. 하지만 응답은 이전 응답이 보내져야 다음 응답을 보낼수 있음.
    • http2.0(2015년)
      • 멀티 플렉스 스트림을 지원. 순서와 상관없이 요청과 응답이 오갈 수 있음. 바이너리 형식으로 전송 속도를 개선.
      • Client가 요청이 있어야 응답을 보낼수 있었지만, 요청이 없어도 응답을 보낼 수 있음.
  • Web Socket
    • 실시간 양방향 통신 지원
    • Application Layer 레벨 Protocol로 TCP/IP 위에서 동작
    • 한번 연결이 수립되면 클라이언트와 서버 자유롭게 데이터 전송 가능
    • 실시간 시세 데이터, 채팅 솔루션 등에 사용
    • 과정 (Client ↔ Server)
      • Web socket 연결 요청(HTTP) →
      • ← Web socket 연결 완료 (HTTP) 상태 101
      • ← 데이터 전달 →
      • ← Web socker Close →
    • websocket을 연결하는 주소만 존재하고 데이터를 보내는 주소가 따로 존재하지 않고 비동기나 메시지로 데이터만 전달.
    • 이더리움에서 Websocket 지원(tranaction, 이벤트 발생 등)
  • RPC
    • RPC(Remote Procedure Call)이란 원격 서버의 함수를 호출 할 수 있는 통신 기술을 뜻한다.
    • IDL(Interface Definition Language)을 사용하여 호출 규약을 정의하고 이를 통해 Stub 코드를 생성한다.
    • Program에서는 Stub을 Call 함으로서 개발자는 네트워크 대한 지식 없이 우너격 함수 호출이 가능하다.
    • Program에서 Stub을 호출 → IDL ← Stub에서 Program을 호출
    • 이때 Stub과 Stub간의 통신을 RPC라고 칭함.
    • HTTP 보다 먼저 나왔지만 최근의 프로토콜들이 gRPC를 사용하기 때문.
  • gRPC (하이퍼레저에서 사용하기도.)
    • gRPC
      • gRPC(google Remote Procedure Call)은 구글에서 개발한 RPC 통신방법이다. HTTP 2.0 기반으로 양방향 Streaming 데이터 처리가 가능하다. MSA 구조의 서비스에서 활용된다.
    • protobuf
      • gRPC의 IDL로 proto buffer의 줄임이다. 프로그램상에서 이를 사용하기 위해서는 .proto stub이 생성되어야 한다. JSON, XML 통신보다 데이터 전송 크기가 작고 성능이 빠르다.
    • 지원언어
      • Protobuf의 경우 version2, version3 2가지가 존재하고, proto 3가 proto 2의 간략한 버전이다. Proto 3가 지원하는 언어가 더 많기 때문에, 일반적으로 proto 3를 사용한다.
  • gRPC vs HTTP API

    • 계약

      • .Proto 파일 생성 필수 vs 실행을 위한 파일 불필요

    • 프로토콜

      • HTTP 2.0 vs HTTP

    • Payload(주고 받는 데이터)

      • Protobuf(바이트로 복호화 필요) vs JSON, Text

    • 스트리밍

      • Client, Server, 양방향 vs Client, Server

    • 브라우저 지원

      • 미지원(브라우저 월렛 등) vs 지원

    • 보안
      - TLS vs TLS

      ⇒ 성능을 중요시 여기는 서비스에서 사용, Client에서는 많이 사용 x

profile
Back end Chain
"프로그래밍은 저의 상상을 실현 시킬 수 있는 유일한 도구입니다."
이전 포스트

[Part1-CH1] ECDSA와 Hash Algorithm

다음 포스트

[Part1-CH1] P2P Network

0개의 댓글