2021. 6. 7. 16:15ㆍgolang
우선 설명에 앞서 간략하게 표로 비교해 확인해보겠습니다.
| 기능 | grpc | JSON을 사용하는 HTTP API |
| 계약 | 필수(.proto) | 선택 사항(Open API) |
| 프로토콜 | HTTP/2 | HTTP |
| Payload | Protobuf(소형, 이진) | JSON(대형, 사람이 읽을 수 있음) |
| 규범 | 엄격한 사양 | 느슨함. 모든 HTTP가 유효합니다. |
| 스트리밍 | 클라이언트, 서버, 양방향 | 클라이언트, 서버 |
| 브라우저 지원 | 아니요(gRPC-웹 필요) | 예 |
| 보안 | 전송(TLS) | 전송(TLS) |
| 클라이언트 코드생성 | 예 | OpenAPI + 타사 도구 |
여기서 평소에 오른쪽의 방법만 사용하다보면 왼쪽의 다양한 정보들이 어색해 보입니다. 이러한 것이 무엇을 뜻하는지 한번 알아 봅시다.
Protobuf(Protocol Buffers)
프로토콜 버퍼는 구글에서 개발한 오픈소스로 공개한, 직렬화 데이터 구조이다. Protocolbuf는 서버와 클라이언트에서 매우 빠르게 직렬화 합니다. 이러한 경우 작은 메시지 페이로드를 발생시키며 이는 모바일 앱꽈 같은 제한된 대역폭 시나리오에서 중요합니다. 또한 현재 사용하는 대부분의 언어를 지원하고 있습니다. C++, JS, Go, Java, Python 등을 지원하고 있습니다.
이러한 데이터 주고받을 명세를 정하기 위해 .proto라는 파일을 작성한다. 이는 다른 글에서 정리해보겠다.
ex) 직렬화: 데이터를 네트워크로 전송하기 위해 바이너리 스트림 형태로 저장하는 행위이다.
엄격한 사양
grpc는 JSON HTTP와 다르게 엄격한 사양을 갖고 있습니다. 해당 주소에 있는 grpc 사양을 따라서 개발을 해야합니다.
https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md
HTTP/2
http2의 성능 향상 중 핵심은 새 바이너리 프레이밍 계층입니다. 이 계층은 HTTP 메시지가 캡슐화되어 클라이언트와 서버 사이에 전송되는 방식을 규정합니다.
기존 http 1.1에 존재하는 헤더를 해쉬 테이블과 허프만 인코딩 방법을 사용해서 헤더 크기를 줄일 수 있습니다. 이러한 방법을 일반적으로 HPACK이라고 부릅니다. HTTP/2는 중복된 헤더 정보인 경우 Index만 전송하고 중복이 아닌 경우는 Huffman Encoding을 통해 데이터를 줄일 수 있습니다.
압축 방법
- 전송되는 헤더 필드를 정적 Huffman 코드로 인코딩하도록 허용합니다. 이 코드는 필드의 개별 전송 크기를 줄여줍니다.
- 이전에 표시된 헤더 필드의 색인 목록을 클라이언트와 서버가 유지하고 업데이트하도록 요구합니다(즉, 공유 압축 컨텍스트를 구성합니다). 그런 다음, 이 목록을 참조로 사용하여 이전에 전송된 값을 효율적으로 인코딩할 수 있습니다.
브라우저 지원
grpc의 경우에는 브라우저에서 직접적으로 지원하지 않습니다. 즉 웹 클라이언트에서 rest 처럼 바로 요청을 보낼 수 없다는 의미이죠.
그래서 저는 gogateway라는 것을 앞에 두어서 클라이언트의 요청은 restapi로 받고 서버간 통신은 grpc로 진행했습니다.
스트리밍
HTTP/2는 수명이 긴 실시간 통신 스트림에 대한 기초를 제공합니다. gRPC는 HTTP/2를 통한 스트리밍을 위한 최고 수준의 지원을 제공합니다.
- 단항(스트리밍 없음)
- 서버-클라이언트 스트리밍
- 클라이언트-서버 스트리밍
- 양방향 스트리밍
protoc 파일을 작성해줄 때 requets이나 response앞에 stream을 붙여주면 된다.
gRPC 권장 시나리오
마이크로 서비스: gRPC는 대기 시간이 짧고 처리량이 높은 통신을 위해 설계되었습니다. gRPC는 효율성이 중요한 경량 마이크로 서비스에 적합합니다.
지점 간 실시간 통신: 양방향 스트리밍을 위한 뛰어난 지원 기능을 제공합니다. gRPC 서비스는 폴링을 사용하지 않고 실시간으로 메시지를 푸시할 수 있습니다.
gRPC 약점
1. 제한된 브라우저 지원
현재 브라우저에서 gRPC 서비스를 직접 호출하는 것은 불가능합니다. gRPC는 HTTP/2 기능을 많이 사용하며, 브라우저에서 gRPC 클라이언트를 지원히기 위해 웹 요청에 필요한 제어 수준을 제공하지 않습니다.
2. 요청하는 데이터를 사람이 읽을 수 없음.
HTTP API 요청은 텍스트로 전송되며, 사람이 읽고 만들 수 있습니다.
gRPC 메시지는 기본적으로 protobuf로 인코딩됩니다. Protobuf는 송신 및 수신에 효율적이지만, 이진 형식은 사람이 읽을 수 없습니다.