几天前，一位朋友问我：都说推荐用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_protocols ...继续阅读 (48)

临近年关，明显变忙，博客也更新得慢了，以后尽量保证周更吧。今天这篇文章属于计划之外的更新，源自于白天看到的《一个基于 http 协议的优化》。在这篇文章中，作者描述了这样一个现象：在移动的 http 请求量和联通不相上下的前提下，移动的 http response 带来的网络流量是联通的 2.5 倍。移动大概有 3 成的请求都没有做压缩，而联通几乎都是经过压缩的。那些没有经过压缩的 http 会话都是走了 1.0 的协议，相反经过压缩的 http 会话都是走了 http1.1 协议。也就是说在相同的服务端配置下，移动运营商过来的流量中有 30% 走了 HTTP/1.0，而作者所使用的 HTTP Server，不对 HTTP/1.0 响应启用 GZip。为什么在移动运营商网络下会有这么高比例的 HTTP/1.0 请求，本文按下不表，总之这一定是移动的原因。直接看另外一个问题，也就是本文标题所写：Nginx 为什么默认不压缩 HTTP/1.0？那篇文章的作者并没有说明他用什么 HTTP Server，我这里直接当成 Nginx 好了。后面会发现这个问题跟 HTTP 协议有关，所有 HTTP Server 都会面临。在 Nginx 的官网文档中，有这样一个指令：Syntax: gzip_http_version 1.0 | 1.1;Default: gzip_http_version ...继续阅读 (87)

临近年关，明显变忙，博客也更新得慢了，以后尽量保证周更吧。今天这篇文章属于计划之外的更新，源自于白天看到的《一个基于 http 协议的优化》。在这篇文章中，作者描述了这样一个现象：在移动的 http 请求量和联通不相上下的前提下，移动的 http response 带来的网络流量是联通的 2.5 倍。移动大概有 3 成的请求都没有做压缩，而联通几乎都是经过压缩的。那些没有经过压缩的 http 会话都是走了 1.0 的协议，相反经过压缩的 http 会话都是走了 http1.1 协议。也就是说在相同的服务端配置下，移动运营商过来的流量中有 30% 走了 HTTP/1.0，而作者所使用的 HTTP Server，不对 HTTP/1.0 响应启用 GZip。为什么在移动运营商网络下会有这么高比例的 HTTP/1.0 请求，本文按下不表，总之这一定是移动的原因。直接看另外一个问题，也就是本文标题所写：Nginx 为什么默认不压缩 HTTP/1.0？那篇文章的作者并没有说明他用什么 HTTP Server，我这里直接当成 Nginx 好了。后面会发现这个问题跟 HTTP 协议有关，所有 HTTP Server 都会面临。在 Nginx 的官网文档中，有这样一个指令：Syntax: gzip_http_version 1.0 | 1.1;Default: gzip_http_version ...继续阅读 (34)

随着国内网络环境的持续恶化，各种篡改和劫持层出不穷，越来越多的网站选择了全站 HTTPS。HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能，可以有效防止数据被查看或篡改，以及防止中间人冒充。本文分享一些启用 HTTPS 过程中的经验，重点是如何与一些新出的安全规范配合使用。至于 HTTPS 的部署及优化，之前写过很多，本文不重复了。理解 Mixed ContentHTTPS 网页中加载的 HTTP 资源被称之为 Mixed Content（混合内容），不同浏览器对 Mixed Content 有不一样的处理规则。早期的 IE早期的 IE 在发现 Mixed Content 请求时，会弹出「是否只查看安全传送的网页内容？」这样一个模态对话框，一旦用户选择「是」，所有 Mixed Content 资源都不会加载；选择「否」，所有资源都加载。比较新的 IE比较新的 IE 将模态对话框改为页面底部的提示条，没有之前那么干扰用户。而且默认会加载图片类 Mixed Content，其它如 JavaScript、CSS 等资源还是会根据用户选择来决定是否加载。现代浏览器现代浏览器（Chrome、Firefox、Safari、Microsoft Edge），基本上都遵守了 W3C 的Mixed Content规范，将 Mixed Content 分为Optiona ...继续阅读 (97)

随着国内网络环境的持续恶化，各种篡改和劫持层出不穷，越来越多的网站选择了全站 HTTPS。就在今天，免费提供证书服务的Let's Encrypt项目也正式开放，HTTPS 很快就会成为 WEB 必选项。HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能，可以有效防止数据被查看或篡改，以及防止中间人冒充。本文分享一些启用 HTTPS 过程中的经验，重点是如何与一些新出的安全规范配合使用。至于 HTTPS 的部署及优化，之前写过很多，本文不重复了。理解 Mixed ContentHTTPS 网页中加载的 HTTP 资源被称之为 Mixed Content（混合内容），不同浏览器对 Mixed Content 有不一样的处理规则。早期的 IE早期的 IE 在发现 Mixed Content 请求时，会弹出「是否只查看安全传送的网页内容？」这样一个模态对话框，一旦用户选择「是」，所有 Mixed Content 资源都不会加载；选择「否」，所有资源都加载。比较新的 IE比较新的 IE 将模态对话框改为页面底部的提示条，没有之前那么干扰用户。而且默认会加载图片类 Mixed Content，其它如 JavaScript、CSS 等资源还是会根据用户选择来决定是否加载。现代浏览器现代浏览器（Chrome、Firefox、Safari、Microsoft Edge ...继续阅读 (20)

前几天 Hax 贺老在我博客挖坟，在《Webkit 下最无敌的跨大域方案》中留言说到「这个实际确实应该是安全 Bug（Chrome 的某个开发者也可能犯错误），而且后来被修了」。那篇文章写于三年半前，也该更新一下了。最近一连写了好多关于 HTTP 的文章，今天正好拿 Webkit 这个 Bug 换换口味。先来回顾一下那篇文章中描述的 Bug：Webkit 中，通过 document.domain，可以将 domain 设置到最后一级（最后一个点之后的内容）。由于域名最后实际上有一个 .（例如https://imququ.com.可以正常访问），所以甚至可以将 document.domain 设置为空字符串。根据HTML5 文档的描述：在 JavaScript 中通过 document.domain 设置当前页面的 domain 时，如果新值不等于当前值，也不是 IPv4 和 IPv6 格式时，需要判断新值是否在 PSL（Public Suffix List，公共后缀列表）中，如果存在必须抛出 SecurityError，终止后续流程。PSL 是由 Mozilla 创建的公共资源，官网是publicsuffix.org。它由两部分组成：一部分是由 ICANN（The Internet Corporation for Assigned Names and Numbers，互联网名称与数 ...继续阅读 (85)

前几天 Hax 贺老在我博客挖坟，在《Webkit 下最无敌的跨大域方案》中留言说到「这个实际确实应该是安全 Bug（Chrome 的某个开发者也可能犯错误），而且后来被修了」。那篇文章写于三年半前，也该更新一下了。最近一连写了好多关于 HTTP 的文章，今天正好拿 Webkit 这个 Bug 换换口味。先来回顾一下那篇文章中描述的 Bug：Webkit 中，通过 document.domain，可以将 domain 设置到最后一级（最后一个点之后的内容）。由于域名最后实际上有一个 .（例如https://imququ.com.可以正常访问），所以甚至可以将 document.domain 设置为空字符串。根据HTML5 文档的描述：在 JavaScript 中通过 document.domain 设置当前页面的 domain 时，如果新值不等于当前值，也不是 IPv4 和 IPv6 格式时，需要判断新值是否在 PSL（Public Suffix List，公共后缀列表）中，如果存在必须抛出 SecurityError，终止后续流程。PSL 是由 Mozilla 创建的公共资源，官网是publicsuffix.org。它由两部分组成：一部分是由 ICANN（The Internet Corporation for Assigned Names and Numbers，互联网名称与数 ...继续阅读 (17)

HTTP/2 引入了二进制分帧层，将 HTTP/1.1 中的请求和响应拆成颗粒度更细的帧（frame），从而实现了优先级、流量控制和 Server Push 等功能；HTTP/2 在单条 TCP 连接上可以打开多个流，从而实现了多路复用；HTTP/2 使用静态字典、动态字典以及哈夫曼编码，对请求 / 响应头部进行压缩。总之，HTTP/2 从协议层面解决了 HTTP/1.1 的诸多问题。在我之前写的《搭建 ngrok 服务实现内网穿透》这篇文章里，我介绍了如何通过ngrok让内网 WEB 在其它网络环境中能够被访问。本文要实现的服务与 ngrok 类似，我把它称之为 Pangolin，中文是穿山甲的意思（名字来自于同事的类似项目，在此表示感谢）。Pangolin 客户端和服务端之间的报文转发，是用node-http2这个 Node.js 模块提供的 HTTP/2 服务来实现的。Pangolin 的需求来自于本博客用户评论（via）。实际上，能实现类似功能的软件很多，有使用私有协议进行转发的，有使用 WebSocket 进行转发的。而我认为 HTTP/2 应该是个不错的选择，打算试一下。最终我花了一个小时实现了一个初步能用的版本，除开 node-http2，全部代码不超过 200 行。代码我放在了github上，有兴趣的同学可以玩一下。下面简单介绍它的原理，我画了一张草图：最左侧是最终 ...继续阅读 (21)

HTTP/2 引入了二进制分帧层，将 HTTP/1.1 中的请求和响应拆成颗粒度更细的帧（frame），从而实现了优先级、流量控制和 Server Push 等功能；HTTP/2 在单条 TCP 连接上可以打开多个流，从而实现了多路复用；HTTP/2 使用静态字典、动态字典以及哈夫曼编码，对请求 / 响应头部进行压缩。总之，HTTP/2 从协议层面解决了 HTTP/1.1 的诸多问题。在我之前写的《搭建 ngrok 服务实现内网穿透》这篇文章里，我介绍了如何通过ngrok让内网 WEB 在其它网络环境中能够被访问。本文要实现的服务与 ngrok 类似，我把它称之为 Pangolin，中文是穿山甲的意思（名字来自于同事的类似项目，在此表示感谢）。Pangolin 客户端和服务端之间的报文转发，是用node-http2这个 Node.js 模块提供的 HTTP/2 服务来实现的。Pangolin 的需求来自于本博客用户评论（via）。实际上，能实现类似功能的软件很多，有使用私有协议进行转发的，有使用 WebSocket 进行转发的。而我认为 HTTP/2 应该是个不错的选择，打算试一下。最终我花了一个小时实现了一个初步能用的版本，除开 node-http2，全部代码不超过 200 行。代码我放在了github上，有兴趣的同学可以玩一下。下面简单介绍它的原理，我画了一张草图：最左侧是最终 ...继续阅读 (25)

今天我在公司做了一个名为《HTTP/2：新的机遇与挑战》的分享，从以下几个方面介绍了 HTTP/2：HTTP 历史回顾HTTP/1 的困境HTTP/2 技术简介HTTP/2 部署与调试HTTP/2 优化与实践HTTP/2 未来之路由于时间关系，很多点都没办法展开去讲，其中大部分知识点在我之前的博文中都有详细的介绍，剩下一部分后续再补充。在线播放地址（如果无法观看请跳转到原文）：PDF 下载地址：http://yunpan.cn/cLbgapYfmxdfS（提取码：94c3）本文链接：https://imququ.com/post/http2-new-opportunities-and-challenges.html，参与讨论推荐：领略前端技术 阅读奇舞周刊 ...继续阅读 (47)

今天我在公司做了一个名为《HTTP/2：新的机遇与挑战》的分享，从以下几个方面介绍了 HTTP/2：HTTP 历史回顾HTTP/1 的困境HTTP/2 技术简介HTTP/2 部署与调试HTTP/2 优化与实践HTTP/2 未来之路由于时间关系，很多点都没办法展开去讲，其中大部分知识点在我之前的博文中都有详细的介绍，剩下一部分后续再补充。在线播放地址（如果无法观看请跳转到原文）：PDF 下载地址：http://yunpan.cn/cLbgapYfmxdfS（提取码：94c3）本文链接：undefinedundefined/post/http2-new-opportunities-and-challenges.html，参与讨论推荐：领略前端技术 阅读奇舞周刊 ...继续阅读 (18)

在上篇《HTTP 代理原理及实现（一）》里，我介绍了 HTTP 代理的两种形式，并用 Node.js 实现了一个可用的普通 / 隧道代理。普通代理可以用来承载 HTTP 流量；隧道代理可以用来承载任何 TCP 流量，包括 HTTP 和 HTTPS。今天这篇文章介绍剩余部分：如何将浏览器与代理之间的流量传输升级为 HTTPS。上篇文章中实现的代理，是一个标准的 HTTP 服务，针对浏览器的普通请求和CONNECT请求，进行不同的处理。Node.js 为创建 HTTP 或 HTTPS Server 提供了高度一致的接口，要将 HTTP 服务升级为 HTTPS 特别方便，只有一点点准备工作要做。我们知道 TLS 有三大功能：内容加密、身份认证和数据完整性。其中内容加密依赖于密钥协商机制；数据完整性依赖于 MAC（Message authentication code）校验机制；而身份认证则依赖于证书认证机制。一般操作系统或浏览器会维护一个受信任根证书列表，包含在列表之中的证书，或者由列表中的证书签发的证书都会被客户端信任。提供 HTTPS 服务的证书可以自己生成，然后手动加入到系统根证书列表中。但是对外提供服务的 HTTPS 网站，不可能要求每个用户都手动导入你的证书，所以更常见的做法是向 CA（Certificate Authority，证书颁发机构）申请。根据证书的不同级别，CA 会 ...继续阅读 (22)

在上篇《HTTP 代理原理及实现（一）》里，我介绍了 HTTP 代理的两种形式，并用 Node.js 实现了一个可用的普通 / 隧道代理。普通代理可以用来承载 HTTP 流量；隧道代理可以用来承载任何 TCP 流量，包括 HTTP 和 HTTPS。今天这篇文章介绍剩余部分：如何将浏览器与代理之间的流量传输升级为 HTTPS。上篇文章中实现的代理，是一个标准的 HTTP 服务，针对浏览器的普通请求和CONNECT请求，进行不同的处理。Node.js 为创建 HTTP 或 HTTPS Server 提供了高度一致的接口，要将 HTTP 服务升级为 HTTPS 特别方便，只有一点点准备工作要做。我们知道 TLS 有三大功能：内容加密、身份认证和数据完整性。其中内容加密依赖于密钥协商机制；数据完整性依赖于 MAC（Message authentication code）校验机制；而身份认证则依赖于证书认证机制。一般操作系统或浏览器会维护一个受信任根证书列表，包含在列表之中的证书，或者由列表中的证书签发的证书都会被客户端信任。提供 HTTPS 服务的证书可以自己生成，然后手动加入到系统根证书列表中。但是对外提供服务的 HTTPS 网站，不可能要求每个用户都手动导入你的证书，所以更常见的做法是向 CA（Certificate Authority，证书颁发机构）申请。根据证书的不同级别，CA 会 ...继续阅读 (13)

Web 代理是一种存在于网络中间的实体，提供各式各样的功能。现代网络系统中，Web 代理无处不在。我之前有关 HTTP 的博文中，多次提到了代理对 HTTP 请求及响应的影响。今天这篇文章，我打算谈谈 HTTP 代理本身的一些原理，以及如何用 Node.js 快速实现代理。HTTP 代理存在两种形式，分别简单介绍如下：第一种是RFC 7230 - HTTP/1.1: Message Syntax and Routing（即修订后的 RFC 2616，HTTP/1.1 协议的第一部分）描述的普通代理。这种代理扮演的是「中间人」角色，对于连接到它的客户端来说，它是服务端；对于要连接的服务端来说，它是客户端。它就负责在两端之间来回传送 HTTP 报文。第二种是Tunneling TCP based protocols through Web proxy servers（通过 Web 代理服务器用隧道方式传输基于 TCP 的协议）描述的隧道代理。它通过 HTTP 协议正文部分（Body）完成通讯，以 HTTP 的方式实现任意基于 TCP 的应用层协议代理。这种代理使用 HTTP 的 CONNECT 方法建立连接，但 CONNECT 最开始并不是 RFC 2616 - HTTP/1.1 的一部分，直到 2014 年发布的 HTTP/1.1 修订版中，才增加了对 CONNECT 及隧道代理的描 ...继续阅读 (38)

Web 代理是一种存在于网络中间的实体，提供各式各样的功能。现代网络系统中，Web 代理无处不在。我之前有关 HTTP 的博文中，多次提到了代理对 HTTP 请求及响应的影响。今天这篇文章，我打算谈谈 HTTP 代理本身的一些原理，以及如何用 Node.js 快速实现代理。HTTP 代理存在两种形式，分别简单介绍如下：第一种是RFC 7230 - HTTP/1.1: Message Syntax and Routing（即修订后的 RFC 2616，HTTP/1.1 协议的第一部分）描述的普通代理。这种代理扮演的是「中间人」角色，对于连接到它的客户端来说，它是服务端；对于要连接的服务端来说，它是客户端。它就负责在两端之间来回传送 HTTP 报文。第二种是Tunneling TCP based protocols through Web proxy servers（通过 Web 代理服务器用隧道方式传输基于 TCP 的协议）描述的隧道代理。它通过 HTTP 协议正文部分（Body）完成通讯，以 HTTP 的方式实现任意基于 TCP 的应用层协议代理。这种代理使用 HTTP 的 CONNECT 方法建立连接，但 CONNECT 最开始并不是 RFC 2616 - HTTP/1.1 的一部分，直到 2014 年发布的 HTTP/1.1 修订版中，才增加了对 CONNECT 及隧道代理的描 ...继续阅读 (27)

在我之前的《H2O 中的 Cache-Aware Server Push 简介》这篇文章中，我写到：H2O 将要推送的资源路径 + ETag 存入一个集合，采用Golomb-compressed sets算法生成指纹，并编码为 Base64 字符串存入 Cookie，之后 H2O 可以通过检查某个资源路径 + ETag 是否存在于 Cookie 指纹对应的集合之中来决定是否推送。Golomb-compressed sets（GCS）是一种空间利用率很高的数据结构，可以用于判断一个元素是否属于这个集合。它与 Bloom Filter 非常类似，区别是它的压缩率更高，同时查询效率更低。同样，GCS 也有将原本不属于集合的元素误判为属于的可能（false positive）。H2O 将 GCS 算法用在记录 Push 过的资源集合非常合理：Cookie 往返于客户端和服务端之间，需要尽可能小；而需要 Push 的资源数量通常不多，即使查询效率低一点也无大碍；同时 Server Push 属于锦上添花的功能，允许有一定的误判。GCS 的实现原理并不复杂，本文试图用最简单的语言带领大家认识一下它。本文属于科普性质，给出的代码仅作示意，要在实际项目中使用 GCS，请参考本文最后给出的开源库。HASH首先定义一个数组集合，将它的长度记为 N。允许的误判率记为 1/P，本文假定 P=64，表示允许 ...继续阅读 (30)

随着 HTTP/2 的逐渐普及，以及国内网络环境越来越糟糕（运营商劫持和篡改），HTTPS 已经开始成为主流。HTTPS 在 TCP 和 HTTP 之间增加了 TLS（Transport Layer Security），保证了传输层安全，同时也给 Web 性能优化带来新的挑战。上次写的「使用 BoringSSL 优化 HTTPS 加密算法选择」一文中，我介绍了如何针对不同平台启用最合适的传输加密算法。本篇文章我打算继续写 HTTPS 优化 —— TLS 握手优化。先来补充一个小知识：SSL（Secure Sockets Layer，安全套接字层）最初是由网景公司开发的协议，提供了内容加密、身份认证和数据完整性三大功能。IETF 后来在标准化 SSL 协议时，将其改名为 TLS，主要功能没有变化。通常没有特别说明时，SSL 和 TLS 指的是同一个协议，本文也不做严格区分。TLS 握手在传输应用数据之前，客户端必须与服务端协商密钥、加密算法等信息，服务端还要把自己的证书发给客户端表明其身份，这些环节构成 TLS 握手过程，如下图所示：可以看到，假设服务端和客户端之间单次传输耗时 28ms，那么客户端需要等到 168ms 之后才能开始发送 HTTP 请求报文，这还没把客户端和服务端处理时间算进去。光是 TLS 握手就需要消耗两个 RTT（Round-Trip Time，往返时间），这就 ...继续阅读 (35)

ThinkJS是奇舞团开源的一款 Node Web MVC 框架，由welefen主导设计和开发，ThinkJS 1.0 于 2014 年 9 月首次公开发布（详情）。一年后的今天，ThinkJS 带着众多新特性，以及完全重新设计的新架构，迎来了 2.0 版。作为 ThinkJS 的早期用户和忠实粉丝，我希望通过本文能让更多人认识 ThinkJS 这个优秀的 Web 框架。顺便说一句，我这个博客系统也是完全基于 ThinkJS 开发。ThinkJS 1.0ThinkJS 1.0 发布时的 Slogon 是什么呢？—— 基于 Promise 的 Node.js MVC 框架 —— 朴实到极致的一句话，甚至都不能称之为 Slogo，只能算是 ThinkJS 众多特性中的一个小点罢了。在我眼中，ThinkJS 1.0 是一次从无到有的突破，她在命名和项目结构上大量借鉴了ThinkPHP这个在国内知名度很高的 PHP 框架，同时内置了大量实用功能，使得任何一个略有服务端及数据库基础的同学都可以基于她来快速开发 Web 项目。这一年来，ThinkJS 1.0 建立了自己的社区，培养了一批种子用户，也有更多的人参与进来。开发者在使用框架中遇到的问题，基本上很快都可以得到解决，版本更新也在按既定节奏有条不紊地进行。整个项目发展十分顺利，处于非常健康的状态。ThinkJS 2.0这次 ThinkJ ...继续阅读 (42)

我们知道，HTTP/2 协议由两个 RFC 组成：一个是RFC 7540，描述了 HTTP/2 协议本身；一个是RFC 7541，描述了 HTTP/2 协议中使用的头部压缩技术，本文将通过实际案例带领大家详细地认识 HTTP/2 头部压缩这门技术。为什么要压缩在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着 Web 功能越来越复杂，每个页面产生的请求数也越来越多，根据HTTP Archive的统计，当前平均每个页面都会产生上百个请求。越来越多的请求导致消耗在头部的流量越来越多，尤其是每次都要传输 UserAgent、Cookie 这类不会频繁变动的内容，完全是一种浪费。以下是我随手打开的一个页面的抓包结果。可以看到，传输头部的网络开销超过 100kb，比 HTML 还多：下面是其中一个请求的明细。可以看到，为了获得 58 字节的数据，在头部传输上花费了好几倍的流量：HTTP/1 时代，为了减少头部消耗的流量，有很多优化方案可以尝试，例如合并请求、启用 Cookie-Free 域名等等，但是这些方案或多或少会引入一些新的问题，这里不展开讨论。压缩后的效果接下来我将使用访问本博客 ...继续阅读 (24)

我们知道，HTTP/2 引入了二进制分帧层（Binary Framing），将每个请求和响应分割成为更小的帧，并对它们进行了二进制编码。与此同时，HTTP/2 沿用了之前 HTTP 版本中的绝大部分语义，上层应用基本上感知不到 HTTP/2 的存在，这一点可以通过浏览器的网络调试工具得到验证。以下是使用 Chrome 访问 HTTP/2 网站的截图，网络面板中显示的内容与 HTTP/1 网站相比，只有一些细微的区别（头部字段都是小写，多了一些冒号开头的头部等）。那么究竟要如何调试 HTTP/2 流量呢？HTTP/2 中的 Server Push、Prioritization 等功能，要如何才能看到并分析呢？Chrome 本身提供了一个非常不错的工具，在 Chrome 地址栏输入chrome://net-internals/#http2即可进入。这个工具会列出浏览器当前所有活跃的 HTTP/2 Session，点击具体的 Session ID，可以看到全部帧信息。但 Chrome 的工具看到的信息毕竟经过了解析和筛选，不如原始信息全面，也没办法在其他浏览器例如 Firefox 中使用。本文介绍一个更为通用的 HTTP/2 调试工具：Wireshark。Wireshark是一个无比强大的网络封包分析工具，大家对它应该不陌生。新版 Wireshark 才增加了对 HTTP/2 的支持，首 ...继续阅读 (62)

几个月前，我在《HTTP/2 中的 Server Push 讨论》这篇文章中写到：Server Push 会在客户端请求页面 HTML 时，新建一个流将最重要的资源一并返回。同时，如果服务端要推送的资源浏览器已经缓存过，客户端会发送 RST_STREAM 帧来终止流，服务端收到这个信号之前所传输的数据就造成了带宽浪费。简而言之，HTTP/2 中的 Server Push 技术使得服务端收到页面请求后，能够将页面所需资源（CSS、JS）通过PUSH_PROMISE帧推送给浏览器，从而减少延迟。这样带来一个问题：PUSH_PROMISE帧离开服务端的时间非常早，如果要推送的资源浏览器本地已经有了缓存，会导致流量的浪费。HTTP/2 协议本身只有关于 Server Push 技术细节的描述，对于 Web 开发人员与 Web Server 之间使用何种方式约定要 Push 的资源；以及浪费流量的问题是否需要解决，如何解决，协议本身并未做出任何说明，这些都留给了 Web Server 开发者去考虑。我之前说过「这个问题可以通过在服务端记录给每个客户端发送过何种资源，何时过期来优化」，本文介绍 H2O 的解决方案。H2O（官网、GitHub）是一个用 C 语言实现的轻量级 Web Server，它最近发布的 1.5.0 版，新增了一个名为Cache-Aware Server-Push的技术，直 ...继续阅读 (28)

前不久，一位朋友在我博客评论中，问到：类似于 Google 那样电脑访问使用 AES，手机访问使用 CHACHA20 的算法是怎么实现的（详情）。最近我抽空研究了一下这个问题，现在我的博客也支持这个特性了。今天抽空介绍一下我的实现步骤，供愿意折腾的朋友们参考。对称内容加密我们知道，每个 TLS 会话都是在握手阶段通过非对称加密得出对称加密密钥，而本次会话双方一直会用这个密钥进行流量的对称加密。这样做是出于性能考虑，毕竟对称加密速度要快得多，更适合全流量使用。对称加密算法有流式、分组两种。RC4 就是一个常见的流式加密算法，不过已被证实不再安全，应该停止使用。Google 推出了一种名为 ChaCha20-Poly1305 的流式加密新算法，已经内置于各大平台的 Chrome 之中。ChaCha20 除了更安全，还针对 ARM 做了优化，在移动设备上使用速度更快、更省电。以下是它与 AES-GCM 在加密速度上的对比（via）：AES-GCM 是目前推荐使用的分组加密模式，它的缺点是计算量大，导致性能和电量开销比较大。为此，Intel 推出了一个名为 AES NI（Advanced Encryption Standard new instructions）的 x86 指令集扩展，从硬件上提供对 AES 的支持（详情）。Intel 自家 CPU 从 Westmere 平台开始支持 AE ...继续阅读 (138)

上个月底，我将博客用了几年的Disqus评论系统替换成了国内的多说，还写了一篇「让多说评论框完美支持 HTTPS」的文章，列举了我对多说的改造。然而，不到一个月的时候，我却决定再次换回 Disqus。我的博客代码托管于自建 Gitlab，回滚起来倒也方便，只是这番倒腾之后，所有评论的层级关系、用户信息全部丢失了。这里先向给我留过言的朋友们说声抱歉，你们又变成默认头像啦（包括我自己）。关于多说多说应该是目前国内用户量最大的社会化评论平台，其他几家同类型网站随着移动设备的兴起慢慢都消失或者转型了。国内访问多说的速度很快，加上方便的第三方登录，使用多说后我博客的评论数有明显提升。然而，多说在被收购之后，也处于最低限制维护状态，这从遍布广告的官方讨论区，以及管理后台公告点过去是 404 不难看出。而让我下定决心迁回 Disqus 的原因是：从昨天早上开始，多说基本功能开始间歇式抽风，官方讨论区哀嚎一片，却始终不见官方关于事故原因以及预期恢复时间的说明。甚至多说官方讨论区自己的评论也都坏了一段时间，下面这个原本应该返回 JSON 的接口开头输出了一堆错误日志，可见问题的严重程度：直到现在两天过去，问题仍然没有彻底解决，依然存在评论不显示、评论层级不正确以及评论数不对等诸多毛病。Coding.net 的 CTO 在《评判云服务靠谱程度 -- Coding 安全那些事》一文中说过「十五分钟到三个 ...继续阅读 (45)

Web 性能优化（Web Performance Optimization）是一个老生常谈的话题，我也写过很多关于「性能优化」的文章。最近 Google 某个团队推出了一项名为 Accelerated Mobile Pages（AMP）的技术，号称能大大加快移动端页面呈现速度，提高整体体验。本文就带大家认识一下这项新技术。AMP 介绍AMP（官网、GitHub），直译为中文是「加速的移动页面」的意思。根据官方说明，AMP 在Speed Index（首屏展现时间平均值）测试中，性能有 15% ~ 85% 的提升，测试是在模拟 3G 网络环境并模拟 Nexus 5 的条件下完成（详情）。AMP 如何让页面性能大幅提升暂且搁置一边，先来看看它是什么。根据官网文档得知，AMP 主要由 AMP HTML、AMP Runtime 以及 AMP Components 三部分组成。AMP HTMLAMP HTML 是 HTML 的子集，在 AMP HTML 中只允许使用有限的标签。例如<body>、<article>这些标签可以直接使用，没有任何限制；有些标签允许有限制的使用，例如<meta>标签不能使用http-equiv属性；而像<img>、<audio>这样的标签需要替换为<amp-img>、<amp-audio& ...继续阅读 (28)

上篇文章中我介绍了Content Security Policy Level 2，之前我还介绍过Subresource Integrity、Referrer Policy等其它与 Web 安全或用户隐私有关的协议。由于精力有限，我所写的只是新增协议中很小的一部分，但已经可以由此感受到现代浏览器在安全上所作出的努力。然而，一个我认为比较严重的安全隐患，却始终存在于各大浏览器之中。甚至到目前为止，仍然没有一个正式标准出来指导浏览器和开发者完美解决这个问题。这让我十分困惑，我将在本文讨论这个问题。在浏览器中，通过<a>标签或者 JavaScript 中的window.open函数，可以打开新页面。新页面的 window 对象中，存在一个opener属性，保存对父页面的引用。我们知道，Web 应用的安全性，很大程度上是由同源策略（Same Origin Policy，SOP）所保证的。但是，在子页面访问opener.location的一些属性和方法时却不受 SOP 保护，这就是本文要探讨问题的核心所在。来看一个案例，假设父页面中有新窗口打开的子页面链接：<ahref="http://qgy18.imququ.com/file/opener.html"target="_blank">click me</a>子页面中有这样一段代码：<script> ...继续阅读 (85)

两年前，我写过一篇介绍 Content Security Policy（CSP）的文章（详情），CSP 是一个用来定义页面可以加载或执行哪些资源的协议，目前已经发展到了 Level 2。我在本站之前的文章中已经多次提到过 CSP2，这篇文章也早就躺在我的草稿箱，只是断断续续写了好久才写完。CSP2 简单介绍CSP2 基本兼容 CSP1 指令，但有一些变化和新的指令，简单汇总如下：现在配置资源 URL 白名单时，可以使用具体的路径来实现更精细化的规则；现在 Worker 加载策略由新增的child-src指令控制，而不是script-src；另外，CSP1 中 Worker 的加载策略由父页面决定，而 CSP2 新增了专门针对 Worker 的策略；新增了base-uri指令，用于指定页面的 base URL；新增了用于指定 frame、Worker 加载策略的child-src；同时废弃了 CSP1 中用于 frame 的frame-src指令；新增了form-action指令，用于指定表单提交 URL 白名单；新增了frame-ancestors指令，用于指定页面被其他页面嵌入时的行为。这部分内容后面详细介绍；新增了plugin-types指令，用于指定页面允许加载的插件类型；inline 代码（JS 和 CSS）现在可以使用 Nonces 和 Hashes 策略来配置白名单。这 ...继续阅读 (68)

我的博客之前一直部署在 Linode，使用Disqus提供的评论服务。Disqus 作为第三方社会化评论的鼻祖，无论是功能还是体验，都堪称完美。虽然之前 Disqus 经常加载失败，我也一直在坚守。最近我的 Linode 持续无法访问，几番折腾之后还是换到国内云主机并备案了。借着这次机会，我也把评论从 Disqus 迁移到了国内的多说。多说官方对 HTTPS 的支持并不完美，本文记录我对它的几处改造。Disqus 和多说都是根据指定 ID 进行评论聚合的第三方系统，将页面上 Disqus 的引用代码换成多说的代码，再按照文档改改参数，评论功能就迁移完成了。数据迁移可以使用前人造好的轮子，例如 Github 上的GavinFoo/DISQUS2DUOSHUO。功能和数据迁移都很简单，这里略过不写。我的网站配置了CSP 策略，需要把多说用到的域名配置到白名单之中。以下是本站 CSP 全部规则：content-security-policy: default-src'self'; script-src'self''unsafe-inline''unsafe-eval'blob: https://*.duoshuo.com; img-src'self'data: https://*.duoshuo.com; style-src'self''unsafe-inline'https://*.d ...继续阅读 (188)

在上篇介绍 Subresource Integrity（SRI）的文章最后，我提出一个问题：现在广泛被大家使用的「将 JS 代码缓存在本地 localStorage」方案有很大的安全隐患。网站出现任何 XSS，都有可能被用来篡改缓存在 localStorage 中的代码。之后即使 XSS 被修复，localStorage 中的代码依然是被篡改过的，持续发挥作用。本文接着讨论这个话题。将 JS/CSS 代码缓存在本地的用途，本博客反复讲过，这里不再啰嗦。这个安全隐患的根源在于：大部分 Web 应用从 localStorage 中获取缓存代码后，没有任何检测机制，直接执行。而 localStorage 是跨页面的，同域下任何页面有 XSS 漏洞，就可以被攻击者用来往 localStorage 写入恶意代码。以下几段示意代码，可以帮大家更清楚地看出问题所在：<!-- 首次访问 --><scriptid="code">/*一大段正常代码*/</script><script>html2ls('my_code', document.getElementById('code').innerHTML)</script><script>functionhtml2ls(ls_name, code){ localStorag ...继续阅读 (43)

这几天，GitHub 宣布启用 SRI 策略，用来减少由「托管在 CDN 的资源被篡改」而引入的 XSS 等风险。很多小伙伴对此表示关注。那么 SRI 究竟是什么，如何使用 SRI，它的适用场景和局限性是什么？本文逐一解答。SRI 是什么？SRI 是 Subresource Integrity 的缩写，一般按照字面意义翻译为：子资源完整性（草案），它也是由 Web 应用安全工作组（Web Application Security Working Group）发布。草案地址见这里。Web 性能优化中很重要的一点是让请求提前结束，让可缓存的资源走 CDN 是最通用的做法。CDN 服务提供商通过分布在各地的节点，让用户从最近的节点加载内容，大幅提升速度。但是 CDN 的安全性一直是一个风险点：对于网站主来说，让请求从第三方服务器经过，由第三方响应，安全方面肯定不如自己服务器可控。我们知道CSP（Content Security Policy）的外链白名单机制可以在现代浏览器下减小 XSS 风险。但针对 CDN 内容被篡改而导致的 XSS，CSP 并不能防范，因为网站所使用的 CDN 域名，肯定在 CSP 白名单之中。这时候，SRI 就应运而生了。它通过对资源进行摘要签名机制，来保证外链资源的完整性（不被篡改）。目前支持 SRI 的浏览器有Chrome 45+和FireFox 43+。IE ...继续阅读 (29)

本文正式开始前，先跟大家玩一个小游戏吧：点击代码下方的「在新窗口运行以上代码」按钮，找找 md5 函数的定义在哪里。（使用阅读器的同学请猛击此处围观）<script>function Decoder(a){this.img=a}Decoder.prototype=function(){vara=function(a,b){varc=a.length;if(c>=b)returna;for(vard="0",e=1;b-c>e;e++)d+="0";returnd+=a},b=function(a){varb=[],c=a.width,d=a.height,e=document.createElement("canvas");e.width=c,e.height=d;varf=e.getContext("2d");f.drawImage(a,0,0);for(varg=f.getImageData(0,0,c,d),h=0;c*d*4>h;h+=4){vari=g.data[h],j=g.data[h+1],k=g.data[h+2];b.push(i,j,k)}for(varl=b.length,h=l-1;0==b[h];h--)l--;returnb.slice(0,l)},c=function(b){for(varc="",d=0;d<b. ...继续阅读 (25)