elasticsearch
elasticsearch copied to clipboard
elastic
support HTTP/2.0
Is ElasticSearch planning to add support (or maybe plugin for) protocol HTTP/2.0? Like in https://github.com/grpc/grpc(used HTTP/2.0) or may be with grpc
This is now possible since we have moved to Netty 4, since Netty supports HTTPP/2.0 in 4.1+ /cc @jasontedor
To be clear, Netty 4 supports HTTP/2 but there is effort required to make Elasticsearch use it, and ensure that it works properly.
Is there any new thinking on supporting h2? It seems like a fruit hanging so high it'll probably take a magic beanstalk to reach, but I'm interested in any thoughts you might have on the cost-benefit equation. I imagine there are bigger wins in first-class client support and alternative APIs that take advantage of more stream-oriented connections in supporting h2 within Elasticsearch itself over just exposing through a h2-enabled proxy.
Any updates on this? With the deprecated TransportClient, there should for sure be HTTP/2 or/and gRPC support.
At this time there is no update on this other than that we are not currently working on it; this not to say that we will not, only that we feel there are higher priority projects. I do not agree that the deprecation of the transport client implies that there should be HTTP/2 support. Can share why you think that the two are tied together?
Thanks for a quick answer.
HTTP/1.1 is limited in the sense that any concurrent operations cannot happen on the same connection and creating a new connection is a huge performance trade-off.
HTTP/2 or gRPC which is based on the former is multiplexing by nature, so is closer to the non-blocking TransportClient.
If we want to keep the transport overhead low, we can't go with REST+HTTP/1.1.
@mantasindrasius Thanks for the feedback. I agree with you on the benefits of HTTP/2.
I do think it's worth noting that with HTTP/1.1 keep alive behavior and a connection pool that you can mitigate some of the disadvantages of HTTP/1.1 versus HTTP/2.0. The best that HTTP/1.1 can offer related to multiplexing is pipelining. Yes, this suffers from head-of-line blocking but it does allow some connection reuse too.
That said, even weighing these advantages and disadvantages, I would prefer that we continue to not tie removal of the transport client to the introduction of HTTP/2. Removing the transport client will bring us major advantages in continuing to develop the server side of Elasticsearch without maintaining a client that is so intimately tied to the internal protocol. These advantages outweigh the loss of benefits of the transport client.
Rest assured that HTTP/2 is on our roadmap, just not at the top of the list at the moment.
Thanks for that. Do you also think there could be gRPC support for elastic or it's not on the table?
@jasongoodwin ELK don't work in OKD 3.11 (Openshift) correctly because there is no support of H2\grpc protocols. See: https://github.com/elastic/kibana/issues/7104 and https://github.com/openshift/origin-aggregated-logging/issues/1465
UPD#1: Yeah...i disable h2 and kibana work perfectly. Enable and stop working) Is there ant information when kibana will support h2?
Are there any news here? AWS NLB has finally ALPN support for the TLS Listener, which would help for the gRPC handshake/http2 connection
https://www.reddit.com/r/aws/comments/gsdo3w/nlb_now_supports_alpn_on_tls_listeners/
Do you have any plan to do that in near future ? i would like to see it if it is in your roadmap. Thanks
Any updates here?
AWS ALB has finally gRPC support built in GCP had it all the time
I endorse http2 too!
One solution for me at this moment, if anyone is interested, is to avoid elasticsearch oficcial client (in a nodejs service that only uses _search), and to use superagent + agentkeepalive, with, in my case of use, maxSockets uninformed, assuming the default value of Infinity. This way I have the connection pool working under the hood, mitigating the http1 limitation as @jasontedor well said.
