1

我只是想知道 HTTP框架在rails中的位置以及如何使用不同的网络层为客户端-服务器通信实现不同的协议？

有一个称为QUIC的新协议具有低延迟，如果有人想在 Rails 应用程序中实现它，有人怎么做？我几乎没有在互联网上找到任何与实施相关的资源。

4

2 回答 2

3

正如评论中所讨论的，QUIC 尚未正式标准化，因此它在大多数工具中不可用也就不足为奇了。没有一个主要的 Web 服务器（例如 Apache、Nginx 或 IIS），甚至表示他们正在开发它。它将于 7 月完成，然后提交标准化，这将需要几个月的时间。在那之后，我希望实现开始变得可用。

Google 发明了 QUIC，并且在他们的服务器和 Chrome 中确实有一个版本。这构成了将被标准化的 QUIC 的基础，但两者已经出现分歧并且不兼容。因此，如果您愿意，您可以实现一个 Google QUIC 版本，而LiteSpeed等服务器和Akamai等一些 CDN执行此操作。就像谷歌自己在他们的云平台上一样。他们基本上是通过对开源 Google Chrome 代码进行逆向工程来做到这一点的。此外，随着谷歌迭代 QUIC 并停止支持他们必须跟上的旧版本，否则它将停止工作。最终，一旦 IETF 标准化的 QUIC 出现，Google QUIC 将被弃用并退役。

QUIC 也非常复杂！实施它并不容易，并且需要相当大的努力和时间。它不像找到 HTTP 代码并复制和粘贴它并更改一些东西那么简单。这是一个庞大的全新协议，重新实现了部分 TCP、TLS 和 HTTP/2。HTTP/3 是 HTTP/2 遗留下来的东西，需要像 QUIC 一样被实现才能有用。

最后，QUIC 的影响可能没有你想象的那么大。QUIC 是 HTTP/2 的演进，修复了一个边缘情况，即如果丢包率非常高，HTTP/2 可能比 HTTP/1.1 慢。除了这种情况，QUIC 的初始版本将与现在可用的 HTTP/2 和 TLSv1.3 非常相似。QUIC 的主要原因之一是允许它快速发展，因为 TCP 几乎不可能改变，因为它是如此的成熟。QUIC 的未来版本可能包括前向纠错（自动重新创建丢弃的数据包）、连接迁移（允许您可以从 WiFi 无缝切换到移动），并且还可以用于 HTTP 以外的版本，但它们超出了QUIC 工作组章程定义的初始版本的范围因为即使没有这些 QUIC 也很复杂。此外，TCP 针对操作系统和网络堆栈进行了高度优化，因此QUIC 的 CPU 成本可能更高且速度更慢，尤其是在最初阶段，并且可能还有其他问题需要解决。

总而言之，如果您现在想要 QUIC，那么请查看其中一个网络服务器或 CDN 或谷歌云平台，并将其放在您的应用程序服务器前面。与 HTTP/2 一样，这通常会带来主要好处，并且意味着您无需担心上述所有并发症。但对我来说，QUIC 是一个值得关注的未来，而不是我现在想要上交的东西。

如果有兴趣了解更多关于 HTTP/2、HTTP/3 和 QUIC 以及一些复杂性的信息，那么您可以查看我关于该主题的书：https ://www.manning.com/books/http2-in-action

于 2019-05-11T20:14:02.093 回答
3

猜测一下，这将由位于 Web 服务器和 Rails 代码之间的Rack 中间件处理。您的 Rails 应用程序不与 Web 服务器交互，而是与 Rack 交互，后者与您的 Web 服务器交互。

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

这是一个小型机架服务器，上面写着“你好，世界！” .

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与微型thinWeb 服务器对话，向其传递由 HTTP 代码、HTTP 标头和响应正文组成的响应。

你可能很幸运。LiteSpeed网络服务器支持 QUIC 并且Rack 有一个 LiteSpeed 处理程序。它可能只是工作。

于 2019-05-11T17:42:37.427 回答