诡异问题排查之「DataURI 引发的血案」

今天在整理资料时，无意中看到一年前做过的一个名为《移动 Web 诡异问题两则》的小分享。这两个问题源自于实际线上业务，都挺有意思，我准备以博客的形式分享给大 家。由于文中的案例发生在一年前，当时的现象和测试数据不一定适用于当前环境，但排查问题的思路可以通用。这篇文章不会涉及任何具体的业务信息。

我们有一个移动 Web 项目，某天启用了内部编译工具中几个优化功能，发布上线后，马上收到了 404 请求报警邮件。这种情况之前从没遇见过，因为我们的静态资源要么托管在 CDN 上，要么 inline 在页面中，正常情况下并不会从我们的 Web 机器读取。

Part I

我的第一反应是代码有问题，立马线上验证。问题当然不是出在代码上，不然就不会称之为诡异问题。排除代码问题后，我又快速过了一遍错误日志，来源 IP 和 UserAgent 并没有明显的规律，所以基本可以排除机器扫描或人为构造 URL 的情况。

接着对收集到的 404 错误 URL 进行初步分析，找出错误次数最多的 URL，这通过 awk、sort、uniq -c 就可以搞定。将 URL 除重排序后，发现错误请求主要有这两类：

/data:image/gif;base64,iVBORw.......

    /cdn.xxx.com/t01acxxxxxx.png

一类是图片 DataURI 前面多了一个 /；一类是图片 CDN 地址前面多了一个 /。去掉它们前面的 /，图片都可以正常访问。

对照线上的代码，发现问题很可能出在下面这两个优化上：

1）将小图片编成 DataURI 形式，如：

background:url(data:image/gif;base64,...

这种做法的目的是减少连接数（移动端尤为重要），是一种非常普遍的做法。本博客四年半前介绍过这个方案。

2）去掉 URL 的协议部分：

background:url(//cdn.xxx.com/t01ac...

对于 // 开头的 URL，浏览器会自动补上当前页面协议去请求。这样做有两个好处：1）减小页面大小；2）自动兼容 HTTP 和 HTTPS。鉴于低廉的成本，这也是一种非常普遍的做法，本站也一直这么用。

根据常识，移动端这两种写法都是合法的，所有浏览器都支持，无论如何也不应该出现 404。之前有篇文章，写到开发同学对测试同学的常用语中有这么一条：在我这里是好的。当时我面临的情况真的是线上源源不断在报 404，而我无论怎么测试都是好的，没有任何办法复现这个问题，如何修复更无从谈起，只能先回滚代码。

Part II

回滚代码后，404 错误立马降下去了。但是优化还是要做，我必须尽快找到原因并解决它。现在，我手头已经有了几万行错误日志，我需要从中找出真相。

首先，我怀疑是某个特定版本的系统、或者某个特定的浏览器，处理 URL 有缺陷导致的问题。因为 Android 设备所安装的系统，经常被厂商改得乱七八糟；移动浏览器也是百花齐放，各种奇怪的改动都有。于是我对日志中的 UA 字段，进行了操作系统、浏览器等几个纬度的分析。然而，并没有发现异样，也就是说这个推测不成立。

接下来，我怀疑的是用户网络环境。相比 PC 端，移动端网络更为复杂：各种免费 WIFI、省流代理，很有可能为了实现某些功能，修改 HTTP 数据包。由于手头的 404 日志是从 Nginx 访问日志筛出来的，能用于分析网络环境的只有终端 IP 了。

首先，我分析了地域分布。下图中，左侧是 404 错误地域分布，右侧是同时期正常访问地域分布：

可以看到，正常请求来自江苏的有 6.29%，而在 404 错误统计中，却找不到任何来自于江苏的访问；湖北也是类似情况。所以这次诡异的 404 事件有着明显不正常的地域分布。

接下来，利用 IP 信息，还可以分析出运营商分布。下图中，左侧是 404 错误运营商分布，右侧是同时期正常访问运营商分布：

这下就更一目了然了，诡异的 404 请求几乎全部来自于特定的运营商。考虑到 IP 地址库自身有偏差，可以认为全部 404 流量都来自于某一家运营商。

那么综上，我们可以得出结论：某些省份的某个运营商会修改我们的页面结果，导致 DataURI 和省略了协议的 URL 出错。

Part III

有了之前的分析，我打算主动出击，验证我的结论并收集更多信息。

首先我在页面 inline 一小段用来测试的 style 标签，里面使用了 DataURI 格式的图片。并在页面底部 inline 一小段 JS，大致内容如下：

var flag = 0;

    var styles = document.querySelectorAll('style');

    for(var i = 0; i < styles.length; i++) {
        if(styles[i].innerHTML.indexOf('/data:image') > -1) {
            flag = 1;
            break;
        }
    }

    //发送 flag，并在 flag=1 时收集页面异常 Dom 节点和外链资源

最终，试验结果验证了之前的结论，还让我们搞明白了运营商修改页面的目的：在页面底部插入他们网上营业厅的 Banner 条。

Part IV

至此，这个诡异问题的原因终于水落石出了。但没有 HTTPS 或客户端的帮助，无法避免 Web 页面被修改。如果坚持上线前面两个优化，一些用户就看不到某些图片，我们无法接受这个体验。但是受影响的用户比例很小，如果为了大部分人而放弃 DataURI 优化，显然也不合理。

最终，我们采用了以下方案：

1）针对 DataURI 这种形式，我们在 Nginx 加了一个 rewrite 规则。下面这种形式的请求会被 rewrite 给一个 php 页面，从而获取 URL 内容并转为图片输出。确保页面被修改时用户依然能看到图片：

http://www.xxx.com/data:image/gif;base64,iVBORw.......

2）关闭「移除 URL 协议部分」这个优化点。因为这个优化的收益实在太小了，为此做兼容方案并不划算。