diff options
| author |  Doug Fawley <dfawley@google.com> | 2018-10-25 09:50:12 -0700 |
|---|---|---|
| committer | Doug Fawley <dfawley@google.com> | 2018-10-25 10:32:52 -0700 |
| commit | a62c53046508e226fe1915d8ff8a9d05ca7b1d2e (patch) | |
| tree | 68f4ec19cba01133637a61b2d2c72e1e4ee5011d /doc | |
| parent | 4139ff895fd413c730c4383d24d13a17bbeaea90 (diff) | |
Add protocol handshake to 'READY' connectivity requirements
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.
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/connectivity-semantics-and-api.md | 11 |
1 files changed, 6 insertions, 5 deletions
diff --git a/doc/connectivity-semantics-and-api.md b/doc/connectivity-semantics-and-api.md index dc30fe5348..8ba22ec3dd 100644 --- a/doc/connectivity-semantics-and-api.md +++ b/doc/connectivity-semantics-and-api.md @@ -23,9 +23,10 @@ make progress on one of the steps involved in name resolution, TCP connection establishment or TLS handshake. This may be used as the initial state for channels upon creation. -READY: The channel has successfully established a connection all the way -through TLS handshake (or equivalent) and all subsequent attempt to communicate -have succeeded (or are pending without any known failure ). +READY: The channel has successfully established a connection all the way through +TLS handshake (or equivalent) and protocol-level (HTTP/2, etc) handshaking, and +all subsequent attempt to communicate have succeeded (or are pending without any +known failure). TRANSIENT_FAILURE: There has been some transient failure (such as a TCP 3-way handshake timing out or a socket error). Channels in this state will eventually @@ -52,8 +53,8 @@ immediately. Pending RPCs may continue running till the application cancels them Channels may enter this state either because the application explicitly requested a shutdown or if a non-recoverable error has happened during attempts to connect communicate . (As of 6/12/2015, there are no known errors (while connecting or -communicating) that are classified as non-recoverable) -Channels that enter this state never leave this state. +communicating) that are classified as non-recoverable) +Channels that enter this state never leave this state. The following table lists the legal transitions from one state to another and corresponding reasons. Empty cells denote disallowed transitions. |