[rest] gRPC (HTTP / 2)는 HTTP / 2를 사용하는 REST보다 빠릅니까?

Program / 글쓴이

목표는 대기 시간 과 네트워크 처리량 이 더 우수한 전송 및 응용 프로그램 계층 프로토콜을 도입하는 것입니다 . 현재 애플리케이션은 HTTP / 1.1 과 함께 REST 를 사용 하며 지연 시간이 길어집니다. 이 지연 시간 문제를 해결해야하며 gRPC (HTTP / 2) 또는 REST / HTTP2를 사용할 수 있습니다.

HTTP / 2 :

  1. 다중화
  2. 단일 TCP 연결
  3. 텍스트 대신 바이너리
  4. 헤더 압축
  5. 서버 푸시

위의 모든 장점을 알고 있습니다. 질문 1 : HTTP / 2와 함께 REST를 사용하면 HTTP / 1.1과 함께 REST와 비교할 때 상당한 성능 향상을 얻을 수 있지만 gRPC (HTTP / 2) 와 어떻게 비교 됩니까?

또한 gRPC가 유선에서 구조화 된 데이터를 전송 하는 데 가장 적합한 이진 직렬화 기술인 proto 버퍼를 사용한다는 것을 알고 있습니다. Proto 버퍼는 언어에 구애받지 않는 접근 방식을 개발하는데도 도움이됩니다. 이에 동의하며 graphQL을 사용하여 REST에서 동일한 기능을 구현할 수 있습니다. 그러나 내 우려는 직렬화에 관한 것입니다. 질문 번호 2 : HTTP / 2 가이 바이너리 기능을 구현할 때 proto 버퍼를 사용 하면 HTTP / 2 에 추가 이점이 있습니까?

질문 3 호 : 의 관점에서 , 양방향 사용 사례 스트리밍 , 어떻게 gRPC (HTTP / 2)과 비교하면 (REST와 HTTP / 2)?

많은있다 블로그 / 비디오 등으로 gRPC (HTTP / 2) (REST와 HTTP / 1.1) 비교 인터넷에서 밖으로 이 . 앞서 언급했듯이 GRPC (HTTP / 2)와 (REST와 HTTP / 2)를 비교할 때의 차이점과 이점을 알고 싶습니다.

답변

gRPC는 기본적으로 HTTP / 2를 통한 REST보다 빠르지는 않지만 속도를 높일 수있는 도구를 제공합니다. REST로 수행하기 어렵거나 불가능한 몇 가지가 있습니다.

  • 선택적 메시지 압축. gRPC에서 스트리밍 RPC는 메시지 압축 여부를 결정할 수 있습니다. 예를 들어 단일 스트림 (또는 실제로 혼합 된 압축 가능 콘텐츠)을 통해 혼합 된 텍스트와 이미지를 스트리밍하는 경우 이미지에 대한 압축을 해제 할 수 있습니다. 이렇게하면 이미 압축 된 데이터를 압축하지 않아도되지만 CPU가 소모됩니다.
  • 일류 부하 분산. 지점 간 연결이 개선되지는 않았지만 gRPC는 트래픽을 보낼 백엔드를 지능적으로 선택할 수 있습니다. (이것은 유선 프로토콜 기능이 아니라 라이브러리 기능입니다). 즉, 프록시를 사용하지 않고도로드가 가장 적은 백엔드 서버에 요청을 보낼 수 있습니다. 이것은 지연 시간 승리입니다.
  • 크게 최적화되었습니다. gRPC (라이브러리)는 속도 회귀가 없는지 확인하기 위해 지속적인 벤치 마크 를 따릅니다 . 이러한 벤치 마크는 지속적으로 개선되고 있습니다. 다시 말하지만, 이것은 gRPC 프로토콜과 관련이 없지만 gRPC를 사용하면 프로그램이 더 빨라집니다.

nfirvine이 말했듯이 Protobuf를 사용하는 것만으로도 대부분의 성능 향상을 볼 수 있습니다. 당신이REST와 함께 proto를 사용할 는 gRPC와 매우 잘 통합됩니다. 기술적으로는 gRPC와 함께 JSON을 사용할 수 있지만 대부분의 사람들은 프로토 타입에 익숙해 진 후 성능 비용을 지불하고 싶지 않습니다.

답변

나는 어떤 식 으로든 이것에 대한 전문가가 아니며 이것 중 어떤 것도 뒷받침 할 데이터가 없습니다.

당신이 말하는 “바이너리 기능”은 HTTP / 2 프레임의 바이너리 표현입니다. 콘텐츠 자체 (JSON 페이로드)는 여전히 UTF-8입니다. Content-Encoding: gzipHTTP / 1과 마찬가지로 JSON을 압축하고을 설정할 수 있습니다 .

그러나 gRPC는 gzip 압축도 수행합니다. 그래서 실제로 우리는 gzip으로 압축 된 JSON과 gzip으로 압축 된 protobufs의 차이점에 대해 이야기하고 있습니다.

상상할 수 있듯이 압축 된 protobufs는 모든면에서 압축 된 JSON을 능가해야합니다. 그렇지 않으면 protobuf가 목표에 실패했습니다.

JSON 대 protobufs의 편재성 외에도 protobufs를 사용할 때 볼 수있는 유일한 단점은 tcpdump 상황에서이를 디코딩하려면 .proto가 필요하다는 것입니다.

답변