New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
LiteSpeed Announces first production-grade QUIC implementation available for the public
"We've just released two new LiteSpeed Firsts. In both LiteSpeed Web Server and LiteSpeed Web ADC we now offer the first production-level QUIC implementation outside of Google, providing this future web protocol to everyone. "
https://blog.litespeedtech.com/2017/07/11/litespeed-announces-quic-support/
Interesting development. Anyone did any bench-marking yet 
?
Thanked by 1szarka
Comments
Nice to see this development for production use, Caddy has exprimental QUIC support for a while, but Caddy itself isn't really for "production" use (yet). I guess the improvement over higher latency links should be decent with 0RTT handshakes.
I'm using Caddy for a high-performance website (ticket selling) and it works great, no issues as of yet.
I agree, Caddy is my favorite server, love the speed and simplicity in configuration, but I still wouldn't use it for a website that my income or a part of my income would rely on. For such projects I would still rely on the proven capabilities of nginx. Also updating Caddy is still not as convenient as it should be, a Debian repository would be really nice.
Thanks for pointing this out! Indeed, their blog post is kind of lying about being first. Caddy is definitely fit for production and has had QUIC support for over a year now.
Never heard of QUIC before. If it's an internet standard I thought there had to be multiple existing implementations? Or does Litespeed itself get to decide what to call "production grade"? Is there some reason it hasn't been hacked into nginx or apache?
Nice to see this, finally getting implemented but I'll consider it production grade only once it's been battle tested against the myriad of stupid firewall/proxy/censorship or otherwise derped installations out there.
Nice.. looking forward to benchmarking both Caddy and Litespeed's QUIC implements
Google uses it for their services for a couple of years, so I'd assume it's fairly tested.
@Clouvider Sure Google's implementation is production grade, but Litespeeds? QUIC is a bit more involved than previous HTTP upgrades such as HTTP/2 (as it runs over UDP). That's something I would strongly hesitate calling production grade until it was rigorously real world tested.
Not saying it isn't great that this has been released. But released and "production grade" on day 1, unlikely.
Should be good, would be better if it was implemented by more than Google applications. If it's widely accepted then I'm sure itll catch on in due time. As litespeed have started the trend I wonder which others will announce a similar integration
first production-grade
Btw, caddy is my everyday
browserweb server for static site to high performance HTTP/2 download server. There are quite a people using caddy for seroius hosting environment. Caddy is awesome!PS: Lazy people should check this out.
@sayem314 Thanks! I'm glad you like using Caddy!
(For what it's worth, people use Caddy's QUIC in production; I don't even know what "production-grade" means, that's about as descriptive as saying something is "secure".)
@mholt, big thanks for the caddy, Matt. This webserver is a joy to use. Eagerly looking forward to the proxy middleware rewrite to be completed.
What is Caddy? Got a url? I'm behind the times...
YAFW (yet another fucking webserver) - It's literally the first hit on derGoog.
Oh I see, thanks. I got confused when Sayem314 said Caddy was a browser.
How does TCP FastOpen compare with QUIC for connection setup? With NGINX supporting FastOpen, is there a real benefit to QUIC on Caddy/LiteSpeed. Some benchmarks would be nice.
Did a quick glance on Chrome (chrome://net-internals/#quic) and Google's servers seem to use HTTP/2 as a standby for QUIC.
Right above your message, mate
@rincewind TCP Fast Open is still TCP, which is a stream protocol. Even with TFO, if a packet is lost, you have to go back in the sliding window and re-transmit. And AFAIK you still have a handshake to complete before you can fast open. QUIC has virtually no handshake, survives through network changes (e.g. wifi to cellular), and can send packets out of order.
As for transport layer speed, I'm frankly more interested in BBR, which has nothing to do with the web server. Early results look really promising.
Got a source for this?
TCP FastOpen still needs client side to support/enabled as well as web site. Most windows browsers don't have TCP FastOpen support. AFAIK only Linux and Android OS based browsers like Chrome have the option to enable it on client side and it's (TFO) disabled by default anyway.
@mholt, yup Google BBR is more interesting already enabled on a few of my servers running CentOS 7 and Linux 4.12+ kernels. Linode VPSes also come with Linode provided 4.9.36 kernels which support Google BBR out of the box too so that makes it easy to deploy.
From what I recall, alot of Google's implement of QUIC uses underlying code based on Google Spdy and thus HTTP/2 ? So would make sense.
I wonder if there's any differences in how different web servers implement FEC and packet pacing for QUIC ? I guess benchmarks and testing will reveal how different web servers' QUIC implementations fair. Is there any documentation I can read regarding Caddy's QUIC implmentation and configuration ?
How does QUIC deal with packet loss and reordering? I had some bad experiences long back with UDP over low-quality networks and high latencies.
Yes: https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/
>
>
@eva2000 You can refer to Caddy's QUIC implementation here: https://github.com/lucas-clemente/quic-go
cheers
QUIC FEC https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit?usp=sharing
Kudos to Caddy server being the first non-google QUIC enabled web server, we did not intend to take that credit, it was miscommunication between our staff when announced it.
We are confident our QUIC implementation is ready for production use, our own website and blog are the first deployment of our QUIC. We eat our own dog food, it means something.
LSWS 5.2 release soon will be pushed through our auto-update system, we will see a lot of sites powered by QUIC soon.
QUIC is not easy to implement, we are sure that there are some rough edges needing to be polished, and there will be constant updates following IETF discussions before it is finalized, but we are committed to maintaining a fully working production quality QUIC implementation to allow our users to enjoy the same next generation technologies as google does.
-LiteSpeed Technologies
Fair enough!