最近，大众对于REST风格应用架构表现出强烈兴趣，这表明Web的优雅设计开始受到人们的注意。现在，我们逐渐理解了“3W架构（Architecture of the World Wide Web）”内在所蕴含的可伸缩性和弹性，并进一步探索运用其范式的方法。本文中，我们将探究一个可被Web开发者利用的、鲜为人知的工具，不引人注意的“ETag响应头（ETag Response Header）”，以及如何将它集成进基于Spring和Hibernate的动态Web应用，以提升应用程序性能和可伸缩性。
我们将要使用的Spring框架应用是基于“宠物诊所（petclinic）”的。下载文件中包含了关于如何增加必要的配置及源码的说明，你可以自己尝试。
HTTP协议规格说明定义ETag为“被请求变量的实体值” （参见 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html —— 章节 14.19）。 另一种说法是，ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义，并在HTTP响应头中将其传送到客户端。
聪明的服务器开发者会把ETags和GET请求的“If-None-Match”头一起使用，这样可利用客户端（例如浏览器）的缓存。因为服务器首先产生ETag，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户端）缓存。
其过程如下：
本文的其余部分将展示在基于Spring框架的Web应用中利用ETag的两种方法，该应用使用Spring MVC。首先我们将使用Servlet 2.3 Filter，利用展现视图（rendered view）的MD5校验和（checksum）以实现生成ETag的方法（一个“浅显的”ETag实现）。 第二种方法使用更为复杂的方法追踪view中所使用的model，以确定ETag有效性（一个“深入的”ETag实现）。尽管我们使用的是Spring MVC，但该技术可以应用于任何MVC风格的Web框架。
在我们继续之前，强调一下这里所展现的是提升动态产生页面性能的技术。已有的优化技术也应作为整体优化和应用性能特性调整分析的一部分来考虑。（见下）。
自顶向下的Web缓存
本文主要涉及对动态生成页面使用HTTP缓存技术。当考虑提升Web应用的性能的时候，应采取一个整体的、自顶向下的方法。为了这一目的，理解HTTP请求经过的各层是很重要的，应用哪些适当的技术取决于你所关注的热点。例如：
- 将Apache作为Servlet容器的前端，来处理如图片和javascript脚本这样的静态文件，而且还可以使用FileETag指令创建ETag响应头。
- 使用针对javascript文件的优化技术，如将多个文件合并到一个文件中以及压缩空格。
- 利用GZip和缓存控制头（Cache-Control headers）。
- 为确定你的Spring框架应用的痛处所在，可以考虑使用 JamonPerformanceMonitorInterceptor。
- 确信你充分利用ORM工具的缓存机制，因此对象不需要从数据库中频繁的再生。花时间确定如何让查询缓存为你工作是值得的。
- 确保你最小化数据库中获取的数据量，尤其是大的列表。如果每个页面只请求大列表的一个小子集，那么大列表的数据应由其中某个页面一次获得。
- 使放入到HTTP session中的数据量最小。这样内存得到释放，而且当将应用集群的时候也会有所帮助。
- 使用数据库明细（database profiling）工具来查看在查询的时候使用了什么索引，在更新的时候整个表没有被上锁。
当然，应用性能优化的至理名言是：两次测量，一次剪裁（measure twice, cut once）。哦，等等，这是对木工而言的！没错，但是它在这里也很适用！
我们要考虑的第一种方法是创建一个Servlet Filter，它将基于页面（MVC中的“View”）的内容产生其ETag 记号。乍一看，使用这种方法所获得的任何性能提升看起来都是违反直觉的。我们仍然不得不产生页面，而且还增加了产生记号的计算时间。然而，这里的想法是减少带宽使用。在大的响应时间情形下，如你的主机和客户端分布在这个星球的两端，这很大程度上是有益的。我曾见过东京办公室使用纽约服务器上托管的应用，其响应时间达到了 350 ms。随着并发用户数的增长，这将变成巨大的瓶颈。
我们用来产生记号的技术是基于从页面内容计算MD5哈希值。这通过在响应之上创建一个包装器来实现。该包装器使用字节数组来保存所产生的内容，在filter链处理完成之后我们利用数组的MD5哈希值计算记号。
doFilter方法的实现如下所示。
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException,
ServletException {
HttpServletRequest servletRequest = (HttpServletRequest) req;
HttpServletResponse servletResponse = (HttpServletResponse) res;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ETagResponseWrapper wrappedResponse = new ETagResponseWrapper(servletResponse, baos);
chain.doFilter(servletRequest, wrappedResponse);
byte[] bytes = baos.toByteArray();
String token = '"' + ETagComputeUtils.getMd5Digest(bytes) + '"';
servletResponse.setHeader("ETag", token); // always store the ETag in the header
String previousToken = servletRequest.getHeader("If-None-Match");
if (previousToken != null && previousToken.equals(token)) { // compare previous token with current one
logger.debug("ETag match: returning 304 Not Modified");
servletResponse.sendError(HttpServletResponse.SC_NOT_MODIFIED);
// use the same date we sent when we created the ETag the first time through
servletResponse.setHeader("Last-Modified", servletRequest.getHeader("If-Modified-Since"));
} else { // first time through - set last modified time to now
Calendar cal = Calendar.getInstance();
cal.set(Calendar.MILLISECOND, 0);
Date lastModified = cal.getTime();
servletResponse.setDateHeader("Last-Modified", lastModified.getTime());
logger.debug("Writing body content");
servletResponse.setContentLength(bytes.length);
ServletOutputStream sos = servletResponse.getOutputStream();
sos.write(bytes);
sos.flush();
sos.close();
}
}
