时间戳

首页 > 解决方案 > 移动网络上的 HTTP/2 浏览器请求一次往返有多少字节？

performance - 移动网络上的 HTTP/2 浏览器请求一次往返有多少字节？

问题描述

我正在一个网站上工作，目标是尽可能快。这个目标需要让移动客户端在一次往返中发出初始 HTTP 请求。（HTTP/2 的 HPACK 应该处理对同一页面的后续请求。）

传统观点认为 14 KB 的压缩响应与您在网页的第一次往返中所期望的一样多（由于 TCP 慢启动），但与该理论类似的计算在测试时不会产生类似的结果.

我的目标连接具有以下特点：

最终，我想为应用程序可控请求标头的大小设定性能目标；主要是Etag和Cookie。（我无法真正控制Referer等等，但至少它们在实践中具有已知的最大尺寸。）

标签： performancehttpcookiestcphttp2

解决方案

你不能做一个往返的 HTTP/2 页面（也不能做 HTTPS 页面，甚至使用 HTTP/1.1 也几乎不可能）。

这是因为 TLS 握手至少需要一次往返（尽管 TLSv1.3 确实有一个 0-RTT 重复握手，浏览器和服务器通常不支持）。

HTTP/2 需要更多消息，虽然它们不需要知识渊博（因此技术上没有往返）将导致 TCP 确认，因此在这种情况下拥塞窗口 (CWND) 将增加到超过 14Kb。此外，当您开始流式传输第一个响应时，它的 TCP 数据包也将被确认，从而进一步增加 CWND。

我最近写了一篇关于此的博客文章：https ://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/

那么，如果不是 14KB，那么对于第一个响应，您真的需要花费多少？这实际上是不可能的，因为它在很大程度上取决于每一侧的 TCP 堆栈（以及 TLS 和 HTTP/2 堆栈）。我的建议是不要沉迷于这个数字，而只是以尽可能少的数据提供您的网站。如果您交付的是 15KB 或 16KB，请特别不要担心，因为您不必为了得到这个 14KB 的幻数而自杀。

说虽然 Cookie 可能很大（尽管 eTag 通常不是），但它们通常不会超过 1 KB 或 2 KB。因此，如果您想在那里节省空间，那么您可能找错了地方 - 或者有一个真正超级优化的网站，这些标题是最后优化的地方！

推荐阅读