To my knowledge, building an RPC protocol based on TCP is more efficient than using HTTP2, which is designed primarily for web services and has additional overhead. What is the meaning of building another application layer protocol over an application layer protocol? Why does not GRPC build its protocol directly over TCP?
Well, that depends on how you measure efficiency :-)
If you're willing to take raw TCP and consider the layering of extra facilities on top of it to be zero development cost then, yes, TCP would probably be more efficient. But they're not really zero cost since you have to develop and test them.
HTTP/2, on the other hand, provides some extra facilities (at true zero development cost) which may be useful to protocols sitting on top of it.
For example, it provides binary framing, header compression, multiplexing (in parallel) request/response groups on a single TCP session, and server push in cases where the server can ascertain client needs without extra requests coming in.
I know for a fact that gRPC uses header compression since I've seen the debug output with its hpack
logging. I'm not sure if it uses the other things but, for performance, I suspect they'd be quite handy.
© 2022 - 2024 — McMap. All rights reserved.