Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Quick Links


Categories

In this Discussion

› › LiteSpeed Announces first production-grade QUIC implementation available for the public
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.

LiteSpeed Announces first production-grade QUIC implementation available for the public

ClouviderClouvider Member, Patron Provider
edited July 2017 in General

"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

  • salakissalakis Member
    edited July 2017

    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.

  • cassacassa Member

    @salakis said:
    But Caddy itself isn't really for "production" use (yet)

    I'm using Caddy for a high-performance website (ticket selling) and it works great, no issues as of yet.

    Thanked by 2mholt sayem314
  • salakissalakis Member

    @cassa said:
    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.

  • mholtmholt Member

    @salakis said:
    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.

    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.

  • williewillie Member

    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?

  • SplitIceSplitIce Member, Host Rep

    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.

  • eva2000eva2000 Veteran

    Nice.. looking forward to benchmarking both Caddy and Litespeed's QUIC implements :)

  • ClouviderClouvider Member, Patron Provider

    @SplitIce said:
    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.

    Google uses it for their services for a couple of years, so I'd assume it's fairly tested.

  • SplitIceSplitIce Member, Host Rep

    @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.

    Thanked by 3Clouvider eva2000 sayem314
  • HyperSpeedHyperSpeed Member

    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

  • sayem314sayem314 Member
    edited July 2017

    @mholt said:
    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.

    first production-grade

    Btw, caddy is my everyday browser web 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.

    Thanked by 1mholt
  • mholtmholt Member

    @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".)

    Thanked by 1sayem314
  • YuraYura Member

    @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.

    Thanked by 2mholt sayem314
  • williewillie Member

    What is Caddy? Got a url? I'm behind the times...

  • WSSWSS Member

    @willie said:
    What is Caddy? Got a url? I'm behind the times...

    YAFW (yet another fucking webserver) - It's literally the first hit on derGoog.

  • williewillie Member

    Oh I see, thanks. I got confused when Sayem314 said Caddy was a browser.

    Thanked by 1sayem314
  • rincewindrincewind Member

    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.

  • YuraYura Member

    @willie said:
    What is Caddy? Got a url? I'm behind the times...

    Right above your message, mate :|

    @Yura said:
    mholt, big thanks for the caddy, Matt. This webserver is a joy to use.

  • mholtmholt Member

    @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.

    Thanked by 1rincewind
  • SplitIceSplitIce Member, Host Rep

    mholt said: QUIC [...] survives through network changes (e.g. wifi to cellular)

    Got a source for this?

  • eva2000eva2000 Veteran

    @rincewind said:
    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.

    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.

    rincewind said: Did a quick glance on Chrome (chrome://net-internals/#quic) and Google's servers seem to use HTTP/2 as a standby for QUIC.

    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.

    mholt said: QUIC has virtually no handshake, survives through network changes (e.g. wifi to cellular), and can send packets out of order.

    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 ?

    Thanked by 1rincewind
  • rincewindrincewind Member

    mholt said: QUIC has virtually no handshake, survives through network changes (e.g. wifi to cellular), and can send packets out of order.

    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.

  • mholtmholt Member

    @SplitIce said:

    mholt said: QUIC [...] survives through network changes (e.g. wifi to cellular)

    Got a source for this?

    Yes: https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/

    Another exciting opportunity with the switch to UDP is the fact that you are no longer dependent on the source IP of the connection.

    >

    QUIC has implemented its own identifier for unique connections called the Connection UUID. It's possible to go from WiFi to LTE and still keep your Connection UUID, so no need to renegotiate the connection or TLS. Your previous connection is still valid.

    >

    This also opens the doors to using multiple sources to fetch content. If the Connection UUID can be shared over a WiFi and cellular connection, it's in theory possible to use both media to download content. You're effectively streaming or downloading content in parallel, using every available interface you have.

    @eva2000 You can refer to Caddy's QUIC implementation here: https://github.com/lucas-clemente/quic-go

    Thanked by 3eva2000 rincewind szarka
  • eva2000eva2000 Veteran

    mholt said: @eva2000 You can refer to Caddy's QUIC implementation here: https://github.com/lucas-clemente/quic-go

    cheers :)

    rincewind said: 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.

    QUIC FEC https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit?usp=sharing

    Background
    Forward Error Correction (aka FEC) allows extra bytes to be transmitted to provide redundancy in case not all packets arrive. QUIC implements a form of FEC based on XOR, which is both simple and fast and provides N+1 redundancy. FEC is commonly used to improve link-layer reliability (such as in Wifi), and there has long been interest in adding FEC to the end-to-end transport layer, but this is prohibitively complex in TCP. As such, QUIC provides an ideal environment to experiment with FEC and to determine in what cases it may be able to provide latency or reliability advantages.

    Advantages
    XOR-based FEC has low computational overhead and is relatively simple to implement. The original packets don’t change, so XOR FEC maintains incremental data processing, unlike some FEC schemes that require multiple packets to arrive before any can be processed.

    Disadvantages
    XOR-based FEC can only recover one packet. If two or more packets are lost, it ends up wasting the FEC packet, because QUIC’s FEC is packet based and QUIC’s retransmission is frame based, so resent frames don’t help recover missing packets. Instead, all lost packets must be retransmitted. The need to indicate a group number when the packet is sent makes it more difficult and less efficient as a replacement for a Tail Loss Probe.

    Thanked by 1rincewind
  • Kacey2002Kacey2002 Member

    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 :)

    Thanked by 3MikePT Clouvider mholt
  • MikePTMikePT Moderator, Patron Provider, Veteran

    @Kacey2002 said:
    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!

Sign In or Register to comment.