算起来已经足足两个半月没有更新文章，这段时间过得比较忙：夜间跑步计划、卖房买房以及工作上各种事情都凑到一块了。实际上，最近也并没有忙到完全抽不出时间写博客这种地步，根本原因可能还是变懒了，这样不好。几个月前，我决定开始写一系列有关「移动 WEB 通用优化」的文章，介绍「面向所有主流移动端浏览器（包括各种 APP 嵌入的通用 Webview）」的前端优化策略，本文是这个系列第二篇。先来回顾下上篇文章最后的结论：重要的 CSS、JS、JSON 数据直接内联在 HTML 中，头部禁止出现任何外链资源。同时，尽可能减少页面传输体积。采用了这个策略的页面，理应能让用户在很短时间内看到主体内容，因为头部 CSS 和 JS 都内联了，不会阻塞浏览器渲染页面。在我们的认识里，浏览器会异步加载页面用到的图片，加载图片不会阻塞页面渲染，更不会阻塞 JS 执行。实际情况是这样吗？本文主要讨论在移动 WEB 中，图片的加载给页面整体性能带来的影响以及优化策略。我们知道，浏览器的 DOMContentLoaded 事件会在主页面加载并解析完成之后触发，不会等页面样式、图片、iframe 等子资源加载完。以下是MDN对它的描述：The DOMContentLoaded event is fired when the initial HTML document has been completely loade ...继续阅读 (45)

算起来已经足足两个半月没有更新文章，这段时间过得比较忙：夜间跑步计划、卖房买房以及工作上各种事情都凑到一块了。实际上，最近也并没有忙到完全抽不出时间写博客这种地步，根本原因可能还是变懒了，这样不好。几个月前，我决定开始写一系列有关「移动 WEB 通用优化」的文章，介绍「面向所有主流移动端浏览器（包括各种 APP 嵌入的通用 Webview）」的前端优化策略，本文是这个系列第二篇。先来回顾下上篇文章最后的结论：重要的 CSS、JS、JSON 数据直接内联在 HTML 中，头部禁止出现任何外链资源。同时，尽可能减少页面传输体积。采用了这个策略的页面，理应能让用户在很短时间内看到主体内容，因为头部 CSS 和 JS 都内联了，浏览器在渲染 HTML 时不会被阻塞。在我们的认识里，浏览器会异步加载页面用到的图片，加载图片不会阻塞页面渲染，更不会阻塞 JS 执行。实际情况是这样吗？本文主要讨论在移动 WEB 中，图片的加载给页面整体性能带来的影响以及优化策略。我们知道，浏览器的 DOMContentLoaded 事件会在主页面加载并解析完成之后触发，不会等页面样式、图片、iframe 等子资源加载完。以下是MDN对它的描述：The DOMContentLoaded event is fired when the initial HTML document has been completel ...继续阅读 (49)

从 2008 年到现在，我写独立博客已经有八个年头了。这期间我的域名从一开始的 qgy18.com 换成了 imququ.com，博客程序也换过好几版。在这过去的八年里，我从未公开过本博客统计相关数据。最近我在 v2ex 无意中提到本博客每天有三五千 PV 时，某位同学提出了疑问：这样的网站平时也有三五千？？？流量来源哪里？（via）这几年，身边坚持写原创文章的人越来越少，其中一大部分还被微信公众号、知乎专栏、简书等平台给吸引过去，愿意经营独立博客的人更是少之又少。也难怪 v2ex 那位同学会有这样的疑问：在信息早已泛滥的今天，独立博客还有人看吗？本文通过公布本博客在2016-01-01 到 2016-05-25这 145 天里的访问情况及流量来源，对前面的问题做一个正面回应。会话数与浏览量我的博客通过自己实现 JavaScript 统计代码 + 服务端转发的方式使用 Google 统计。相比直接使用 Google 统计代码，对统计代码逻辑进行了大幅精简并本地化之后，对页面性能的影响可以降到最低。而在服务端通过 Node.js 将统计请求异步转发给 Google Analytics API，可以解决 Google 统计在国内访问不畅的顽疾。最后，相比将统计逻辑完全挪到后端，本方案可以有效过滤那些来自不支持 JS 的爬虫、扫描工具等非正常流量。过去的 145 天里，本博客的基本访问情 ...继续阅读 (69)

从 2008 年到现在，我写独立博客已经有八个年头了。这期间我的域名从一开始的 qgy18.com 换成了 imququ.com，博客程序也换过好几版。在这过去的八年里，我从未公开过本博客统计相关数据。最近我在 v2ex 无意中提到本博客每天有三五千 PV 时，某位同学提出了疑问：这样的网站平时也有三五千？？？流量来源哪里？（via）这几年，身边坚持写原创文章的人越来越少，其中一大部分还被微信公众号、知乎专栏、简书等平台给吸引过去，愿意经营独立博客的人更是少之又少。也难怪 v2ex 那位同学会有这样的疑问：在信息早已泛滥的今天，独立博客还有人看吗？本文通过公布本博客在2016-01-01到2016-05-25这 145 天里的访问情况及流量来源，对前面的问题做一个正面回应。会话数与浏览量我的博客通过自己实现 JavaScript 统计代码 + 服务端转发的方式使用 Google 统计。相比直接使用 Google 统计代码，对统计代码逻辑进行了大幅精简并本地化之后，对页面性能的影响可以降到最低。而在服务端通过 Node.js 将统计请求异步转发给 Google Analytics API，可以解决 Google 统计在国内访问不畅的顽疾。最后，相比将统计逻辑完全挪到后端，本方案可以有效过滤那些来自不支持 JS 的爬虫、扫描工具等非正常流量。过去的 145 天里，本博客的基本访问情况如 ...继续阅读 (29)

从 2008 年到现在，我写独立博客已经有八个年头了。这期间我的域名从一开始的 qgy18.com 换成了 imququ.com，博客程序也换过好几版。在这过去的八年里，我从未公开过本博客统计相关数据。最近我在 v2ex 无意中提到本博客每天有三五千 PV 时，某位同学提出了疑问：这样的网站平时也有三五千？？？流量来源哪里？（via）这几年，身边坚持写原创文章的人越来越少，其中一大部分还被微信公众号、知乎专栏、简书等平台给吸引过去，愿意经营独立博客的人更是少之又少。也难怪 v2ex 那位同学会有这样的疑问：在信息早已泛滥的今天，独立博客还有人看吗？本文通过公布本博客在2016-01-01到2016-05-25这 145 天里的访问情况及流量来源，对前面的问题做一个正面回应。会话数与浏览量我的博客通过自己实现 JavaScript 统计代码 + 服务端转发的方式使用 Google 统计。相比直接使用 Google 统计代码，对统计代码逻辑进行了大幅精简并本地化之后，对页面性能的影响可以降到最低。而在服务端通过 Node.js 将统计请求异步转发给 Google Analytics API，可以解决 Google 统计在国内访问不畅的顽疾。最后，相比将统计逻辑完全挪到后端，本方案可以有效过滤那些来自不支持 JS 的爬虫、扫描工具等非正常流量。过去的 145 天里，本博客的基本访问情况如 ...继续阅读 (24)

昨天有位朋友在微信上发过来一个链接：The day Google Chrome disables HTTP/2 for nearly everyone: May 31st, 2016。看标题这篇文章说的是 Google Chrome 即将大面积禁用 HTTP/2，这究竟是怎么回事呢？本文为你揭晓答案。先来回顾一下，浏览器在访问 HTTPS 网站时，如何得知服务端是否支持 HTTP/2 呢？答案是借助 HTTP/2 的协议协商机制。在 HTTP/2 Over HTTP 中，可以使用 HTTP 的 Upgrade 机制进行协商；而对于 HTTP/2 Over TLS，可以使用 TLS 的 NPN 或 ALPN 扩展来完成协商。HTTP/2 的这两种协商方式，不了解的同学请看《谈谈 HTTP/2 的协议协商机制》，这里不再赘述。当前所有浏览器，都只支持 HTTP/2 Over TLS。也就是说，浏览器和服务端都支持 NPN 或 ALPN 协商，是用上 HTTP/2 的大前提。本文重点讨论 NPN 和 ALPN。NPN（Next Protocol Negotiation，下一代协议协商），是一个 TLS 扩展，由 Google 在开发 SPDY 协议时提出。随着 SPDY 被 HTTP/2 取代，NPN 也被修订为 ALPN（Application Layer Protocol Negot ...继续阅读 (45)

昨天有位朋友在微信上发过来一个链接：The day Google Chrome disables HTTP/2 for nearly everyone: May 31st, 2016（中文翻译）。看标题这篇文章说的是 Google Chrome 即将大面积禁用 HTTP/2，这究竟是怎么回事呢？本文为你揭晓答案。先来回顾一下，浏览器在访问 HTTPS 网站时，如何得知服务端是否支持 HTTP/2？答案是借助 HTTP/2 的协议协商机制：在 HTTP/2 Over HTTP 中，可以使用 HTTP 的 Upgrade 机制进行协商；而对于 HTTP/2 Over TLS，可以使用 TLS 的 NPN 或 ALPN 扩展来完成协商。HTTP/2 的这两种协商方式，不了解的同学请看《谈谈 HTTP/2 的协议协商机制》，这里不再赘述。当前所有浏览器，都只支持 HTTP/2 Over TLS。也就是说，浏览器和服务端都支持 NPN 或 ALPN 协商，是用上 HTTP/2 的大前提。本文重点讨论 NPN 和 ALPN。NPN（Next Protocol Negotiation，下一代协议协商），是一个 TLS 扩展，由 Google 在开发 SPDY 协议时提出。随着 SPDY 被 HTTP/2 取代，NPN 也被修订为 ALPN（Application Layer Protocol N ...继续阅读 (25)

昨天有位朋友在微信上发过来一个链接：The day Google Chrome disables HTTP/2 for nearly everyone: May 31st, 2016（中文翻译）。看标题这篇文章说的是 Google Chrome 即将大面积禁用 HTTP/2，这究竟是怎么回事呢？本文为你揭晓答案。先来回顾一下，浏览器在访问 HTTPS 网站时，如何得知服务端是否支持 HTTP/2？答案是借助 HTTP/2 的协议协商机制：在 HTTP/2 Over HTTP 中，可以使用 HTTP 的 Upgrade 机制进行协商；而对于 HTTP/2 Over TLS，可以使用 TLS 的 NPN 或 ALPN 扩展来完成协商。HTTP/2 的这两种协商方式，不了解的同学请看《谈谈 HTTP/2 的协议协商机制》，这里不再赘述。当前所有浏览器，都只支持 HTTP/2 Over TLS。也就是说，浏览器和服务端都支持 NPN 或 ALPN 协商，是用上 HTTP/2 的大前提。本文重点讨论 NPN 和 ALPN。NPN（Next Protocol Negotiation，下一代协议协商），是一个 TLS 扩展，由 Google 在开发 SPDY 协议时提出。随着 SPDY 被 HTTP/2 取代，NPN 也被修订为 ALPN（Application Layer Protocol N ...继续阅读 (23)

最近一年，我写了不少有关 HTTPS 和 HTTP/2 的文章。很多同学都问我，HTTPS 真的有那么好吗，我自己的 WEB 服务需要迁移到 HTTPS 吗？对此我的观点是：HTTPS 早就不是锦上添花的可有可无项，它已经逐渐成为 WEB 服务的标配，推荐大家尽早迁移。HTTPS 可以给用户带来更安全、更好隐私保护的网络体验，目前各大浏览器都在积极推进 HTTPS 的普及。HTTP/2 通过引入二进制分帧层，将 HTTP 的请求和响应报文拆分为二进制帧，从而实现了多路复用、优先级、Server Push 等诸多新特性，大大提升了 WEB 性能。HTTP/2 还引入了基于静态字典和动态字典的头部压缩算法 —— HPACK，有效减少了 HTTP 协议头部开销。现阶段，所有浏览器都只支持 HTTP/2 Over TLS，也就是浏览器中的 HTTP/2，必须基于 HTTPS 部署。一些 HTML5 API 可以用来获取用户地理位置、摄像头音视频等隐私数据。尽管网站在使用这些权限前需要获得用户授权，但由于 HTTP 很容易被劫持，如果通过 HTTP 传输这些隐私数据十分危险。于是，Chrome 启用了Deprecating Powerful Features on Insecure Origins计划，以下功能必须在安全环境（Secure Contexts）中才能启用：Geolocation ...继续阅读 (45)

关于「启用 HTTPS 的经验分享」这个话题，我已经写过两篇文章：第一篇主要介绍 HTTPS 如何与一些较新的安全规范配合使用，面向的是现代浏览器；第二篇主要讨论启用 HTTPS 过程中，在 SSL 版本、Cipher Suite、证书、SSL 扩展（如 SNI）等方面可能遇到的问题，以及在老旧浏览器下如何取舍。本文做为本系列最后一篇，我想补充一些启用 HTTPS 过程中的注意事项。资源替换HTTPS 网页中加载的 HTTP 资源被称之为 Mixed Content（混合内容），我在之前的文章中详细介绍了Optionally-blockable和Blockable两类 Mixed Content，也介绍了各种浏览器对 Mixed Content 的加载策略。为了最好的用户体验，HTTPS 网站不要出现任何 Mixed Content。换句话说，HTTPS 页面中所有资源都必须替换为 HTTPS 的。代码层的替换比较简单，但一些存在数据库中的文本（例如商品描述中的图片地址）就很容易遗漏，需要特别注意。如果你的网站只打算支持 HTTPS，将所有外链资源（CSS、JS、图片、音频、字体文件、异步接口等等）直接替换为 HTTPS 地址，再把网站 HTTP 请求重定向到 HTTPS 即可。当前很多支持 HTTPS 的网站出于各种原因，针对老旧浏览器或特殊网络还是允许通过 HTTP 访问。这时 ...继续阅读 (83)

上篇文章中，我介绍了 HTTP 协议中的 Accept-Encoding 和 Content-Encoding 机制。它可以很好地用于文本类响应正文的压缩，减少网络数据的传输，已被广泛使用。但 HTTP 请求的发起方浏览器，无法事先知晓要访问的服务端是否支持解压，所以现阶段的浏览器没有压缩请求正文。有一些通讯协议基于 HTTP 做了扩展，他们的客户端和服务端是专用的，完全可以针对请求正文进行压缩，例如 WebDAV 客户端就是这么做的。实际的 Web 项目中，存在请求正文非常大的场景，例如发表长篇博客，上报用于调试的网络数据等等。这些数据如果能在本地压缩后再提交，就可以节省大量流量、减少传输时间。本文介绍如何对 HTTP 请求正文进行压缩，包含如何在服务端解压、如何在客户端压缩两个部分。开始之前，先来介绍本文涉及的三种数据压缩格式：DEFLATE，是一种使用 Lempel-Ziv 压缩算法（LZ77）和哈夫曼编码的压缩格式。详见RFC 1951；ZLIB，是一种使用 DEFLATE 的压缩格式，对应 HTTP 中的 Content-Encoding: deflate。详见RFC 1950；GZIP，也是一种使用 DEFLATE 的压缩格式，对应 HTTP 中的 Content-Encoding: gzip。详见RFC 1952；Content-Encoding 中的 deflate ...继续阅读 (45)

Accept-Encoding 和 Content-Encoding 是 HTTP 中用来对「采用何种编码格式传输正文」进行协定的一对头部字段。它的工作原理是这样：浏览器发送请求时，通过 Accept-Encoding 带上自己支持的内容编码格式列表；服务端从中挑选一种用来对正文进行编码，并通过 Content-Encoding 响应头指明选定的格式；浏览器拿到响应正文后，依据 Content-Encoding 进行解压。当然，服务端也可以返回未压缩的正文，但这种情况不允许返回 Content-Encoding。这个过程就是 HTTP 的内容编码机制。内容编码目的是优化传输内容大小，通俗地讲就是进行压缩。一般经过 gzip 压缩过的文本响应，只有原始大小的 1/4。对于文本类响应是否开启了内容压缩，是我们做性能优化时首先要检查的重要项目；而对于 JPG / PNG 这类本身已经高度压缩过的二进制文件，不推荐开启内容压缩，效果微乎其微还浪费 CPU。内容编码针对的只是传输正文。在 HTTP/1 中，头部始终是以 ASCII 文本传输，没有经过任何压缩。这个问题在 HTTP/2 中得以解决，详见：HTTP/2 头部压缩技术介绍。内容编码使用特别广泛，理解起来也很简单，随手打开一个网页抓包看下请求响应就能明白。唯一要注意的是不要把它与 HTTP 中的另外一个概念：传输编码（Transfe ...继续阅读 (49)

相信大部分前端同学都知道，Webkit 对于页面滚动条位置，没有按照标准处理。以下是一段相关描述，摘自W3Help：在混杂模式下，由于所有浏览器均使用 document.body.scrollTop 获取页面的垂直滚动条的位置，所以不会出现兼容性问题。而在标准模式下，由于 Chrome 与 Safari 仍然使用 document.body.scrollTop，而对于 document.documentElement.scrollTop 返回为 0。也就是说对 Webkit 来说，无论是混杂模式还是标准模式，它都认为页面滚动元素是BODY；而其它浏览器只有在混杂模式下，才会认为页面滚动元素是BODY，标准模式下则是HTML。各种 JS 库通常都会抹平不同浏览器及不同模式下的这些差异，统一提供获取或设置 scrollTop / scrollLeft 的接口，所以这个问题往往不会暴露出来。具体的兼容方案很简单，略过不提。但需要注意一点，千万不要使用 UA 检测来解决这个问题，如果针对 UA 包含webkit的浏览器统一使用 document.body 那就有问题，后面会讲到原因。最近我发现了一个诡异的现象：在我的 Chrome 里需要通过 document.documentElement 元素获取页面滚动条位置。原本我以为是 Chrome 修改了实现，保持跟标准一致；但奇怪的是，我的 ...继续阅读 (32)

在我去年的《AMP，来自 Google 的移动页面优化方案》这篇文章里，我给自己挖了个坑：借助客户端所做的优化，如现在广为流行的移动端 Webview 容器加速方案，优化效果局限在指定 APP 内，甚至还会导致使用通用浏览器访问速度更慢（这个话题很有意思，有机会以后再讨论）。现在过去快半年，我终于想起来把这个坑填上，今天先来写这个系列第一篇。我在标题里用了「通用」二字，说明我要介绍的优化策略不是为特定的 Webview 容器定制，它面向的是所有主流的移动端浏览器，包括各种 APP 嵌入的通用 Webview。借助定制化的 Webview 容器，我们完全可以通过主动提前本地化资源包，使得移动 WEB 应用跟 Native 应用一样，只需走网络获取必要的数据。这种情况下的性能优化，更多需要关注代码执行效率，本地化资源包的推送流程和成功率。而对于通用的移动 WEB 性能优化，首先要考虑的是网络传输性能。我们知道，浏览器获取一个资源，花在网络上的时间开销至少有这几块：DNS 解析、建立 TCP 连接、发送请求、等待响应、传输响应正文。相比 PC 的网络环境，移动端更为糟糕，集中在这几点：高时延、高丢包、低速率、多劫持。所以，在移动 WEB 上，引入外链资源的网络成本非常高。在我们最近的一次测试中，移动端同域名空图片（使用 Nginx 的empty_gif指令构造）加载失败率（我们对失败的定 ...继续阅读 (68)

在过去的几个月里，我写了很多有关 HTTP/2 的文章，也做过好几场相关分享。我在向大家介绍 HTTP/2 的过程中，有一些问题经常会被问到。例如要部署 HTTP/2 一定要先升级到 HTTPS 么？升级到 HTTP/2 之后，不支持 HTTP/2 的浏览器还能正常访问么？本文重点介绍 HTTP/2 的协商机制，明白了服务端和客户端如何协商出最终使用的 HTTP 协议版本，这两个问题就迎刃而解了。HTTP Upgrade为了更方便地部署新协议，HTTP/1.1 引入了 Upgrade 机制，它使得客户端和服务端之间可以借助已有的 HTTP 语法升级到其它协议。这个机制在 RFC7230 的「6.7 Upgrade」这一节中有详细描述。要发起 HTTP/1.1 协议升级，客户端必须在请求头部中指定这两个字段：Connection:UpgradeUpgrade:protocol-name[/protocol-version]客户端通过Upgrade头部字段列出所希望升级到的协议和版本，多个协议之间用,（0x2C, 0x20）隔开。除了这两个字段之外，一般每种新协议还会要求客户端发送额外的新字段。如果服务端不同意升级或者不支持Upgrade所列出的协议，直接忽略即可（当成 HTTP/1.1 请求，以 HTTP/1.1 响应）；如果服务端统一升级，那么需要这样响应：HTTP/1.1101S ...继续阅读 (34)

Web 安全是一项系统工程，任何细微疏忽都可能导致整个安全壁垒土崩瓦解。拿 HTTPS 来说，它的「内容加密、数据完整性、身份认证」三大安全保证，也会受到非法根证书、服务端配置错误、SSL 库漏洞、私钥被盗等等风险的影响。很多同学认为只要访问的网站地址前有一把小绿锁就绝对安全，其实不然。本文通过介绍三种最常规的 HTTPS 流量解密方法及原理，浅谈一下 HTTPS 的安全风险。Man-in-the-middleMan-in-the-middle（中间人，简称为 MITM），能够与网络通讯两端分别创建连接，交换其收到的数据，使得通讯两端都认为自己直接与对方对话，事实上整个会话都被中间人所控制。简而言之，在真正的服务端看来，中间人是客户端；而真正的客户端会认为中间人是服务端。实现中间人攻击有各种各样的手段，这里不展开讨论。一些常见的 HTTP/HTTPS 抓包调试工具，都是通过创建本地 Proxy 服务，再修改浏览器 Proxy 设置来达到拦截流量的目的，他们的工作原理与中间人攻击一致。我用过的这一类工具有：Fiddler、Charles和whistle。我在「HTTP 代理原理及实现（一）」一文中介绍的 HTTP 普通代理，扮演的就是 HTTP 中间人角色。本文主要讨论 HTTPS 中间人，简单示意如下：Server <---> Local Proxy <---&g ...继续阅读 (37)

最近有很多朋友邮件或者留言询问本博客服务端配置相关问题，基本都是关于 HTTPS 和 HTTP/2 的，其实我的 Nginx 配置在之前的文章中多次提到过，不过都比较分散。为了方便大家参考，本文贴出完整配置。本文内容会随时调整或更新，请大家不要把本文内容全文转载到第三方平台，以免给他人造成困扰或误导。另外限于篇幅，本文不会对配置做过多说明，如有疑问或不同意见，欢迎留言指出。准备工作我的 VPS 系统是 Ubuntu 14.04.3 LTS，如果你使用的是其它发行版，与包管理有关的命令请自行调整。本博客是我的试验田，Nginx 自然要用最新的 1.9.12。为了启用 Certificate Transparency，我使用了 nginx-ct 这个模块。同时，我还使用了 CloudFlare Patch 过的 OpenSSL 1.0.2g 做为 Nginx 的 SSL 库。下面是完整安装过程：首先安装 Nginx 依赖库：sudo apt-get install build-essential libpcre3 libpcre3-dev zlib1g-de然后获取 OpenSSL 源码和 Patch、最新的 Nginx 以及 nginx-ct 源码，开始编译：gitclonehttps://github.com/cloudflare/sslconfig wget -O openssl ...继续阅读 (52)

最近收到的几封读者邮件，都是询问为什么在 Nginx 中无法开启 OCSP Stapling。具体现象是在 Nginx 中明明配置了ssl_stapling on，但通过SSL Labs等工具查看，OCSP stapling 这一项并没有生效。本文就这个问题详细探讨下，如果你只关心结论，直接跳到最后一节即可。我之前在《TLS 握手优化详解》这篇文章中介绍了 OCSP 是什么，为什么要开启 OCSP Stapling，这里再简单介绍下：OCSP（Online Certificate Status Protocol，在线证书状态协议）是用来检验证书合法性的在线查询服务，一般由证书所属 CA 提供。某些客户端会在 TLS 握手阶段进一步协商时，实时查询 OCSP 接口，并在获得结果前阻塞后续流程。OCSP 查询本质是一次完整的 HTTP 请求 - 响应，这中间 DNS 查询、建立 TCP、服务端处理等环节都可能耗费很长时间，导致最终建立 TLS 连接时间变得更长。而 OCSP Stapling（OCSP 封套），是指服务端主动获取 OCSP 查询结果并随着证书一起发送给客户端，从而让客户端跳过自己去验证的过程，提高 TLS 握手效率。验证 OCSP Stapling 状态通过前面提到的SSLLabs这个强大的在线服务，可以轻松验证指定网站是否开启 OCSP Stapling。但这个网站功 ...继续阅读 (75)

本博客之前的《像素化你的代码》文章中，我介绍了一种将文本生成图片的方法，还提供了一个Encode/Decode工具。在那篇文章中，我写到「这又是一个除了好玩并没什么卵用的东西」，确实如此。不过，我今天想到一个用图片传递数据的另类应用场景，分享给大家。在 Android 系统中，很多 App 为了在网页里实现一些客户端的功能，往往会在客户端开启一个本地 HTTP 服务。通过在网页中调用这个服务的不同接口，可以轻松实现原本无法实现的功能。本文不讨论这种做法本身，只说存在的问题：随着越来越多 Web 产品升级到 HTTPS，通过 JSONP 或 XHR2 与 HTTP 服务交互就行不通了。下面这几段直接摘自我的《关于启用 HTTPS 的一些经验分享（一）》这篇文章：现代浏览器（Chrome、Firefox、Safari、Microsoft Edge），基本上都遵守了 W3C 的Mixed Content规范，将 Mixed Content 分为Optionally-blockable和Blockable两类：Optionally-blockable类 Mixed Content 包含那些危险较小，即使被中间人篡改也无大碍的资源。现代浏览器默认会加载这类资源，同时会在控制台打印警告信息。这类资源包括：通过<img>标签加载的图片（包括 SVG 图片）；通过<video&g ...继续阅读 (53)

在本站之前的文章中，我介绍过两种查看 HTTP/2 流量的方法：1）在 Chrome 地址栏输入chrome://net-internals/#http2，使用 Chrome 自带的 HTTP/2 调试工具；2）使用 Wireshark 调试 HTTP/2 流量。方案 1 使用方便，但受限于 Chrome 浏览器，对于 Chrome 不支持的 h2c（HTTP/2 Cleartext，没有部署 TLS 的 HTTP/2）协议无能为力。同时，这个工具显示的信息经过了解析和筛选，不够全面。而在方案 2 中，Wireshark 位于服务端和浏览器之间，充当的是中间人角色，用它查看 HTTP/2 over HTTPS 流量时，必须拥有网站私钥或者借助浏览器共享对称密钥，才能解密 TLS 流量，配置起来比较麻烦。而本文要介绍的nghttp2，是一个用 C 实现的 HTTP/2 库，支持 h2c。它可以做为其它软件的一部分，为其提供 HTTP/2 相关功能（例如 curl 的 HTTP/2 功能就是用的 nghttp2）。除此之外，它还提供了四个有用的 HTTP/2 工具：nghttp：HTTP/2 客户端；nghttpd：HTTP/2 服务端；nghttpx：HTTP/2 代理，提供 HTTP/1、HTTP/2 等协议之间的转换；h2load：HTTP/2 性能测试工具；本文简单介绍 ngh ...继续阅读 (48)

上篇文章中，我介绍了由 Google 推动的Certificate Transparency技术，它旨在通过开放的审计和监控系统，提高 HTTPS 网站证书安全性。本文要介绍的 HTTP Public Key Pinning（HPKP），也是用来防范由「伪造或不正当手段获得网站证书」造成的中间人攻击，但有着与 CT 不同的思路。我们知道，受信任的 CA（证书颁发机构）有好几百个，他们成为整个网站身份认证过程中一个较大的攻击面。现有的证书信任链机制最大的问题是，任何一家受信任的 CA 都可以签发任意网站的站点证书，这些证书在浏览器看来，都是合法的。前面提到的 CT 技术能改善这种情况，但 CT 还没有普及，现阶段浏览器不能贸然阻断没有提供 SCT 信息的 HTTPS 网站。HPKP 技术给予我们主动选择信任 CA 的权利。它的工作原理是通过响应头或者<meta>标签告诉浏览器当前网站的证书指纹，以及过期时间等其它信息。未来一段时间内，浏览器再次访问这个网站必须验证证书链中的证书指纹，如果跟之前指定的值不匹配，即便证书本身是合法的，也必须断开连接。HPKP 官方文档见RFC7469，目前 Firefox 35+ 和 Chrome 38+ 已经支持。它的基本格式如下：Public-Key-Pins: pin-sha256="base64=="; max-a ...继续阅读 (61)

最近本站 HTTPS 方面有两个变化：一是本站域名（imququ.com）加入了 Chrome 的 HSTS Preload List，从 Chrome 49 开始生效；二是我给本站 HTTPS 证书启用了 Certificate Transparency 策略。HSTS Preload List 在我之前的文章中写过，更多介绍及申请如何加入请点这里。本文主要介绍 Certificate Transparency。Certificate Transparency 是什么？HTTPS 网站的身份认证是通过证书信任链完成的，浏览器从站点证书开始递归校验父证书，直至出现信任的根证书（根证书列表一般内置于操作系统，Firefox 则自己维护）。然而，受信任的 CA（证书颁发机构）有好几百个，他们成为整个网站身份认证过程中一个较大的攻击面。实际上，目前由于 CA 失误导致错误签发证书；以及 CA 出于某些目的（如监控加密流量）故意向第三方随意签发证书这两种情况时有发生。无论是 CA 无意或有意签发出来的「非法证书」，都能通过目前的证书信任链校验机制的验证。这些 CA 签发的「非法证书」相比自签名的「无效证书」，更难被发现，即使被发现依靠现有机制也很难快速消除影响。另外，域名所有者的管理不善也可能导致域名配置被第三方控制，从而第三方能够向 CA 申请你网站的证书（特别是 DV 类型的证书）。这 ...继续阅读 (48)

最近本站 HTTPS 方面有两个变化：一是本站域名（imququ.com）加入了 Chrome 的 HSTS Preload List，从 Chrome 49 开始生效；二是我给本站 HTTPS 证书启用了 Certificate Transparency 策略。HSTS Preload List 在我之前的文章中写过，更多介绍及申请如何加入请点这里。本文主要介绍 Certificate Transparency。Certificate Transparency 是什么？HTTPS 网站的身份认证是通过证书信任链完成的，浏览器从站点证书开始递归校验父证书，直至出现信任的根证书（根证书列表一般内置于操作系统，Firefox 则自己维护）。然而，受信任的 CA（证书颁发机构）有好几百个，他们成为整个网站身份认证过程中一个较大的攻击面。实际上，目前由于 CA 失误导致错误签发证书；以及个别 CA 出于某些目的（如监控加密流量）故意向第三方随意签发证书这两种情况时有发生。无论是 CA 无意或有意签发出来的「非法证书」，都能通过目前的证书链校验机制的验证。这些 CA 签发的「非法证书」相比自签名的「无效证书」，更难被发现，即使被发现依靠现有机制也很难快速消除影响。另外，域名所有者的管理不善也可能导致域名配置被第三方控制，从而第三方能够向 CA 申请你网站的证书（特别是 DV 类型的证书）。这 ...继续阅读 (45)

最近好几个朋友在给网站开启 HTTP/2 后，都遇到了无法访问的问题。其中有的网站只是 Firefox 无法访问，通过控制台网络面板可以看到请求被 Abort；有的网站不但 Firefox 无法访问，连 Chrome 也会跳到错误页，错误代码是「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」。诡异的是，只要去掉对 HTTP/2 的支持（例如去掉 Nginx listen 配置中的 http2）就一切正常。也就是说无法访问的现象只存在于 HTTPS + HTTP/2 的组合，单独提供 HTTPS 服务时就是好的。这个问题比较有趣，本文除了告诉大家如何解决它之外，还会帮助大家弄清问题的来龙去脉。首先，网站无法访问有很多种可能，一般要从基本项开始检查：是否网络不通（可以通过能否访问imququ.com来排查 ^_^）；网站 DNS 解析是否正常（可以通过 ping、nslookup、dig 等工具来排查）；TCP 连接能否建立（可以通过 telnet 来排查，例如 telnet imququ.com 443）；如果 TCP 连接能够建立，至少说明 Web Server 在运行，本地到 Web Server 网络也正常。如果还有问题，就要开始往应用层去排查，例如：是否因为域名没备案被阻止（改用 IP 访问，或者换非标准端口应该可以访问）；是否因为 Web 程 ...继续阅读 (76)

最近好几个朋友在给网站开启 HTTP/2 后，都遇到了无法访问的问题。其中有的网站只是 Firefox 无法访问，通过控制台网络面板可以看到请求被 Abort；有的网站不但 Firefox 无法访问，连 Chrome 也会跳到错误页，错误代码是「ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY」。诡异的是，只要去掉对 HTTP/2 的支持（例如去掉 Nginx listen 配置中的 http2）就一切正常。也就是说无法访问的现象只存在于 HTTPS + HTTP/2 的组合，单独提供 HTTPS 服务时就是好的。这个问题比较有趣，本文除了告诉大家如何解决它之外，还会帮助大家弄清问题的来龙去脉。首先，网站无法访问有很多种可能，一般要从基本项开始检查：是否网络不通（可以通过能否访问imququ.com来排查 ^_^）；网站 DNS 解析是否正常（可以通过 ping、nslookup、dig 等工具来排查）；TCP 连接能否建立（可以通过 telnet 来排查，例如 telnet imququ.com 443）；如果 TCP 连接能够建立，至少说明 Web Server 在运行，本地到 Web Server 网络也正常。如果还有问题，就要开始往应用层去排查，例如：是否因为域名没备案被阻止（可以尝试用 IP，或者换非标准端口访问）；是否因为 Web 程序太慢， ...继续阅读 (41)

一直以来，为了优化本博客站内搜索效果和速度，我使用 bing 的site:站内搜索做为数据源，在服务端获取、解析、处理并缓存搜索结果，直接输出 HTML。这个方案唯一的问题是时效性难以保证，尽管我可以在发布和修改文章时主动告诉 bing，但它什么时候更新索引则完全不受我控制。本着不折腾就浑身不自在的原则，我最终还是使用Elasticsearch搭建了自己的搜索服务。Elasticsearch 是一个基于 Lucene 构建的开源、分布式、RESTful 搜索引擎，很多大公司都在用，程序员的好伙伴 Github 的搜索也用的是它。本文记录我使用 Elasticsearch 搭建站内搜索的过程，目前支持中文分词、同义词、标题匹配优先等常见策略，可以点击这里体验。安装 Elasticsearch部署 Elasticsearch 最简单的方法是使用Elasticsearch Dockerfile。为了更彻底地折腾，我没有使用 Docker，好在手动安装过程也不复杂。我的虚拟机和线上环境都是 Ubuntu 14.04.3 LTS，Elasticsearch 用的是目前最新的 2.1.1。一切开始之前，先要检查机器上是否装有 java 环境，如果没有可以通过以下命令安装：sudo apt-get install openjdk-7-jre-headless下载 Elasticsearch 2. ...继续阅读 (48)

一直以来，为了优化本博客站内搜索效果和速度，我使用 bing 的site:站内搜索做为数据源，在服务端获取、解析、处理并缓存搜索结果，直接输出 HTML。这个方案唯一的问题是时效性难以保证，尽管我可以在发布和修改文章时主动告诉 bing，但它什么时候更新索引则完全不受我控制。本着不折腾就浑身不自在的原则，我最终还是使用Elasticsearch搭建了自己的搜索服务。Elasticsearch 是一个基于 Lucene 构建的开源、分布式、RESTful 搜索引擎，很多大公司都在用，程序员的好伙伴 Github 的搜索也用的是它。本文记录我使用 Elasticsearch 搭建站内搜索的过程，目前支持中文分词、同义词、标题匹配优先等常见策略，请「点击这里」体验。安装 Elasticsearch部署 Elasticsearch 最简单的方法是使用Elasticsearch Dockerfile。为了更彻底地折腾，我没有使用 Docker，好在手动安装过程也不复杂。我的虚拟机和线上环境都是 Ubuntu 14.04.3 LTS，Elasticsearch 用的是目前最新的 2.1.1。一切开始之前，先要检查机器上是否装有 java 环境，如果没有可以通过以下命令安装：sudo apt-get install openjdk-7-jre-headless下载 Elasticsearch 2 ...继续阅读 (56)

很早之前我就在关注Let's Encrypt这个免费、自动化、开放的证书签发服务。它由 ISRG（Internet Security Research Group，互联网安全研究小组）提供服务，而 ISRG 是来自于美国加利福尼亚州的一个公益组织。Let's Encrypt 得到了 Mozilla、Cisco、Akamai、IdenTrust 和 Electronic Frontier Foundation 等众多大公司的支持，发展十分迅猛。申请 Let's Encrypt 证书不但免费，还非常简单，虽然每次只有 90 天的有效期，但可以通过脚本定期更新，配好之后一劳永逸。经过一段时间的观望，我也正式启用 Let's Encrypt 证书了，本文记录本站申请过程和遇到的问题。我没有使用 Let's Encrypt 官网提供的工具来申请证书，而是用了acme-tiny这个更为小巧的开源工具。以下内容基本按照 acme-tiny 的说明文档写的，省略了一些我不需要的步骤。创建帐号首先创建一个目录，例如ssl，用来存放各种临时文件和最后的证书文件。进入这个目录，创建一个 RSA 私钥用于 Let's Encrypt 识别你的身份：openssl genrsa4096> account.key创建 CSR 文件接着就可以生成 CSR（Certificate Signing Reque ...继续阅读 (61)

很早之前我就在关注Let's Encrypt这个免费、自动化、开放的证书签发服务。它由 ISRG（Internet Security Research Group，互联网安全研究小组）提供服务，而 ISRG 是来自于美国加利福尼亚州的一个公益组织。Let's Encrypt 得到了 Mozilla、Cisco、Akamai、Electronic Frontier Foundation 和 Chrome 等众多公司和机构的支持，发展十分迅猛。申请 Let's Encrypt 证书不但免费，还非常简单，虽然每次只有 90 天的有效期，但可以通过脚本定期更新，配好之后一劳永逸。经过一段时间的观望，我也正式启用 Let's Encrypt 证书了，本文记录本站申请过程和遇到的问题。我没有使用 Let's Encrypt 官网提供的工具来申请证书，而是用了acme-tiny这个更为小巧的开源工具。以下内容基本按照 acme-tiny 的说明文档写的，省略了一些我不需要的步骤。ACME 全称是 Automated Certificate Management Environment，直译过来是自动化证书管理环境的意思，Let's Encrypt 的证书签发过程使用的就是 ACME 协议。有关 ACME 协议的更多资料可以在这个仓库找到。创建帐号首先创建一个目录，例如ssl，用来存放各种临时文件 ...继续阅读 (79)

几天前，一位朋友问我：都说推荐用Qualys SSL Labs这个工具测试 SSL 安全性，为什么有些安全实力很强的大厂家评分也很低？我认为这个问题应该从两方面来看：1）国内用户终端情况复杂，很多时候降低 SSL 安全配置是为了兼容更多用户；2）确实有一些大厂家的 SSL 配置很不专业，尤其是配置了一些明显不该使用的 CipherSuite。我之前写的《关于启用 HTTPS 的一些经验分享（一）》，主要介绍 HTTPS 如何与一些新出的安全规范配合使用，面向的是现代浏览器。而今天这篇文章，更多的是介绍启用 HTTPS 过程中在老旧浏览器下可能遇到的问题，以及如何取舍。SSL 版本选择TLS（Transport Layer Security，传输层安全）的前身是 SSL（Secure Sockets Layer，安全套接字层），它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。TLS 1.3 改动会比较大，目前还在草案阶段。SSL 1.0 基本已经没人用，而 SSL 2.0 和 SSL 3.0 都存在安全问题，不推荐使用。Nginx 从 1.9.1 开始默认只支持 TLS 的三个版本，以下是 Nginx官方文档中对ssl_protoco ...继续阅读 (58)