我正在开发一个网站，目标是尽可能快。这个目标需要让移动客户端发出初始 HTTP 请求one往返。 （HTTP/2 的 HPACK 应该处理同一页面的后续请求。）
传统观点认为 14 KB 的压缩文件response与您对网页第一次往返的预期一样多（由于 TCP 慢启动），但在测试时，与该理论类似的计算不会产生类似的结果。
我的目标连接具有以下特征：
-
第三代蜂窝数据协议 (3G)
-
200毫秒延迟（400 毫秒RTT）
- 400Kb/s最大下载带宽
- 最大上传带宽300Kb/s https://www.opensignal.com/reports/2019/07/usa/mobile-network-experience
-
0% 丢包率，至少就这个问题而言
- 基于 TLS 的 HTTP/2
- Assume 安卓浏览器为客户
最终，我想为应用程序可控制的请求标头的大小设定性能目标；主要是Etag and Cookie。 （我实在无法控制Referer等等，但至少它们在实践中具有已知的最大尺寸。）
您无法完成一次往返 HTTP/2 页面（也无法完成 HTTPS 页面，甚至使用 HTTP/1.1 也几乎无法完成）。
这是因为 TLS 握手至少需要一次往返（尽管 TLSv1.3 确实具有浏览器和服务器通常不支持的 0-RTT 重复握手）。
HTTP/2 需要进一步的消息，虽然它们不需要知识丰富（因此技术上没有往返）将导致 TCP 确认，因此在这种情况下拥塞窗口 (CWND) 将增加到超过 14Kb。此外，当您开始传输第一个响应时，它的 TCP 数据包也将被确认，从而进一步增加 CWND。
我最近写了一篇关于此的博客文章：https://www.tunetheweb.com/blog/ritic-resources-and-the-first-14kb/ https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/
那么，如果第一个响应不是 14KB，那么您真正需要使用多少内存呢？好吧，实际上这是不可能的，因为它很大程度上取决于双方的 TCP 堆栈（以及 TLS 和 HTTP/2 堆栈）。我的建议是不要沉迷于这个数字，只需用尽可能少的数据来交付您的网站即可。特别是，如果您要交付 15KB 或 16KB，请不要担心，因为您不必为了低于这个 14KB 的神奇数字而自杀。
虽然 Cookie 可能很大（但 eTags 通常不会），但它们通常不会超过一两 KB。因此，如果您想在那里节省空间，那么您可能找错了地方 - 或者有一个真正超级优化的网站，其中这些标头是最后优化的地方！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
