출처 : grpc.io/docs/what-is-grpc/introduction/ (영어, 어려움)
출처 : blog.naver.com/n_cloudplatform/221751268831 (한국어, grpc가 나오게 된 과정)
1. HTTP/2
GRPC란 google 에서 만든 google remote procedure call의 준말입니다.
회사에서 사용하기로 해서 공부를 해 보기로 했습니다.
GRPC가 나오기 전에, Server - Client model, Socket, RPC, REST 등 여러 프로토콜이 있었는데, 이 모든 프로토콜의 문제는 HTTP/1.1 을 사용한다는 점이었습니다. http/1.1 과 http/2.0의 차이는 상당히 큰데, 그림으로 보시는 것 과 같이 http/2 는 비동기 통신이 가능하고, http/1.1의 경우 동기식이기 때문에 여러가지 문제점들이 생겼습니다.
이 문제들을 해결하기 위해 이미지 스프라이트, 도메인 샤딩, CSS/JS 압축, Data URI등을 사용하였습니다.
하지만 HTTP/2는 월등한 속도를 이용해서 multiplexed streams, Stream Prioritation, Server push, Header compression등을 활용하여 획기적으로 성능을 향상시켰습니다.
http/1.1은 기본적으로 클라이언트의 요청이 올때만 서버가 응답을 하는 구조로 매 요청마다 connection을 생성해야만 합니다. cookie 등 많은 메타 정보들을 저장하는 무거운 header가 요청마다 중복 전달되어 비효율적이고 느린 속도를 보여주었죠. 이에 http/2에서는 한 connection으로 동시에 여러 개 메시지를 주고 받으며, header를 압축하여 중복 제거 후 전달하기에 version1에 비해 훨씬 효율적입니다. 또한, 필요 시 클라이언트 요청 없이도 서버가 리소스를 전달할 수도 있기 때문에 클라이언트 요청을 최소화 할 수 있습니다. (by naver cloud)
2. ProtoBuf (Protocol Buffer, 프로토콜 버퍼)
Protocol Buff 는 Google 에서 개발한 Serialization method 입니다. 아래 그림과 같이, JSON 에서는 82 Byte를 사용해야 하는데 비해, Protocol Buff 는 필드 번호, 필드 유형을 1 Byte로 표현하기 때문에, 33 Byte로도 표현할 수 있습니다.
3. Proto File
Proto File은 Protocol Buff의 기본 정보를 명시하는 용도로 사용합니다.
1) message and field
> syntax : proto2 (default) vs proto3
proto2 와 proto3 는 지원 언어, 문법이 다릅니다.
> Naming
message는 CamelCase, parameter는 under_bar 형식으로 하는것을 권장합니다. (필수는 아님)
> Field Number (Field Tag)
각 필드들은 고유의 값을 갖게 되며, 왠만하면 1~15까지의 값을 주는 것이 좋습니다.
> Proto file field rule
- required : 필수값 (proto2 에서만 사용)
- optional: 가지거나 하나만 가짐 (proto2에서만 사용)
- repeated: 임의 반복 가능
repeated rule을 줄 경우 packed=true 옵션을 줄 경우 key를 생략하고 value만 들어가게 할 수 있습니다.
2) Package
package는 message를 구분할 때 사용합니다. package를 사용하지 않아도 상관은 없지만, 구성 메시지가 많다면 표현해주는 것이 better practice라고 볼 수 있겠습니다.
3) Service
Service 는 서버가 클라이언트에 제공할 함수의 형태를 정의합니다. 서비스명과 메소드명은 모두 CamelCase를 권장합니다. 옵션을 주지 않으면 단일 요청/응답으로 동작하지만, stream 옵션을 주면 RPC를 구현할 수 있습니다.
단방향 예시 :
양방향 예시(stream) :
