作者 显然，计算机科学中只有两个难题：缓存失效和命名（或者 如 Phil Karlton 的格言所说）。本月初，我们邀请了来自 Twitter、Facebook、SproutCore、Palm 的 webOS、微软的“Office On The Web”、Yahoo 和 Google 的代表与我们讨论第一个问题（以及其他事项），虽然我们也从中学到了一些关于第二个问题的知识。
缓存是网络上需要正确处理的重要问题，尤其是在移动设备上出现了大量网络应用程序之后。我们缓存峰会的目标是确定有助于我们推进缓存和 HTTP 请求效率的用例。例如，我们是否应该卷起袖子看看 Firefox 中的 HTTP/1.1 管道？HTTP 层还需要其他什么？而备受赞誉的 HTML5 AppCache（从 Firefox 3.5 开始实施）对开发人员来说真的有用吗？除了内容之外，我们还需要向网络应用程序公开什么，或者通过其他标题公开什么？
开发人员的反馈非常宝贵，并且越来越成为我们想要发展网络平台下一个组成部分的基础。网络开发人员是我们主要的组成部分之一；未来，我们希望他们能够帮助我们优先考虑我们应该实施什么，以及我们需要重点关注网络标准的哪些方面。我们明智地选择了与会者；如果有任何群体能够谈论大规模网络应用程序、缓存的当前性能以及他们对网络平台未来浏览器缓存行为的愿望，那就是这群人。他们给我们的反馈很多而且有用——我们的工作已经摆在我们面前。值得注意的是，我们将针对以下几个方面采取行动：
-
增加我们的磁盘和内存缓存的默认大小。Firefox 的磁盘缓存目前设置为 50MB，考虑到目前硬件上可用的磁盘空间，这个数字有点小（尽管可以通过高级偏好设置增加这个限制，但实际上很少有用户更改默认值）。这对我们来说是容易解决的问题。一个有趣的问题是，我们是否应该启发式地确定磁盘缓存大小，而不是选择新的上限。 Steve Souders 参加了我们的缓存峰会，他在博客中谈到了 缓存大小以及过早的缓存驱逐。
-
进行一个 “Mozilla 测试飞行员项目”，以获取更多关于我们目前如何准确地缓存资源的数据。这是关于更新我们的缓存算法的一个更大的问题的一部分。与其他浏览器一样，我们使用最近最少使用 (LRU) 缓存算法的优化版本，称为 LRU-SP。我们想要收集的数据包括确定缓存资源的命中率、均值、方差和分布。平均寿命是多少？对于某些应用程序，我们的 LRU-SP 替换策略在哪些模式下效果不佳，其中大型资源（例如基本脚本文件）可能在小型资源（例如地图瓦片）之前被删除？我们还必须研究反病毒软件在定期清除缓存方面所起的作用，从而导致相关资源被过早驱逐的现象。
-
探索根据 MIME 类型对缓存中的资源进行优先级排序。例如，允许 JavaScript (text/javascript) 在我们的 LRU-SP 算法中始终获得更高的优先级，以便确定哪些内容会被清除。一个很好的后续操作是让 Chrome、IE、Apple 和 Opera 与我们一起讨论这个问题，然后记录我们提出的基于 MIME 类型“朴素”优先级排序的内容。我们还希望允许开发人员自行设置资源优先级，也许可以通过标题来实现。这可能会成为一个持续讨论的话题。
-
真正找出什么阻碍了 HTTP/1.1 管道 在网络上的采用，包括来自代理的数据以及它们是如何清除的。虽然管道在 移动 Firefox 版本（例如在诺基亚 N900 和 Android 设备上运行的版本）中默认启用，但在桌面 Firefox 版本中已禁用。我们这样做有各种原因，最重要的是，如果管道请求中的一个请求减慢了其他请求的速度，可能会导致性能下降。从我们的讨论中可以清楚地看出，许多参加我们缓存峰会的人认为管道将有助于他们的应用程序更好地执行。现在网络上关于管道的现状是一种人质困境：在主要桌面浏览器中，没有人启用管道，因为害怕出现减慢性能的情况（导致该特定浏览器被指责为“速度慢”）。访问我们的开发人员扔下了这块石头；至少我们必须弄清楚什么阻碍了管道在网络上的使用，并确定我们实际上可以做些什么来消除这些障碍。
-
找出如何发展 HTML5 AppCache，坦白地说，它并没有达到我们最初预期的采用率。虽然我们倾向于将 HTML5 的部分内容（例如 缓存清单和
window.applicationCache）视为另一个性能工具（以确保网络应用程序在后续访问时快速加载），但它与通用浏览器缓存不同。名称有什么意义，为什么命名是计算机科学中最难的问题之一？使用“缓存”这个词来描述处理离线网络应用程序的 HTML5 部分，让一些开发人员感到困惑。我们所说的HTML5 AppCache主要是为了实现离线网络应用程序的使用，但许多应用程序（例如使用 SproutCore 构建的应用程序）将它视为辅助缓存，以确保应用程序具有快速的启动时间并总体上执行良好。我们被问到，为什么我们应该拥有两样东西：一个通用浏览器缓存，以及专门用于离线使用的其他东西？一方面，HTML5 AppCache 允许网络应用程序像原生应用程序一样运行（在某些移动手机上启用“快速启动图标”），也许最终会与原生应用程序启动器集成。另一方面，HTML5 AppCache 与通用缓存的分离可能意味着我们创建不同的 API 来处理通用缓存。总的来说，同时发展包含“缓存”的多个 API 可能令人困惑。但这就是为什么命名是难题之一，也是为什么我们必须在构建下一代架构时考虑到冗余和混淆的可能性。
我们有一个 跟踪错误，标题大胆：“改进 HTTP 缓存”。你会看到我们想在这里引入的所有变化，包括将我们的缓存与 Chromium 的缓存进行基准测试（如果需要，也许可以使用 Chromium 的缓存代码）。
缓存很重要，但也很难。可以说，网络的短期发展大多数都是这样的，无论是引入可索引数据库功能、流媒体视频还是 CSS 中的新布局模型。这些演变不一定会发生在标准机构内或在邮件列表中，而是通过快速原型制作和有意义的反馈来实现。这就是为什么我们必须与网络开发人员进行交流，以帮助我们做正确的事情，也是为什么我们将继续组织像最近的缓存峰会这样的聚会。
23 条评论