.png&blockId=3197e115-ee0d-4d9c-9f5d-4b57cb28634e)
→ 아니요, 잘 모르겠어요,,, 
핵심
gRPC는 google사에서 개발한
서비스 간의 고성능 통신에 사용되는 오픈 소스 원격 프로시저 호출(RPC) 프레임워크
RPC 기술의 핵심 아이디어는 원격 서버에서 함수/메서드를 호출할 수 있게 하는 것이며
그 프레임워크인 gRPC은 직렬화 및 통신을 위한 인터페이스 정의 언어로 프로토콜 버퍼를 사용하기 때문에 (빠르고) 서로 다른 언어로 작성된 서비스를 연결하는데 효율적이며
양방향 통신을 지원하는 HTTP/2를 기반
이런 장점들을 가지고 있어, 마이크로서비스 아키텍처, 분산 시스템 및 클라우드 네이티브 애플리케이션에서 많이 사용하고 있는 추세
RPC(Remote Procedure Call)
•
네트워크로 연결된 서버 상의 프로시저(함수, 메서드 등)를 원격으로 호출할 수 있는 기능
•
통신이나 call 방식에 신경쓰지 않고 원격지의 자원을 내 것처럼 사용 가능
== 한 프로그램이 네트워크의 세부 정보를 이해하지 않고도 네트워크 안의 다른 컴퓨터에 있는 프로그램에서 서비스를 요청하는 프로토콜
•
IDL(Interface Definication Language) 기반으로 다양한 언어를 가진 환경에서도 쉽게 확장이 가능
•
인터페이스 협업에도 용이하다는 장점
스텁 Stub
•
서버와 클라이언트는 서로 다른 주소 공간을 사용 하므로, 함수 호출에 사용된 매개 변수를 꼭 변환해줘야 한다.
•
안그러면 메모리 매개 변수에 대한 포인터가 다른 데이터를 가리키게 된다.
•
이 변환을 담당하는게 스텁
gRPC의 주요 특징
protocol buffer를 IDL(인터페이스 정의 언어)로 사용
protocol buffer (vs json 객체 직렬화 ) 사용 시 장점 ?→ 빠르다!
1. 데이터 크기가 작음
JSON 포맷 - 82byte
protocol buffer - 33byte
2. 파싱을 할 필요가 없다.
•
JSON포맷으로 온 데이터는 다시 객체로 파싱해서 객체로 사용
•
프로토콜 버퍼를 쓰면 바이트가 오면 그 바이트 그대로 메모리에 써버리고 객체 레퍼런스가 가리켜 사용.
•
별도의 파싱이 필요가 없는 것이다.
•
그렇기 때문에 또 빠르다.
HTTP/2 채택
HTTP/2 프로토콜 장점
•
기존 응답 요청 구조와 함께 HTTP 2의 양방향 통신 기능을 사용
•
한 connection으로 동시에 여러 개 메시지를 주고 받으며, header를 압축하여 중복 제거 후 전달하기에 version1에 비해 훨씬 효율적
•
필요 시 클라이언트 요청 없이도 서버가 리소스를 전달할 수도 있기 때문에 클라이언트 요청 최소화 가능
HTTP 1.1 vs 2
•
HTTP 1.1 - 여러 클라이언트가 여러 요청을 받으면 하나씩 제공
•
HTTP 2 - 멀티플렉싱을 허용하므로 여러 요청과 응답을 동시에 처리 가능 (서버와 클라이언트 간의 느슨한 결합을 허용)
gRPC 구조
참고
