HEAD 响应是否比 GET 更快？
我目前正在使用 GET 获取有关文件的信息，如果使用 HEAD 请求重写它会更快吗？因为我在第一次响应后关闭了连接。
I'm currently getting the info about the files with GET, will it be faster if I rewrite it using HEAD request? Cause I close the connection after the first response.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
HEAD 响应仅包含 HTTP 标头，但不包含正文 - 如果正文中不使用通常在 GET 响应中传输的任何信息，则仅使用 HEAD 通常会更快 - 如果没有正文开头应该没有什么区别。
同样来自此处：
A HEAD response only includes the HTTP headers but no body - it is generally faster to just use a HEAD if you do not use any information in the body that would have normally transferred in a GET response - if there was no body to begin with it should not make a difference.
Also from here:
HEAD是否比GET更快完全取决于服务器端的实现（通常是由于数据传输较少）... IF 信息HEAD在您的情况下提供就足够了，我会使用HEAD，并且仅在HEAD未正确实现和/或一些不起眼的代理正在搞乱它......Whether
HEADis faster thanGETdepends purely on the implementation of the server-side (it usually is due to less data transfer)... IF the informationHEADdelivers is sufficient in your case I would go withHEADand only fallback toGETwhereHEADis not implemented properly and/or some obscure proxy is messing with it...您尚未提供有关您正在访问的服务器类型或您正在访问的网络的任何信息。
HEAD 请求确实比 GET 更快完成，因为它涉及的数据传输更少。然而，在快速或高延迟连接上，这几乎总是无关紧要。至于服务器端，它实际上在很大程度上取决于您正在做什么，但在大多数情况下，如果您计时，则不会有可测量的差异。
如果您不需要响应正文，为什么不使用 HEAD 呢？无论您是否可以测量响应时间的任何差异，它都更加节省带宽。
You haven't given any information about the type of server you're accessing or network you're accessing it over.
It is indeed plausible that a HEAD request would complete faster than GET, since it involves less data transfer. However, on a fast or high latency connection this almost always won't matter. As for the server side, it really depends heavily on what you're doing, but in most circumstances there would be no measurable difference if you timed it.
If you don't need the body of the response, why not use HEAD anyway? Regardless of whether you can measure any difference in response time or you can't, it is more bandwidth-efficient.
可能是可以忽略不计的。这实际上取决于服务器在做什么。一旦收到请求，您不能保证 HEAD 请求或 GET 请求的响应速度比其他请求更快。
理论上，因为 HEAD 请求的响应应该与 GET 请求的响应相同，但没有响应正文，所以它应该更快，因为它传输的数据更少。但不能保证处理 HEAD 请求的一个连接会比处理 GET 请求的另一个连接更快。
It's probably negligible. It really depends what the server is doing. Once it receives a request, you can't guarantee to expect a response from a HEAD request or a GET request any quicker than the other.
In theory, because the response to a HEAD request should be the same as that of a GET request, but without the response body, it should be quicker because its transfering less data. But there is no guaruntee that one connection which processes a HEAD request will be any quicker than another connection processing a GET request.
关于您的问题需要注意的重要一点是，您正在谈论“GET 请求和 HEAD 请求”，而不是“GET 响应和 HEAD 响应”
逻辑上来说，HEAD 和 GET 的请求都需要相同的时间从您的 PC 前往服务器目的地。服务器对 HEAD/GET 执行的任何操作都将取决于服务器所有者，因此如果他们对其进行编码，则可能会使 HEAD 花费更长的时间。
如果您确实想深入了解语义，您可能会认为 HEAD 请求比 GET 请求多了一个数据字符，因此，从技术上讲，HEAD 请求必须在请求阶段多传输 1 个字节的数据。实际上，这在请求时间上将是不可测量的差异。
如果您从两个“响应”离开服务器返回请求者的那一刻起启动计时器，那么从逻辑上讲，GET 响应将需要更长的时间才能通过网络传输。由于它通常由标头和正文组成 - 正文可能是大量数据。
Head 响应的传输时间会更少，因为它只是 headers。
使用一个非常极端的示例 - 如果您发送 4GB 文件的 GET 请求，则该 GET 响应需要几分钟才能完成将数据写入网络流。
对同一个 4GB 文件的 HEAD 请求几乎会立即完成，因为它只是发送高层描述 4GB 文件的信息，而不必将其内容传输给请求者。
我个人将 HEAD 请求与一种称为 IPFS 的技术结合使用 - 这是一种分布式互联网，文件和数据可以存储在 P2P 网络上。为了使文件在网络上保持活动状态，需要经常请求它们。但是，如果您通过 GET 请求拉取文件，您最终会使用带宽来下载几周前存储的 4GB 文件。
然而，在我的例子中，执行 HEAD 请求可以使文件在网络上保持活动状态，但不会请求 4GB 数据在网络上传输给我。
The important thing to note with your question, is that you are talking about 'GET requests and HEAD requests' - instead of 'GET responses, and HEAD responses'
Logically - the request for a HEAD and a GET both take the same amount of time to travel from your PC to the server destination. Whatever that server does with the HEAD/GET will be up to the server owner, so they could make a HEAD take longer if they coded it to do so.
If you really want to get into semantics, you could argue that a HEAD request is one extra character of data than a GET request, therefore, a HEAD request technically has to transmit 1 byte more of data in the request phase. In practice, this is going to be an non-measurable difference in request time.
If you were to start a timer from the moment both 'RESPONSES' left the server on their way back to the requester, then logically speaking, a GET response will take longer to travel across the network. Since it will usually consist of HEADERS and BODY - the BODY can be a huge amount of data.
A Head response will take less time to travel, because it is just HEADERS.
Using a really extreme example - if you send a GET request for a 4GB file, it will take minutes for that GET response to finish writing the data to your network stream.
A HEAD request for the same 4GB file will finish almost instantly, because it is only sending information that describes the 4GB file at a high level, without having to transmit its contents to the requester.
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.