protobuf 대 gRPC

protobuf와 gRPC를 이해하고 어떻게 둘 다 사용할 수 있는지 이해하려고합니다. 다음 사항을 이해하도록 도와 주시겠습니까?

• OSI 모델을 고려할 때 예를 들어 레이어 4의 Protobuf는 어디에 있습니까?
• 메시지 전송을 통해 "흐름"이 어떻습니까? gRPC는 protobuf가 놓친 작업을 수행하는 것은 무엇입니까?
• 발신자가 protobuf를 사용하는 경우 서버에서 gRPC를 사용할 수 있나요? 아니면 gRPC가 gRPC 클라이언트 만 전달할 수있는 항목을 추가하나요?
• gRPC가 동기식 및 비동기식 통신을 가능하게 할 수 있다면 Protobuf는 마샬링을위한 것이므로 상태 (참 또는 거짓)와 아무 관련이 없습니다.
• REST 또는 GraphQL 대신 통신하는 프런트 엔드 애플리케이션에서 gRPC를 사용할 수 있나요?

나는 이미 알고 있거나 알고 있다고 가정합니다.

Protobuf

• 데이터 교환을위한 바이너리 프로토콜
• Google에서 설계
• 클라이언트 및 서버에서 생성 된 "Struct"와 같은 설명을 사용하여 메시지를 un-/-marshall

gRPC

• protobuf (v3) 사용
• 다시 Google에서
• RPC 호출을위한 프레임 워크
• HTTP / 2도 사용합니다.
• 동기 및 비동기 통신 가능

나는 이미 기술을 사용하는 누군가에게는 쉬운 질문이라고 다시 가정합니다. 인내심을 갖고 도와 주셔서 감사합니다. 또한 기술에 대한 네트워크 심층 분석에 대해 정말 감사 할 것입니다.

프로토콜 버퍼 는 인터페이스 정의 언어 및 직렬화 라이브러리입니다.

• IDL에서 데이터 구조를 정의합니다. 즉, 사용하려는 데이터 개체를 설명합니다.
• 예를 들어 디스크에서 데이터 쓰기 / 읽기 등 데이터 개체를 바이너리간에 변환하는 루틴을 제공합니다.

gRPC 는 동일한 IDL을 사용하지만 데이터 유형으로 Protobuf 데이터 구조를 사용하여 원격 프로 시저 호출 메소드 서명을 정의 할 수있는 "rpc"구문을 추가합니다.

• 데이터 구조를 정의합니다.
• rpc 메서드 정의를 추가합니다.
• 네트워크를 통해 메소드 서명을 제공하고 호출하는 코드를 제공합니다.
• 필요한 경우 Protobuf를 사용하여 데이터 개체를 수동으로 직렬화 할 수 있습니다.

질문에 대한 답변 :

1. gRPC는 레이어 5, 6, 7에서 작동합니다. Protobuf는 레이어 6에서 작동합니다.
2. "메시지 전송"이라고 말하면 Protobuf는 전송 자체와 관련이 없습니다. 데이터 전송의 양쪽 끝에서만 작동하여 바이트를 객체로 바꿉니다.
3. 기본적으로 gRPC를 사용한다는 것은 Protobuf를 사용 한다는 의미 입니다. gRPC와 상호 운용하기 위해 gRPC가 아닌 Protobuf를 사용하는 자체 클라이언트를 작성하거나 gRPC에 다른 직렬 변환기를 플러그인 할 수 있지만 gRPC를 사용하는 것이 더 쉬울 것입니다.
4. 진실
5. 그래 넌 할수있어

실제로 gRPC와 Protobuf는 완전히 다른 두 가지입니다. 단순화하겠습니다.

• gRPC는 클라이언트와 서버가 상호 작용할 수있는 방식을 관리합니다 (REST API를 사용하는 웹 클라이언트 / 서버처럼).
• protobuf는 JSON과 같은 직렬화 / 역 직렬화 도구입니다.

gRPC에는 서버 측과 클라이언트 측의 두 가지 측면이 있으며 서버에 전화를 걸 수 있습니다. 서버는 RPC (즉, 원격으로 호출 할 수있는 함수)를 노출합니다. 그리고 거기에는 많은 옵션이 있습니다 : 통신 보안 (TLS 사용), 인증 계층 추가 (인터셉터 사용), ...

클라이언트 / 서버 일 필요가없는 모든 프로그램 내에서 protobuf를 사용할 수 있습니다. 데이터를 교환해야하고 데이터를 강력하게 입력하려면 protobuf가 좋은 옵션입니다 (빠르고 신뢰할 수 있음).

즉, 두 가지를 결합하여 멋진 클라이언트 / 서버 시스템을 구축 할 수 있습니다. gRPC는 클라이언트 / 서버 코드가되고 데이터 프로토콜을 프로토 버핑합니다.

추신 : Go를 사용하여 gRPC 및 protobuf로 클라이언트 / 서버를 구축하는 방법을 단계별로 보여주기 위해이 문서 를 작성했습니다 .

grpc 는 Google에서 빌드 한 프레임 워크이며 Google 자체의 프로덕션 프로젝트에서 사용되며 #HyperledgerFabric은 grpc로 빌드되었습니다. grpc로 빌드 된 많은 오픈 소스 애플리케이션이 있습니다.

protobuff 는 json 과 같은 데이터 표현입니다. 이것은 또한 Google에 의해 실제로 생산 프로젝트에서 수천 개의 proto 파일이 생성됩니다.

grpc

• gRPC는 Google에서 개발 한 오픈 소스 프레임 워크입니다.
• RPC에 대한 요청 및 응답을 생성하고 프레임 워크에서 나머지를 처리 ​​할 수 ​​있습니다.
• REST는 CRUD 지향이지만 grpc는 API 지향 (제약 없음)
• HTTP / 2 위에 빌드
• >>>>> 인증,로드 밸런싱, 모니터링, 로깅 제공
• [HTTP / 2]
  • HTTP1.1은 1997 년에 출시되었습니다.
  • HTTP1은 각 요청에서 서버에 대한 새로운 TCP 연결을 엽니 다.
  • 헤더를 압축하지 않습니다.
  • 서버 푸시 없음, Req, Res와 함께 작동합니다.
  • 2015 년에 출시 된 HTTP2 (SPDY)
  • 멀티플렉싱 지원
  • 클라이언트와 서버는 동일한 TCP 연결을 통해 메시지를 병렬로 푸시 할 수 있습니다.
  • 대기 시간 대폭 감소
  • HTTP2는 헤더 압축을 지원합니다.
  • HTTP2는 바이너리입니다.
    • proto buff은 바이너리이므로 HTTP2와 아주 잘 어울립니다.
• [유형]
  • 단항
  • 클라이언트 스트리밍
  • 서버 스트리밍
  • 양방향 스트리밍
  • grpc 서버는 기본적으로 비동기입니다.
  • grpc 클라이언트는 동기화 또는 비동기 일 수 있습니다.

프로토 버프

• 프로토콜 버퍼는 언어에 구애받지 않습니다.
• 프로토콜 버퍼 (이진 형식) 구문 분석은 CPU 집약적이지 않습니다.
• [이름 지정]
  • 메시지 이름에 카멜 케이스 사용
  • 필드의 경우 underscore_seperated
  • 열거 형에는 camelcase를 사용하고 값 이름에는 CAPITAL_WITH_UNDERSCORE를 사용합니다.
• [코멘트]
  • 지원하다 //
  • 지원하다 /* */
• [장점]
  • 데이터가 완전히 입력 됨
  • 데이터가 완전히 압축 됨 (대역폭 사용량 감소)
  • 코드를 생성하고 코드를 읽으려면 스키마 (메시지)가 필요합니다.
  • 스키마에 문서를 삽입 할 수 있습니다.
  • 모든 언어로 데이터를 읽을 수 있습니다.
  • 스키마는 언제든지 안전한 방식으로 진화 할 수 있습니다.
  • XML보다 빠름
  • 코드가 자동으로 생성됩니다.
  • Google은 proto buff를 발명했으며 48000 protobuf 메시지와 12000.proto 파일을 사용합니다.
  • grpc를 포함한 많은 RPC 프레임 워크는 프로토콜 버퍼를 사용하여 데이터를 교환합니다.