gRPC Channel, Stream 개념
gRPC Channel
gRPC는 HTTP 2.0 기반에 HTTP Streaming을 이용해서 데이타를 보낸다. HTTP 2.0의 경우에는 커넥션을 계속 유지하는 메커니즘이기 때문에, gRPC는 보통 하나의 Connection을 맺어놓고, 이 Connection에 계속 메세지를 보내는 방식을 이용하는데, 이 Connection (TCP Connection)을 Channel이라고 한다.
Stream
하나의 RPC 콜을 호출할때 이 호출을 Stream 이라고 한다. RPC 호출이 시작되면, Stream이 시작되었다가 종료되면 당연히 Stream이 닫힌다.
Stream의 동시성
그러면 하나의 Channel에서 Stream을 호출하는데, 만약에 Stream의 길이가 길다면 다른 Stream 호출은 지연되지 않을까?
예를 들어서 하나의 채널을 통해서 function download()와 function helloworld()를 순차적으로 호출했다고 가정하자. download()가 오래 걸리는 호출이라면, 이로 인해서 helloworld는 나중에 호출이 될까?
순차적으로 호출이 된다면, 그렇게 되겠지만 gRPC는 Stream 호출에 대한 동시성을 제공한다.
Stream을 패킷 단위로 쪼갠후에, Round robin 방식으로, 여러 Stream을 번갈아 가면서 보낸다. 한번에 여러 Stream을 동시에 보내지는 않는다. 한번 보낼때는 한 Stream의 패킷만을 보낼 수 있지만, 여러 Stream의 패킷을 번갈아 보내는 방식으로 이 문제를 해결한다. \
Multi channel 을 사용해야 할까?
일단 가이드를 보면 한 주소로는 1개의 Connection(채널)만을 사용하도록 권고하고 있다. 종종 Throughput을 늘리기 위해서 connection pool 을 이용해서, 여러 채널을 동시에 여는 내용도 있기는 하지만 매우 드물다.
참고 자료
https://grpc.io/blog/http2_smarter_at_scale
'프로그래밍' 카테고리의 다른 글
구글 프로토콜 버퍼 (Protocol buffer) (7) | 2017.06.25 |
---|---|
grpc 설치하기 (0) | 2015.04.02 |
grpc (google rpc)에 대한 분석 #1 (1) | 2015.04.01 |
구글의 HTTP 기반의 RPC 프로토콜 GRPC (3) | 2015.03.31 |
국내 자바 MVC 프레임웍 사용 현황 (5) | 2009.11.11 |