HTTP协议在Rails框架中的位置是什么？

Question

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

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

- Nischay Namdev

---

QUIC仍在标准化过程中。预计将于今年7月完成（尽管此前曾经延迟），之后将提交给IETF进行正式的互联网标准化审批。在那之后，它需要一段时间才能变得普遍。Google在其服务器和Chrome浏览器上有一个QUIC版本，但它与标准版本不同，一旦标准化就可能被弃用。HTTP/2具有QUIC的大部分优点，并且QUIC扩展了HTTP/2的功能，因此如果没有使用HTTP/2，则应先转向HTTP/2等待QUIC的到来。 - Barry Pollard

UDP不是可靠的，因此它没有TCP的开销，但这并不意味着它更“快”。特别是QUIC必须在UDP之上构建TCP保证。而且它必须在应用程序层面上进行，这将比内置于操作系统中的TCP更低效且更耗资源。QUIC带来的好处是允许进行非常难以在TCP中实现的更改和改进，因为TCP已经深入到生态系统中。但对于大多数用例，QUIC最初将类似于TCP。它确实解决了HTTP/2在贫弱网络上比HTTP/1.1慢的一个问题。 - Barry Pollard

它具有前向纠错、连接迁移功能，无需等待确认。我猜它非常轻量级？ - Nischay Namdev

QUIC的初始版本中都不会有这两个功能：https://datatracker.ietf.org/wg/quic/about/。当然，由于它仍然像TCP一样是一个可靠的协议，因此必须等待确认。只是在流级别上保证，而不是像TCP那样在连接级别上保证。我认为QUIC将会很重要，但需要很长时间才能实现。当然，还不用担心Rails尚未支持它。 - Barry Pollard

有一个支持QuiC的服务器。如果我们真的想要利用QUIC的功能，我想我们可以编写自己的服务器。我认为现在QUIC可以比其他协议更具优势。正如你所说，谷歌也使用QUIC。可靠性存在问题，但我想在传输过程中丢失的数据报并不重要吧？ - Nischay Namdev

Answer 1

大概来说，这将由位于Web服务器和您的Rails代码之间的Rack中间件处理。 您的Rails应用程序不与Web服务器交互，而是与Rack交互，Rack再与您的Web服务器交互。

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

这是一个小型Rack服务器，向世界问好！.

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服务器支持QUIC，并且Rack有一个专门为LiteSpeed设计的处理程序。它可能只需要起作用即可。

- Schwern

---

如果我使用QUIC（UDP）而不是HTTP，Rails中是否会受到任何功能的影响？ - Nischay Namdev

@nnd 我不是Rails或QUIC专家，不能确定。只要您可以映射QUIC和HTTP代码和标头之间的关系，我认为不会有任何影响。如果LiteSpeed已经这样做，我也不会感到惊讶。而拟议中的HTTP/3正是如此。试试吧！ - Schwern

@Schwern - 提醒一下，QUIC协议将替代TCP协议，并由服务器处理。由于其位于网络堆栈上的位置，Rack中间件将无法处理QUIC协议，而Rack本身也不会意识到该协议的存在。服务器将处理QUICK协议，并将生成的HTTP请求传递给Rack应用程序（例如Rails）。 - Myst

Answer 2

正如评论中所讨论的，QUIC目前尚未正式标准化，因此大多数工具都无法使用它，这并不令人意外。目前没有任何主要的Web服务器（例如Apache、Nginx或IIS）表示他们正在研究它。QUIC计划在7月份完成并提交标准化，此后还需要几个月的时间进行标准化。之后，我预计将开始提供实现。

Google发明了QUIC，并在其服务器和Chrome浏览器中拥有一个版本。这是标准化的QUIC的基础，但两者已经分化并且不兼容。因此，如果您想要，您可以实现Google QUIC的版本，一些服务器（如LiteSpeed）和一些CDN（如Akamai）也这样做。Google自己在其Cloud Platform上也是如此。他们基本上通过反向工程开源的Google Chrome代码来实现这一点。此外，随着Google迭代QUIC并停止支持旧版本，他们必须跟上，否则它将停止工作。最终，Google QUIC将被弃用，一旦IETF标准化的QUIC发布，它就会被淘汰。

QUIC也非常复杂！实现它并不容易，需要付出相当大的努力和时间。它不像找到HTTP代码并复制粘贴然后改变几个东西那样简单。它是一个庞大的全新协议，重新实现了TCP、TLS和HTTP/2的部分内容。因此，HTTP/3也需要被实现，以及QUIC才能发挥作用。

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

所以总体而言，如果您现在想使用QUIC，则可以查看其中一个Web服务器或CDN或Google Cloud平台，并将其放在应用程序服务器前面。像HTTP/2一样，这通常会带来主要的好处，并且意味着您不需要担心上述所有复杂性。但对我来说，QUIC是未来值得关注的内容，现在不是我想要交付的东西。

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

- Barry Pollard