http 协议在 rails 框架中的位置在哪里？答案

【问题标题】：Where does http protocol rests in rails framework?http 协议在 rails 框架中的位置在哪里？
【发布时间】：2019-05-12 04:21:08
【问题描述】：

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

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

【问题讨论】：

QUIC 仍在标准化中。它将于今年 7 月完成（尽管之前已经推迟），之后将提交 IETF 正式批准互联网标准化。在那之后，它需要一点时间才能变得普遍。谷歌在他们的服务器和 Chrome 中都有一个 QUIC 版本，但它与标准版本不同，一旦标准化，它很可能会被弃用。 HTTP/2 具有 QUIC 的大部分优点，并且 QUIC 扩展了这一点，所以如果不在 HTTP/2 上，那么在等待它的同时先移动到它。
UDP 没有保证，因此它没有 TCP 的开销，但这并不意味着它“更快”。尤其是 QUIC 必须在 UDP 之上构建 TCP 保证。它必须在应用层执行此操作，这将比操作系统内置的 TCP 效率更低且资源消耗更大。 QUIC 带来的是它允许在 TCP 中很难做到的更改和改进，因为它已经融入了生态系统。但是对于大多数用例来说，QUIC 将类似于 TCP，至少在最初是这样。它确实解决了 HTTP/2 在较差的网络上比 HTTP/1.1 慢的一个问题。
它具有前向纠错、连接迁移且无需等待确认。我猜它很轻？
两者都不会出现在 QUIC 的初始版本中：datatracker.ietf.org/wg/quic/about。当然它必须等待确认，因为它仍然是像 TCP 一样的有保证的协议。与 TCP 的连接级别不同，它只是在流级别得到保证。 QUIC 将会是大的恕我直言，但需要很长时间才能到达那里。当然不会担心 Rails 还不支持它。
有一个支持QuiC的服务器。或者我们可以编写自己的服务器，我想如果我们真的想利用 QUIC 的功能，我认为 QUIC 现在可以比其他人更具优势。正如你所说，谷歌也使用 QUIC。存在可靠性问题，但我猜在这个过程中丢失的数据报并不重要？

标签： ruby-on-rails http network-protocols quic

【解决方案1】：

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

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

你可能很幸运。 LiteSpeed web server 支持 QUIC 和 Rack has a LiteSpeed handler。它可能只是工作。

【讨论】：

如果我使用 QUIC(UDP) 而不是 HTTP，rails 的任何功能会受到影响吗？
@nnd 我既不是 Rails 也不是 QUIC 专家，我不能肯定。只要您可以在 QUIC 和 HTTP 代码和标头之间进行映射，我认为不会有任何影响。如果 LiteSpeed 已经这样做了，我不会感到惊讶。而proposed HTTP/3 正是如此。试试看！
@Schwern - 仅供参考，QUIC 协议将取代 TCP 协议并由服务器处理。由于它位于网络堆栈上，Rack 中间件不会处理 QUIC 协议，而 Rack 本身将不知道该协议。服务器将处理 QUICK，将生成的 HTTP 请求传递给 Rack 应用程序（即 Rails）。

【解决方案2】：

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

Google 发明了 QUIC，并且在其服务器和 Chrome 中确实有一个版本。这构成了将被标准化的 QUIC 的基础，但两者已经出现分歧并且不兼容。因此，如果您愿意，您可以实现一个 Google QUIC 版本，而像 LiteSpeed 这样的一些服务器和像 Akamai 这样的一些 CDN 会这样做。就像谷歌自己在他们的Cloud Platform 上一样。他们基本上是通过对开源 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 几乎不可能改变，因为它是如此的成熟。Future versions of QUIC 可能包括前向纠错（自动重新创建丢弃的数据包），连接迁移（允许你无缝地从 WiFi 切换到移动），并且还可以用于 HTTP 之外，但它们超出了 QUIC working group charter 定义的初始版本的范围，因为即使没有这些 QUIC 也很复杂。此外，TCP 针对操作系统和网络堆栈进行了高度优化，因此QUIC will likely be more CPU expensive and slow, especially initially and there may be other issues to solve as well。

总而言之，如果您现在想要 QUIC，请查看其中一个网络服务器或 CDN 或 Google Cloud Platform，并将其放在您的应用程序服务器前面。 Like HTTP/2 this usually gives the main benefits，这意味着您无需担心上述所有并发症。但对我来说，QUIC 是一个值得关注的未来，而不是我现在想上交的东西。

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

【讨论】：