http-get - HEAD 响应是否比 GET 快？

Question

我目前正在使用 GET 获取有关文件的信息，如果我使用 HEAD 请求重写它会更快吗？因为我在第一次响应后关闭了连接。

Answer 1

HEAD 响应仅包含 HTTP 标头但不包含正文 - 如果您不使用正文中通常会在 GET 响应中传输的任何信息，则仅使用 HEAD 通常更快 - 如果没有正文以它开头不应该有所作为。

也从这里：

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

Answer 2

是否HEAD比GET纯粹取决于服务器端的实现更快（通常是由于数据传输较少）......如果HEAD在您的情况下提供的信息足够，我会选择HEAD并且只回退到未正确实施的GET地方并且HEAD/或一些不起眼的代理正在搞乱它......

Answer 3

您没有提供有关您正在访问的服务器类型或您正在访问它的网络的任何信息。

HEAD 请求比 GET 更快完成确实是合理的，因为它涉及的数据传输更少。但是，在快速或高延迟连接上，这几乎总是无关紧要。至于服务器端，它实际上在很大程度上取决于您在做什么，但在大多数情况下，如果您对其进行计时，则不会有明显的差异。

如果您不需要响应的正文，为什么不使用 HEAD 呢？无论您是否可以测量响应时间的任何差异或不能测量，它都更节省带宽。

Answer 4

恐怕可以忽略不计。这真的取决于服务器在做什么。一旦它收到一个请求，你就不能保证期望一个 HEAD 请求或一个 GET 请求的响应比另一个更快。

理论上，因为 HEAD 请求的响应应该和 GET 请求的响应一样，但是没有响应体，它应该更快，因为它传输的数据更少。但是不能保证一个处理 HEAD 请求的连接会比另一个处理 GET 请求的连接快。

Answer 5

您的问题要注意的重要一点是，您正在谈论“GET 请求和 HEAD 请求” - 而不是“GET 响应和 HEAD 响应”

从逻辑上讲 - 对 HEAD 和 GET 的请求都需要相同的时间从您的 PC 传输到服务器目的地。该服务器对 HEAD/GET 所做的任何事情都将取决于服务器所有者，因此如果他们对其进行编码，他们可能会使 HEAD 花费更长的时间。如果您真的想了解语义，您可能会争辩说 HEAD 请求比 GET 请求多出一个数据字符，因此，从技术上讲，HEAD 请求必须在请求阶段多传输 1 个字节的数据。在实践中，这将是请求时间的不可测量的差异。

如果您要从两个“响应”离开服务器返回请求者的那一刻开始计时，那么从逻辑上讲，GET 响应将需要更长的时间才能通过网络传输。由于它通常由 HEADERS 和 BODY 组成 - BODY 可能是大量数据。

Head 响应将花费更少的时间来旅行，因为它只是 HEADERS。举一个非常极端的例子——如果您发送一个 4GB 文件的 GET 请求，该 GET 响应将需要几分钟才能完成将数据写入您的网络流。对同一个 4GB 文件的 HEAD 请求几乎会立即完成，因为它只发送描述 4GB 文件的高级信息，而不必将其内容传输给请求者。

GET 响应将包含 HEAD + BODY。HEAD 响应将仅包含 HTTP 标头。

I personally use HEAD requests in combination with a technology called IPFS - which is a type of distributed internet, where files and data can be stored on a P2P network. In order to keep files alive on the network, they need to be requested frequently. However, if you pull the file via a GET request, you end up using bandwidth, to download that 4GB file you stored weeks ago. Performing a HEAD request however, in my case, keeps the file alive on the network, but does not request the 4GB of data to travel to me on the network.