V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
NGINX
NGINX Trac
3rd Party Modules
Security Advisories
CHANGES
OpenResty
ngx_lua
Tengine
在线学习资源
NGINX 开发从入门到精通
NGINX Modules
ngx_echo
Livid
V2EX  ›  NGINX

NGINX HTTP/2 Alpha Patch

  •  
  •   Livid · 2015-09-21 21:54:02 +08:00 · 4648 次点击
    这是一个创建于 3111 天前的主题,其中的信息可能已经有所发展或是发生改变。

    https://www.nginx.com/blog/early-alpha-patch-http2/

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

    • 需要配合最新的 OpenSSL 1.0.2 编译安装
    • 原来的 SPDY 功能无法同时启用
    • 可能会破坏和 PageSpeed 插件的兼容性
    15 条回复    2015-09-22 17:18:16 +08:00
    adexbn
        1
    adexbn  
       2015-09-21 22:00:20 +08:00 via iPhone
    用过一阵子了已经,因为不是所有的客户都用支持 http2 的浏览器,并且也不向下兼容 spdy ,所以暂时搁置
    mafuyu
        2
    mafuyu  
       2015-09-21 22:07:16 +08:00
    必须要用 OpenSSL...那就意味着要抛弃 CHACHA20-POLY1305 要怎么选还真是是纠结...。
    ivmm
        3
    ivmm  
       2015-09-21 22:39:58 +08:00
    需要配合最新的 OpenSSL 1.0.2 编译安装
    qgy18
        4
    qgy18  
       2015-09-21 23:02:27 +08:00 via iPhone   ❤️ 1
    用了都有一个多月了。

    https://imququ.com/post/nginx-http2-patch.html

    并不一定需要 openssl ,最新的 libressl 也可以, chcha20 可以继续用。

    具体的可以看我的博客。
    songjiaxin2008
        5
    songjiaxin2008  
       2015-09-21 23:14:09 +08:00
    @qgy18 在这里看到博主了 请问 tcp_fastopen 您是在阿里云什么系统的主机上能成功开启的?
    zhicheng
        6
    zhicheng  
       2015-09-21 23:16:38 +08:00
    并不看好 HTTP/2 。
    qgy18
        7
    qgy18  
       2015-09-21 23:26:13 +08:00 via iPhone
    @songjiaxin2008 我还没有验证是否成功,不是说只有 Linux 下的 chrome 才支持么?
    qgy18
        8
    qgy18  
       2015-09-21 23:26:27 +08:00 via iPhone
    @zhicheng 理由?
    songjiaxin2008
        9
    songjiaxin2008  
       2015-09-21 23:35:20 +08:00
    @qgy18 貌似是对 server 端有要求 我这样写的 listen ... fastopen=3 ... 这一部分会报错 查过文档是要求 linux kernel 版本高于 3.5
    zhicheng
        10
    zhicheng  
       2015-09-21 23:47:50 +08:00
    @qgy18

    一,把文本协议换成二进制协议并声称减少了流量,并不算是一种进步。在流量宝贵的时期选用文本协议,是有所考量的。相反在这个时代换回二进制协议,不得不说其实是一种退步。
    二,把传输层协议放到应用层协议中实现,也不是明智之举。
    三,有了 WebSocket 之后 ServerPush 并没有非常大的用处。
    四, way too complex 。
    qgy18
        11
    qgy18  
       2015-09-22 00:26:44 +08:00   ❤️ 7
    @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 也是一件好事。
    rotoava
        12
    rotoava  
       2015-09-22 09:07:48 +08:00
    一个还挺稳定的 HTTP/1.1 vs HTTP/2 速度测试 https://http2.akamai.com/demo
    zhicheng
        13
    zhicheng  
       2015-09-22 13:57:24 +08:00   ❤️ 1
    @qgy18

    内容是二进制的,但不影响协议是文本协议,关键在于,需要不需要处理协议的时候进行 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 了。
    qgy18
        14
    qgy18  
       2015-09-22 16:47:45 +08:00 via iPhone
    @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 通常被认为是幂等的)。而多路复用没这些问题。
    zhicheng
        15
    zhicheng  
       2015-09-22 17:18:16 +08:00   ❤️ 1
    @qgy18 有时间交流,现在能聊得了协议的朋友不多了。。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5373 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 529ms · UTC 07:34 · PVG 15:34 · LAX 00:34 · JFK 03:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.