Hi, Sorry for not having answers your last mails, I was busy with some new improvment for QUIC on haproxy side. Most notably, we improved the transfer performance slightly by being able to use multiple buffers per streams. Please find my answers to your remarks below,
On Sat, Apr 23, 2022 at 11:13:01PM -0600, Shawn Heisey wrote: > After seeing http/3 (orange lightning bolt with the HTTP Version Indicator > extension) talking to a lot of websites, I had thought the standard was > further along than it is. I see that the openssl team is discussing it, and > plans to fully embrace it, but hasn't actually started putting QUIC code in > openssl yet, and it may be quite some time before something usable shows up > even in their master branch. I would not put too much faith in it for the near future. The OpenSSL team seems to have put aside a simple QUIC API integration in favor of a brand new full QUIC stack, which should take quite some time. So for now, manually rebuilding your SSL library seems the only way to go. > It's been fun fiddling with it using haproxy with quictls, and I hope I can > provide useful information to stabilize the implementation. > I'd like to say thank you to Willy and all the other people who make haproxy > one of the best things in my problem-solving arsenal. It handles the > internet side of all my web deployments. I haven't yet put other services > behind it. At a previous $DAYJOB I had been testing FTP load-balancing, > which I did get working, but didn't actually get to the deployment stage. > At the moment, I am experiencing two problems with http3. The second > problem might actually just be another instance of the first problem. > First problem: If I do enough fiddling with an HTTP3 page, in either > Firefox or Chrome, eventually that page will stop loading and the only way > I've found to fix it is to completely close the browser and reopen it. > Restarting haproxy or Apache doesn't seem to help. We already experienced this kind of problems but we though we have fixed them. It seems the connection closure it not always properly handle on haproxy side, which left the client with no notification that it should open a new connection. It may help to increase the timeout client to be greater than the default QUIC idle timeout, which is hardcoded to 10s on haproxy side. For haproxy.org, we use a value of 1m and it seems to be working. Please tell me if this makes your problem disappears or not. > Second problem: If I try pasting a REALLY large block of text into my paste > website at the following URL while I have it configured to use HTTP/3, it > won't work. The page never loads. I can't tell if this is a separate > problem from the one above, or just another occurrence of it that triggers > more readily because there is more data transferred. The reason I think it > might be actually the first problem is that if I open another tab, I can't > get to the website ... but if I close the browser and reopen it, then I can > get to the website again. > https://paste.elyograg.org/ > If I remove the paste website from the http3 ACL so it doesn't send the > alt-svc header, then everything works once I can convince the browser to > stop using HTTP/3. We did not have enough time to work on POST so there is still bugs in this part. I just recently fixed two bugs which may be enough to fix your situattion with the latest 2.6-dev7. However, I still have issues when I use large payloads. Thanks for your kind compliment for haproxy reliability. We hope one day we will reach this level for QUIC but for now this objectif is still far. -- Amaury Denoyelle
