块传输 vs grpc 流

Question

I am working on a project, where I want to expose an API which will read a large file send that in response.

Since file can be large in size, it is better to send the file in chunks, so not much memory pressure on system.

I evaluated 2 options: chunked transfer ( https://en.m.wikipedia.org/wiki/Chunked_transfer_encoding ) which is supported by HTTP-1.1, and a server side streaming by grpc.

In grpc approach, client request through a rpc, while server will stream bytes over grpc channel and close the same once done.

My ecosystem can support both, and client also supports grpc.

Can you please suggest which option is better, what are pros and cons of both approaches.

Answer 1

Both approaches will yield similar results. Just choose the stack you are most comfortable with.

HTTP chunking uses length-prefixed batches. gRPC streaming uses length-prefixed messages. The main difference is the batch size is chosen for you with chunking.

gRPC uses chunking to provide its streaming, although chunking is implemented differently between HTTP/1.1 and HTTP/2. When using gRPC the main thing is to use a "reasonable" message size; there's an overhead of ~5-10 bytes per message. Overheads exist in chunking as well, just you didn't have to choose the "reasonable" message size.

Both chunking and gRPC streaming use pipelining, where you send a chunk before the previous chunk has been fully received and processed. This reduces the influence of the chunk size on.network performance. As long as you choose a chunk size of at least 1 KB, the chunk size shouldn't matter too much and fine-tuning will rapidly see diminishing returns.