标签 缓存 下的文章

Mozilla Firefox 多年来一直是我的默认 Web 浏览器,我每天用它来进行日常网络活动,例如访问邮件,浏览喜欢的网站等。今天,我在使用 Firefox 时遇到了一个奇怪的错误。我试图在 Reddit 平台上分享我们的一个指南时,在 Firefox 上出现了以下错误消息:

Network Protocol Error

Firefox has experienced a network protocol violation that cannot be repaired.

The page you are trying to view cannot be shown because an error in the network protocol was detected.

Please contact the website owners to inform them of this problem.

老实说,我有点慌,我以为可能是我的系统受到了某种恶意软件的影响。哈哈!但是我发现我错了。我在 Arch Linux 桌面上使用的是最新的 Firefox 版本,我在 Chromium 浏览器中打开了相同的链接,它正确显示了,我猜这是 Firefox 相关的错误。在谷歌上搜索后,我解决了这个问题,如下所述。

出现这种问题主要是因为“浏览器缓存”,如果你遇到此类错误,例如 “Network Protocol Error” 或 “Corrupted Content Error”,遵循以下任何一种方法。

方法 1:

要修复 “Network Protocol Error” 或 “Corrupted Content Error”,你需要在重新加载网页时绕过缓存。为此,按下 Ctrl + F5Ctrl + Shift + R 快捷键,它将从服务器重新加载页面,而不是从 Firefox 缓存加载。这样网页就应该可以正常工作了。

方法 2:

如果方法 1 不起作用,尝试以下方法。

打开 “Edit - > Preferences”,在 “Preferences” 窗口中,打开左窗格中的 “Privacy & Security” 选项卡,单击 “Clear Data” 选项清除 Firefox 缓存。

确保你选中了 “Cookies and Site Data” 和 “Cached Web Content” 选项,然后单击 “Clear”。

完成!现在 Cookie 和离线内容将被删除。注意,Firefox 可能会将你从登录的网站中注销,稍后你可以重新登录这些网站。最后,关闭 Firefox 浏览器并重新启动系统。现在网页加载没有任何问题。

希望这对你有帮助。更多好东西要来了,敬请关注!

干杯!


via: https://www.ostechnix.com/how-to-fix-network-protocol-error-on-mozilla-firefox/

作者:SK 选题:lujun9972 译者:MjSeven 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

上一篇文章中我们学习了内核怎么为一个用户进程 管理虚拟内存,而没有提及文件和 I/O。这一篇文章我们将专门去讲这个重要的主题 —— 页面缓存。文件和内存之间的关系常常很不好去理解,而它们对系统性能的影响却是非常大的。

在面对文件时,有两个很重要的问题需要操作系统去解决。第一个是相对内存而言,慢的让人发狂的硬盘驱动器,尤其是磁盘寻道。第二个是需要将文件内容一次性地加载到物理内存中,以便程序间共享文件内容。如果你在 Windows 中使用 进程浏览器 去查看它的进程,你将会看到每个进程中加载了大约 ~15MB 的公共 DLL。我的 Windows 机器上现在大约运行着 100 个进程,因此,如果不共享的话,仅这些公共的 DLL 就要使用高达 ~1.5 GB 的物理内存。如果是那样的话,那就太糟糕了。同样的,几乎所有的 Linux 进程都需要 ld.so 和 libc,加上其它的公共库,它们占用的内存数量也不是一个小数目。

幸运的是,这两个问题都用一个办法解决了:页面缓存 —— 保存在内存中的页面大小的文件块。为了用图去说明页面缓存,我捏造出一个名为 render 的 Linux 程序,它打开了文件 scene.dat,并且一次读取 512 字节,并将文件内容存储到一个分配到堆中的块上。第一次读取的过程如下:

Reading and the page cache

  1. render 请求 scene.dat 从位移 0 开始的 512 字节。
  2. 内核搜寻页面缓存中 scene.dat 的 4kb 块,以满足该请求。假设该数据没有缓存。
  3. 内核分配页面帧,初始化 I/O 请求,将 scend.dat 从位移 0 开始的 4kb 复制到分配的页面帧。
  4. 内核从页面缓存复制请求的 512 字节到用户缓冲区,系统调用 read() 结束。

读取完 12KB 的文件内容以后,render 程序的堆和相关的页面帧如下图所示:

Non-mapped file read

它看起来很简单,其实这一过程做了很多的事情。首先,虽然这个程序使用了普通的读取(read)调用,但是,已经有三个 4KB 的页面帧将文件 scene.dat 的一部分内容保存在了页面缓存中。虽然有时让人觉得很惊奇,但是,普通的文件 I/O 就是这样通过页面缓存来进行的。在 x86 架构的 Linux 中,内核将文件认为是一系列的 4KB 大小的块。如果你从文件中读取单个字节,包含这个字节的整个 4KB 块将被从磁盘中读入到页面缓存中。这是可以理解的,因为磁盘通常是持续吞吐的,并且程序一般也不会从磁盘区域仅仅读取几个字节。页面缓存知道文件中的每个 4KB 块的位置,在上图中用 #0#1 等等来描述。Windows 使用 256KB 大小的 视图 view ,类似于 Linux 的页面缓存中的 页面 page

不幸的是,在一个普通的文件读取中,内核必须拷贝页面缓存中的内容到用户缓冲区中,它不仅花费 CPU 时间和影响 CPU 缓存在复制数据时也浪费物理内存。如前面的图示,scene.dat 的内存被存储了两次,并且,程序中的每个实例都用另外的时间去存储内容。我们虽然解决了从磁盘中读取文件缓慢的问题,但是在其它的方面带来了更痛苦的问题。内存映射文件是解决这种痛苦的一个方法:

Mapped file read

当你使用文件映射时,内核直接在页面缓存上映射你的程序的虚拟页面。这样可以显著提升性能:Windows 系统编程 报告指出,在相关的普通文件读取上运行时性能提升多达 30% ,在 Unix 环境中的高级编程 的报告中,文件映射在 Linux 和 Solaris 也有类似的效果。这取决于你的应用程序类型的不同,通过使用文件映射,可以节约大量的物理内存。

对高性能的追求是永恒不变的目标,测量是很重要的事情,内存映射应该是程序员始终要使用的工具。这个 API 提供了非常好用的实现方式,它允许你在内存中按字节去访问一个文件,而不需要为了这种好处而牺牲代码可读性。在一个类 Unix 的系统中,可以使用 mmap 查看你的 地址空间,在 Windows 中,可以使用 CreateFileMapping.aspx),或者在高级编程语言中还有更多的可用封装。当你映射一个文件内容时,它并不是一次性将全部内容都映射到内存中,而是通过 页面故障 来按需映射的。在 获取 需要的文件内容的页面帧后,页面故障句柄 映射你的虚拟页面 到页面缓存上。如果一开始文件内容没有缓存,这还将涉及到磁盘 I/O。

现在出现一个突发的状况,假设我们的 render 程序的最后一个实例退出了。在页面缓存中保存着 scene.dat 内容的页面要立刻释放掉吗?人们通常会如此考虑,但是,那样做并不是个好主意。你应该想到,我们经常在一个程序中创建一个文件,退出程序,然后,在第二个程序去使用这个文件。页面缓存正好可以处理这种情况。如果考虑更多的情况,内核为什么要清除页面缓存的内容?请记住,磁盘读取的速度要慢于内存 5 个数量级,因此,命中一个页面缓存是一件有非常大收益的事情。因此,只要有足够大的物理内存,缓存就应该保持全满。并且,这一原则适用于所有的进程。如果你现在运行 render 一周后, scene.dat 的内容还在缓存中,那么应该恭喜你!这就是什么内核缓存越来越大,直至达到最大限制的原因。它并不是因为操作系统设计的太“垃圾”而浪费你的内存,其实这是一个非常好的行为,因为,释放物理内存才是一种“浪费”。(LCTT 译注:释放物理内存会导致页面缓存被清除,下次运行程序需要的相关数据,需要再次从磁盘上进行读取,会“浪费” CPU 和 I/O 资源)最好的做法是尽可能多的使用缓存。

由于页面缓存架构的原因,当程序调用 write() 时,字节只是被简单地拷贝到页面缓存中,并将这个页面标记为“脏”页面。磁盘 I/O 通常并不会立即发生,因此,你的程序并不会被阻塞在等待磁盘写入上。副作用是,如果这时候发生了电脑死机,你的写入将不会完成,因此,对于至关重要的文件,像数据库事务日志,要求必须进行 fsync()(仍然还需要去担心磁盘控制器的缓存失败问题),另一方面,读取将被你的程序阻塞,直到数据可用为止。内核采取预加载的方式来缓解这个矛盾,它一般提前预读取几个页面并将它加载到页面缓存中,以备你后来的读取。在你计划进行一个顺序或者随机读取时(请查看 madvise()readahead()Windows 缓存提示.aspx#caching_behavior) ),你可以通过 提示 hint 帮助内核去调整这个预加载行为。Linux 会对内存映射的文件进行 预读取,但是我不确定 Windows 的行为。当然,在 Linux 中它可能会使用 O\_DIRECT 跳过预读取,或者,在 Windows 中使用 NO\_BUFFERING.aspx) 去跳过预读,一些数据库软件就经常这么做。

一个文件映射可以是私有的,也可以是共享的。当然,这只是针对内存中内容的更新而言:在一个私有的内存映射上,更新并不会提交到磁盘或者被其它进程可见,然而,共享的内存映射,则正好相反,它的任何更新都会提交到磁盘上,并且对其它的进程可见。内核使用 写时复制 copy on write (CoW)机制,这是通过 页面表条目 page table entry (PTE)来实现这种私有的映射。在下面的例子中,render 和另一个被称为 render3d 的程序都私有映射到 scene.dat 上。然后 render 去写入映射的文件的虚拟内存区域:

The Copy-On-Write mechanism

  1. 两个程序私有地映射 scene.dat,内核误导它们并将它们映射到页面缓存,但是使该页面表条目只读。
  2. render 试图写入到映射 scene.dat 的虚拟页面,处理器发生页面故障。
  3. 内核分配页面帧,复制 scene.dat 的第二块内容到其中,并映射故障的页面到新的页面帧。
  4. 继续执行。程序就当做什么都没发生。

上面展示的只读页面表条目并不意味着映射是只读的,它只是内核的一个用于共享物理内存的技巧,直到尽可能的最后一刻之前。你可以认为“私有”一词用的有点不太恰当,你只需要记住,这个“私有”仅用于更新的情况。这种设计的重要性在于,要想看到被映射的文件的变化,其它程序只能读取它的虚拟页面。一旦“写时复制”发生,从其它地方是看不到这种变化的。但是,内核并不能保证这种行为,因为它是在 x86 中实现的,从 API 的角度来看,这是有意义的。相比之下,一个共享的映射只是将它简单地映射到页面缓存上。更新会被所有的进程看到并被写入到磁盘上。最终,如果上面的映射是只读的,页面故障将触发一个内存段失败而不是写到一个副本。

动态加载库是通过文件映射融入到你的程序的地址空间中的。这没有什么可奇怪的,它通过普通的 API 为你提供与私有文件映射相同的效果。下面的示例展示了映射文件的 render 程序的两个实例运行的地址空间的一部分,以及物理内存,尝试将我们看到的许多概念综合到一起。

Mapping virtual memory to physical memory

这是内存架构系列的第三部分的结论。我希望这个系列文章对你有帮助,对理解操作系统的这些主题提供一个很好的思维模型。


via:https://manybutfinite.com/post/page-cache-the-affair-between-memory-and-files/

作者:Gustavo Duarte 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这篇教程说明你应该怎样配置 nginx、设置 HTTP 头部过期时间,用 Cache-Control 中的 max-age 标记为静态文件(比如图片、 CSS 和 Javascript 文件)设置一个时间,这样用户的浏览器就会缓存这些文件。这样能节省带宽,并且在访问你的网站时会显得更快些(如果用户第二次访问你的网站,将会使用浏览器缓存中的静态文件)。

1、准备事项

我想你需要一个正常工作的 nginx 软件,就像这篇教程里展示的:在 Ubuntu 16.04 LTS 上安装 Nginx,PHP 7 和 MySQL 5.7 (LEMP)

2 配置 nginx

可以参考 expires 指令手册来设置 HTTP 头部过期时间,这个标记可以放在 http {}server {}location {} 等语句块或者 location {} 语句块中的条件语句中。一般会在 location 语句块中用 expires 指令控制你的静态文件,就像下面一样:

location ~*  \.(jpg|jpeg|png|gif|ico|css|js)$ {
   expires 365d;
}

在上面的例子中,所有后缀名是 .jpg.jpeg.png.gif.ico.css.js 的文件会在浏览器访问该文件之后的 365 天后过期。因此你要确保 location {} 语句块仅仅包含能被浏览器缓存的静态文件。

然后重启 nginx 进程:

/etc/init.d/nginx reload

你可以在 expires 指令中使用以下的时间设置:

  • offExpiresCache-Control 头部不能被更改。
  • epochExpires 头部设置成 1970 年 1 月 1 日 00:00:01。
  • max 设置 Expires 头部为 2037 年 12 月 31 日 23:59:59,设置 Cache-Control 的最大存活时间为 10 年
  • 没有 @ 前缀的时间意味着这是一个与浏览器访问时间有关的过期时间。可以指定一个负值的时间,就会把 Cache-Control 头部设置成 no-cache。例如:expires 10d 或者 expires 14w3d
  • @ 前缀的时间指定在一天中的某个时间过期,格式是 Hh 或者 Hh:Mm,H 的范围是 0 到 24,M 的范围是 0 到 59,例如:expires @15:34

你可以用以下的时间单位:

  • ms: 毫秒
  • s: 秒
  • m: 分钟
  • h: 小时
  • d: 天
  • w: 星期
  • M: 月 (30 天)
  • y: 年 (365 天)

例如:1h30m 表示一小时三十分钟,1y6M 表示一年六个月。

注意,要是你用一个在将来很久才会过期的头部,当组件修改时你就要改变组件的文件名。因此给文件指定版本是一个不错的方法。例如,如果你有个 javascript.js 文件 并且你要修改它,你可以在修改的文件名字后面添加一个版本号。这样浏览器就要下载这个文件,如果你没有更改文件名,浏览器将从缓存里面加载(旧的)文件。

除了把基于浏览器访问时间设置 Expires 头部(比如 expires 10d)之外,也可以通过在时间前面的 modified 关键字,将 Expires 头部的基准设为文件修改的时间(请注意这仅仅对存储在硬盘的实际文件有效)。

expires modified 10d;

3 测试

要测试你的配置是否有效,可以用火狐浏览器的开发者工具中的网络分析功能,然后用火狐访问一个静态文件(比如一张图片)。在输出的头部信息里,应该能看到 Expires 头部和有 max-age 标记的 Cache-Control 头部(max-age 标记包含了一个以秒为单位的值,比如 31536000 就是指今后的一年)

4 链接

nginx 的 Http 头部模块(HttpHeadersModule): http://wiki.nginx.org/HttpHeadersModule


via: https://www.howtoforge.com/tutorial/how-to-cache-static-files-on-nginx/

作者:Falko Timme 译者:GitFuture 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

简介

对于您的站点的访问者来说,智能化的内容缓存是提高用户体验最有效的方式之一。缓存,或者对之前的请求的临时存储,是HTTP协议实现中最核心的内容分发策略之一。分发路径中的组件均可以缓存内容来加速后续的请求,这受控于对该内容所声明的缓存策略。

在这份指南中,我们将讨论一些Web内容缓存的基本概念。这主要包括如何选择缓存策略以保证互联网范围内的缓存能够正确的处理您的内容。我们将谈一谈缓存带来的好处、副作用以及不同的策略能带来的性能和灵活性的最大结合。

什么是缓存(caching)?

缓存(caching)是一个描述存储可重用资源以便加快后续请求的行为的术语。有许多不同类型的缓存,每种都有其自身的特点,应用程序缓存和内存缓存由于其对特定回复的加速,都很常用。

这份指南的主要讲述的Web缓存是一种不同类型的缓存。Web缓存是HTTP协议的一个核心特性,它能最小化网络流量,并且提升用户所感知的整个系统响应速度。内容从服务器到浏览器的传输过程中,每个层面都可以找到缓存的身影。

Web缓存根据特定的规则缓存相应HTTP请求的响应。对于缓存内容的后续请求便可以直接由缓存满足而不是重新发送请求到Web服务器。

好处

有效的缓存技术不仅可以帮助用户,还可以帮助内容的提供者。缓存对内容分发带来的好处有:

  • 减少网络开销:内容可以在从内容提供者到内容消费者网络路径之间的许多不同的地方被缓存。当内容在距离内容消费者更近的地方被缓存时,由于缓存的存在,请求将不会消耗额外的网络资源。
  • 加快响应速度:由于并不是必须通过整个网络往返,缓存可以使内容的获得变得更快。缓存放在距用户更近的地方,例如浏览器缓存,使得内容的获取几乎是瞬时的。
  • 在同样的硬件上提高速度:对于保存原始内容的服务器来说,更多的性能可以通过允许激进的缓存策略从硬件上压榨出来。内容拥有者们可以利用分发路径上某个强大的服务器来应对特定内容负载的冲击。
  • 网络中断时内容依旧可用:使用某种策略,缓存可以保证在原始服务器变得不可用时,相应的内容对用户依旧可用。

术语

在面对缓存时,您可能对一些经常遇到的术语可能不太熟悉。一些常见的术语如下:

  • 原始服务器:原始服务器是内容的原始存放地点。如果您是Web服务器管理员,它就是您所管理的机器。它负责为任何不能从缓存中得到的内容进行回复,并且负责设置所有内容的缓存策略。
  • 缓存命中率:一个缓存的有效性依照缓存的命中率进行度量。它是可以从缓存中得到数据的请求数与所有请求数的比率。缓存命中率高意味着有很高比例的数据可以从缓存中获得。这通常是大多数管理员想要的结果。
  • 新鲜度:新鲜度用来描述一个缓存中的项目是否依旧适合返回给客户端。缓存中的内容只有在由缓存策略指定的新鲜期内才会被返回。
  • 过期内容:缓存中根据缓存策略的新鲜期设置已过期的内容。过期的内容被标记为“陈旧”。通常,过期内容不能用于回复客户端的请求。必须重新从原始服务器请求新的内容或者至少验证缓存的内容是否仍然准确。
  • 校验:缓存中的过期内容可以验证是否有效以便刷新过期时间。验证过程包括联系原始服务器以检查缓存的数据是否依旧代表了最近的版本。
  • 失效:失效是依据过期日期从缓存中移除内容的过程。当内容在原始服务器上已被改变时就必须这样做,缓存中过期的内容会导致客户端发生问题。

还有许多其他的缓存术语,不过上面的这些应该能帮助您开始。

什么能被缓存?

某些特定的内容比其他内容更容易被缓存。对大多数站点来说,一些适合缓存的内容如下:

  • Logo和商标图像
  • 普通的不变化的图像(例如,导航图标)
  • CSS样式表
  • 普通的Javascript文件
  • 可下载的内容
  • 媒体文件

这些文件更倾向于不经常改变,所以长时间的对它们进行缓存能获得好处。

一些项目在缓存中必须加以注意:

  • HTML页面
  • 会替换改变的图像
  • 经常修改的Javascript和CSS文件
  • 需要有认证后的cookies才能访问的内容

一些内容从来不应该被缓存:

  • 与敏感信息相关的资源(银行数据,等)
  • 用户相关且经常更改的数据

除上面的通用规则外,通常您需要指定一些规则以便于更好地缓存不同种类的内容。例如,如果登录的用户都看到的是同样的网站视图,就应该在任何地方缓存这个页面。如果登录的用户会在一段时间内看到站点中用户特定的视图,您应该让用户的浏览器缓存该数据而不应让任何中介节点缓存该视图。

Web内容缓存的位置

Web内容会在整个分发路径中的许多不同的位置被缓存:

  • 浏览器缓存:Web浏览器自身会维护一个小型缓存。典型地,浏览器使用一种策略指示缓存最重要的内容。这可能是用户相关的内容或可能会再次请求且下载代价较高。
  • 中间缓存代理:任何在客户端和您的基础架构之间的服务器都可以按期望缓存一些内容。这些缓存可能由ISP(网络服务提供者)或者其他独立组织提供。
  • 反向缓存:您的服务器基础架构可以为后端的服务实现自己的缓存。如果实现了缓存,那么便可以在处理请求的位置返回相应的内容而不用每次请求都使用后端服务。

上面的这些位置通常都可以根据它们自身的缓存策略和内容源的缓存策略缓存一些相应的内容。

缓存头部

缓存策略依赖于两个不同的因素。所缓存的实体本身需要决定是否应该缓存可接受的内容。它可以只缓存部分可以缓存的内容,但不能缓存超过限制的内容。

缓存行为主要由缓存策略决定,而缓存策略由内容拥有者设置。这些策略主要通过特定的HTTP头部来清晰地表达。

经过几个不同HTTP协议的变化,出现了一些不同的针对缓存方面的头部,它们的复杂度各不相同。下面列出了那些你也许应该注意的:

  • **Expires**:尽管使用范围相当有限,但Expires头部是非常简洁明了的。通常它设置一个未来的时间,内容会在此时间过期。这时,任何对同样内容的请求都应该回到原始服务器处。这个头部或许仅仅最适合回退模式(fall back)。
  • **Cache-Control**:这是Expires的一个更加现代化的替换物。它已被很好的支持,且拥有更加灵活的实现。在大多数案例中,它比Expires更好,但同时设置两者的值也无妨。稍后我们将讨论您可以设置的Cache-Control的详细选项。
  • **ETag**:ETag用于缓存验证。源服务器可以在首次服务一个内容时为该内容提供一个独特的ETag。当一个缓存需要验证这个内容是否即将过期,他会将相应的ETag发送回服务器。源服务器或者告诉缓存内容是一致的,或者发送更新后的内容(带着新的ETag)。
  • Last-Modified:这个头部指明了相应的内容最后一次被修改的时间。它可能会作为保证内容新鲜度的验证策略的一部分被使用。
  • **Content-Length**:尽管并没有在缓存中明确涉及,Content-Length头部在设置缓存策略时很重要。某些软件如果不提前获知内容的大小以留出足够空间,则会拒绝缓存该内容。
  • **Vary**:缓存系统通常使用请求的主机和路径作为存储该资源的键。当判断一个请求是否是请求同样内容时,Vary头部可以被用来提醒缓存系统需要注意另一个附加头部。它通常被用来告诉缓存系统同样注意Accept-Encoding头部,以便缓存系统能够区分压缩和未压缩的内容。

Vary头部的隐语

Vary头部提供给您存储同一个内容的不同版本的能力,代价是降低了缓存的容量。

在使用Accept-Encoding时,设置Vary头部允许明确区分压缩和未压缩的内容。这在服务某些不能处理压缩数据的浏览器时很重要,它可以保证基本的可用性。Vary的一个典型的值是Accept-Encoding,它只有两到三个可选的值。

一开始看上去User-Agent这样的头部可以用于区分移动浏览器和桌面浏览器,以便您的站点提供差异化的服务。但User-Agent字符串是非标准的,结果将会造成在中间缓存中保存同一内容的许多不同版本的缓存,这会导致缓存命中率的降低。Vary头部应该谨慎使用,尤其是您不具备在您控制的中间缓存中使请求标准化的能力(也许可以,比如您可以控制CDN的话)。

缓存控制标志怎样影响缓存

上面我们提到了Cache-Control头部如何被用与现代缓存策略标准。能够通过这个头部设定许多不同的缓存指令,多个不同的指令通过逗号分隔。

一些您可以使用的指示内容缓存策略的Cache-Control的选项如下:

  • no-cache:这个指令指示所有缓存的内容在新的请求到达时必须先重新验证,再发送给客户端。这条指令实际将内容立刻标记为过期的,但允许通过验证手段重新验证以避免重新下载整个内容。
  • no-store:这条指令指示缓存的内容不能以任何方式被缓存。它适合在回复敏感信息时设置。
  • public:它将内容标记为公有的,这意味着它能被浏览器和其他任何中间节点缓存。通常,对于使用了HTTP验证的请求,其回复被默认标记为privatepublic标记将会覆盖这个设置。
  • private:它将内容标记为私有的。私有数据可以被用户的浏览器缓存,但不能被任何中间节点缓存。它通常用于用户相关的数据。
  • max-age:这个设置指示了缓存内容的最大生存期,它在最大生存期后必须在源服务器处被验证或被重新下载。在现代浏览器中这个选项大体上取代了Expires头部,浏览器也将其作为决定内容的新鲜度的基础。这个选项的值以秒为单位表示,最大可以表示一年的新鲜期(31536000秒)。
  • s-maxage:这个选项非常类似于max-age,它指明了内容能够被缓存的时间。区别是这个选项只在中间节点的缓存中有效。结合这两个选项可以构建更加灵活的缓存策略。
  • must-revalidate:它指明了由max-ages-maxageExpires头部指明的新鲜度信息必须被严格的遵守。它避免了缓存的数据在网络中断等类似的场景中被使用。
  • proxy-revalidate:它和上面的选项有着一样的作用,但只应用于中间的代理节点。在这种情况下,用户的浏览器可以在网络中断时使用过期内容,但中间缓存内容不能用于此目的。
  • no-transform:这个选项告诉缓存在任何情况下都不能因为性能的原因修改接收到的内容。这意味着,缓存不允许压缩接收到的内容(没有从原始服务器处接收过压缩版本的该内容)并发送。

这些选项能够以不同的方式结合以获得不同的缓存行为。一些互斥的值如下:

  • no-cacheno-store以及由其他前面未提到的选项指明的常用的缓存行为
  • publicprivate

如果no-storeno-cache都被设置,那么no-store会取代no-cache。对于非授权的请求的回复,public是隐含的设置。对于授权的请求的回复,private选项是隐含的。他们可以通过在Cache-Control头部中指明相应的相反的选项以覆盖。

开发一种缓存策略

在理想情况下,任何内容都可以被尽可能缓存,而您的服务器只需要偶尔的提供一些验证内容即可。但这在现实中很少发生,因此您应该尝试设置一些明智的缓存策略,以在长期缓存和站点改变的需求间达到平衡。

常见问题

在许多情况中,由于内容被产生的方式(如根据每个用户动态的产生)或者内容的特性(例如银行的敏感数据),这些内容不应该被缓存。另一些许多管理员在设置缓存时可能面对的问题是外部缓存的数据未过期,但新版本的数据已经产生。

这些都是经常遇到的问题,它们会影响缓存的性能和您提供的数据的准确性。然而,我们可以通过开发提前预见这些问题的缓存策略来缓解这些问题。

一般性建议

尽管您的实际情况会指导您选择的缓存策略,但是下面的建议能帮助您获得一些合理的决定。

在您担心使用哪一个特定的头部之前,有一些特定的步骤可以帮助您提高您的缓存命中率。一些建议如下:

  • 为图像、CSS和共享的内容建立特定的文件夹:将内容放到特定的文件夹内使得您可以方便的从您的站点中的任何页面引用这些内容。
  • 使用同样的URL来表示同样的内容:由于缓存使用内容请求中的主机名和路径作为键,因此应保证您的所有页面中的该内容的引用方式相同,前一个建议能让这点更加容易做到。
  • 尽可能使用CSS图像拼接:对于像图标和导航等内容,使用CSS图像拼接能够减少渲染您页面所需要的请求往返,并且允许对拼接缓存很长一段时间。
  • 尽可能将主机脚本和外部资源本地化:如果您使用Javascript脚本和其他外部资源,如果上游没有提供合适的缓存头部,那么您应考虑将这些内容放在您自己的服务器上。您应该注意上游的任何更新,以便更新本地的拷贝。
  • 对缓存内容收集文件摘要:静态的内容比如CSS和Javascript文件等通常比较适合收集文件摘要。这意味着为文件名增加一个独特的标志符(通常是这个文件的哈希值)可以在文件修改后绕开缓存保证新的内容被重新获取。有很多工具可以帮助您创建文件摘要并且修改HTML文档中的引用。

对于不同的文件正确地选择不同的头部这件事,下面的内容可以作为一般性的参考:

  • 允许所有的缓存存储一般内容:静态内容以及非用户相关的内容应该在分发链的所有节点被缓存。这使得中间节点可以将该内容回复给多个用户。
  • 允许浏览器缓存用户相关的内容:对于每个用户的数据,通常在用户自己的浏览器中缓存是可以被接受且有益的。缓存在用户自身的浏览器能够使得用户在接下来的浏览中能够瞬时读取,但这些内容不适合在任何中间代理节点缓存。
  • 将时间敏感的内容作为特例:如果您的数据是时间敏感的,那么相对上面两条参考,应该将这些数据作为特例,以保证过期的数据不会在关键的情况下被使用。例如,您的站点有一个购物车,它应该立刻反应购物车里面的物品。依据内容的特点,可以在Cache-Control头部中使用no-cacheno-store选项。
  • 总是提供验证器:验证器使得过期的内容可以无需重新下载而得到刷新。设置ETagLast-Modified头部将允许缓存向原始服务器验证内容,并在内容未修改时刷新该内容新鲜度以减少负载。
  • 对于支持的内容设置长的新鲜期:为了更加有效的利用缓存,一些作为支持性的内容应该被设置较长的新鲜期。这通常比较适合图像和CSS等由用户请求用来渲染HTML页面的内容。和文件摘要一起,设置延长的新鲜期将允许缓存长时间的存储这些资源。如果资源发生改变,修改的文件摘要将会使缓存的数据无效并触发对新的内容的下载。那时,新的支持的内容会继续被缓存。
  • 对父内容设置短的新鲜期:为了使得前面的模式正常工作,容器类的内容应该相应的设置短的新鲜期,或者设置不全部缓存。这通常是在其他协助内容中使用的HTML页面。这个HTML页面将会被频繁的下载,使得它能快速的响应改变。支持性的内容因此可以被尽量缓存。

关键之处便在于达到平衡,一方面可以尽量的进行缓存,另一方面为未来保留当改变发生时从而改变整个内容的机会。您的站点应该同时具有:

  • 尽量缓存的内容
  • 拥有短的新鲜期的缓存内容,可以被重新验证
  • 完全不被缓存的内容

这样做的目的便是将内容尽可能的移动到第一个分类(尽量缓存)中的同时,维持可以接受的缓存命中率。

结论

花时间确保您的站点使用了合适的缓存策略将对您的站点产生重要的影响。缓存使得您可以在保证服务同样内容的同时减少带宽的使用。您的服务器因此可以靠同样的硬件处理更多的流量。或许更重要的是,客户们能在您的网站中获得更快的体验,这会使得他们更愿意频繁的访问您的站点。尽管有效的Web缓存并不是银弹,但设置合适的缓存策略会使您以最小的代价获得可观的收获。


via: https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies

作者: Justin Ellingwood 译者:wwy-hust 校对:wxy 推荐:royaso

本文由 LCTT 原创翻译,Linux中国 荣誉推出

我在Linux下使用拨号连接上网,频繁的拨号断线造成DNS的问题。我如何在Linux/Unix发行版下使用shell命令清除DNS缓存?

在MS-Windows下,你可以使用ipconfig命令来清除dns缓存。然而,Linux和Unix提供了不同的方法来清除缓存。Linux可以运行 nscd 或者 BIND 或者 dnsmasq 作为名称服务缓存守护进程。大型或者工作组服务器可能使用BIND或者dnsmasq作为专用缓存服务器来加速查询。

如何: 清除 nscd dns 缓存

Nscd 会缓存libc发起的名称服务的请求。如果把检索NSS数据看做很慢,那么nscd能够显著加快连续访问同一数据的速度,并能提高整个系统的性能。只需重启nscd即可刷新缓存:

$ sudo /etc/init.d/nscd restart

# service nscd restart

# service nscd reload

这个守护进程给最常用的名称服务请求提供了高速缓存。默认的配置文件/etc/nscd.conf,其决定了高速缓存守护进程的行为。

清除 dnsmasq dns 缓存

dnsmasq的是一个轻量级的DNS、TFTP和DHCP服务器。它的目的是给局域网提供配对的DNS和DHCP服务。 dnsmasq接受DNS查询,并从一个小的本地高速缓存应答它们或将其转发到一个真正的递归DNS服务器。该软件也被安装在很多便宜的路由器上来缓存DNS查询。只需重新启动dnsmasq的服务来清除DNS缓存:

$ sudo /etc/init.d/dnsmasq restart

或者

# service dnsmasq restart

清除BIND缓存服务器的dns缓存

一台BIND缓存服务器从另一台服务器(区域主)响应主机的查询而获得信息,然后保存(缓存)数据到本地。您所要做的就是重启BIND以清除其缓存:

# /etc/init.d/named restart

你也可以使用下面rndc命令来清除所有的缓存:

# rndc restart

或者

# rndc exec

BIND v9.3.0 及其以上版本支持一个清除一个特定域名的所有记录缓存的命令:rndc flushname。本例中刷新cyberciti.biz相关域的所有记录:

# rndc flushname cyberciti.biz

同样也可以清除BIND View。比如,LAN和WAN的View可以用下面的命令清除:

# rndc flush lan
# rndc flush wan

给 Mac OS X Unix 用户的提示

Mac下用root用户输入下面的命令:

# dscacheutil -flushcache

或者

$ sudo dscacheutil -flushcache

如果你正在使用OSX 10.5 或者更早的版本,尝试使用下面的命令:

lookupd -flushcache

关于 /etc/hosts 文件的一个提示

/etc/hosts用作静态查询主机的表格。你需要在类Unix操作系统下依据你的要求移除并且/或者更新它:

# vi /etc/hosts

示例输出:

127.0.0.1   localhost
127.0.1.1   wks01.WAG160N   wks01
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.37.34.2     build
192.168.1.10    nas01
192.168.1.11    nas02
192.168.1.12    nas03
#192.168.2.50   nfs2.nixcraft.net.in nfs2
#192.168.2.51   nfs1.nixcraft.net.in nfs1
172.168.232.50  nfs1.nixcraft.net.in nfs1
172.168.232.51  nfs2.nixcraft.net.in nfs2
192.168.1.101   vm01

参考

相关: 在Windows Vista / XP中用ipconfig 命令清除 DNS 缓存


via: http://www.cyberciti.biz/faq/rhel-debian-ubuntu-flush-clear-dns-cache/

译者:geekpi 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出