静态页面我们都知道，WEB服务器在发回文件内容时会附带一个Last-Modified头信息，把静态文件的最后修改时间存储在里面，这样当下次浏览器请求该文件时，会把得到的这个Last-Modified头信息里的时间存在If-Modified-Since里一起发送给服务器，告诉服务器本地缓存的最后修改时间，当服务器接收到有If-Modified-Since时间信息的请求时，会先判断文件的最后修改时间是否比这个时间晚，晚就说明有更新，就会重发文件内容，并附带最新的Last-Modified头信息给客户端，如果时间相等或者比这个时间早，那就说明没有更新，缓存完全同步，就会直接发回一个304 Not Modified状态码，并且停止重发文件内容，可以节省不必要的数据传输。
以上是静态页面的缓存和更新控制机制，一般这一切都是由WEB服务器直接包办处理的，完全不需要用户干预。但动态页面就没这么幸运了，由于对动态页面的请求，都是由WEB服务器转接给特定的页面处理程序来完成，而且不会包办其缓存和更新的策略问题，所以这些控制就必须有程序员自己来完成了。然而更不幸的是，动态页面处理程序自己是无法自动处理缓存的，特别是整页面级别的缓存，我们可以在代码里缓存一个变量以便于下次调用，但仍然要执行很多程序代码，能不能像静态页面那样，给客户端一个Last-Modified头信息，下次请求时再判断这个时间和数据的更新时间，以便决定是否重复处理和发送数据？
从以上分析来看这是完全可行的，不过需要对脚本程序做特殊处理，也就是需要一个逻辑来规范这个更新的检测，当然这里不是重点讨论这个了。因为客户端接受最后修改时间完全是依靠Last-Modified头信息，所以只要动态脚本能在发回内容的时候也输出一个时间作为判断依据的话，那么下次客户端请求同一个页面（准确的说应该是同一个URL地址）的话，会把接收到的Last-Modified头信息里的时间也附加到If-Modified-Since请求过来。到了动态页面这里，我们就可以获取到这个请求附带的最后修改时间，然后先判断时间点之后是否有新处理的数据，没有新数据的话，我们就直接结束当前脚本，就可以节省服务端资源。当然结束脚本之前，需要发挥一个304的状态码，因为要让客户端确认使用缓存的话，也必须依赖这个状态码，所以只需要用动态脚本发回一个的304 Not Modified头信息就可以了，不但节省了服务器脚本的执行资源，还节省了流量，可谓一举两得，而且应用形式更灵活更可控。