HTTP/2 support

[liclac]

Is this planned at all? And if I was interested in implementing it myself, where would I start?

[ernado]

Hi, @uppfinnarn!

Is this planned at all?

https://github.com/valyala/fasthttp/blob/master/TODO
HTTP 2.0 is in TODO.

if I was interested in implementing it myself, where would I start?

Because fasthttp implements http stack from scratch, http2 support should implement RFC 7540 from scratch.

So, IMHO you can start just implementing RFC 7540 with the motto "Tuned for high performance. Zero memory allocations in hot paths." in mind and trying to reuse existing low-level pieces (e.g. bytesconv_*.go) It will take a lot of time, effort and research.

[newtack]

Are there any estimates as to when this would be available?

[akyoto]

This is a very important feature, HTTP/2 support would make the package faster in real word applications:

• Single Connection.
• Multiplexing.
• Header Compression.
• Server Push.
• Request Priority Levels.

Right now fasthttp might be winning unrealistic benchmarks but the official Go package supports HTTP/2 which is a big plus in real world applications.

I'd also be interested in helping fasthttp implementing HTTP/2.
Maybe take a look at H2O's C implementation, the fastest implementation afaik.

[DevotionGeo]

@valyala when will HTTP/2 support come to fasthttp? It will make it the preferred http package for Go.

Thank You!

[xgfone]

@DevotionGeo Since HTTP/2 is in TODO, but it gives me a feeling that there's no person to do it.

[xxx7xxxx]

HTTP/2 is worth implementing.

[gnanakeethan]

Are there any progress on HTTP/2?

[dgrr]

@gnanakeethan Hello. In this repository github.com/erikdubbelboer/fasthttp we are working to improve fasthttp library. Now we are working to implement http2.

[savsgio]

@TheMester Do you continue developing HTTP/2 for fasthttp?

[savsgio]

Or is there someone developing it?

[dgrr]

@savsgio I stopped because of exams. I want to follow after the next week.

[dgrr]

I created a repo here to develop http2 for fasthttp @kirillDanshin

[kirillDanshin]

@dgrr awesome! thanks for your work. is there any roadmap and current status? when you finish your work, we can embed it in the fasthttp and finally support http/2 officially. also, feel free to ping me if you have any questions

[dgrr]

@kirillDanshin we talk about embedding it in fasthttp and finally I decided to do not do this. Fasthttp has a good support for HTTP/1.x.
Embedding HTTP/2 will cause the change of the API internally making methods be forked to support HTTP/1.x and HTTP/2 and fasthttp more heavyer and probably slower in a few cases. This is caused because of the framing method that HTTP/2 follows. It is not header and body.
You can see my poor work here

[kirillDanshin]

@dgrr I think we should at least try and benchmark embedded version and see if we can get any better solution for this

[dgrr]

Okay. Let me finish fasthttp2 and we will try to embed it in original repo.

[kirillDanshin]

@dgrr huge shout-out to you for that work 👍

[dgrr]

There are anyone interested in participate in this project?

[erikdubbelboer]

I'm afraid I currently don't do anything with http2. I see you have continued working on your implementation. How is that going?

[dgrr]

I am blocked working on it. I tried to implement it in my repo but the main problem is the RequestCtx header fields handling.

HTTP/2 follows a frame by frame schema (like Websocket). There are many types of frames. The two main types are Headers and Data which in HTTP/1.x language are the same as the headers and a body in a HTTP Request/Response.
Also HTTP/2 is a multiplexed protocol which allows to handle multiple streams (multiple request/responses) in the same connection.
I thought to implement this with multiple RequestCtx's (RequestCtx per stream). But I have troubles handling RequestCtx in other package (third-party package).
So... I am trying to implement HTTP/2 in fasthttp natively but there are so many changes to do and this will be a huge change. I think that I can create a http2 branch in this repo and start making pull request along the developing process to help you to check every commit I do.

If you agree I can commit changes in my fasthttp fork and start making pull request in other branch (not master. http2?).

[erikdubbelboer]

I think if you implement http2 in the fasthttp repo instead of a separate one it makes the most sense to have it be one big pull request/commit. So working on a separate http2 branch in this repo and making pull requests to that branch sounds like a good idea. When everything works then we can rebase on master and squash into one big commit.

[skiloop]

There are anyone interested in participate in this project?

@dgrr I would like to participate in! How can I help? How is it going? Do you have any plan about the project?

[dgrr]

Hello @skiloop

Right now it's stopped because I am a little busy with my work and that stuff. But you can take a look here https://github.com/dgrr/http2
I successfully develop an adapter which is able to read the request but no to send a response. My plan is to adopt HTTP/2 natively in fasthttp, but for the moment I want to develop first a package to use HTTP/2 independently.

To summarize:

1. Finish the http2 package.
2. Make the http2 package works with fasthttp via adapter.
3. Copy that package functionalities to fasthttp so it can handle HTTP/2 requests natively.

[cipriancraciun]

Lately I've been working on a small "pet project" regarding a high performance static server, and I thought that for some use-cases HTTP/2 would be a perfect match (i.e. lots of small requests).

However given the complexity of HTTP/2, I would incline more towards keeping it out of the "main" fasthttp project, mainly because the current implementation is so HTTP/1 oriented that it would have a large impact retrofitting it to support both HTTP/1 and HTTP/2.

I wonder if it wouldn't be simpler for one to implement a fast HTTP/2 to HTTP/1 gateway, that would also benefit other projects.

[cipriancraciun]

Today I wondered "what if":

• one creates a single tls.Listener and configures NextProtos to include h2;
• instead of using that listener in both fasthttp.Server or net.http.Server, those will use "dummy" listeners that "accept connections" from a channel;
• then one listens on new connections, and for each new connection,
• calls tls.Conn.Handshake() and verifies if tls.Conn.ConnectionState().NegotiatedProtocol == "h2";
• if so it passes it to net.http.Server and implements the required net.http.Handler to fasthttp.RequestHandler adapter;
• if the negotiated protocol is not h2, then pass the newly created connection to fasthttp as normal;

Granted, it will be sub-optimal, but it would still allow one to have HTTP/2 and use fasthttp for HTTP/1.1 on TLS connections.

---

I've tried implementing this idea:
https://github.com/volution/kawipiko/blob/b6426f56552d9ec3583491d532df89788cb16f14/sources/cmd/server/server.go#L1271-L1327
https://github.com/volution/kawipiko/blob/b6426f56552d9ec3583491d532df89788cb16f14/sources/cmd/server/server.go#L1374
https://github.com/volution/kawipiko/blob/b6426f56552d9ec3583491d532df89788cb16f14/sources/cmd/server/server.go#L1387
(Ignore the rest of the code, as it's in a quite bad shape due to rapid prototyping...)

And apparently it works flawlessly, by using curl --http1.1 or curl --http2.

---

Any thoughts about this proposed "hack"?

Perhaps we could implement some of this code as part of fasthttp?

[dgrr]

@cipriancraciun I will develop more this comment but just want to let you know that I already successfully develop something like a gateway for HTTP/2 to fasthttp. The only concern I have on doing that is the performance. You can check that here

[dgrr]

Hello. I know it's been long but just wanted to tell you all that I have a working on HTTP/2 a little. Example here.

Why after 2 years I recovered that old work? Because the HTTP/2 library of the Golang's std sucks quite a lot. fasthttp (using HTTP/1.1) is faster than the Golang's HTTP/2. I tested that in a server made in with the net/http. That's ridiculous.

I want to create a full implementation (so client and server). If someone wants to help, I'll be appreciated!

[renanbastos93]

Do we have a date planned to use http2 on fasthttp?

[dgrr]

For now I am a bit busy. I'll continue working in a few weeks. The client is my priority number one. I'll do the server later.

[renanbastos93]

For now I am a bit busy. I'll continue working in a few weeks. The client is my priority number one. I'll do the server later.

alright, can you need help? anything you can call me

[dgrr]

@renanbastos93 you can pick the issue you want and start a discussion/solving the issue

[efectn]

Do you have any plan to release stable HTTP/2 adapter ?

[wxpjimmy]

Is there any ETA on this? Seems there's no progress on this for a while...

[ZQun]

@dgrr Do you have any plan to release stable HTTP/2 adapter ?

[G2G2G2G]

Just give up and add quic / http3.. http2 wasn't that great anyway

https://github.com/lucas-clemente/quic-go

https://interop.seemann.io/

[gaby]

This issue has been open for over 6 years now, is there a concrete plan on how to address this?

[erikdubbelboer]

I'm afraid not. Most features of http2 aren't relevant for the use cases fasthttp is meant for.

[cipriancraciun]

Having experimented in my kawipiko static server based on fasthttp with both HTTP/2 (based on the Go's implementation) and HTTP/3 (based on an experimental available library), I continue to believe that perhaps HTTP/2 and HTTP/3 is a job for some other component of the infrastructure, be it a CDN or even a local HTTP router / load-balancer such as HAProxy.

In my experiments the major issue with Go-based HTTP servers and performance is mainly memory allocation overhead (or as it's called in Go "heap escape"); with fasthttp you can manage to implement a server that has almost zero allocations (although you'll have to profile the heck out of it); with other HTTP implementations (like Go's one) it's harder. Now I imagine that with HTTP/2 and HTTP/3 complexities, any development that also tries to eliminate lots of allocations would be extremely difficult, thus any potential gains from HTTP/2 and HTTP/3 would be diminished by the lost performance due to memory allocation overhead.

[kolinfluence]

http2 is supported by hertz but a lot of things are not compatible. tried porting fasthttp to hertz for 1 week and still working on areas.

they have ideas on http2 which is great but means changing a few sections of fasthttp.
however, fasthttp has certain mechanism which makes things more mature.
look into hertz.

[bryanvaz]

I'm afraid not. Most features of http2 aren't relevant for the use cases fasthttp is meant for.

@erikdubbelboer, when you get a second, can you quickly clarify just three things for any downstream project that might be waiting on HTTP2 support from fasthttp (I know you've mentioned it sporadically in this and other issues, but I want to centralize and confirm the answers, feel free to just provide a quick Yes/No if I've captured your reasoning correctly):

1. To confirm there is currently no plans to include HTTP/2 support into fasthttp, and most likely never will be, based on the usecase for fasthttp and the new features of HTTP/2 (& even HTTP/3)?
2. The reason that the use case does not align is because fasthttp is meant to be a "fast implementation of HTTP/1.1", and not a general "fast HTTP implementation" supporting all future revisions to the protocol.
3. If anyone wants to leverage the framework of fasthttp but offer HTTP/2 or HTTP/3, should either fork and extend the fasthttp code, or look at some related packages - e.g. dgrr/http2 which is linked on the fasthttp README.

Motivation: HTTP/2 support is brought up about once every 2 months for downstream webserver project, e.g. gofiber/fiber, and in a few other projects. The spike in HTTP/2 interest is mainly due to the increased popularity and adoption of gRPC, and now HTTP/3 & QUIC being enabled by default in all major browsers as of March 2023 (Safari was the last holdout). The standing position within these projects is to wait for fasthttp to implement HTTP/2, at which point those downstream projects would have native support for HTTP/2. In particular, this specific issue (#144) is cited as the "work" that is being done to implement HTTP/2 (which is obviously not true).

If the answer to all 3 questions above is "YES", should we update the README to clarify that that no work is being done on HTTP/2 within the fasthttp project? The README is currently ambiguous and implies that work is being done to integrate HTTP/2 into fasthttp, when in actuality if ever completed, would exist as a separate project (referring to fasthttp/http2) - I only realized this after digging through the http2 project, and all the issues around HTTP/2.

Cheers,
Bryan

[dgrr]

Hello @bryanvaz. Thanks for your comment. Supporting HTTP/2 is possible, but it requires a LOT of work to develop an HTTP/2 framework.
I did start the protocol myself and later got some help developing some tests and fixing a few things. But later I realized that the project is bigger than myself. It required support for browser engines other than Chromium's (Firefox doesn't work with the http2 library, for example). I did got offered getting paid to do it, but I ultimately decided to not take it. The main reason was because I was out of time. I have projects myself that require some attendance. Nowadays I don't see incentive for myself because I no longer use Golang on a daily basis. And if I ever do, I use I might not use fasthttp, and if I do I use fasthttp for very straightforward services like supporting bid requests from SSPs, etc...

Work can be done to fork net/http2 and adapt it to fasthttp. But then more work will need to be added to the pile to support GRPC, aka forking the compiler to replace the code that generates net/http code with fasthttp code. And what is the actual incentive? A few microseconds that you could save per request? Because memory-wise is going to be mostly the same, you need a goroutine per connection and maybe another gorouting to handle the HTTP/2 streams. If you are using Golang, generally you don't care about microseconds (generally). And... on top of that, who is going to use http/2 without GRPC support? Is it worth the try?
To be honest, it took me less time to learn Rust and how frameworks like tokio work than to develop the http2 library (and it is not fully finished!).
I'd say that if the community (go-fiber mainly) is willing to develop an http/2 library, PRs are welcome in fasthttp/http2, and also in my repo, but I might not be able to review as fast as other people could. They can also create their own repo. The thing comes down to: If there's interest, someone will do it. If nobody did it, then there's no real advantage with net/http2.

Maybe the explanation is too big, but I think it helps.

[erikdubbelboer]

There is currently no plans to include HTTP/2 support into fasthttp. I myself would only like to add support if I was going to use http2 myself, otherwise it's too hard and time consuming to work on. Pull requests on either repo are always welcome of course.

[bryanvaz]

Agree with both of you, Erik and Darío. Basically no HTTP/2 support is actively being built for fasthttp and no plans to support it in the future.

If any downstream project needs HTTP/2, it should not expect one from fasthttp. Instead it should implement HTTP/2 on its own, either by forking fasthttp and adding HTTP/2 support, or by building a separate extension to add HTTP/2.

[phuslu]

agree. I used to use fasthttp for rtb, and I realized we only need a http2 client rather than a http2 framework.

So I ripped a http2 implementation from grpc-go but haven't to verify it yet.

[daenney]

And... on top of that, who is going to use http/2 without GRPC support?

fasthttp is used by plenty of frameworks that aren't limited to computer-to-computer communication. Roughly 35-40% of the web properties use HTTP/2. You're using HTTP/2 fairly regularly without gRPC support.

That's not necessarily a reason for a fasthttp HTTP/2 implementation to be developed, but it definitely doesn't have to come with support for gRPC to be useful. JSON-over-HTTP works just as well for HTTP/2 and you'd still benefit from the improvements to the wire format like multiplexing and the HPACK header compression.

[lesismal]

JSON-over-HTTP works just as well for HTTP/2 and you'd still benefit from the improvements to the wire format like multiplexing and the HPACK header compression.

Websocket can handle that too.

[dgrr]

@daenney Sure, I agree with you that it does have usages, but I don't even use Golang anymore (not only fasthttp but Go at all), so it doesn't make sense that I try to implement it because it would divert my focus from my current job. Also, I would not be able to test it in a daily basis because I wouldn't be using it, therefore I would have to wait for people to report bugs, etc... I don't wanna sell a product that I wouldn't even buy.

[apuatcfbd]

PLEASE MENTION IT IN THE README! that this lib doesn't support http2

[cipriancraciun]

PLEASE MENTION IT IN THE README! that this lib doesn't support http2

@apuatcfbd you mean like this snippet that already exists in the README:

fasthttp/README.md

Lines 577 to 581 in 5f81476

	* *Why fasthttp doesn't support HTTP/2.0 and WebSockets?*
	[HTTP/2.0 support](https://github.com/fasthttp/http2) is in progress. [WebSockets](https://github.com/fasthttp/websockets) has been done already.
	Third parties also may use [RequestCtx.Hijack](https://pkg.go.dev/github.com/valyala/fasthttp#RequestCtx.Hijack)
	for implementing these goodies.