当Android遇见HTTP缓存代理服务器

前言：

在web上面经常会使用大量的缓存服务器来加速一些静态页面和静态资源的访问，比如CDN服务器加速，DNS负载均衡等技术，常用的服务有nginx，squid等。那么Android客户端能不能也借助这些技术加快静态页面的访问，降低服务器负载呢？当然是可以的，本文就从代码的角度讨论如何加速Android客户端静态页面和静态资源的访问速度。

一些变化不大的静态页面和json数据没有必要每次打开都请求一遍网络，既增加了服务器压力，占用网络带宽，增加用户等待时间，也耗费了用户的网络流量，尤其在现在手机客户端用户一半以上都在使用流量上网，为用户节省流量是保住用户的一个关键。所以，做好Android APP的本地网络缓存非常的重要。

okhttp是一个非常优秀的http网络框架，它可以不仅可以实现网络文件下载后的自动缓存至sd卡，还可以对普通的以json字符串为body的GET请求。Android客户端上常用的网络请求缓存我把它分为两类，第一大类是需要联网才能调用的缓存，第二种是无条件的缓存，在缓存过期前只要调用相同的url就会使用上次获得的结果。

做这项研究始于一个偶然的bug，在公司开发项目的时候，为了翻墙方便，搭建了一个linux的翻墙代理服务器，使用的软件是polipo，然后发现app上一些刷新功能不好用了，现象是每次刷新时间特别短，几乎瞬间完成，但是根本没有取得最新的数据。从以往的经验来看，绝对不会这么快就能完成一次网络请求。当把wifi关掉切换4g或者重新登录，刷新功能又恢复正常。于是我怀疑是http代理服务器的缓存所致。既然如此，不如直接发回http代理服务器的缓存功能来缓存一些静态页面，达到CDN一样的网络加速功能。

给大家推荐一篇文章科普一下基础知识，并盗图一张

http://www.codeceo.com/article/http-cache-control.html

所需工具：

1、局域网linux主机一台。

2、nginx，squid，polipo或其他功能相似的http代理软件，本文是围绕polipo展开的（polipo适合小型网络代理环境搭建，不适合生产环境，这里仅做测试用）。

3、Android app一款，我测试过基于HttpURLConnection和Okhttp的网络请求框架均支持代理缓存。

4、真实数据服务器一台，用于向Android客户端返回json字符串。

科普一下使用Polipo作为 代理服务器在缓存功能上的优势：

1、代理和缓存

代理是一种同时作为客户端和服务器端工作的程序，它监听客户端的请求并发送给服务器，然后将服务器的响应发回客户端。

一个http 能够通过缓存服务器响应来优化网络流量，它将服务器的响应数据存储在内存中用来应付其他相同的请求。如果一个响应被缓存下来了，在此以后的客户端请求在某些体定条件下将不需要再次重新请求服务器。

代理能够比普通客户端应用产生更好的网络流量控制，进而提升网络性能。

代理同时也能用于连接一个客户端本身不能连接的服务器，比如有一个防火墙在客户端和服务器中间。或者客户端和服务器采用用了不同等级的协议，比如ipv4和ipv6.

还有一个代理的常见应用是修改客户端发给服务器的数据，比如删减暴露了太多客户端信息的Http头或者移除服务器发回来的广告。

polipo是一个带缓存的Http代理，设计用于个人使用。原则上他应该用于单个用户或者一小组用户。但是它也曾成功的被用于数量大的用户组。

2、延迟时间和吞吐量

多数网络跑分软件认为吞吐量，或者单位时间的平均数据发送量非常重要。但是平均吞吐量对于网络使用体验几乎没啥关系，重要的是中间传输延迟时间，简单的说就是数据在用户已经等得不耐烦的时候才开始的传输。

典型的web缓存优化了吞吐量--比如他们在连接远程服务器之前首先查找一下本地缓存。通过这个步骤，代理能够极大的减少中间延迟时间，polipo就是设计用于最小化延迟时间的工具。

3、网络流量

web是由那些喜欢做文字传输的人而不是做网络传输的人开发的。不意外的是，第一个HTTP协议版本并没有很好的利用网络传输资源。主要的问题是在HTTP/0.9和比HTTP/1.0更早的版本中，分开的TCP连接在每一个实体传输的时候被创建。

开启多重的TCP连接对性能有巨大的影响。连接建立和释放需要额外的包交换并会明显的增加网络使用量，更恐怖的是，增加了延迟时间。

不容易被察觉的一点是：TCP对小请求做优化，TCP的目标是避免网络拥堵。一个正确的TCP实现应该是非常小心的在每次开始连接的时候探测网络状况，这也就是说TCP在刚开始传输几Kb的时候是非常缓慢的，并且会慢慢的提速。

但是由于多数HTTP实体非常小（在1Kb-10Kb）之间，HTTP/0.9使用TCP的方式是非常没有效率的。

长连接：后期版本的HTTP协议允许一个连接通过多个实体。一个连接携带多个实体就被称为“长连接”或者是“keep-alive”。但不幸的是，长连即使在HTTP/1.1接也是一个HTTP可选的功能。（博主测试HttpURLConnection不会发送keep-alive报文，也不会保持连接，在一次请求结束之后会立即发送挥手报文关闭连接，而okHttp会等待服务器发送挥手报文）

HTTP流水线技术（pipelining）：

它是指在一个tcp链接内，多个HTTP请求可以并行，下一个HTTP请求在上一个HTTP请求的应答完成之前就发起。因为这个技术向服务器发送请求更快，它减少了延迟。并且，因为多重请求经常能够封在单个包里进行发送，管线化也减少了网络流量。

管线化是一个非常常见的技术，但是它不被HTTP/1.0所支持。HTTP/1.1让每一个服务器必须实现管线化，所以才能使用长连接，但是又一批有bug的服务器他们虽然使用的是HTTP/1.1但是并没有支持管线化。

使用这个技术必须要求客户端和服务器端都能支持，目前仅有部分浏览器完全支持，而服务器端的支持仅需要按HTTp请求顺序正确饭胡Response(也就是请求&响应采用FIFO模式)，只要服务器能够正确处理使用HTTP pipelining的客户端的客户端请求，就算支持了流水线技术。由于服务端返回响应数据的顺序必须跟客户端请求时的顺序一致，这样也就是要求FIFO，这容易导致Head-of-line blocking,第一个请求的响应发送影响到了后边的请求，因此导致HTTP流水线技术性能的提升并不明显。

polipo会小心地探测服务器的管线化支持，并且在确保可靠的情况下使用管线话技术。polipo也非常希望客户端也采用管线化技术。

多路复用技术：

Http协议的一个主要弱点就是她无法通过分享一个链接给多个同时的事务使用。在HTTP协议中，一个客户端既能够同步请求所有的实例，这将会极大的挺假延迟，或者也可以开启多个同时的连接，这样会引起短链接过多的问题。

多路复用技术（PMM）是一个模拟多重请求并通过多个segments只请求一个实例的技术；因为segemtns被服务器通过独立的事务返回。他们能够通过多个请求交叉存取其他的资源。

如果资源时动态获取来的，那么在segments之前很有可能会发成改变；因此一个PMM的实现必须能够在探测到动态资源的时候重新切换资源。

polipo支持PMM技术，但是默认是关闭的如果变量pmmSize被设置成一个证书，那么polipo就会启用PMM，向一致的支持管线化的服务器发送请求。他会请求资源使用pmmSize规定的segment大小，而且首个segment的大小将会是pmmFirstSize规定的大小，默认是两倍的pmmSize。

PMM是一个本质上不可靠的技术。polipo进行了史诗般的努力来让它能用。如果要请求一个不支持PMM的服务器或者动态输出会让PMM失效。尽管如此，除非服务器合作，否则你会在使用PMM的时候看见一些失败提示，比如返回空页面和损坏的图片icon；敲击浏览器的刷新按钮会提示polipo注意到发生了错误并且修正这些问题。

缓存部分实例：

所谓的部分实例是被缓存到本地内存但是只有部分是可用的实例。有三种方式可以长生部分实例：客户端应用只请求部分实例（比如Adobe’s Acrobat Reader就很擅长做这个࿰