nginx / unit

NGINX Unit - universal web app server - a lightweight and versatile open source server that simplifies the application stack by natively executing application code across eight different programming language runtimes.
https://unit.nginx.org
Apache License 2.0
5.4k stars 330 forks source link

HTTP/2 support #388

Open ghost opened 4 years ago

robjr commented 4 years ago

Any update when this will be available?

VBart commented 4 years ago

Any update when this will be available?

There's no ETA yet. Right now this isn't a top priority feature as Unit still lacks some essential functionality like SNI or statistics API. HTTP/2 can be temporary compensated via nginx proxy in front.

Anyway, I hope to see HTTP/2 till the end of the year at least in some limited support.

Could you elaborate a bit more about your case? Do you need HTTP/2 on client side, or for proxy as well?

robjr commented 4 years ago

Thanks @VBart I wanted to have the header compression benefit on a small service where only Nginx unit is enough, but then I will add nginx in front.

gertcuykens commented 3 years ago

Hmm when you need to resort to proxy passing a nginx server in front of unit doesn't it defeat the general purpose of unit? Because when you need to proxy pass anyway, why not nginx proxy pass it directly to your native app service instead of unit? Don't get me wrong I do see why unit is a very nice app server, but if you need to put a proxy in front of it anyway that kind of defeats the purpose of a all in one easy to maintain app server I would think?

I am also having a hard time understanding why large portions of the nginx code base can't be used for http2? It just worries me a bit that it takes so long to implement http2, I mean http3 is just around the corner :) and if http2 is already difficult I don't want to know how much effort it going to take for http3 which I think is allooot more complicated than http2. Can't the developers who did the http2 for nginx give some hint or clues what the best way forward is to implement this in unit?

https://github.com/nginx/unit/issues/554

VBart commented 3 years ago

@gertcuykens

why not nginx proxy pass it directly to your native app service instead of unit?

Anyway you need some software to be responsible for running, monitoring, scaling that service and maintaining connections: PHP-FPM, Gunicorn, Unicorn... or that can be Unit.

Unit isn't just an app server. It's a multi-purpose web-server, that is able to proxy, serve static media, and finally run apps. For example, you can use Unit just to serve static files and that's perfectly fine. You don't need proxy in front of it unless you need some features that are currently missing.

I am also having a hard time understanding why large portions of the nginx code base can't be used for http2?

Because Unit has completely different architecture and incompatible with nginx internal APIs in almost all aspects. There's just no such large portion that can be taken from nginx and reused saving some significant effort for the implementation.

It just worries me a bit that it takes so long to implement http2

It doesn't take so long to implement. It's still not implemented because nobody is working on it, as we have other tasks with higher priorities and all dev resources are busy with that work.

mercurykd commented 2 years ago

only the absence of http2 prevents the transfer of projects from nginx to nginx-unit. Have you got some news?

lcrilly commented 1 year ago

HTTP/2 and gRPC support is still on the wish list, but not currently planned.

lone-cat commented 1 year ago

Up. Looking forward for http/2 =)

pikhovkin commented 1 year ago

let's http2

Pavlusha311245 commented 1 year ago

We are still waiting HTTP/2 =)

ac000 commented 1 year ago

Would it be worth doing HTTP/2? and instead just go straight to HTTP/3...

It seems to me that HTTP/2 is one of those things we wish we could uninvent.

lcrilly commented 1 year ago

Hi @Pavlusha311245 , I enjoyed your blog post on habr.com 👏

Is there a gRPC requirement here, or a strong desire for multiplexing? I'm curious which parts of H/2 are attractive?

Pavlusha311245 commented 1 year ago

Hi @Pavlusha311245 , I enjoyed your blog post on habr.com 👏

Is there a gRPC requirement here, or a strong desire for multiplexing? I'm curious which parts of H/2 are attractive?

Hi @lcrilly. Thank you very much for reading my article 😀 . Of course, gRPC will play the main role here, I would like to use it together with Nginx Unit for projects)

Pavlusha311245 commented 1 year ago

Any updates? =)

lcrilly commented 1 year ago

No change. We would like to support gRPC applications but H/2 support is not yet planned.

As per @ac000 's comments, we might get lucky and be able to jump straight to H/3 in the future. Currently we wait to see what happens with https://github.com/grpc/grpc/issues/19126

Pavlusha311245 commented 1 year ago

Thanks for the update. I will follow grpc issue. I hope implementations will appear asap 😁.

ivanpepelko commented 10 months ago

First one here in 2024 to ask: is there an update? :)

nklmilojevic commented 8 months ago

Hi - I see that the issue is now moved to ice-box. Is there support for HTTP2/3 planned or it is on hiatus?

danielchristianschroeter commented 5 months ago

The integration of HTTP/2 and HTTP/3 into Nginx Unit would address the demand for modern protocol support, offering enhanced performance through improved connection management and header compression, as well as reduced latency and better security. These updates would ensure that Nginx Unit remains at the forefront of serving dynamic web content efficiently and securely.

sinedoOo commented 4 months ago

Any specific reason why so popular and crucial feature is in Ice-Box?

ac000 commented 4 months ago

I would argue the crucial part...

It simply hasn't been a priority for us. HTTP 1.1 simply works well enough. One of the main things HTTP 2.0 was supposed to do was solve the head-of-line blocking issue, except it didn't really, it just moved it from the HTTP layer to the TCP layer.

HTTP/3 is somewhat more interesting however...