grpc는 go 언어만 지원하나요?

grpc는 go 언어만 지원하는 것이 아닙니다. grpc는 HTTP/2 기반의 통신 프로토콜이며 다중 언어 RPC 프레임워크를 지원합니다. 현재 C, Java 및 Go 언어 버전, 즉 grpc, grpc-java, grpc-go를 제공합니다. C 버전은 C, C++, Node.js를 지원합니다. , Python, Ruby, Objective-C, PHP 및 C#이 지원됩니다.

이 튜토리얼의 운영 환경: Windows 7 시스템, GO 버전 1.18, Dell G3 컴퓨터.

grpc란

---

gRPC는 HTTP/2 기반의 통신 프로토콜로 다국어 RPC 프레임워크를 지원하며 모바일 및 HTTP/2용으로 설계되었습니다. gRPC는 HTTP/2 표준을 기반으로 설계되었으며 단일 TCP 연결에서 양방향 스트리밍, 흐름 제어, 헤더 압축 및 멀티플렉싱 요청과 같은 기능을 제공합니다. 이러한 기능을 통해 모바일 장치에서 더 나은 성능을 발휘하고 전력과 공간을 절약할 수 있습니다.

RPC: Remote Procedure Call의 약어로, Remote Procedure Call(Remote Method Call 또는 Remote Call이라고도 번역됨)로 번역되며 컴퓨터 통신 프로토콜입니다. 이 프로토콜을 사용하면 네트워크 간, 플랫폼 간, 언어 간 및 기타 문제에 대해 걱정할 필요 없이 로컬 서비스를 호출하는 것처럼 간단하게 원격 서비스를 호출할 수 있습니다.

gRPC 메시지 직렬화 방법은 일반적으로 바이너리 형식인 Protobuf를 사용합니다. Protobuf는 크기가 작고 네트워크 전송 속도가 빠르며 대역폭과 트래픽을 덜 차지하며 호출 성능이 더 높습니다.

gRPC의 특징

• IDL

  gRPC는 ProtoBuf를 사용하여 서비스를 정의합니다. ProtoBuf는 Google에서 개발한 데이터 직렬화 프로토콜입니다(XML, JSON과 유사). ProtoBuf는 데이터를 직렬화할 수 있으며 데이터 저장, 통신 프로토콜 등에 널리 사용됩니다.

• 다국어 지원

  gRPC는 다국어를 지원하며 언어를 기반으로 클라이언트 및 서버 기능 라이브러리를 자동으로 생성할 수 있습니다. 현재 C 버전 grpc, Java 버전 grpc-java 및 Go 버전 grpc-go가 제공됩니다. 그중 grpc는 C, C++, Node.js, Python, Ruby, Objective-C, PHP 및 C# 및 기타 언어를 지원합니다. .grpc-java는 Android 개발을 지원합니다.

• HTTP2

  gRPC는 HTTP2 표준을 기반으로 설계되었으며 양방향 스트리밍, 헤더 압축, 멀티플렉싱 요청 등과 같은 더욱 강력한 기능을 제공합니다. 이러한 기능은 대역폭 절감, TCP 링크 시간 단축, CPU 사용량 절감, 배터리 수명 연장과 같은 상당한 이점을 제공합니다. 동시에 gRPC는 클라우드 서비스 및 웹 애플리케이션의 성능도 향상시킬 수 있습니다. gRPC는 클라이언트 측과 서버 측 모두에 적용할 수 있어 클라이언트-서버 통신이 투명하게 이루어지고 통신 시스템 구축이 단순화됩니다.

grpc를 사용하는 이유

• 좋은 생태: Google의 지원을 받습니다. 예를 들어, nginx는 grpc에 대한 지원도 제공하며 참조 링크

• 교차 언어: 교차 언어를 제공하고 자동으로 sdk

• 를 생성합니다. 고성능: 예를 들어 protobuf 성능은 json보다 높습니다(예: http2). 0 성능은 http1.1

• 강한 타이핑: 컴파일러가 많은 문제를 해결합니다

• 스트리밍 처리(http2.0 기반): 클라이언트 스트리밍, 서버 스트리밍 및 양방향 스트리밍을 지원합니다

grpc의 장점은 어떻게 구현되나요?

---

1. grpc의 고성능: protobuf가 json보다 나은 이유는 무엇인가요?

1) 프로토부프란?

• Protobuf는 다양한 서비스 간 데이터 직렬화를 위해 Google에서 개발한 바이너리 형식입니다. IDL(인터페이스 설명 언어) 언어입니다.

2) json보다 얼마나 빠릅니까?

• 6배 빠름, 참조 링크

3) protobuf가 json보다 빠른 이유는 무엇입니까?

• protobuf의 바이너리 데이터 흐름과 json 데이터 흐름은 아래와 같습니다

• json 데이터와 protobuf 데이터 형식을 비교하면
• 작은 크기 - 구분 기호가 필요하지 않음: TLV 저장 방법에는 필드를 구분하는 데 구분 기호(쉼표, 큰따옴표 등)가 필요하지 않으므로 use of delimiters
• 작은 크기 - 빈 필드 생략: 필드에 필드 값이 설정되지 않은 경우 필드가 직렬화될 때 데이터가 전혀 존재하지 않습니다. 즉, 인코딩이 필요하지 않으며 json은 키와 빈 값의 값
• 작은 크기 - 태그 이진 표현: 필드의 숫자 값을 사용한 다음 이를 이진 표현으로 변환합니다. json 키의 문자열 표현보다 공간을 절약합니다.
• 빠른 인코딩 및 디코딩: 필드의 유형이 태그에 저장되어 값의 길이를 직접 알 수 있으며, 값이 문자열인 경우 길이를 직접 가져올 수 있습니다. 값의 값을 얻으려면 길이 뒤에 n바이트를 입력해야 합니다. 문자열 일치를 수행하려면
• protobuf 인코딩에 대해 자세히 알아보려면 : varint 및 zigzag 인코딩 방법
으로 이동하세요.

2. grpc의 고성능: http2.0이 http1.1보다 성능이 더 높은 이유는 무엇입니까?

1) 멀티플렉싱

• http2.0 및 http 1.* 및 http1.1pipling

  개략도

• 비교 http/1. *: 하나의 요청, 하나의 응답, 연결이 설정되고 사용 후 닫힙니다. 각 요청은 연결을 설정해야 합니다
• http1.1 파이프링: 파이프링 솔루션은 직렬화된 단일 스레드 처리를 위해 여러 요청을 대기열에 넣은 다음 요청이 대기하는 것입니다. 실행 기회를 얻기 위해 이전 요청을 반환합니다. 요청 시간이 초과되면 후속 요청만 차단될 수 있으며, 이를 종종 헤드 오브 라인 차단이라고 부릅니다.
• http2: 여러 요청을 동시에 처리할 수 있습니다. 하나의 연결에서 병렬로 실행됩니다. 특정 요청 작업은 시간이 많이 걸리며 다른 연결의 정상적인 실행에 영향을 미치지 않습니다. grpc 멀티플렉싱의 다른 장점은 무엇입니까? TCP 연결을 줄이고 서버와 클라이언트의 메모리 및 CPU 요구 사항을 줄입니다. 대기 중
• TCP 연결을 줄이고 TCP 재설정이 자주 발생하지 않도록 하여 느린 시작이 자주 발생하지 않도록 합니다. TCP 연결을 줄이고 네트워크 정체를 개선합니다.
• http/1.1 멀티플렉싱을 달성할 수 없지만 왜 http2.0은 가능합니까?
• http/1.1은 텍스트를 전송에 사용하고 http2.0은 바이너리 프레임 전송을 사용하기 때문입니다
2) 헤더 압축

고정 필드 압축

: http는 http와 쌍을 이룰 수 있습니다. 본문은 gzip입니다. 압축되어 대역폭을 절약할 수 있습니다. 그러나 메시지 헤더에는 쿠키 및 사용자 에이전트 허용과 같이 압축되지 않은 필드도 많이 있습니다. 이러한 필드는 중복을 피하기 위해

필요합니다. 메시지의 요청과 응답이 반복되므로 중복을 피해야 합니다

• 인코딩 개선: 필드가 ASCII로 인코딩되어 있어 비효율적입니다. 바이너리 인코딩으로 변경하면 개선될 수 있습니다
• 위 내용은 다음과 같습니다. HPACK 알고리즘을 통해 구현됩니다. 알고리즘에는 주로 세 가지 부분
• 정적 사전이 포함됩니다. 일반적으로 사용되는 헤더 필드를 단일 숫자로 표시할 수 있는 {":method":"GET"}와 같은 사전으로 구성합니다. 2
동적 사전: 정적 사전에 없는 일부 헤더 필드, 동적 사전 사용
• 허프만 인코딩: 압축 인코딩
• 3) 바이너리 프레이밍
• 바이너리 프레이밍 레이어에서는 HTTP 2.0이 분할됩니다. 전송된 모든 정보는 더 작은 메시지와 프레임으로 변환되고 이를 바이너리 형식으로 인코딩합니다. 여기서 HTTP1.x의 헤더 정보는 헤더 프레임에 캡슐화되고 요청 본문은 데이터 프레임에 캡슐화됩니다.

이러한 방식으로 프레임을 구성한 후 이러한 프레임은 순서 없이 전송될 수 있으며 각 프레임의 헤더에 있는 스트림 식별자에 따라 조립될 수 있습니다.

http/1.1을 비교하세요

텍스트 기반이고 줄바꿈을 사용하기 때문입니다. 각 키 분리: 값 다음 문제:

• 구분 기호로 메시지를 분할하는 이러한 종류의 데이터는 완료되기 전에 구문 분석을 중지할 수 없기 때문에 한 번에 하나의 요청 또는 응답만 처리할 수 있습니다.
• 예측이 불가능합니다. 이런 종류의 데이터를 분석하는데 얼마나 많은 메모리가 필요한지, 서버에 많은 문제를 일으킬 것입니다. 큰 압박감
4) 서버가 리소스를 적극적으로 푸시합니다
• • 서버가 리소스를 적극적으로 푸시하도록 지원하므로 일부 요청은 생략될 수 있습니다. 예를 들어, 1.html과 1.css라는 두 개의 파일이 필요한 경우 http1.0인 경우 이를 두 번 요청해야 하며 서버는 이를 두 번 반환합니다. 하지만 http2.0에서는 클라이언트가 한 번 요청하면 서버가 직접 두 번 응답합니다

  더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 소개를 방문하세요! !

위 내용은 grpc는 go 언어만 지원하나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!