https://www.nginx.抗投诉服务器com/blog/early-alpha-patch-http2/

目前已经可以在 Nginx 1.9 分支上试验 HTTP/2 的效果。不过如果启用了这个补丁的话：

• 需要配合最新的 OpenSSL 1.0.2 编译安装
• 原来的 SPDY 功能无法同时启用
• 可能会破坏和 PageSpeed 插件的兼容性

用过一阵子了已经，因为不是所有的客户都用支持 http2 的浏览器，并且也不向下兼容 spdy ，所以暂时搁置

必须要用 OpenSSL...那就意味着要抛弃 CHACHA20-POLY1305 要怎么选还真是是纠结...。

需要配合最新的 OpenSSL 1.0.2 编译安装

用了都有一个多月了。
https://imququ.com/post/nginx-http2-patch.html
并不一定需要 openssl ，最新的 libressl 也可以， chcha20 可以继续用。
具体的可以看我的博客。

在这里看到博主了 请问 tcp_fastopen 您是在阿里云什么系统的主机上能成功开启的？

并不看好 HTTP/2 。

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

理由？

貌似是对 server 端有要求 我这样写的 listen ... fastopen=3 ... 这一部分会报错 查过文档是要求 linux kernel 版本高于 3.5


一，把文本协议换成二进制协议并声称减少了流量，并不算是一种进步。在流量宝贵的时期选用文本协议，是有所考量的。相反在这个时代换回二进制协议，不得不说其实是一种退步。
二，把传输层协议放到应用层协议中实现，也不是明智之举。
三，有了 WebSocket 之后 ServerPush 并没有非常大的用处。
四， way too complex 。


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

一个还挺稳定的 HTTP/1.1 vs HTTP/2 速度测试 https://http2.akamai.com/demo


内容是二进制的，但不影响协议是文本协议，关键在于，需要不需要处理协议的时候进行 pack 和 unpack 。把文本变成二进制是肯定可以降低流量的，这点毋庸置疑。但比较可耻的是，他们又 roll 了一套压缩算法 /协议。这真是增加代码复杂度的好办法。同样的，我对 dns 协议中的压缩算法也非常不满意。
如果 HTTP 抛弃 TCP ，那就是一个典型过度工程化的协议。
WebSocket 的优势在于，不需要修改 HTTP 甚至可以完全不依赖 HTTP ，是一个新的，可以用来构建 Web 的协议，缺点在于，必须使用 JavaScript 。但现在我们也没有办法逃避 JavaScript 在 Client Side 的影响力了不是吗。
多路复用这个问题，是一个比较复杂的问题，它很有用并且能提高性能也是毋庸置疑的。只是在以后未必会启用，很可能会像 HTTP Pipeline 一样。
TLS 是个很有意思的话题，几年前大家说 HTTP 就是 HTTP 。现在说 HTTP 大多都会带上 TLS 。
不过我对现有的 PKI 也有槽可吐，比较长，等我写文章吧。
我估计我的 Server 里未来几年都不会考虑实现 HTTP/2 了。


在手机上，打字不方便。就探讨几点：
如果 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 通常被认为是幂等的）。而多路复用没这些问题。

有时间交流，现在能聊得了协议的朋友不多了。。。