개요
gRPC는 Google이 오픈 소스로 공개한 현대적인 고성능 RPC 프레임워크로, HTTP/2 프로토콜과 Protocol Buffers 직렬화를 기반으로 합니다. 다중 언어 크로스 플랫폼 통신을 지원하며, 스트리밍 전송, 인증 및 로드 밸런싱과 같은 기능을 제공합니다.
README 미리보기
# gRPC – An RPC library and framework\n\ngRPC is a modern, open source, high-performance remote procedure call (RPC)\nframework that can run anywhere. gRPC enables client and server applications to\ncommunicate transparently, and simplifies the building of connected systems.\n\n\n \n Homepage:\n grpc.io\n \n \n Mailing List:\n grpc-io@googlegroups.com\n \n\n\n[](https://gitter.im/grpc/grpc?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)\n\n## To start using gRPC\n\nTo maximize usability, gRPC supports the standard method for adding dependencies\nto a user's chosen language (if there is one). In most languages, the gRPC\nruntime comes as a package available in a user's language package manager.\n\nFor instructions on how to use the language-specific gRPC runtime for a project,\nplease refer to these documents\n\n- [C++](src/cpp): follow the instructions under the `src/cpp` directory\n- [C#/.NET](https://github.com/grpc/grpc-dotnet): NuGet packages\n `Grpc.Net.Client`, `Grpc.AspNetCore.Server`\n- [Dart](https://github.com/grpc/grpc-dart): pub package `grpc`\n- [Go](https://github.com/grpc/grpc-go): `go get google.golang.org/grpc`\n- [Java](https://github.com/grpc/grpc-java): Use JARs from Maven Central\n Repository\n- [Kotlin](https://github.com/grpc/grpc-kotlin): Use JARs from Maven Central\n Repository\n- [Node](https://github.com/grpc/grpc-node): `npm install @grpc/grpc-js`\n- [Objective-C](src/objective-c): Add `gRPC-ProtoRPC` dependency to podspec\n- [PHP](src/php): `pecl install grpc`\n- [Python](src/python/grpcio): `pip install grpcio`\n- [Ruby](src/ruby): `gem install grpc`\n- [WebJS](https://github.com/grpc/grpc-web): follow the grpc-web instructions\n\nPer-language quickstart guides and tutorials can be found in the\n[documentation section on the grpc.io website](https://grpc.io/docs/). Code\nexamples are available in the [examples](examples) directory.\n\nPrecompiled bleeding-edge p
FAQ (5)
문제 해결gRPC C++에서 클라이언트가 서버에 연결할 수 없을 때 발생하는 Abseil 'Potential Mutex deadlock' abort를 해결하는 방법
이 문제는 gRPC의 TCP connect handshaker에서 발생하는 락 순서 역전(lock-ordering inversion) 때문에 발생합니다: TCPConnectHandshaker::FinishLocked()가 TCPConnectHandshaker::mu_를 보유한 상태에서 핸드셰이크 완료 콜백을 호출하는데, 이 콜백은 연결 실패, 재시도 또는 종료 과정에서 일관되지 않은 순서로 HandshakeManager::mu_를 획득할 수 있습니다. 그러면 Abseil의 디버그 데드락 감지기가 abort()를 호출합니다.
영구적인 해결 방법: PR #43184가 포함된 gRPC 릴리스를 사용하거나, gRPC를 빌드할 때 해당 PR을 cherry-pick하세요. 이 PR은 TCPConnectHandshaker::mu_ 임계 영역(critical section) 외부에서 InvokeOnHandshakeDone을 호출합니다.
임시 해결 방법으로, gRPC를 사용하기 전에 Abseil 데드락 감지가 abort 대신 report하도록 초기화하세요:
#include "absl/synchronization/mutex.h"
absl::SetMutexDeadlockDetectionMode(absl::OnDeadlockCycle::kReport);또는 -DCMAKE_BUILD_TYPE=Release와 같이 gRPC와 동일한 release 구성으로 Abseil을 빌드하면 NDEBUG가 정의되어 디버그 전용 데드락 검사가 비활성화됩니다. 이 감지기는 실제 락 역전 문제를 식별하므로, gRPC를 업그레이드하거나 패치하는 것을 권장합니다.
문제 해결macOS에서 "Too many open files" 또는 "Failed accept4" 오류가 발생하는 gRPC 스트레스 테스트 실패를 어떻게 해결하나요?
스트레스 테스트를 실행하기 전에 셸의 열린 파일 디스크립터 제한을 높이세요:
ulimit -n 8192
build/client_channel_stress_testthread_stress_test 또는 영향을 받는 다른 gRPC 테스트를 실행하기 전에 동일한 명령을 사용하세요. ulimit -n으로 설정을 확인하세요. 이 실패는 테스트가 기본 파일 디스크립터 제한을 모두 소진할 때 발생하며, 특히 코어 수가 많은 머신에서 발생합니다.
문제 해결OpenSSL 4.0에서 발생하는 gRPC 빌드 오류 해결 방법 (C2440: 'const X509_NAME *'을(를) 'X509_NAME *'(으)로 변환할 수 없음)?
gRPC가 OpenSSL 4.0에 대해 컴파일에 실패합니다. X509_get_subject_name()이 이제 const X509_NAME*를 반환하면서 src/core/tsi/ssl_transport_security.cc, ssl_transport_security_utils.cc, grpc_tls_crl_provider.cc에서 'conversion loses qualifiers' 오류가 발생하기 때문입니다. 해결 방법: 커밋 fb056ab0bb3ed003febe82f069ff41514288a4f3(OpenSSL 4 컴파일 지원, PR #41932)이 포함된 gRPC 버전으로 업그레이드하십시오. 이전 릴리스(예: 1.76.0)의 경우 소스를 패치하십시오: subject_name을 const X509_NAME*로 선언하고 X509_NAME_get_index_by_NID, X509_NAME_get_entry, X509_NAME_print_ex에 전달할 때 const_cast<X509_NAME*>(...)로 감싸십시오. 참고: gRPC의 OpenSSL 4 지원은 실험적인 것으로 간주됩니다.
문제 해결연결 핸드셰이크 중 TCPConnectHandshaker에서 발생하는 gRPC C++ 클라이언트 SIGABRT 데드락을 해결하는 방법은?
이는 HandshakeManager::mu_와 TCPConnectHandshaker::mu_ 간의 락 역전(lock inversion)으로 인해 발생합니다. 연결 실패, 재시도 또는 종료 시 TCPConnectHandshaker::FinishLocked()가 TCPConnectHandshaker::mu_를 계속 보유한 상태에서 핸드셰이크 완료 콜백을 호출하며, 이 콜백이 HandshakeManager에 다시 진입할 때 데드락이 발생할 수 있습니다.
해결 방법:
1. PR [#43184](https://github.com/grpc/grpc/pull/43184)이 포함된 릴리스로 gRPC를 업그레이드하세요.
2. 즉시 업그레이드할 수 없는 경우, 해당 PR을 적용하여 소스에서 gRPC를 빌드하세요:
git clone https://github.com/grpc/grpc.git
cd grpc
git fetch origin pull/43184/head:fix-tcp-handshake-deadlock
git checkout fix-tcp-handshake-deadlock
cmake -S . -B build -DgRPC_INSTALL=ON
cmake --build build --target install3. 패치된 gRPC 라이브러리를 기반으로 클라이언트를 다시 빌드하세요.
이 패치는 InvokeOnHandshakeDone을 뮤텍스 범위 밖에서 실행하여 데드락 사이클을 끊습니다. 임시 완화 조치로는 장기 유휴 연결 끊김을 줄이고 동일한 주소로 여러 채널을 반복적으로 생성하는 것을 피할 수 있지만, 업그레이드 또는 패치 적용이 확실한 해결 방법입니다. 이 문제는 gRPC 1.69, RHEL 9.x, GCC 11.4.1 환경에서 보고되었습니다.
문제 해결gRPC C++에서 지원되지 않는 grpc-encoding 헤더에 대해 "Stream removed" 또는 INTERNAL_ERROR를 반환하는 문제를 해결하는 방법
issue #36770에 대한 PR "[Core] Fix compression error handling edge cases"가 포함된 릴리스로 gRPC C++를 업그레이드하거나, 해당 수정 사항이 포함된 커밋으로부터 빌드하세요. 수정된 동작은 다음과 같습니다: 서버로부터 지원되지 않는 인코딩을 수신한 클라이언트는 INTERNAL을 반환하고, 클라이언트로부터 지원되지 않는 인코딩을 수신한 서버는 HTTP/2 스트림을 RST_STREAM INTERNAL_ERROR로 리셋하는 대신 UNIMPLEMENTED를 반환하며, non-identity 인코딩이 협상되지 않은 상태에서 envelope compressed bit가 설정된 메시지는 무시되지 않고 INTERNAL로 실패합니다. 해결 방법으로, 양쪽 피어가 상호 지원되는 압축 알고리즘만 advertise하도록 하고, 스트림에 대해 non-identity 인코딩이 협상되지 않은 한 compressed message bit를 설정하지 않도록 하세요.