本文禁止转载，由UC浏览器内部出品。
3. HTTP Cache
综述
HTTP Cache是完全按照IETF规范实现的，最新的RFC规范地址是
https://tools.ietf.org/html/rfc7234。它的作用就是保存可缓存的响应以备重新使用，在下次请求时可减少响应时间和网络带宽。只有GET和HEAD method会缓存。
浏览器的优化
浏览器是过滤了部分没有意义进行缓存的响应头才保存到磁盘，例如Connection（keep-alive）、www-authenticate等。这能减少耗时较多的磁盘IO时间。另外Cookie也不会保存在HTTP Cache，而是存到专门的Cookie Storage。
新的规范允许先使用后验证（stale-while-revalidate）https://tools.ietf.org/html/rfc5861
在隐身模式下，不存在磁盘读写的HTTP Cache。
http://www.chromium.org/user-experience/incognito。
但是某些浏览器厂商可能做优化，在临时文件夹中读写，退出或重启即删。
容量
容量是以整体计算的，不区分Domain。
Android WebView是20MB。iOS WebView也可能是20MB（根据https://github.com/gnustep/base/blob/master/Source/NSURLCache.m，不确定GNUstep是否也是Apple的源码）。
PC上的Chromium是以80MB为基准结合磁盘可用空间来考虑的，最大是320MB。算法是：
// js伪代码
if (可用空间 < 100MB)
容量 = 80%的可用空间 // < 80MB
else if (可用空间 < 800MB)
容量 = 80MB
else if (可用空间 < 2000MB) // 约2GB
容量 = 10%的可用空间 // < 200MB
else if (可用空间 < 20000MB) // 约20GB
容量 = 200MB
else // >= 20000MB
容量 = Math.min(1%的可用空间, 320MB) // 200MB <= 容量 <= 320MB其它基于Chromium开发的浏览器可能会修改这个算法，特别是移动浏览器会扩大那个常量值，以更高容量来提高资源复用数（嗯，不是复用率）。
淘汰
淘汰算法是一般是LRU，但在一些场景会结合文件大小、时间因素等做进一步优化。Cache的管理模块会记录总的缓存大小，每次创建新的缓存时会判断是否缓存是否超出容量限制，满了就会按LRU淘汰一定比例的缓存。
浏览器需要对缓存的文件进行索引，如果这个索引损坏，浏览器会删除所有的缓存。用户也可以通过设置界面来删除。此外，第三方程序也会做清理。
Revalidation
用户点击刷新按钮，会强制走revalidate流程，其它的情况都按照规范来执行。
RFC规范不只是为服务器和浏览器设计的，还考虑了网络中的各种节点，比如代理服务器、CDN服务器、智能路由等。
Chromium肯定是严格遵守RFC规范的，但第三方浏览器通常会破坏这些规范来获得一定的性能提升。比如更宽松的缓存条件。
Chromium代码参考：http_response_headers.cc ： RequiresValidation
后端优化
后端需要在响应中添加Cache-Control来利用浏览器缓存。
- Expires不要超过一年。
- 稳定的文件应该加上max-age。max-age不要大于2^31，以免大于int32而变成负数。
- Some HTTP/1.0 caches might not implement Cache-Control.对HTTP 1.0可以使用Pragma
没有任何与过期相关的指令的话，是由client端决定是否缓存的。Chromium有缓存，但再次请求的时候并不会走Revalidate流程，还是会得到200 OK。
因为HTTP Cache以URL为key，所以不想用以前的缓存，则可以更换URL，例如加不同的query、改文件名（如加上MD5或版本号）等。URL是忽略锚点的。
要做性能优化的同学，可以在协议文档里淘金。鉴于网上也有不少文章，这里不做整理了。
4. Cookie Storage
综述
因为Cookie是在多个请求头中复用数据的，所以需要从响应头中抽取出来另外保存。而且Cookie有自己的生命周期管理语法，就有独立的模块来管理。Cookie数据同时保存在内存和磁盘。
容量
容量是规范里就有建议最小值的。最新规范是RFC6265，它引用两个比较旧的规范RFC2965和RFC2109。
其中最老的规范RFC2109的6.3.1节中就有说明：
拒绝服务攻击
浏览器应该按照host或域名设置Cookie的数量和数据大小上限。
Denial of Service Attacks
User agents may choose to set an upper bound on the number of cookies
to be stored from a given host or domain name or on the size of the
cookie information. Otherwise a malicious server could attempt to
flood a user agent with many cookies, or large cookies, on successive
responses, which would force out cookies the user agent had received
from other servers. However, the minima specified above should still
be supported.Chromium的实现是：
- 每个Cookie的最大长度为4096 bytes。大于这个长度的Cookie将不被处理，即不会保存。
- 每个域的最大数量是180个
- 总体的个数是3300个
这里有各个浏览器的Cookie限制列表：http://browsercookielimits.squawky.net/。
内存缓存
从容量可知，所有Cookie占用的最大内存为3300*4K ≈ 13M。这点内存在手机上也是支撑得了的，所以Chromium会把硬盘上的全部Cookie数据都读到内存，每次发送请求都是在内存中查找，所以速度很快。在收到响应，需要创建或更新Cookie时，Chromium才会去写硬盘。而这个写操作是在非网络线程中完成的，避免慢速的文件IO占用网络线程的时间。
内存中的组织是以eTLD+1为key放在multimap里。
Chromium用SQLite存放cookie。在PC上是对value加密的。在iOS不加密，因为它的沙箱机制足够完善了，除非越狱。
Chromium把增删改表示为操作，向数据库发指令，而不是全部写一次。它是在后台线程flush。每30秒或满512次操作就直接Flush。
参考
http://www.quantum-step.com/download/sources/mystep/Foundation/Sources/NSHTTPCookieStorage.m
Apple是用了系统的NSHTTPCookieStorage。是全写的。
（注：本节的描述经过简化，非真实完整的实现）
淘汰
每次创建或更新Cookie就会进行垃圾回收的判断。有下列的规则：
1. 先淘汰过期的。即超出Max-Age指定时间。
2. 如果超出容量，则会按LRU规则（这里的used是指accessed）淘汰掉300个Cookie。
3. 如果最近30天内有访问过，即使超出容量也不会淘汰掉。
下面是Chromium源码中的部分注释供参考。
// Any cookies accessed more recently than kSafeFromGlobalPurgeDays will not
// be evicted by global garbage collection, even if we have more than
// kMaxCookies. This does not affect domain garbage collection.
const int CookieMonster::kSafeFromGlobalPurgeDays = 30;
const size_t CookieMonster::kPurgeCookies = 300;
const size_t CookieMonster::kDomainCookiesQuotaLow = 30;
const size_t CookieMonster::kDomainCookiesQuotaMedium = 50;
const size_t CookieMonster::kDomainCookiesQuotaHigh =
kDomainMaxCookies - kDomainPurgeCookies - kDomainCookiesQuotaLow -
kDomainCookiesQuotaMedium;开发建议
- 浏览器可能会被用户设置成禁用Cookie。当确实需要Cookie而发现获取不了时，请做好一定的提示，提升用户体验。
- 设好max-age，不要让冗余的cookie加入到请求头里，可加速连网过程。
- 因为都在内存，Cookie操作的时耗较少，但太大的cookie会在连网阶段造成较高的延时。还是乖乖地加上Expire吧。
