diff --git a/docs/configuration/http_filters/grpc_http1_bridge_filter.rst b/docs/configuration/http_filters/grpc_http1_bridge_filter.rst index 25cdc5da60cb..2f9861ddfbfd 100644 --- a/docs/configuration/http_filters/grpc_http1_bridge_filter.rst +++ b/docs/configuration/http_filters/grpc_http1_bridge_filter.rst @@ -1,12 +1,12 @@ .. _config_http_filters_grpc_bridge: -GRPC HTTP/1.1 bridge +gRPC HTTP/1.1 bridge ==================== -GRPC :ref:`architecture overview `. +gRPC :ref:`architecture overview `. This is a simple filter which enables the bridging of an HTTP/1.1 client which does not support -response trailers to a compliant GRPC server. It works by doing the following: +response trailers to a compliant gRPC server. It works by doing the following: * When a request is sent, the filter sees if the connection is HTTP/1.1 and the request content type is *application/grpc*. @@ -17,7 +17,7 @@ response trailers to a compliant GRPC server. It works by doing the following: * The client should send HTTP/1.1 requests that translate to the following psuedo headers: * *\:method*: POST - * *\:path*: + * *\:path*: * *content-type*: application/grpc * The body should be the serialized grpc body which is: @@ -27,12 +27,12 @@ response trailers to a compliant GRPC server. It works by doing the following: * serialized proto message. * Because this scheme must buffer the response to look for the *grpc-status* trailer it will only - work with unary GRPC APIs. + work with unary gRPC APIs. More info: http://www.grpc.io/docs/guides/wire.html -This filter also collects stats for all GRPC requests that transit, even if those requests are -normal GRPC requests over HTTP/2. +This filter also collects stats for all gRPC requests that transit, even if those requests are +normal gRPC requests over HTTP/2. .. code-block:: json diff --git a/docs/configuration/overview/rate_limit.rst b/docs/configuration/overview/rate_limit.rst index b24a2cb1690c..6791490ffa99 100644 --- a/docs/configuration/overview/rate_limit.rst +++ b/docs/configuration/overview/rate_limit.rst @@ -29,10 +29,10 @@ config service. The client will connect to this cluster when it needs to make rate limit service requests. -GRPC service IDL +gRPC service IDL ---------------- -Envoy expects the rate limit service to support the GRPC IDL specified in +Envoy expects the rate limit service to support the gRPC IDL specified in :repo:`/source/common/ratelimit/ratelimit.proto`. See the IDL documentation for more information on how the API works. In the future Lyft will open source a reference service implementation written in Go. diff --git a/docs/intro/arch_overview/global_rate_limiting.rst b/docs/intro/arch_overview/global_rate_limiting.rst index 0c85b5a0d4a9..ef7183184d75 100644 --- a/docs/intro/arch_overview/global_rate_limiting.rst +++ b/docs/intro/arch_overview/global_rate_limiting.rst @@ -13,7 +13,7 @@ tight enough circuit breaking limit on each downstream host such that the system normally during typical request patterns but still prevent cascading failure when the system starts to fail. Global rate limiting is a good solution for this case. -Envoy integrates directly with a global GRPC rate limiting service. Although any service that +Envoy integrates directly with a global gRPC rate limiting service. Although any service that implements the defined RPC/IDL protocol can be used, Lyft provides a reference implementation written in Go which uses a Redis backend. Envoy’s rate limit integration has the following features: diff --git a/docs/intro/arch_overview/grpc.rst b/docs/intro/arch_overview/grpc.rst index 202613a3ee52..08a4a6506362 100644 --- a/docs/intro/arch_overview/grpc.rst +++ b/docs/intro/arch_overview/grpc.rst @@ -1,18 +1,18 @@ .. _arch_overview_grpc: -GRPC +gRPC ==== -`GRPC `_ is a new RPC framework from Google. It uses protocol buffers as the +`gRPC `_ is a new RPC framework from Google. It uses protocol buffers as the underlying serialization/IDL format. At the transport layer it uses HTTP/2 for request/response -multiplexing. Envoy has first class support for GRPC both at the transport layer as well as at the +multiplexing. Envoy has first class support for gRPC both at the transport layer as well as at the application layer: -* GRPC makes use of HTTP/2 trailers to convey request status. Envoy is one of very few HTTP proxies +* gRPC makes use of HTTP/2 trailers to convey request status. Envoy is one of very few HTTP proxies that correctly supports HTTP/2 trailers and is thus one of the few proxies that can transport - GRPC requests and responses. -* The GRPC runtime for some languages is relatively immature. Envoy supports a GRPC :ref:`bridge - filter ` that allows GRPC requests to be sent to Envoy over + gRPC requests and responses. +* The gRPC runtime for some languages is relatively immature. Envoy supports a gRPC :ref:`bridge + filter ` that allows gRPC requests to be sent to Envoy over HTTP/1.1. Envoy then translates the requests to HTTP/2 for transport to the target server. The response is translated back to HTTP/1.1. * When installed, the bridge filter gathers per RPC statistics in addition to the standard array diff --git a/docs/intro/comparison.rst b/docs/intro/comparison.rst index 9d32966e7c6a..054d6dcd2082 100644 --- a/docs/intro/comparison.rst +++ b/docs/intro/comparison.rst @@ -97,10 +97,10 @@ versus a library that must be built into something by each project individually. `gRPC `_ ----------------------------- -GRPC is a new multi-platform message passing system out of Google. It uses an IDL to describe an RPC +gRPC is a new multi-platform message passing system out of Google. It uses an IDL to describe an RPC library and then implements application specific runtimes for a variety of different languages. The -underlying transport is HTTP/2. Although GRPC likely has the goal of implementing many Envoy like +underlying transport is HTTP/2. Although gRPC likely has the goal of implementing many Envoy like features in the future (load balancing, etc.), as of this writing the various runtimes are somewhat -immature and are primarily focused on serialization/de-serialization. We consider GRPC to be a -companion to Envoy versus a competitor. How Envoy integrates with GRPC is described :ref:`here +immature and are primarily focused on serialization/de-serialization. We consider gRPC to be a +companion to Envoy versus a competitor. How Envoy integrates with gRPC is described :ref:`here `. diff --git a/docs/intro/deployment_types/service_to_service.rst b/docs/intro/deployment_types/service_to_service.rst index 1eafdae72997..9f16d8063e1e 100644 --- a/docs/intro/deployment_types/service_to_service.rst +++ b/docs/intro/deployment_types/service_to_service.rst @@ -14,7 +14,7 @@ Service to service egress listener ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the port used by applications to talk to other services in the infrastructure. For example, -*http://localhost:9001*. HTTP and GRPC requests use the HTTP/1.1 *host* header or the HTTP/2 +*http://localhost:9001*. HTTP and gRPC requests use the HTTP/1.1 *host* header or the HTTP/2 *:authority* header to indicate which remote cluster the request is destined for. Envoy handles service discovery, load balancing, rate limiting, etc. depending on the details in the configuration. Services only need to know about the local Envoy and do not need to concern @@ -30,7 +30,7 @@ Service to service ingress listener This is the port used by remote Envoys when they want to talk to the local Envoy. For example, *http://localhost:9211*. Incoming requests are routed to the local service on the configured port(s). Multiple application ports may be involved depending on application or load balancing -needs (for example if the service needs both an HTTP port and a GRPC port). The local Envoy +needs (for example if the service needs both an HTTP port and a gRPC port). The local Envoy performs buffering, circuit breaking, etc. as needed. Our default configurations use HTTP/2 for all Envoy to Envoy communication, regardless of whether diff --git a/docs/intro/what_is_envoy.rst b/docs/intro/what_is_envoy.rst index b1c020aedd64..f1b1c3420162 100644 --- a/docs/intro/what_is_envoy.rst +++ b/docs/intro/what_is_envoy.rst @@ -60,9 +60,9 @@ requests based on path, authority, content type, :ref:`runtime `_ is a new RPC framework from Google that uses HTTP/2 +**gRPC support:** `gRPC `_ is a new RPC framework from Google that uses HTTP/2 as the underlying multiplexed transport. Envoy :ref:`supports ` all of the -HTTP/2 features required to be used as the routing and load balancing substrate for GRPC requests +HTTP/2 features required to be used as the routing and load balancing substrate for gRPC requests and responses. The two systems are very complementary. **MongoDB L7 support:** `MongoDB `_ is a popular database used in modern diff --git a/docs/landing_generated/index.html b/docs/landing_generated/index.html index 7191c9f766d9..4c6c312496db 100644 --- a/docs/landing_generated/index.html +++ b/docs/landing_generated/index.html @@ -108,7 +108,7 @@

TLS: Envoy supports both TLS termination and initiation, client certificate verification, and certificate pinning.

-

GRPC: Envoy has first class support for Google's GRPC framework.

+

gRPC: Envoy has first class support for Google's gRPC framework.

MongoDB: Envoy contains a full MongoDB wire format parser that is used to gather statistics about database connections.

DynamoDB: Envoy contains a full DynamoDB API parser that is used to gather diff --git a/docs/landing_source/source/localizable/index.html.erb b/docs/landing_source/source/localizable/index.html.erb index 6feb28ad2b95..4adc80e24095 100644 --- a/docs/landing_source/source/localizable/index.html.erb +++ b/docs/landing_source/source/localizable/index.html.erb @@ -70,7 +70,7 @@ layout: layout

TLS: Envoy supports both TLS termination and initiation, client certificate verification, and certificate pinning.

-

GRPC: Envoy has first class support for Google's GRPC framework.

+

gRPC: Envoy has first class support for Google's gRPC framework.

MongoDB: Envoy contains a full MongoDB wire format parser that is used to gather statistics about database connections.

DynamoDB: Envoy contains a full DynamoDB API parser that is used to gather