从源代码编译 nginx docker 镜像开启 TLS 1.3

发表于2018-03-14由daniel

nginx最近更新挺频繁的，其中TLS 1.3和是HTTP/2 Server Push是两个比较有意思的特性。前者可以有效的减少握手次数，降低延迟，尤其在恢复会话时候可以将握手开销降低到 0-RTT，后者则可以通过服务器主动推送资源，可以认为是在资源预加载之上更进一步的「资源主动加载」，有效提高网页性能和用户体验。

考虑到平时自己需要比较频繁的测试不同的nginx的新版本，但是又不想破坏机器本地已经安装好的nginx环境，因此我决定制作一个nginx docker镜像。需要说明的是，dockerhub官方是有一个nginx镜像的，但我们希望自己定制nginx版本和需要开启的模块，因此该镜像并不符合需求。

这里以开启TLS 1.3为例制作一个以ubuntu:16.04为基础镜像的 nginx dockerm镜像。顺便把上次在Ubuntu 14.04开启nginx http2支持的方法中埋的坑填了?

nginx开启TLS 1.3的前置条件

nginx >= 1.13.0
openSSL >= 1.1.1 alpha

openSSL版本有几点点需要注意：

以前可以使用分支tls1.3-draft-18编译支持TLS 1.3，~~但是现在已经merge到1.1.1版本中了，因此，这里不再推荐使用tls1.3-draft-18编译nginx~~. 使用openSSL 1.1.1编译nginx会触发nginx的一个config bug: undefined reference to 'pthread_atfork', 解决办法可以参见这里以及nginx mailing list, 这里暂时回退到使用tls1.3-draft-18.
不要尝试使用tls1.3-draft-19编译nginx, 使用Chrome 64测试无法在nginx 1.13.9上成功开启TLS 1.3, 应该跟Chrome对draft版本的支持有关系。
- 2018-03-14更新：升级到Chrome 65以后，发现默认支持为TLS 1.3 Draft 23, 后面顺带连通config bug一起解决了再更新。
openSSL目前最新版本是OpenSSL_1_1_1-pre2, 还不是stable版本，因此，不要在生产环境中使用。

Dockerfile

FROM ubuntu:16.04

LABEL maintainer="liudanking@gmail.com"

RUN apt-get update

# dependency
RUN set -x \
    &amp;&amp; apt-get install build-essential libpcre3 libpcre3-dev zlib1g-dev unzip git -y

RUN apt-get install wget

# module nginx-ct
RUN set -x  \
    &amp;&amp; wget -O nginx-ct.zip -c https://github.com/grahamedgecombe/nginx-ct/archive/v1.3.2.zip \
    &amp;&amp; unzip nginx-ct.zip

# module ngx_brotli
RUN set -x \
    &amp;&amp; git clone https://github.com/google/ngx_brotli.git \
    &amp;&amp; cd ngx_brotli \
    &amp;&amp; git submodule update --init

# openssl 1.3
RUN set -x \
    &amp;&amp; git clone -b 'OpenSSL_1_1_1-pre2' --single-branch --depth 1 https://github.com/openssl/openssl.git openssl 
    #&amp;&amp; git clone -b tls1.3-draft-18 --single-branch https://github.com/openssl/openssl.git openssl

# build and install nginx
RUN set -x \
    &amp;&amp; wget -c https://nginx.org/download/nginx-1.13.9.tar.gz \
    &amp;&amp; tar zxf nginx-1.13.9.tar.gz \
    &amp;&amp; cd nginx-1.13.9 \
    &amp;&amp; ./configure --add-module=../ngx_brotli --add-module=../nginx-ct-1.3.2 --with-openssl=../openssl --with-openssl-opt='enable-tls1_3 enable-weak-ssl-ciphers' --with-http_v2_module --with-http_ssl_module --with-http_gzip_static_module \
    &amp;&amp; make \
    &amp;&amp; make install 

CMD ["/usr/local/nginx/sbin/nginx", "-g", "daemon off;"]

FROM ubuntu:16.04

LABEL maintainer="liudanking@gmail.com"

RUN apt-get update

# dependency

RUN set -x \

&& apt-get install build-essential libpcre3 libpcre3-dev zlib1g-dev unzip git -y

RUN apt-get install wget

# module nginx-ct

RUN set -x \

&& wget -O nginx-ct.zip -c https://github.com/grahamedgecombe/nginx-ct/archive/v1.3.2.zip \

&& unzip nginx-ct.zip

# module ngx_brotli

RUN set -x \

&& git clone https://github.com/google/ngx_brotli.git \

&& cd ngx_brotli \

&& git submodule update --init

# openssl 1.3

RUN set -x \

&& git clone -b 'OpenSSL_1_1_1-pre2' --single-branch --depth 1 https://github.com/openssl/openssl.git openssl

#&& git clone -b tls1.3-draft-18 --single-branch https://github.com/openssl/openssl.git openssl

# build and install nginx

RUN set -x \

&& wget -c https://nginx.org/download/nginx-1.13.9.tar.gz \

&& tar zxf nginx-1.13.9.tar.gz \

&& cd nginx-1.13.9 \

&& ./configure --add-module=../ngx_brotli --add-module=../nginx-ct-1.3.2 --with-openssl=../openssl --with-openssl-opt='enable-tls1_3 enable-weak-ssl-ciphers' --with-http_v2_module --with-http_ssl_module --with-http_gzip_static_module \

&& make \

&& make install

CMD ["/usr/local/nginx/sbin/nginx", "-g", "daemon off;"]

Nginx 开启 TLS1.3

一个完整的配置模板参考如下：

    server {
        listen       443 ssl http2;
        server_name  localhost;

        ssl_certificate      /usr/local/nginx/conf/ssl/chained.pem;
        ssl_certificate_key  /usr/local/nginx/conf/ssl/domain.key;

        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;

        ssl_protocols   TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
        ssl_ciphers     TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305-D:ECDHE-RSA-CHACHA20-POLY1305-D:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384;
        ssl_prefer_server_ciphers  on;

        location / {
            root   html;
            index  index.html index.htm;
        }
    }

server {

listen 443 ssl http2;

server_name localhost;

ssl_certificate /usr/local/nginx/conf/ssl/chained.pem;

ssl_certificate_key /usr/local/nginx/conf/ssl/domain.key;

ssl_session_cache shared:SSL:1m;

ssl_session_timeout 5m;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305-D:ECDHE-RSA-CHACHA20-POLY1305-D:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384;

ssl_prefer_server_ciphers on;

location / {

root html;

index index.html index.htm;

}

主要新增两个修改：

ssl_protocols添加TLSv1.3.
ssl_ciphers加入TLS13_为前缀的密码套件。

完整项目地址：docker-nginx

验证TLS 1.3

Chrome: 将 chrome://flags/ 中的 Maximum TLS version enabled 改为 Enabled (Draft).

如果你刚刚升级到了Chrome 65，选项中开启TLS1.3有三个选项：Enabled(Experiment 2), Enabled(Draft 22), Enabled (Draft 23). 同时很遗憾的告诉你，本文中使用的是Draft 18编译nginx，因此无法配合Chrome 65无法开启TLS1.3，请下面介绍Firefox的开启方法测试TLS1.3?

Firefox: 将 about:config 中的 security.tls.version.max 改为 4.

以Chrome 64为例，如果开启成功后Protocol显示TLS 1.3:

你也可以访问tls.liudanking.com来测试自己的浏览器是否已经成功开启TLS 1.3.

参考资料

本博客开始支持 TLS 1.3

Ubuntu 14.04开启nginx http2支持的方法

发表于2018-03-01由daniel

再过不到两个月，Ubuntu18.04就要出来了，但是手上还有一些老机器还停留在14.04?：

Ubuntu 18.04 release date:

30th November: Feature Definition Freeze
4th January: Alpha 1 release
1st February: Alpha 2 release
1st March: Feature Freeze
8th March: First beta release
5th April: Final beta release
19th April: Final Freeze
26th April: Stable Ubuntu 18.04 LTS release

Ubuntu 18.04 release date:

30th November: Feature Definition Freeze

4th January: Alpha 1 release

1st February: Alpha 2 release

1st March: Feature Freeze

8th March: First beta release

5th April: Final beta release

19th April: Final Freeze

26th April: Stable Ubuntu 18.04 LTS release

没有足够的时间和动力来升级这几台老机器，但是一些常用的软件准备顺手升级一下。最基本的自然是升级nginx支持http2. http2的优势可以参见《当我们在谈论HTTP队头阻塞时，我们在谈论什么？》以及《低延迟与用户体验杂谈》。

Ubuntu 14.04开启nginx http2支持的前置条件

nginx >=1.9.5
openSSL >= 1.0.2

第一个条件大家一般都不会漏掉。但是第二个条件一般是http2无法成功开启时才发现。这是因为随14.04一起分发的openSSL版本是1.0.1f. 那么要开启http2支持，有两种方式：

使用他人编译好的ngingx with http2 support package安装；
升级本地openSSL版本，然后从源码编译安装。

而随Ubuntu 18.04一起分发的openSSL版本为1.1.0g, 因此不存在这个问题。

使用packaege安装（懒人专用）

这里需要注意一下，很多为提供14.04提供nginx安装包的源虽然可以让你安装更高版本的nginx，但是大多是使用openSSL 1.0.1编译的，因此无法支持http2, 比如jessis, nginx mainline为14.04提供的安装包是使用1.0.1编译的，因此不支持http2的。这里我们使用ondrej提供的源。

卸载已经安装的nginx（会保留配置文件，take is easy）:

sudo apt-get remove nginx nginx-common

1 2	sudo apt-get remove nginx nginx-common

添加ondrej nginx安装源：

sudo add-apt-repository ppa:ondrej/nginx

1 2	sudo add-apt-repository ppa:ondrej/nginx

如果出现如下错误：

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 92: ordinal not in range(128)

1 2	UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 92: ordinal not in range(128)

应该是终端编码问题，尝试使用LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/nginx解决。

更新源，并安装：

sudo apt-get update
sudo apt-get install nginx

sudo apt-get update

sudo apt-get install nginx

从源码安装

修改nginx配置开启http2

设置nginx支持http2最关键是在https端口添加http2指令：

listen 443 ssl http2;

1 2	listen 443 ssl http2;

一个网站的参考配置模板如下：

server {
  listen              443 ssl http2;
  ssl_certificate     your_chained.pem;
  ssl_certificate_key your_domain.key;
  ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers         HIGH:!aNULL:!MD5;

  server_name your_domain.com;

  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://127.0.0.1:18010;
  }
}

server {

listen 443 ssl http2;

ssl_certificate your_chained.pem;

ssl_certificate_key your_domain.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers HIGH:!aNULL:!MD5;

server_name your_domain.com;

location / {

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_pass http://127.0.0.1:18010;

}

小结

nginx开启http2的支持不要忘记了对openSSL最低版本的要求。其实http2已经不再时髦啦，http2+TLS1.3才是未来，可以参见《低延迟与用户体验杂谈》。后面会讲讲docker+nginx开启http2和TLS1.3的方式，这种方式即可以方便的尝试各个nginx版本，同时也不会破坏本地的nginx环境。

低延迟与用户体验杂谈

发表于2018-02-27由daniel

最近在做系统设计梳理的时候，明显感觉到「低延迟」已经成为被提及越来越频繁、考量权重越来越大的因素。并且，越是靠用户近的系统，对延迟越敏感，对用户体验影响越大，对低延迟要求越高。

HTTP/2如今（2018.02）已经逐渐普及，其设计的第一目标就是降低延迟。主要采用了两个手段来解决：

TCP连接复用。连接复用减少了TCP每次握手带来的延迟，同时避免了每次新建TCP连接的窗口慢启动带来的数据吞吐开启延迟。
使用数据分帧解决队头阻塞问题。当然，这个问题HTTP/2解决得不彻底，具体可以参见《当我们在谈论HTTP队头阻塞时，我们在谈论什么？》了解细节。

HTTP/2毕竟只能解决应用层的低延迟问题。如果要继续降级延迟，就需要下潜到传输层。因此，Google的QUIC和TLS 1.3应运而生。QUIC目前主要是Google主导，除去其自家的服务，如Google搜索首页，G+等，支持的网站还非常少。TLS 1.3则由标准化组织加持，目前在最新的OpenSSL、nginx已经支持。TLS 1.3能够做到新连接3RTT，恢复连接2RTT（TLS 1.2分别是4RTT, 3RTT；而2RTT已经与http的RTT持平！），的确非常吸引人。

回顾WEB技术过去十几年的发展，很多的特性引入和改进都是基于降低延迟。有些是技术层面的，比如上面提到的HTTP/2的低延迟设计、DNS查询缓存、HTTP1.1并发多个TCP连接请求资源、雪碧图等；有些是用户体验层面的，比如异步加载/预加载js资源、优先加载影响首屏渲染的CSS资源、避免使用大表布局、图片渐变加载、过渡动画等。

而这些年技术层面的发展其实都是受物理定律限制的。祭出程序员延迟心经Latency Numbers Every Programmer Should Know:

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
Disk seek                           10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from disk    20,000,000   ns   20,000 us   20 ms  80x memory, 20X SSD
Send packet CA-&gt;Netherlands-&gt;CA    150,000,000   ns  150,000 us  150 ms

Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Credit
------
By Jeff Dean:               http://research.google.com/people/jeff/
Originally by Peter Norvig: http://norvig.com/21-days.html#answers

Contributions
-------------
Some updates from:       https://gist.github.com/2843375
'Humanized' comparison:  https://gist.github.com/2843375
Visual comparison chart: http://i.imgur.com/k0t1e.png
Animated presentation:   http://prezi.com/pdkvgys-r0y6/latency-numbers-for-programmers-web-development/latency.txt

Latency Comparison Numbers

--------------------------

L1 cache reference 0.5 ns

Branch mispredict 5 ns

L2 cache reference 7 ns 14x L1 cache

Mutex lock/unlock 25 ns

Main memory reference 100 ns 20x L2 cache, 200x L1 cache

Compress 1K bytes with Zippy 3,000 ns 3 us

Send 1K bytes over 1 Gbps network 10,000 ns 10 us

Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD

Read 1 MB sequentially from memory 250,000 ns 250 us

Round trip within same datacenter 500,000 ns 500 us

Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory

Disk seek 10,000,000 ns 10,000 us 10 ms 20x datacenter roundtrip

Read 1 MB sequentially from disk 20,000,000 ns 20,000 us 20 ms 80x memory, 20X SSD

Send packet CA->Netherlands->CA 150,000,000 ns 150,000 us 150 ms

Notes

-----

1 ns = 10^-9 seconds

1 us = 10^-6 seconds = 1,000 ns

1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Credit

------

By Jeff Dean: http://research.google.com/people/jeff/

Originally by Peter Norvig: http://norvig.com/21-days.html#answers

Contributions

-------------

Some updates from: https://gist.github.com/2843375

'Humanized' comparison: https://gist.github.com/2843375

Visual comparison chart: http://i.imgur.com/k0t1e.png

Animated presentation: http://prezi.com/pdkvgys-r0y6/latency-numbers-for-programmers-web-development/latency.txt

软件工程师无论是做什么职位和方向，心里都应该对此有B树。

有了这些当前人类所认识的物理极限，才能做到在「在边界内做事情」(这句话不是我说的，第一次看到这句话是吴军老师的《硅谷来信》)。

举个例子，当前人类认知范围内最快的速度是光速，这是一个上限，而广泛使用的光纤通信速度大概是光速的2/3。那么，要想优化上海到加州的网络延迟，无论你如何优化线缆布设以及质量，RTT都不可能低于127ms. 因此，如你所见，这些年虽然新架设了不少新的跨太平洋光缆，但是最优网络延迟没有什么太大变化，反倒是这些光缆带来的扩容让网络拥塞得到了缓解，让我们感觉出口网络「好像」更快了。

那么在光速这个物理边界的限制下，我们要如何降低延迟呢？显然，固定的两点之间的网络延迟是无法突破该边界的（这里不讨论空间扭曲力场?‍♀️）。但是，很多时候，我们要解决的问题是「让用户感觉延迟低」就可以了。

在这个思想下，CDN应运而生。将内容分发到距离用户近的网络节点来降低用户访问延迟。这个idea非常简单，甚至简陋，但是非常有效，并且廉价。

顺着这个思路下去，如果把算力分发到距离用户近的节点，那是不是也可以让用户觉得计算任务也变快了呢？在一定程度上，这是可以做到的。比如，我们使用了数十年运行于浏览器的javascript，以及我们的多IDC、多主架构方案，都有这方面的考量。近来流行的serverless、边缘计算其实也可以是认为是将算力部署到离用户尽可能近的物理位置或业务流程中。

有时候，技术参数指标的提升在短期内是难以低成本解决的。这个时候，尽量避免死磕参数，投入100%的精力去换取1%的性能提升。可以尝试从设计交互上给用户形成反应很快的体验，降低体感延迟。比如，1）耗时的任务后台化并给出进度条；2）区块处理的逻辑任务尝试修改成流处理，加速部分处理结果的输出，典型应用如以视频直播服务为代表的流媒体服务全力优化首屏播放延迟；批处理任务每处理完一个子任务就反馈结果等。

不仅软件系统的延迟影响着用户体验，硬件更是如此。现在人们普遍认为iPhone的用户体验是优于安卓的。因素有很多，那些复杂的系统参数普通用户未必搞得懂，但是很多用户却承认在滑动屏幕的时候iPhone比安卓更加「跟手指」，打开应用也「感觉更快」。「跟手指」这个体验跟苹果的软件+硬件的技术优化有关，目前安卓阵营也没有赶上。打开app快则是典型的交互优化：苹果打开app未必真的比安卓快，但是从点击app图标到显示story board的确非常快。无论苹果是否鸡贼，至少从这个层面看，它的确是非常了解延迟与用户体验之间的奥义的。至于苹果每次升级系统「故意」让老设备变卡……咳，咳，同学，你怎么有又抬杠呢?

喜欢汽车并且喜欢驾驶的朋友一定知道甚至深入研究过这几款车：马自达3/6/BRZ/86-宝马M2/M4-保时捷718/911。排名分先后，每一辆都是不同级别的驾驶者之车，也是很多玩车朋友的玩车升级路线。这些车都是「运动取向」，这是一个非常抽象的概念，普通消费者未必明白，但是你会发现他们的消费者大多会用「操控好」「响应快」来评价这些车。如果你是参数党，你会发现其实这些车在同级别中都不是最好的，但却是给人愉悦感最强的。

由物及人，当上司交给你一个任务的时候，有反馈好过无反馈，快反馈好过慢反馈。

总结

在节奏日益变快的今天，低延迟很多时候意味着良好的用户体验。而做到低延迟可以通过技术优化，也可以通过一些产品的交互方式和有选择的强调某些方面来让用户感觉很快。内容比较分散，但是都是顺着这根主线，希望你也有所思考和收获。

参考文献

Introducing Zero Round Trip Time Resumption (0-RTT)

行思錄 | Travel Coder

Arch, Coding, Life

标签归档：http2

从源代码编译 nginx docker 镜像开启 TLS 1.3

nginx开启TLS 1.3的前置条件

Dockerfile

Nginx 开启 TLS1.3

验证TLS 1.3

参考资料

Ubuntu 14.04开启nginx http2支持的方法

Ubuntu 14.04开启nginx http2支持的前置条件

使用packaege安装（懒人专用）

从源码安装

修改nginx配置开启http2

小结

低延迟与用户体验杂谈

总结

参考文献