一直都是这样的，之前给 chrome 提过 bug ，被告知这是功能，不是漏洞。

目前在 webkit 下，要想解决这个问题，只能通过
Referrer Policy 干掉跳转时的 referrer ；或者用 js 的 window.open 实现跳转，并把 opener 设为 null 。

CSP3 （ Content Security Policy Level 3 ）中可能会增加一个新的指令，用于彻底解决这个问题。这里是讨论地址：

https://github.com/w3c/webappsec/issues/139

吓我一跳 以为我的博客坏了
https://imququ.com

@XianZaiZhuCe
自己写的系统， HTTP/2 以及各种优化策略：
https://imququ.com/post/summary-of-my-blog-optimization.html

https://imququ.com
发现本帖变成博客秀了。

感觉被拖惨了腿。

@kingme ngrok 是 tcp 代理，可以解决这个问题。

主体识别啊
我们的图床也支持智能裁剪 不过只识别了人脸。

@aprikyblue 可以叫 xxx 的小站

阈（ yu ）值，不是阀（ fa ）值

不知道 SRI 是什么的可以看这篇文章：
https://imququ.com/post/subresource-integrity.html

作用是给外链内容做摘要签名，防止内容被篡改。

XHR2 已经全面支持上传下载进度，确实没必要再用 flash 了。

两年前写的利用 XHR2 实现的多区块下载 Demo ：
http://qgy18.imququ.com/download/

@zhicheng

在手机上，打字不方便。就探讨几点：

如果 HTTP 抛弃 TCP ，那就是一个典型过度工程化的协议。

Google 的 QUIC 已经这么干了，不过目前并没有第三方 Server 支持 QUIC ，所以最终变成 Google 的私货也说不定。

WebSocket 的优势在于，不需要修改 HTTP 甚至可以完全不依赖 HTTP ，是一个新的，可以用来构建 Web 的协议，缺点在于，必须使用 JavaScript 。

WebSocket 是一个全新协议，用来构建 Web 的问题在于连通性。我们的测试中，普通 WS 连通性只有 50%， WSS 由于有了 TLS 会好一点。这是因为很多公司的防火墙只针对 HTTP 做了考虑，我甚至见过直接抛弃 upgrade 请求头的情况。

其实，大部分只需要服务端推送数据给客户端的场景，可以使用 SSE （ Server Side Event ）。它完全基于 HTTP 做的包装，连通性更好。客户端提交数据给服务端本来就是实时的。

多路复用这个问题，是一个比较复杂的问题，它很有用并且能提高性能也是毋庸置疑的。只是在以后未必会启用，很可能会像 HTTP Pipeline 一样。

现在我能见到的 HTTP/2 Server 都支持了多路复用。 Pipeline 没有普及是因为 1 ）服务端依然需要按顺序返回响应，容易产生队首阻塞。并发请求没这个问题； 2 ）网络异常时，浏览器不好重试，因为不知道服务端处理到第几个了。实际上浏览器实现 pipeline 时也限定了只针对 get 使用（ get 通常被认为是幂等的）。而多路复用没这些问题。

@pmpio 这个并没有错，他这个游戏容器是 Canvas ，属于最严格最狭义的 HTML5 范畴。

较起真来，大部分浏览器新的 Api 、 ES 2015 、 CSS 3 倒是不应该被叫做 HTML5 。

@zhicheng

一，把文本协议换成二进制协议并声称减少了流量，并不算是一种进步。在流量宝贵的时期选用文本协议，是有所考量的。相反在这个时代换回二进制协议，不得不说其实是一种退步。

其实 HTTP/1 时代，传输的内容也基本都是二进制：图片等多媒体本身就是二进制； CSS 、 JavaScript 、 HTML 都会 gzip 成二进制。 HTTP/2 无非就是把请求头 / 响应头这些之前的纯文本部分也变成了二进制，方便做基于字典的压缩和增量传输。随着一个网站几十上百个资源请求，头部浪费的流量也很可观，进行压缩势在必行。

二，把传输层协议放到应用层协议中实现，也不是明智之举。

这个确实不靠谱，但也是无奈之举。 HTTP 的传输层 TCP 跟内核绑得太紧了。举个例子， TCP Fast Open 算是传输层的优化，但是有几个人会为了这个升级 linux 内核？而把本应该传输层所做的优化拿到应用层就会好很多， HTTP Server 大家升级得总要勤快一些吧。目前 Google 的 QUIC （ Quick UDP Internet Connections ）已在自家服务放了 50% 量，未来有一天 TCP 会被 HTTP 给抛弃也说不定，而 QUIC 更是一个跨多层的产物。

三，有了 WebSocket 之后 ServerPush 并没有非常大的用处。

ServerPush 目前确实没有多大用，但跟 WebSocket 无关。 ServerPush 推送的是资源，必须遵循请求-响应的循环，只能借着对请求的响应推送， PUSH_PROMISE 帧必须在返回响应之前发送，服务器不能随意发起推送流。 ServerPush 目标是替代 HTTP/1 时期为了减少页面时延所普遍采用的资源内联（ inline ）的做法。至于 WebSocket 纯粹是依赖于 HTTP upgrade 的全新协议，目的是双向通讯。实测中它的连通性大概在 50% 左右，一般实战中需要部署 WSS 增加网络穿透能力，以及采用 SSE 、 Pulling 等降级方案。

另外，我补充一点： HTTP/2 的多路复用很有用。 HTTP/1 时期，一个 TCP 连接上同时只能传输一个 HTTP 请求 / 响应。为了增加并发，浏览器都会开启多个 TCP 连接并发获取资源。大部分网站还会对资源进行域名散列，来绕开浏览器对同一域名并发数的限制（实际上， HTTP/1.1 协议 RFC 2616 版中规定了同一域名最多只能有两个并发连接，但几乎没有浏览器按标准实现， RFC 7230 中直接去掉了这个限制）。本地 TCP 连接和本地端口也是一种资源，为了 WEB 性能，想尽办法建立更多的并发连接，是很霸道和不公平的做法。而 HTTP/2 的多路复用可以解决这个问题。

最后，尽管 HTTP/2 协议并没有规定 HTTP/2 一定要基于 TLS 实现，但是 Chrome 和 Firefox 都明确表示只支持 HTTP/2 Over TLS ，鉴于我国目前复杂的网络现状，如果能借 HTTP/2 推广 HTTPS 也是一件好事。

@zhicheng 理由？

@songjiaxin2008 我还没有验证是否成功，不是说只有 Linux 下的 chrome 才支持么？

周杰伦