3

I just wanted to know that where does the HTTP framework rests in rails and how to implement a different protocol for client-server communication using different network layer?

There's a new protocol called QUIC which has low latency and if somebody wants to implement that in rails app how does someone do it? I hardly found any resources related to the implementation on internet.

Nischay Namdev
  • 553
  • 7
  • 23
  • QUIC is still being standardised. It’s due for completion in July of this year (though has been delayed before) after which it will be submitted for formal Internet standardisation approval by the IETF. It will take a bit to become common after that. Google have a version of QUIC on their servers and in Chrome but it is different than the standard one and is likely to be deprecated once that is standardised. HTTP/2 has most of the benefits of QUIC and QUIC extends that so if not on HTTP/2 then move to that first while you wait for it. – Barry Pollard May 11 '19 at 17:45
  • UDP is not guaranteed so it doesn’t have the overhead of TCP but that doesn’t mean it’s “faster”. Especially as QUIC has to build TCP guarantees on top of UDP. And it has to do this in application layer which will be less efficient and more resource hungry than TCP which is built into the OS. What QUIC brings to the table is that it allows changes and improvements which are very difficult to do in TCP as it’s so baked in to the ecosystem. But for majority of use cases QUIC will be similar to TCP, at least initially. It does fix one issue of HTTP/2 being slower than HTTP/1.1 on poor networks. – Barry Pollard May 11 '19 at 18:30
  • it has forward error correction, connection migrations and doesn't have to wait for acknowledgements. it's very lightweight I guess? – Nischay Namdev May 11 '19 at 19:16
  • Neither will be in initial version of QUIC: https://datatracker.ietf.org/wg/quic/about/. And of course it has to wait for acks as it’s still a guaranteed protocol like TCP. Just it’s guaranteed at stream level unlike at connection level which TCP is. QUIC is gonna be big IMHO but will take a long while to get there. Certainly wouldn’t worry about rails not supporting it yet. – Barry Pollard May 11 '19 at 19:23
  • There's a server which supports QuiC. or we can code our own server I guess if we really wanna exploit the functionalities of the QUIC, I think QUIC right now can give an edge over others. Google also uses QUIC as u said. There's an issue of reliability but I guess the datagrams which are lost in the process are not important? – Nischay Namdev May 11 '19 at 19:29
  • You can implement Google QUIC and some other servers and CDNs have done this. It will only work with Chrome based browsers, it will change and stop working and revert back to TCP as Google changes it. You will need to keep up with Google changes. You will then need to reimplement it for the standardised QUIC when it’s released as it is different. To me it’s one to watch, rather than one to worry about now. Datagrams are not lost in QUIC: QUIC implements pretty much the same processes as TCP to ensure they are resent. – Barry Pollard May 11 '19 at 19:33
  • I guess yea, We have to wait and watch! – Nischay Namdev May 11 '19 at 19:40

2 Answers2

4

At a guess, this would be handled by the Rack middleware that sits between the web server and your Rails code. Your Rails application does not interact with the web server, rather it interacts with Rack which interacts with your web server.

Rails <---> Rack <---> Web Server <---> Web Client

Here is a tiny Rack server that says "Hello, world!".

require "rack"
require "thin"

class HelloWorld
  def call(env)
    [ 200, { "Content-Type" => "text/plain" }, ["Hello World"] ]
  end
end

Rack::Handler::Thin.run HelloWorld.new

Rack::Handler::Thin talks to the tiny thin web server passing it a response consisting of an HTTP code, HTTP headers, and the response body.

You may be in luck. The LiteSpeed web server supports QUIC and Rack has a LiteSpeed handler. It might Just Work.

Schwern
  • 153,029
  • 25
  • 195
  • 336
  • is there any functionality of rails which would be affected if I used QUIC(UDP) than HTTP? – Nischay Namdev May 11 '19 at 18:07
  • @nnd I'm no Rails nor QUIC expert, I can't say for sure. So long as you can map between QUIC and HTTP codes and headers I don't see there would be any effect. I wouldn't be surprised if LiteSpeed already does this. And the [proposed HTTP/3](https://datatracker.ietf.org/doc/draft-ietf-quic-http/) is exactly that. Try it! – Schwern May 11 '19 at 19:14
  • 1
    @Schwern - FYI, the QUIC protocol will replace the TCP protocol and is handled by the server. Because of it's location on the network stack, Rack middleware won't be handling the QUIC protocol and Rack itself will be unaware of the protocol. The server will handle QUICK, passing the resulting HTTP request to the Rack application (i.e., Rails). – Myst Aug 09 '19 at 17:10
3

As discussed in the comments QUIC is not yet formally standardised so it is unsurprising it is not available in most tools. None of the major web servers (e.g. Apache, Nginx or IIS) and even indicated they are working on it yet. It is due to be completed in July and then submitted for standardisation which will take a few months after that. After that I would expect implementations to start becoming available.

Google invented QUIC and do have a version on their servers and in Chrome. This form the basis of the QUIC that will be standardised but the two have diverged and are not compatible. So you could implement a version of Google QUIC if you wanted to and some servers like LiteSpeed and some CDNs like Akamai do this. As do Google themselves on their Cloud Platform. They basically do this by reverse engineering the open source Google Chrome code. Also as Google iterates QUIC and stops supporting the old versions they must keep up or it will stop working. Eventually Google QUIC will be deprecated and then retired once the IETF standardised QUIC comes out.

QUIC is also incredibly complex! Implementing it will not be easy and will take considerable effort and time. It is not as simple as finding the HTTP code and copying and pasting it and changing a couple of things. It’s a massive whole new protocol that reimplements parts of TCP, TLS and HTTP/2. HTTP/3 then is what is left over from HTTP/2 and needs to be implemented as well as QUIC to be useful.

Finally the the impact of QUIC might not be as large as you think. QUIC is an evolution of HTTP/2 and fixes one edge case where HTTP/2 can be slower than HTTP/1.1 if there is very high packet loss. Apart from this scenario the initial versions of QUIC will be very similar to HTTP/2 and TLSv1.3 which are available now. One of the main reasons for QUIC is to allow it to evolve quickly as TCP is almost impossible to change as it’s so baked in. Future versions of QUIC will likely include Forward Error Correction (to automatically recreate dropped packets), connection migration (to allow you to seamlessly switch from WiFi to Mobile) and also be available for more than HTTP but they are out of scope for the initial version as defined by the QUIC working group charter because even without those QUIC is complicated. Additionally TCP is highly optimised into Operating Systems and network stacks so QUIC will likely be more CPU expensive and slow, especially initially and there may be other issues to solve as well.

So all in all, if you want QUIC now then look at one of the webservers or CDN or Google Cloud Platform and put this in front of your application server. Like HTTP/2 this usually gives the main benefits, and means you don’t need to worry about all of the above complications. But to me, QUIC is one to watch for the future, and not something id want to turn in for now.

If interested in learning more about HTTP/2, HTTP/3 and QUIC, and some of the complexities, then you can check out my book on the subject: https://www.manning.com/books/http2-in-action

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92