|
| 1 | +--- |
| 2 | +layout: docs |
| 3 | +title: Wire Protocol |
| 4 | +--- |
| 5 | + |
| 6 | +<h1 class="page-header">gRPC over HTTP2 protocol</h1> |
| 7 | + |
| 8 | +<div id="toc"></div> |
| 9 | + |
| 10 | +This document serves as a detailed description for an implementation of gRPC carried over HTTP2 draft 17 framing. It assumes familiarity with the HTTP2 specification. Production rules use <a href="http://tools.ietf.org/html/rfc5234">ABNF syntax</a>. |
| 11 | + |
| 12 | +## Outline |
| 13 | + |
| 14 | +The following is the general sequence of message atoms in a GRPC request & response message stream |
| 15 | + |
| 16 | +* Request → Request-Headers *Delimited-Message EOS |
| 17 | +* Response → (Response-Headers *Delimited-Message Trailers) / Trailers-Only |
| 18 | + |
| 19 | + |
| 20 | +## Requests |
| 21 | + |
| 22 | +* Request → Request-Headers *Delimited-Message EOS |
| 23 | + |
| 24 | +Request-Headers are delivered as HTTP2 headers in HEADERS + CONTINUATION frames. |
| 25 | + |
| 26 | +* **Request-Headers** → Call-Definition *Custom-Metadata |
| 27 | +* **Call-Definition** → Method Scheme Path TE [Authority] [Timeout] [Content-Type] [Message-Type] [Message-Encoding] [Message-Accept-Encoding] [User-Agent] |
| 28 | +* **Method** → “:method POST” |
| 29 | +* **Scheme** → “:scheme ” (“http” / “https”) |
| 30 | +* **Path** → “:path” {_path identifying method within exposed API_} |
| 31 | +* **Authority** → “:authority” {_virtual host name of authority_} |
| 32 | +* **TE** → “te” “trailers” # Used to detect incompatible proxies |
| 33 | +* **Timeout** → “grpc-timeout” TimeoutValue TimeoutUnit |
| 34 | +* **TimeoutValue** → {_positive integer as ASCII string of at most 8 digits_} |
| 35 | +* **TimeoutUnit** → Hour / Minute / Second / Millisecond / Microsecond / Nanosecond |
| 36 | +* **Hour** → “H” |
| 37 | +* **Minute** → “M” |
| 38 | +* **Second** → “S” |
| 39 | +* **Millisecond** → “m” |
| 40 | +* **Microsecond** → “u” |
| 41 | +* **Nanosecond** → “n” |
| 42 | +* **Content-Type** → “content-type” “application/grpc” [(“+proto” / “+json” / {_custom_})] |
| 43 | +* **Content-Coding** → “gzip” / “deflate” / “snappy” / {_custom_} |
| 44 | +* **Message-Encoding** → “grpc-encoding” Content-Coding |
| 45 | +* **Message-Accept-Encoding** → “grpc-accept-encoding” Content-Coding *("," Content-Coding) |
| 46 | +* **User-Agent** → “user-agent” {_structured user-agent string_} |
| 47 | +* **Message-Type** → “grpc-message-type” {_type name for message schema_} |
| 48 | +* **Custom-Metadata** → Binary-Header / ASCII-Header |
| 49 | +* **Binary-Header** → {lowercase ASCII header name ending in “-bin” } {_base64 encoded value_} |
| 50 | +* **ASCII-Header** → {lowercase ASCII header name} {_value_} |
| 51 | + |
| 52 | + |
| 53 | +HTTP2 requires that reserved headers, ones starting with “:” appear before all other headers. Additionally implementations should send **Timeout** immediately after the reserved headers and they should send the **Call-Definition** headers before sending **Custom-Metadata**. |
| 54 | + |
| 55 | +If **Timeout** is omitted a server should assume an infinite timeout. Client implementations are free to send a default minimum timeout based on their deployment requirements. |
| 56 | + |
| 57 | +**Custom-Metadata** is an arbitrary set of key-value pairs defined by the application layer. Aside from transport limits on the total length of HTTP2 HEADERS the only other constraint is that header names starting with “grpc-” are reserved for future use. |
| 58 | + |
| 59 | +Note that HTTP2 does not allow arbitrary octet sequences for header values so binary header values must be encoded using Base64 as per [https://tools.ietf.org/html/rfc4648#section-4](https://tools.ietf.org/html/rfc4648#section-4). Implementations MUST accept padded and un-padded values and should emit un-padded values. Applications define binary headers by having their names end with “-bin”. Runtime libraries use this suffix to detect binary headers and properly apply base64 encoding & decoding as headers are sent and received. |
| 60 | + |
| 61 | +The repeated sequence of **Delimited-Message** items is delivered in DATA frames |
| 62 | + |
| 63 | +* **Delimited-Message** → Compressed-Flag Message-Length Message |
| 64 | +* **Compressed-Flag** → 0 / 1 # encoded as 1 byte unsigned integer |
| 65 | +* **Message-Length** → {_length of Message_} # encoded as 4 byte unsigned integer |
| 66 | +* **Message** → *{binary octet} |
| 67 | + |
| 68 | +A **Compressed-Flag** value of 1 indicates that the binary octet sequence of **Message** is compressed using the mechanism declared by the **Message-Encoding** header. A value of 0 indicates that no encoding of **Message** bytes has occurred. Compression contexts are NOT maintained over message boundaries, implementations must create a new context for each message in the stream. If the **Message-Encoding** header is omitted then the **Compressed-Flag** must be 0. |
| 69 | + |
| 70 | +For requests, **EOS** (end-of-stream) is indicated by the presence of the END_STREAM flag on the last received DATA frame. In scenarios where the **Request** stream needs to be closed but no data remains to be sent implementations MUST send an empty DATA frame with this flag set. |
| 71 | + |
| 72 | +##Responses |
| 73 | + |
| 74 | +* **Response** → (Response-Headers *Delimited-Message Trailers) / Trailers-Only |
| 75 | +* **Response-Headers** → HTTP-Status [Message-Encoding] [Message-Accept-Encoding] Content-Type *Custom-Metadata |
| 76 | +* **Trailers-Only** → HTTP-Status Content-Type Trailers |
| 77 | +* **Trailers** → Status [Status-Message] *Custom-Metadata |
| 78 | +* **HTTP-Status** → “:status 200” |
| 79 | +* **Status** → “grpc-status” <status-code-as-ASCII-string> |
| 80 | +* **Status-Message** → “grpc-message” <descriptive text for status as ASCII string> |
| 81 | + |
| 82 | +**Response-Headers** & **Trailers-Only** are each delivered in a single HTTP2 HEADERS frame block. Most responses are expected to have both headers and trailers but **Trailers-Only** is permitted for calls that produce an immediate error. Status must be sent in **Trailers** even if the status code is OK. |
| 83 | + |
| 84 | +For responses end-of-stream is indicated by the presence of the END_STREAM flag on the last received HEADERS frame that carries **Trailers**. |
| 85 | + |
| 86 | +Implementations should expect broken deployments to send non-200 HTTP status codes in responses as well as a variety of non-GRPC content-types and to omit **Status** & **Status-Message**. Implementations must synthesize a **Status** & **Status-Message** to propagate to the application layer when this occurs. |
| 87 | + |
| 88 | +## Example |
| 89 | + |
| 90 | +Sample unary-call showing HTTP2 framing sequence |
| 91 | + |
| 92 | +**Request** |
| 93 | + |
| 94 | +``` |
| 95 | +HEADERS (flags = END_HEADERS) |
| 96 | +:method = POST |
| 97 | +:scheme = http |
| 98 | +:path = /google.pubsub.v2.PublisherService/CreateTopic |
| 99 | +:authority = pubsub.googleapis.com |
| 100 | +grpc-timeout = 1S |
| 101 | +content-type = application/grpc+proto |
| 102 | +grpc-encoding = gzip |
| 103 | +authorization = Bearer y235.wef315yfh138vh31hv93hv8h3v |
| 104 | +
|
| 105 | +DATA (flags = END_STREAM) |
| 106 | +<Delimited Message> |
| 107 | +``` |
| 108 | +**Response** |
| 109 | + |
| 110 | +``` |
| 111 | +HEADERS (flags = END_HEADERS) |
| 112 | +:status = 200 |
| 113 | +grpc-encoding = gzip |
| 114 | +
|
| 115 | +DATA |
| 116 | +<Delimited Message> |
| 117 | +
|
| 118 | +HEADERS (flags = END_STREAM, END_HEADERS) |
| 119 | +grpc-status = 0 # OK |
| 120 | +trace-proto-bin = jher831yy13JHy3hc |
| 121 | +``` |
| 122 | +## User Agents |
| 123 | + |
| 124 | +While the protocol does not require a user-agent to function it is recommended that clients provide a structured user-agent string that provides a basic description of the calling library, version & platform to facilitate issue diagnosis in heterogeneous environments. The following structure is recommended to library developers: |
| 125 | + |
| 126 | +``` |
| 127 | +User-Agent → “grpc-” Language ?(“-” Variant) “/” Version ?( “ (“ *(AdditionalProperty “;”) “)” ) |
| 128 | +``` |
| 129 | +E.g. |
| 130 | + |
| 131 | +``` |
| 132 | +grpc-java/1.2.3 |
| 133 | +grpc-ruby/1.2.3 |
| 134 | +grpc-ruby-jruby/1.3.4 |
| 135 | +grpc-java-android/0.9.1 (gingerbread/1.2.4; nexus5; tmobile) |
| 136 | +``` |
| 137 | +## HTTP2 Transport Mapping |
| 138 | + |
| 139 | +### Stream Identification |
| 140 | +All GRPC calls need to specify an internal ID. We will use HTTP2 stream-ids as call identifiers in this scheme. NOTE: These id’s are contextual to an open HTTP2 session and will not be unique within a given process that is handling more than one HTTP2 session nor can they be used as GUIDs. |
| 141 | + |
| 142 | +### Data Frames |
| 143 | +DATA frame boundaries have no relation to **Delimited-Message** boundaries and implementations should make no assumptions about their alignment. |
| 144 | + |
| 145 | +### Errors |
| 146 | + |
| 147 | +When an application or runtime error occurs during an RPC a **Status** and **Status-Message** are delivered in **Trailers**. |
| 148 | + |
| 149 | +In some cases it is possible that the framing of the message stream has become corrupt and the RPC runtime will choose to use an **RST_STREAM** frame to indicate this state to its peer. RPC runtime implementations should interpret RST_STREAM as immediate full-closure of the stream and should propagate an error up to the calling application layer. |
| 150 | + |
| 151 | +The following mapping from RST_STREAM error codes to GRPC error codes is applied. |
| 152 | + |
| 153 | +HTTP2 Code|GRPC Code |
| 154 | +----------|----------- |
| 155 | +NO_ERROR(0)|INTERNAL - An explicit GRPC status of OK should have been sent but this might be used to aggressively lameduck in some scenarios. |
| 156 | +PROTOCOL_ERROR(1)|INTERNAL |
| 157 | +INTERNAL_ERROR(2)|INTERNAL |
| 158 | +FLOW_CONTROL_ERROR(3)|INTERNAL |
| 159 | +SETTINGS_TIMEOUT(4)|INTERNAL |
| 160 | +STREAM_CLOSED|No mapping as there is no open stream to propagate to. Implementations should log. |
| 161 | +FRAME_SIZE_ERROR|INTERNAL |
| 162 | +REFUSED_STREAM|UNAVAILABLE - Indicates that no processing occurred and the request can be retried, possibly elsewhere. |
| 163 | +CANCEL(8)|Mapped to call cancellation when sent by a client.Mapped to CANCELLED when sent by a server. Note that servers should only use this mechanism when they need to cancel a call but the payload byte sequence is incomplete. |
| 164 | +COMPRESSION_ERROR|INTERNAL |
| 165 | +CONNECT_ERROR|INTERNAL |
| 166 | +ENHANCE_YOUR_CALM|RESOURCE_EXHAUSTED ...with additional error detail provided by runtime to indicate that the exhausted resource is bandwidth. |
| 167 | +INADEQUATE_SECURITY| PERMISSION_DENIED … with additional detail indicating that permission was denied as protocol is not secure enough for call. |
| 168 | + |
| 169 | + |
| 170 | +### Security |
| 171 | + |
| 172 | +The HTTP2 specification mandates the use of TLS 1.2 or higher when TLS is used with HTTP2. It also places some additional constraints on the allowed ciphers in deployments to avoid known-problems as well as requiring SNI support. It is also expected that HTTP2 will be used in conjunction with proprietary transport security mechanisms about which the specification can make no meaningful recommendations. |
| 173 | + |
| 174 | +###Connection Management |
| 175 | +#### GOAWAY Frame |
| 176 | +Sent by servers to clients to indicate that they will no longer accept any new streams on the associated connections. This frame includes the id of the last successfully accepted stream by the server. Clients should consider any stream initiated after the last successfully accepted stream as UNAVAILABLE and retry the call elsewhere. Clients are free to continue working with the already accepted streams until they complete or the connection is terminated. |
| 177 | + |
| 178 | +Servers should send GOAWAY before terminating a connection to reliably inform clients which work has been accepted by the server and is being executed. |
| 179 | + |
| 180 | +####PING Frame |
| 181 | +Both clients and servers can send a PING frame that the peer must respond to by precisely echoing what they received. This is used to assert that the connection is still live as well as providing a means to estimate end-to-end latency. If a server initiated PING does not receive a response within the deadline expected by the runtime all outstanding calls on the server will be closed with a CANCELLED status. An expired client initiated PING will cause all calls to be closed with an UNAVAILABLE status. Note that the frequency of PINGs is highly dependent on the network environment, implementations are free to adjust PING frequency based on network and application requirements. |
| 182 | + |
| 183 | +####Connection failure |
| 184 | +If a detectable connection failure occurs on the client all calls will be closed with an UNAVAILABLE status. For servers open calls will be closed with a CANCELLED status. |
| 185 | + |
| 186 | + |
| 187 | +## Appendix A - GRPC for Protobuf |
| 188 | + |
| 189 | +The service interfaces declared by protobuf are easily mapped onto GRPC by code generation extensions to protoc. The following defines the mapping to be used |
| 190 | + |
| 191 | + |
| 192 | +* **Path** → / Service-Name / {_method name_} |
| 193 | +* **Service-Name** → ?( {_proto package name_} "." ) {_service name_} |
| 194 | +* **Message-Type** → {_fully qualified proto message name_} |
| 195 | +* **Content-Type** → "application/grpc+proto" |
| 196 | + |
| 197 | + |
0 commit comments