참고
gRPC의 등장배경
1. Server-Client Model
NOTE
왜 네트워크 통신이 중요해졌는가?
•
PC의 개념이 없던 시절 프로그램은 하나의 메인 프레임에서 동작하는 ‘모놀리틱’구조로 설계되었다.
•
이때까지만해도 모든 기능들이 한 공간에서 구동되다보니 네트워크 통신이 별로 중요하지 않았다.
왼쪽 → 메인프레임 (대규모 서버용 컴퓨터)
오른쪽 → 워크스테이션 (전문적 작업을 위한 개인용 컴퓨터)
•
기술 발전에 따라 소형 컴퓨터 장비들이 등장하게 되고, 기업 입장에서 매우 고가인 메인 프레임워크를 비교적 저가의 워크스테이션 서버로 대체하고 싶어했다.
•
하지만 메인프레임의 초고사양 서비스를 워크스테이션에 그대로 제공하기엔 무리가 있었다.
•
이 때문에 메인프레임의 기능을 여러 워크스테이션 서버로 분산시키고, 네트워크로 연결하는 방식을 채택했다!
⇒ Server-Client Model
•
서버간 혹은 서버-개인PC간 네트워크 연결 통신이 중요해지면서 OSI 7계층, TCP/IP등 네트워크 구조가 정의되고 발전한다.
2. IPC(Inter Process Communication)
NOTE
프로세스들은 기본적으로 상호독립적이고, 메모리를 공유하지 않기 때문에 서로 간섭하지 않는다.
⇒ 필요에 따라 정보를 교환할때의 방법론이 IPC
•
IPC 기법에는 공유 메모리, PIPE, 메시지 큐, Socket등이 있다.
Socket
•
OSI 7계층의 7L에서 4L의 TCP/UDP를 이용하기위한 수단이다.
•
목적지와의 통신이 컴퓨터 내부가 아니라 온라인 범위에서 이루어진다.
•
소켓은 대부분의 언어에서 API 형태로 제공하는 편리함 떄문에 많이 사용된다.
•
하지만 직접 구현해야 하므로, 통신 관련 장애를 처리하기 어려워진다.
RPC
•
이름 그대로 네트워크로 연결된 서버 상의 프로시저를 원격으로 호출할 수 있는 기능이다!
•
RPC의 구현이 어렵고, 지원 기능이 한정적이라는 문제점이 있다.
•
이로인해 데이터 통신을 우리에게 익숙한 Web을 활용해보려는 시도로 이어졌고, Rest가 이 자리를 차지한다.
Rest
•
HTTP/1.1 기반으로 URI를 통해 모든 자원을 명시하고 HTTP Method를 통해 처리하는 구조이다.
•
사용하기 편리했지만, Parameter와 응답 값이 명시적이지 않고 HTTP Method의 형태가 제한적이다.
번외(데이터 포맷)
•
XML
◦
tag기반이라 높은 확장성이 있지만, 복잡하고 비효율적인 구조탓에 속도가 느리다.
•
JSON
◦
key-value 구조로 복잡함을 해결
◦
제공되는 자료형의 한계로 추가 형변환이 필요한 경우가 많다.
•
두 타입 모두 String기반이라 읽기는 편하지만, 이후 직렬화가 필요하다.
gRPC (google Remote Procedure Call)
NOTE
gRPC ⇒ Google에서 만든 RPC!
•
이전까지는 RPC 기능을 지원하지 않고, 메세지(JSON 등)을 직렬화할 수 있는 프레임워크인 PB(프로토콜 버퍼)만을 제공했다.
•
PB기반 직렬화에 HTTP/2를 결합하여 RPC 프레임워크를 탄생시킴!
HTTP 버전 발전
NOTE
HTTP 버전별로 통신차이가 있다.
HTTP 1.0
•
비영구적(non-persistent) 연결
◦
클라이언트가 각각의 HTTP 요청에 대해 새로운 TCP 연결을 생성한다.
◦
응답이 끝나면 연결을 종료한다.
HTTP 1.1
•
영구적(Persistent) 연결
◦
1.0과 달리 하나의 TCP 연결로 여러 요청에 재사용할 수 있게 되었다.
•
파이프라이닝
클라이언트가 요청을하고 응답을 기다리지않고 다시 요청한다. (단 요청 순서대로 응답을 받음)
◦
한 번에 여러 요청을 보내고, 서버는 그 순서대로 응답을 보낸다.
◦
하지만 이 방식은 Head-of-line blocking 문제를 발생시킨다. (처음 요청이 지연되면, 이후 요청도 지연됨)
HTTP 2
- 1.1 → 하나의 커넥션 하나의 스트림
- 2 → 하나의 커넥션 여러 스트
•
멀티플렉싱
◦
여러개의 요청과 응답 메시지를 동시에 같은 연결을 통해 보낼 수 있다. (1.1의 Head-of-line blocking 문제해결)
◦
요청과 응답이 Frame 단위로 나누어 전송되고, TCP를 통해 전송된다.
◦
각 Frame은 StreamID를 가지고 있으며, 이후 이 ID를 토대로 조합된다.
•
서버 푸쉬
◦
서버가 클라이언트의 요청에 응답하는 동시에 추가 리소스를 클라이언트에게 푸시할 수 있다.
◦
ex) 클라이언트가 웹페이지 요청, 서버는 그 웹페이지와 함께 CSS, JS도 함께 보낼 수 있다.
•
Header Compression
◦
1.1에서 많은 양의 중복된 헤더 정보가 전송되었다.
◦
2에서는 HPACK의 압축형식을 통해 해결
HTTP 3.0
•
TCP 대신 UDP 기반의 QUIC 프로토콜을 사용한다.
•
QUIC는 TCP의 신뢰성과 순서유지 특성을 지니면서, 연결 설정 시간을 단축한다.
ProtoBuf(프로토콜 버퍼)
NOTE
google에서 개발한 구조화된 데이터를 직렬화하는 기법!
ProtoBuf vs Json 이미지
•
json(text기반)
◦
82byte
•
protocol buffer(필드 번호, 필드 유형을 1byte로 받음)
◦
33byte
Proto File
NOTE
google의 프로토콜 버퍼라는 바이너리 메시지 형식에서 사용되는 파일!
syntax = "proto3";
message SearchRequest {
string query = 1;
int32 page_number = 2;
int32 result_per_page = 3;
}
Java
복사
간단한 예시
•
각 필드는 자신의 데이터 타입과 필드 번호를 가진다.
•
이러한 정의를 바탕으로 ProtoBuf 컴파일러가 해당 언어에 맞는 코드 생성