When security is disabled, not waiting for the HTTP/2 handshake can lead to
DoS-style behavior. For details, see:
https://github.com/grpc/grpc-go/issues/954. This requirement will incur an
extra half-RTT latency before the first RPC can be sent under plaintext, but
this is negligible and unencrypted connections are rarer than secure ones.
Under TLS, the server will effectively send its part of the HTTP/2 handshake
along with its final TLS "server finished" message, which the client must wait
for before transmitting any data securely. This means virtually no extra
latency is incurred by this requirement.
Go had attempted to separate "connection ready" with "connection successful"
(Issue: https://github.com/grpc/grpc-go/issues/1444 PR:
https://github.com/grpc/grpc-go/pull/1648). However, this is confusing to
users and introduces an arbitrary distinction between these two events. It has
led to several bugs in our reconnection logic (e.g.s
https://github.com/grpc/grpc-go/pull/2380,
https://github.com/grpc/grpc-go/pull/2391,
https://github.com/grpc/grpc-go/pull/2392), due to the complexity, and it makes
custom transports (https://github.com/grpc/proposal/pull/103) more difficult
for users to implement.
We are aware of some use cases (in particular,
https://github.com/soheilhy/cmux) expecting the behavior of transmitting an RPC
before the HTTP/2 handshake is completed. Before making behavior changes to
implement this, we will reach out to our users to the best of our abilities.
In a previous version of the document we used FATAL_FAILURE instead of
SHUTDOWN. This was changed when there was no case that would cause a
fatal failure other than shutdown. However, one reference to the old
name was missed.
Vu Cong Tuan