4 ms·

To be fair, the majority of benefits for HTTP/2 and QUIC are for the browser and experienced at the edge of your service. While that's not to say having the opt

To be fair, the majority of benefits for HTTP/2 and QUIC are for the browser and experienced at the edge of your service. While that's not to say having the option to pipe HTTP/2 to your gRPC servers wouldn't be nice the majority I've seen are using HTTP/1.1 at their application layer and what happens from there is a matter between consenting servers.

euyyn 8y ago
The counterpoint to that would be that, inside Google, it's all gRPC or Stubby.
- seangrogg 8y ago
  I counter your counter with this neither being an internal tool nor gRPC/Stubby owning even plurality utilization outside of Google.
imtringued 8y ago
If QUIC allows arbitrary length datagrams and retransmits them out of order then it's still going to be useful for video games and other systems with long lived connections. This is how I imagine how a replacement for TCP and UDP should work. But it doesn't look like there are standalone implementations of QUIC so I have no idea what the API actually looks like. There is only google's implementation which is part of chromium.
- Gazler 8y ago
  There are a few. This page lists the IETF QUIC implementations and gQUIC implementations (which is supported here) at the bottom. https://github.com/quicwg/base-drafts/wiki/Implementations https://github.com/quicwg/base-drafts/wiki/Implementations
manigandham 8y ago
HTTP/2 would still be great for upstreams to ensure HTTPS and make things much more efficient via compression and multiplexing. It makes a difference in higher-scale situations.
- bastawhiz 8y ago
  HTTP/2 as a spec doesn't demand HTTPS. Only browsers enforce this requirement. From a technical perspective, HTTP/2 makes little sense when you're commingling requests from different user agents. Header compression is ineffective. Persistent connections provide little benefit, as keep-alive works just as well in a data center environment. Between servers, there is no connection limit (as there is with browsers) so there isn't really head-of-line blocking issues that would go away when using HTTP/2. In general, you're unlikely to benefit materially from using HTTP/2 (versus vanilla HTTPS) between your edge servers and your application servers.
  - manigandham 8y ago
    Yes, with low traffic it won't matter, but "it makes a difference in higher-scale situations." We benefit materially when doing billions of daily requests. Servers don't have unlimited connections so HTTP/2 provides more throughput and concurrency over the same TCP connection pool, while also preventing any slow requests from affecting all other requests queued on the same connection. HPACK compression operates on individual headers and saving the keys alone can save significant overhead for smaller payloads, along with the binary protocol.

euyyn 8y ago

The counterpoint to that would be that, inside Google, it's all gRPC or Stubby.

seangrogg 8y ago
I counter your counter with this neither being an internal tool nor gRPC/Stubby owning even plurality utilization outside of Google.

imtringued 8y ago

If QUIC allows arbitrary length datagrams and retransmits them out of order then it's still going to be useful for video games and other systems with long lived connections. This is how I imagine how a replacement for TCP and UDP should work. But it doesn't look like there are standalone implementations of QUIC so I have no idea what the API actually looks like. There is only google's implementation which is part of chromium.

Gazler 8y ago
There are a few. This page lists the IETF QUIC implementations and gQUIC implementations (which is supported here) at the bottom. https://github.com/quicwg/base-drafts/wiki/Implementations https://github.com/quicwg/base-drafts/wiki/Implementations

manigandham 8y ago

HTTP/2 would still be great for upstreams to ensure HTTPS and make things much more efficient via compression and multiplexing. It makes a difference in higher-scale situations.

bastawhiz 8y ago
HTTP/2 as a spec doesn't demand HTTPS. Only browsers enforce this requirement. From a technical perspective, HTTP/2 makes little sense when you're commingling requests from different user agents. Header compression is ineffective. Persistent connections provide little benefit, as keep-alive works just as well in a data center environment. Between servers, there is no connection limit (as there is with browsers) so there isn't really head-of-line blocking issues that would go away when using HTTP/2. In general, you're unlikely to benefit materially from using HTTP/2 (versus vanilla HTTPS) between your edge servers and your application servers.
- manigandham 8y ago
  Yes, with low traffic it won't matter, but "it makes a difference in higher-scale situations." We benefit materially when doing billions of daily requests. Servers don't have unlimited connections so HTTP/2 provides more throughput and concurrency over the same TCP connection pool, while also preventing any slow requests from affecting all other requests queued on the same connection. HPACK compression operates on individual headers and saving the keys alone can save significant overhead for smaller payloads, along with the binary protocol.