http HEAD 与 GET 性能答案

【问题标题】：http HEAD vs GET performancehttp HEAD 与 GET 性能
【发布时间】：2013-05-08 12:04:40
【问题描述】：

我正在设置一个 REST Web 服务，它只需要尽快回答“是”或“否”。

设计 HEAD 服务似乎是最好的方法，但我想知道与执行 GET 请求相比，我是否真的能获得一些时间。

我想我获得了不会在我的服务器上打开/关闭的正文流（大约 1 毫秒？）。由于返回的字节数非常少，我是否在传输中获得任何时间，在 IP 数据包数中？

提前感谢您的回复！

编辑：

进一步解释上下文：

我有一组 REST 服务在执行某些进程（如果它们处于活动状态）。
我有另一个 REST 服务指示所有这些第一个服务的状态。

由于最后一个服务会经常被大量客户端调用（预计每 5 毫秒调用一次），我想知道使用 HEAD 方法是否可以进行有价值的优化？响应正文中返回大约 250 个字符。 HEAD 方法至少获得了这 250 个字符的传输，但那有什么影响呢？

我尝试对这两种方法（HEAD 与 GET）之间的差异进行基准测试，运行 1000 次调用，但根本看不到任何增益（

【问题讨论】：

这也取决于您使用服务器端的方法。通常可能需要相同的服务器时间来处理 GET 请求或 HEAD 请求，因为服务器可能需要知道最终的主体来计算 Content-Length 标头值，这是 HEAD 请求响应中的重要信息。除非有其他更优化的服务器端方法，否则唯一的好处是节省了带宽并且客户端不必解析响应正文。所以基本上优化收益取决于服务器和客户端的实现。

标签： http get head

【解决方案1】：

HEAD 请求与 GET 请求类似，只是响应的正文为空。当您只需要有关文件的元数据但不需要传输文件的所有数据时，可以使用这种请求。

【讨论】：

【解决方案2】：

GET 获取头部 + 主体，HEAD 仅获取头部。哪个更快不应该是一个意见问题。我不明白上面赞成的答案。如果您正在寻找 META 信息，请选择 HEAD，它就是为此目的。

【讨论】：

【解决方案3】：

我在查找请求者提出的相同问题时发现了此回复。我也在http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html找到了这个：

HEAD 方法与 GET 相同，只是服务器不能在响应中返回消息体。响应 HEAD 请求的 HTTP 标头中包含的元信息应该与响应 GET 请求发送的信息相同。此方法可用于获取有关请求所隐含的实体的元信息，而无需传输实体主体本身。这种方法通常用于测试超文本链接的有效性、可访问性和最近的修改。

在我看来，对请求者问题的正确答案是它取决于 REST 协议所代表的内容。例如，在我的特定情况下，我的 REST 协议用于检索相当大（如超过 10K）的图像。如果我经常检查大量此类资源，并且考虑到我使用了请求标头，那么根据 w3.org 的建议，使用 HEAD 请求是有意义的。

【讨论】：

【解决方案4】：

我强烈反对这种方法。

RESTful 服务应该尊重 HTTP 动词语义。 GET 动词用于检索资源的内容，而 HEAD 动词不会返回任何内容，可用于例如查看资源是否已更改、了解其大小或类型、检查是否存在，等等。

请记住：早期优化是万恶之源。

【讨论】：

【解决方案5】：

我不明白您对“打开/关闭正文流”的担忧。响应正文将在与 http 响应标头相同的流上，并且不会创建第二个连接（顺便说一下，它在 3-6 毫秒的范围内更多）。

这似乎是一个非常不成熟的优化尝试，它不会产生显着甚至可测量的差异。真正的区别在于总体上与 REST 的一致性，它建议使用 GET 来获取数据..

我的回答是否定的，如果有意义就使用 GET，使用 HEAD 不会提高性能。

【讨论】：

假设内容为 100MB。头部肯定会小于内容的大小。现在，当我们通过 GET 或 HEAD 方法请求该资源时，您认为它们之间没有性能差异？！
OP 在响应正文中声明了 250 个字符。不是 100MB。这完全是一个不同的问题。

【解决方案6】：

RESTful URI 应该代表服务器上的“资源”。资源通常存储为数据库中的记录或文件系统上的文件。除非资源很大或者在服务器上检索的速度很慢，否则使用HEAD 而不是GET 可能看不到可衡量的收益。可能是检索元数据并不比检索整个资源快。

您可以实现这两个选项并对其进行基准测试以查看哪个更快，但我不会进行微优化，而是专注于设计理想的 REST 接口。从长远来看，干净的 REST API 通常比可能更快也可能不会更快的杂乱无章的 API 更有价值。我并不是不鼓励使用HEAD，只是建议您仅在“正确”设计时才使用它。

如果您需要的信息确实是关于可以在 HTTP 标头中很好地表示的资源的元数据，或者检查资源是否存在，HEAD 可能会很好地工作。

例如，假设您要检查资源 123 是否存在。 200 表示“是”，404 表示“否”：

HEAD /resources/123 HTTP/1.1
[...]

HTTP/1.1 404 Not Found
[...]

但是，如果您希望 REST 服务的“是”或“否”是资源本身的一部分，而不是元数据，则应使用 GET。

【讨论】：

最好的事情总是简单的，就像这个答案一样。瞧！
精彩的答案！我有一个问题：如何将其用作touch 命令来更新服务器上帖子的查看次数？帖子数据已经通过普通的/posts 调用检索到，所以我只想在用户以某种方式与帖子交互后更新查看次数。
@aalaap 如果您要为HEAD 请求更新视图计数器，那么您也应该为GET 请求更新。使用GET 或HEAD 的决定最终取决于HTTP 客户端。您的服务器对这两种请求类型的行为方式应该相同，除了在响应 HEAD 时没有响应正文。至于这是否是实现视图计数器之类的好方法，我不确定。
-1 任何可以命名的信息都可以是资源。因此统一资源定位器。按照设计使用 HTTP 协议的一部分是“杂乱无章”或“不干净”的想法很奇怪。
@Siddhartha，这通常是正确的，但并非总是如此。使用Transfer-Encoding: chunked 时可以省略Content-Length。即使使用Content-Length，服务器也有可能在不获取实际资源的情况下获取标头中使用的资源大小和其他元数据。也许该元数据甚至缓存在内存中以便非常快速地访问。这都是非常具体的实现。

【解决方案7】：

您可以轻松地进行一个小测试来自己衡量性能。我认为性能差异可以忽略不计，因为如果您只在正文中返回“Y”或“N”，那么它就是附加到已经打开的流的一个额外字节。

我也会选择 GET，因为它更正确。您不应该返回 HTTP 标头中的内容，只能返回元数据。

【讨论】：

【解决方案8】：

使用 HEAD 请求而不是 GET 请求几乎不会改变您的性能。

此外，当您希望它是 REST-ful 并且想要获取数据时，您应该使用 GET 请求而不是 HEAD 请求。

【讨论】：