[gRPC] gRPC과 websocket 비교 정리

 

기존에 개발했던 서비스에서 클라이언트와 서버 통신을 websocket 으로 구현했다.

다 끝내고나서 클라이언트, 서버 통신하는 방법을 좀 더 서치해보고 싶었다

그렇게 알게된 gRPC. 정리해보자

 

✅ gRPC와 WebSocket

gRPC와 WebSocket은 둘 다 네트워크 통신 프로토콜로, 실시간 데이터 전송과 클라이언트-서버 간 상호작용을 가능하게 함

• gRPC
  • Google이 개발한 RPC(Remote Procedure Call) 프레임워크
  • HTTP/2 기반으로 동작하며, 프로토콜 버퍼(Protocol Buffers, Protobuf)를 사용하여 데이터 직렬화를 수행
  • 클라이언트는 서버의 메서드를 호출하듯이 원격으로 기능을 실행
• WebSocket
  • HTML5 표준으로, TCP 소켓 연결을 통해 양방향 통신을 가능하게 함
  • 프로토콜은 HTTP에서 업그레이드 후 지속적인 풀 듀플렉스 연결을 제공

gRPC

😀 gRPC를 사용해야 할 때

1. 고성능이 필요한 경우
   1. 낮은 대역폭 사용 : *Protobuf를 사용하여 데이터를 이진(binary) 형식으로 직렬화하므로 JSON이나 XML보다 데이터 크기가 작다.
   2. 낮은 지연 시간 : *HTTP/2의 멀티플렉싱과 헤더 압축 덕분에 지연 시간이 적다.
2. 마이크로서비스 간 통신
   1. 마이크로서비스 아키텍처에서 개별 서비스 간 통신이 빈번한 경우
3. 실시간 데이터 스트리밍
   1. 클라이언트와 서버 간 실시간 데이터 교환 ✅
4. 다양한 언어 지원
   1. gRPC는 여러 언어(C++, Python, Go, Java, Node.js 등)를 지원
5. 복잡한 API 설계
   1. 클라이언트가 서버의 특정 메서드만 호출하도록 설계된 API가 필요한 경우

 

😀 gRPC의 주요 통신 방식

총 4가지 통신 방식을 지원한다.

• Unary RPC (기본 요청-응답)
  • 클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 반환
  • REST API와 유사
  • ex) 특정 리소스의 상태를 조회하거나 간단한 요청-응답 작업
• Server Streaming RPC
  • 클라이언트가 요청을 보내면 서버가 응답 스트림을 여러 번 보냄
  • ex) 실시간 알림, 주식 가격 업데이트, 비디오 스트리밍 ✅
• Client Streaming RPC
  • 클라이언트가 스트림 형태로 데이터를 여러 번 보내고, 서버가 이를 처리한 후 단일 응답 반환
  • ex) IoT 디바이스에서 서버로 데이터를 업로드하거나 대량 데이터 처리
• Bidirectional Streaming RPC
  • 클라이언트와 서버가 서로 스트림 데이터를 주고받음
  • ex) 실시간 채팅 애플리케이션, 게임 서버-클라이언트 동기화

😀 gRPC의 단점

1. 복잡한 설정
   1. REST API에 비해 초기 설정과 학습 곡선이 높음
   2. Protobuf 정의 및 컴파일 필요
2. 브라우저 클라이언트 지원 제한
   1. gRPC는 HTTP/2를 사용하므로 브라우저에서 직접 사용이 제한적
   2. 대신 gRPC-Web을 통해 브라우저에서 gRPC 호출 가능
3. 디버깅 어려움
   1. 이진 직렬화를 사용하므로 JSON 기반 REST API처럼 쉽게 디버깅하기 어려움

---

▶️ 추가로 공부한 개념

• Protobuf
  • Protocol Buffers(Protobuf)는 Google이 개발한 효율적이고 구조화된 데이터 직렬화 포맷
  • 특징
    • 이진(binary) 형식 사용 : JSON이나 XML처럼 사람이 읽을 수 있는 텍스트 형식이 아니라, 컴퓨터가 해석하기 쉬운 이진 데이터 형식으로 변환 → 결과적으로 데이터 크기 축소 및 빠른 처리 속도 제공
    • 스키마 기반 : 데이터를 어떻게 직렬화할지 미리 정의(Protobuf schema)해야 함, 이 스키마를 바탕으로 데이터 구조를 자동으로 생성
• HTTP/2
  • 기본 HTTP/1.1의 단점을 보완한 새로운 프로토콜, 웹 성능 개선에 중점을 둔 기능 제공
  • HTTP/2는 멀티플렉싱과 헤더 압축과 같은 최적화 기법을 도입하여 요청 및 응답의 효율성을 높였다
  • 멀티플렉싱 (Multiplexing)
    • 하나의 TCP 연결에서 여러 요청/응답을 동시에 처리할 수 있는 기능
    • HTTP/1.1 방식 : 하나의 요청-응답이 끝나야 다음 요청-응답을 처리 가능 → 요청 간 순서 의존성이 발생
      • Request 1 -> Response 1
      • Request 2 -> Response 2 (Request 1 종료 후)
    • HTTP/2 방식 : 스트림(Stream)이라는 개념을 도입하여 하나의 연결에서 여러 요청을 병렬 처리 → 순서와 무관하게 요청과 응답이 독립적으로 이루어짐
      •  
        Request 1 -> Response 1
      • Request 2 -> Response 2
      • Request 3 -> Response 3 (병렬 처리)
    • 하나의 연결에서 동시에 다수의 요청을 처리하므로, 네트워크 지연 시간이 감소
    • 새로운 TCP 연결을 열 필요가 없어 TCP 핸드쉐이크 시간 절약
  • 헤더 압축 (Header Compression)
    • 요청 및 응답에서 반복되는 헤더 데이터를 효율적으로 압축하여 전송하는 기능
    • HTTP/1.1 방식 : 매 요청마다 모든 헤더를 완전히 전송 → 헤더가 크거나 중복 데이터가 많으면 대역폭이 낭비
      • Request 1:
        • GET /index.html HTTP/1.1
        • Host: example.com
        • Cookie: session_id=abc123
      • Request 2:
        • GET /style.css HTTP/1.1
        • Host: example.com
        • Cookie: session_id=abc123
    • HTTP/2 방식 : HPACK이라는 압축 방식을 사용해 헤더를 압축 → 중복 데이터를 제거하고, Header Field Table 에 데이터를 저장하여 필요시 참조
      • Request 1:
        • Compressed Headers
      • Request 2:
        • Reuse Headers (참조만 전달)
    • 헤더 크기를 줄여 대역폭 사용량 감소
    • 네트워크 지연 시간 줄어듦

 

✨ gRPC 를 간단하게 구현해보았다

[python] gRPC 간단하게 구현해보기