The requirement of my application is to send the data from the server to the client once the connection is established over HTTP/2.
I have opted to go with a combination of SSE for frontend and HTTP/2 Pusher in the backend.
But since gRPC is in general availability for the browser clients, I am thinking to switch to gRPC (because of simpler structure and protobufs) but I couldn't find any performance benchmarks for these two.
So whats better Http/2 with Pusher making a uni-directional channel or gRPC with a bi-directional channel.
Related
I am a little bit confused about grpc and http/2. From what I learned, grpc is a RPC framework and can use different types of transports and http/2 is just one of the transports.
In golang, grpc.Dial() will create a connection to the server and the grpc server is created by grpc#Server.Serve(). So what is this connection? Is that a http/2 connection?
Thank you very much for your help.
When you connect to a server with gRPC, that does establish a single HTTP/2 connection that can be shared between many gRPC requests (the channel concept).
gRPC is indeed an RPC framework, built on HTTP/2. By default, it uses Protobufs as the serialization protocol, but that can be customised.
Think of gRPC as an RPC application layer over HTTP/2. To quote the FAQ:
"... gRPC is also a set of libraries that will provide higher-level features consistently across platforms that common HTTP libraries typically do not. Examples of such features include:
interaction with flow-control at the application layer
cascading call-cancellation
load balancing & failover
"
I'm just curious if I'm missing something in http2 that would make it more efficient in service-to-service communication, for example in a microservice architecture.
Are its improvements just related to end-users (browsers)?
If you are issuing many concurrent requests between microservices, then there's benefit from connection multiplexing. You do not need to manage TCP connection pools on the client, and restrict the number of incoming TCP connections at the service side.
Some services might benefit from server push, though it really depends on what the service does.
Headers compression can be useful if you have high traffic volumes to the service with repeated meta-data. More information can be found here.
In summary, yes, it is designed more with end users in mind, but there's value for RESTful microservices as well, especially due to connection multiplexing.
HTTP/2 adds an additional aspect to service-to-service communication that was not mandatory with HTTP/1.1. And that is security in form of SSL/TLS.
Although not required by the RFC standard, almost all HTTP/2 servers and clients will only support HTTP/2 over TLS, which makes encryption de facto mandatory.
So if you want to offer and consume microservices over HTTP/2, you have to think about ways to create, manage and distribute SSL-certificates to servers and clients.
Consequently, moving to HTTP/2 means introducing a new stack of technology, e.g. a public key infrastructure, to your service eco system.
Another way to make your services HTTP/2-ready for your service consumers would be to place a reverse proxy between your HTTP/2-enabled consumers and your HTTP/1.1 services.
The proxy would terminate the HTTP/2 connections from the consumers and translate them into HTTP/1.1 requests for your servers (and vise-versa).
This would implement a separation of concern, where your services would only be responsible for their business-logic stuff, while the proxies would handle the certificates and encryption. But again, you would add more complexity to your system.
More Complexity, but also better use of network resources
More complexity is what you are paying with. But you get a smarter consumption of network resources for it. With HTTP/1.1 you can have multiple TCP connections between one client and a server. And opening multiple connection is almost always necessary to overcome HTTP/1.1's performance drawbacks.
Establishing TCP connections is an expensive task, though. In order to create them DNS lookup, TCP handshake and SSL handshake are necessary.
HTTP/2 limits the number of open TCP-connections between one client and one server to exactly one (1). But at the same time, HTTP/2 brings us connection multiplexing, i.e. you can have multiple HTTP conversations simultaneously over the same TCP connection (HTTP/1.1: 1 TCP-connection = 1 HTTP connection).
I've read some articles comparing the differences between WebSocket and the other push methods like Long polling. All the conclusions tend to be WebSocket is better then HTTP with low latency in the server and client bidirectional communication process.
But if server push is not a must, for example, a client game program just make a few queries to the server for some information, does it still better to use WebSocket then HTTP? More specially, I have two doubts here:
1. In a single Request-Response procedure, which is more efficency ? (I establish a WebSocket connection each time querying in the above case.)
2. Will the server capacity (The total number of clients that the server can serve) be affected by the unnecessary long-lived connection if I keep an WebSocket connection during the life cycle of the client?
Added Question:
3. Suppose there is only one TCP connection between the server and the client, will the stability of the connection go down and down as time flows?
The basic thing behind both the WebSocket and HTTP is the socket. In HTTP, it opens a connection on request and closes on response. For WebSocket, concept is a 2 way communication (full duplex) rather than request-response cycle.
Answers to your question:
Either you can use HTTP server or can create request-response design
using WebSocket
That's obvious. Each connection is a socket object. Server capacity
will be affected if we are not managing connections.
In WebSocket, it's using ping-pong mechanism to make sure that the client or
the server is alive. For every ping requests from one end, other end is
subjected to reply a pong response. This mechanism helps to detect failures and hence to maintain stability.
Websocket is designed in such a way that its servers can share a port with HTTP servers, by having its handshake be a valid HTTP Upgrade request.
I have a doubt in this design philosophy.
Any ways the WebSocket Protocol is an independent TCP-based protocol.
Why would we need this HTTP handshake(upgrade request) and a protocol switching. Instead why can't we directly(& independently) follow a websocket like protocol?
To quote from the IETF 6455 WebSocket spec:
The WebSocket Protocol attempts to address the goals of existing
bidirectional HTTP technologies in the context of the existing HTTP
infrastructure; as such, it is designed to work over HTTP ports 80
and 443 as well as to support HTTP proxies and intermediaries, even
if this implies some complexity specific to the current environment.
However, the design does not limit WebSocket to HTTP, and future
implementations could use a simpler handshake over a dedicated port
without reinventing the entire protocol.
In other words, there is a vast infrastructure for HTTP and HTTPS that already exists (proxies, firewalls, caches, and other intermediaries). In order to increase the chances of being adopted widely, the WebSocket protocol was designed to allow adjustments and extensions to the existing infrastructure without having to recreate everything from scratch to support a new protocol on a dedicate port.
It's also important to note that even if WebSocket protocol were to get rid of the HTTP compatible handshake, it would still need a handshake of almost equivalent complexity to support security requirements of the modern web so the browser and server can validate each other and to support CORS (cross-origin request sharing) securely. Even "raw" Flash sockets do a handshake with the server via the security policy request prior to creating the actual socket.
From this article on Wikipedia:
Keepalive messages were not officially
supported in HTTP 1.0. In HTTP 1.1 all
connections are considered persistent,
unless declared otherwise.
Does this mean that using this
mechanism I can actually simulate a
TCP socket connection?
Using this can I make a Server
"push" data to a client?
Are all HTTP connections, even the
one I am using to connect to Stack
Overflow "HTTP persistent"?
Does the COMET technology of
server push use this mechanism of
HTTP persistent connection to push
data to clients?
Does this mean that using this mechanism I can actually simulate a
TCP socket connection?
Not really, sockets have MANY more features and flexibility.
Using this can I make a Server "push" data to a client?
Not directly, it's still a request/response protocol; the persistent connection just means the client can use the same underlying socket to send multiple requests and receive the respective responses.
Are all HTTP connections, even the one I am using to connect to Stack
Overflow "HTTP persistent"?
Unless your browser (or a peculiar server) says otherwise, yes.
Does the COMET technology of server push use this mechanism of HTTP
persistent connection to push data to
clients?
Kinda (for streaming, at least), but with a lot of whipped cream on top. There are other Comet implementation approaches, such as hidden iframes and AJAX long polling, that may not require persistent connections (which give some firewalls &c the fits anyway;-).
Actually, the HTTP server can "push" data to a connected http client without the client requesting it. See "HTTP server push" at http://en.wikipedia.org/wiki/Push_technology. However it does seem to be commonly implemented.