从源代码编译 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

TLS1.3/QUIC 是怎样做到 0-RTT 的

发表于2018-03-10由daniel

在《低延迟与用户体验杂谈》中，我们提到了TLS1.3以及QUIC协议可以有效的降低传输层的延迟，改善用户体验。而TLS1.3和QUIC降低用户延迟有一个共同点，那就是在提供同等功能特性下，减少Round-Trip Time (RTT)次数。你甚至会经常听到QUIC和TLS1.3的拥趸说TLS1.3和QUIC可以做到0-RTT，基本消灭了（安全）传输层的延迟。事实真的是这样吗？

TLS RTT

我们先看一下TLS1.2 (以ECDH为例)的建立加密连接的过程:

从上图可以看出，在发送应用数据之前，TLS安全传输层需要经过2-RTT才能完成握手。如果是恢复会话，TLS1.2可以采用Session ID或Session Ticket进行快速握手：

从上图可以看到，在使用Session Ticket的情况下，需要1-RTT。

那么TLS1.3是如何进一步优化的呢？

TLS 1.3完全握手：

在完全握手情况下，TLS 1.3需要1-RTT建立连接。与TLS1.2有两点不同：握手过程中移除了ServerKeyExchange和ClientKeyExchange, DH (Diffie-Hellman) 参数通过 key_share 传输。

TLS1.3恢复会话握手

TLS1.3恢复会话可以直接发送加密后的应用数据，不需要额外的TLS握手。因此，我们常说的TLS1.3 0-RTT握手其实是指恢复加密传输层会话不需要额外的RTT。但是，在第一次进行完全握手时，是需要1-RTT的。

与TLS1.2比较，无论是完全握手还是恢复会话，TLS1.3均比TLS1.2少1-RTT。因此，TLS1.3从被提上draft草案开始获得了各方面的好评。从nginx和Chrome支持此特性的速度可见一斑。

但是TLS1.3也并不完美。TLS 1.3 O-RTT无法保证前向安全性(Forward secrecy). 简单讲就是，如果当攻击者通过某种手段获取到了Session Ticket Key，那么该攻击者可以解密以前的加密数据。

这个问题不是TLS1.3独有，TLS1.2也存在这个问题。对于TLS1.3来说，要缓解该问题可以通过设置ServerConfiguration中的Expiration Date字段，使得与Session Ticket Key相关的DH静态参数在短时间内过期（一般几个小时）。

使用TLS最多的场景是HTTPS和HTTP/2. 以HTTP/2为例，一个完整的 HTTP Request需要经历的RTT如下：

	HTTP/2 over TLS1.2首次连接	HTTP/2 over TLS1.2连接复用	HTTP/2 over TLS1.3首次连接	HTTP/2 over TLS1.3连接复用
DNS解析	1-RTT	0-RTT	1-RTT	0-RTT
TCP握手	1-RTT	0-RTT	1-RTT	0-RTT
TLS握手	2-RTT	1-RTT	1-RTT	0-RTT
HTTP Request	1-RTT	1-RTT	1-RTT	1-RTT
总计	5RTT	2-RTT	4-RTT	1-RTT

从上表可以看出：

首次连接发起HTTP请求是非常昂贵的。因此，如果你是用HTTPS作一些不可告人的代理应用的话，一定尽量保持长连接，避免频繁建立新连接。
连接的multlplexing(多路复用)可以有效减少RTT次数，降低延迟。在连接复用的情况下，TLS1.3将整个http request的RTT降低到了1个，达到理论的最小值。

QUIC RTT

当客户端首次发起QUIC连接时，客户端想服务器发送一个client hello消息，服务器回复一个server reject消息。该消息中有包括server config，类似于TLS1.3中的key_share交换。这需要产生1-RTT. 事实上，QUIC加密协议的作者也明确指出当前的QUIC加密协议是「注定要死掉的」(destined to die), 未来将会被TLS1.3代替。只是在QUIC提出来的时候，TLS1.3还没出生?，这只是一个临时的加密方案。
当客户端获取到server config以后，就可以直接计算出密钥，发送应用数据了，可以认为是0-RTT。密钥推导可以参见Key derivation.
因此，QUIC握手除去首次连接需要产生1-RTT，理论上，后续握手都是0-RTT的。
假设1-RTT=100ms, QUIC建立安全连接连接的握手开销为0ms, 功能上等价于TCP+TLS, 但是握手开销比建立普通的TCP连接延迟都低：

（正常体为首次建立连接的延迟，粗体部分为后续握手的延迟）

HTTP/2 over TLS 1.3 vs QUIC

当前，QUIC普遍的应用场景是 HTTP/2 over QUIC. 我们以一个完整的 HTTP Request需要经历的RTT为例，比较TLS1.3与QUIC的RTT开销：

	HTTP/2 over TLS1.3首次连接	HTTP/2 over TLS1.3连接复用	HTTP/2 over QUIC首次连接	HTTP/2 over QUIC连接复用
DNS解析	1-RTT	0-RTT	1-RTT	0-RTT
TCP握手	1-RTT	0-RTT	–	–
TLS握手	1-RTT	0-RTT	–	–
QUIC握手	–	–	1-RTT	0-RTT
HTTP Request	1-RTT	1-RTT	1-RTT	1-RTT
总计	4RTT	1-RTT	3-RTT	1-RTT

从上表可以看出：HTTP/2 over QUIC相比HTTP/2 over TLS 1.3最大的优势是首次连接是的RTT开销降低了1-RTT(25%)。在连接复用的情况，QUIC的RTT开销与TLS1.3相等。

前面我们提到，QUIC（UDP+QUIC Crypto）在功能层面等价于TCP+TLS, 并且其加密协议(QUIC Crypto)未来会被TLS1.3代替。而在连接复用的情况下QUIC与TLS1.3的RTT开销旗鼓相当，那么是否意味着在HTTP/2的应用场景下，TCP+TLS1.3就可以完全替代QUIC呢？答案是否定的，主要原因如下：

QUIC从数据包级别解决了队头阻塞的问题，而TCP+TLS只能解决http request级别的队头阻塞问题。具体原理可以参见《当我们在谈论HTTP队头阻塞时，我们在谈论什么》.
QUIC与HTTP/2结合更加紧密，比如HTTP/2的stream, frame, Header Compression都可以直接映射到QUIC的stream, packet, Header Compression. 从协议分层看这会使得应用层和传输层紧耦合，但是在HTTP/2这个具体场景下，QUIC可以接管HTTP/2的拥塞控制，相较于HTTP/2 over TLS 1.3会受到TCP和HTTP/2两层的拥塞控制来说，无疑具有更直接有效的控制策略。并且，QUIC的拥塞控制是应用层可插件化的。虽然你也可以为TCP编写拥塞控制模块，但那是一个内核模块，稍不注意就会让系统崩溃。如果你有兴趣的话，实现一个QUIC的BBR拥塞控制模块是很容易的。
QUIC支持连接迁移（Connection Migration），即在客户端切换网络IP以后，也能够保持连接不间断。这对于移动网络这种漫游网络特别友好，再加上QUIC在首次连接上RTT比TLS1.3低25%，因此会有更好的用户体验。虽然Multipath TCP, MPTCP也可以吃支持连接迁移，但这受限于操作系统和网络协议栈，要想普及，任重道远。
QUIC支持Forward Error Correction，利用一定的数据包冗余，提供丢包时恢复丢包数据的能力。减少了包重传的数量，进而减少延迟，提高带宽利用率。如果你使用过kcptun，你会发现它也采用了FEC，对于弱网和高丢包环境下，效果尤其好。

当然，QUIC也是有缺点的。比如很多运营商对UDP的QoS级别是比TCP低的，甚至只允许DNS 53端口的UDP包，其他UDP包都是被封掉的。在IDC中，UDP的优先级一般也比TCP低。因此，即使以后大规模普及QUIC，也不会完全替代TCP+TLS，毕竟需要确保在QUIC不可用时，可以回落到TCP+TLS.

总结

在首次连接的时候，无论是TLS1.3还是QUIC都需要1-RTT，在连接复用的情况下，两者才能做到0-RTT. 在HTTP/2的应用场景中，QUIC可以有效的降低首次连接的RTT次数，并且支持连接迁移、FEC以及更加灵活高效的拥塞控制，因此可以在移动网络、弱网环境提供低延迟的用户体验。

扩展阅读

Golang 获取 goroutine id 完全指南

发表于2018-03-06由daniel

在Golang中，每个goroutine协程都有一个goroutine id (goid)，该goid没有向应用层暴露。但是，在很多场景下，开发者又希望使用goid作为唯一标识，将一个goroutine中的函数层级调用串联起来。比如，希望在一个http handler中将这个请求的每行日志都加上对应的goid以便于对这个请求处理过程进行跟踪和分析。

关于是否应该将goid暴露给应用层已经争论多年。基本上，Golang的开发者都一致认为不应该暴露goid（faq: document why there is no way to get a goroutine ID），主要有以下几点理由：

goroutine设计理念是轻量，鼓励开发者使用多goroutine进行开发，不希望开发者通过goid做goroutine local storage或thread local storage（TLS）的事情；
Golang开发者Brad认为TLS在C/C++实践中也问题多多，比如一些使用TLS的库，thread状态非常容易被非期望线程修改，导致crash.
goroutine并不等价于thread, 开发者可以通过syscall获取thread id，因此根本不需要暴露goid.

官方也一直推荐使用context作为上下文关联的最佳实践。如果你还是想获取goid，下面是我整理的目前已知的所有获取它的方式，希望你想清楚了再使用。

通过stack信息获取goroutine id.
通过修改源代码获取goroutine id.
通过CGo获取goroutine id.
通过汇编获取goroutine id.
通过汇编获取伪goroutine id.

在开始介绍各种方法前，先看一下定义在src/runtime/runtime2.go中保存goroutine状态的g结构：

type g struct {
    // Stack parameters.
    // stack describes the actual stack memory: [stack.lo, stack.hi).
    // stackguard0 is the stack pointer compared in the Go stack growth prologue.
    // It is stack.lo+StackGuard normally, but can be StackPreempt to trigger a preemption.
    // stackguard1 is the stack pointer compared in the C stack growth prologue.
    // It is stack.lo+StackGuard on g0 and gsignal stacks.
    // It is ~0 on other goroutine stacks, to trigger a call to morestackc (and crash).
    stack       stack   // offset known to runtime/cgo
    stackguard0 uintptr // offset known to liblink
    stackguard1 uintptr // offset known to liblink

    _panic         *_panic // innermost panic - offset known to liblink
    _defer         *_defer // innermost defer
    m              *m      // current m; offset known to arm liblink
    sched          gobuf
    syscallsp      uintptr        // if status==Gsyscall, syscallsp = sched.sp to use during gc
    syscallpc      uintptr        // if status==Gsyscall, syscallpc = sched.pc to use during gc
    stktopsp       uintptr        // expected sp at top of stack, to check in traceback
    param          unsafe.Pointer // passed parameter on wakeup
    atomicstatus   uint32
    stackLock      uint32 // sigprof/scang lock; TODO: fold in to atomicstatus
    goid           int64 // goroutine id
    ...

type g struct {

// Stack parameters.

// stack describes the actual stack memory: [stack.lo, stack.hi).

// stackguard0 is the stack pointer compared in the Go stack growth prologue.

// It is stack.lo+StackGuard normally, but can be StackPreempt to trigger a preemption.

// stackguard1 is the stack pointer compared in the C stack growth prologue.

// It is stack.lo+StackGuard on g0 and gsignal stacks.

// It is ~0 on other goroutine stacks, to trigger a call to morestackc (and crash).

stack stack // offset known to runtime/cgo

stackguard0 uintptr // offset known to liblink

stackguard1 uintptr // offset known to liblink

_panic *_panic // innermost panic - offset known to liblink

_defer *_defer // innermost defer

m *m // current m; offset known to arm liblink

sched gobuf

syscallsp uintptr // if status==Gsyscall, syscallsp = sched.sp to use during gc

syscallpc uintptr // if status==Gsyscall, syscallpc = sched.pc to use during gc

stktopsp uintptr // expected sp at top of stack, to check in traceback

param unsafe.Pointer // passed parameter on wakeup

atomicstatus uint32

stackLock uint32 // sigprof/scang lock; TODO: fold in to atomicstatus

goid int64 // goroutine id

...

其中goid int64字段即为当前goroutine的id。

1. 通过stack信息获取goroutine id

package main

import (
    "bytes"
    "fmt"
    "runtime"
    "strconv"
)

func main() {
    fmt.Println(GetGID())
}

func GetGID() uint64 {
    b := make([]byte, 64)
    b = b[:runtime.Stack(b, false)]
    b = bytes.TrimPrefix(b, []byte("goroutine "))
    b = b[:bytes.IndexByte(b, ' ')]
    n, _ := strconv.ParseUint(string(b), 10, 64)
    return n
}

package main

import (

"bytes"

"fmt"

"runtime"

"strconv"

)

func main() {

fmt.Println(GetGID())

}

func GetGID() uint64 {

b := make([]byte, 64)

b = b[:runtime.Stack(b, false)]

b = bytes.TrimPrefix(b, []byte("goroutine "))

b = b[:bytes.IndexByte(b, ' ')]

n, _ := strconv.ParseUint(string(b), 10, 64)

return n

}

原理非常简单，将stack中的文本信息”goroutine 1234″匹配出来。但是这种方式有两个问题：

stack信息的格式随版本更新可能变化，甚至不再提供goroutine id，可靠性差。
性能较差，调用10000次消耗>50ms。

如果你只是想在个人项目中使用goid，这个方法是可以胜任的。维护和修改成本相对较低，且不需要引入任何第三方依赖。同时建议你就此打住，不要继续往下看了。

2. 通过修改源代码获取goroutine id

既然方法1效率较低，且不可靠，那么我们可以尝试直接修改源代码src/runtime/runtime2.go中添加Goid函数，将goid暴露给应用层：

func Goid() int64 {
    _g_ := getg()
    return _g_.goid
}

func Goid() int64 {

_g_ := getg()

return _g_.goid

}

这个方式能解决法1的两个问题，但是会导致你的程序只能在修改了源代码的机器上才能编译，没有移植性，并且每次go版本升级以后，都需要重新修改源代码，维护成本较高。

3. 通过CGo获取goroutine id

那么有没有性能好，同时不影响移植性，且维护成本低的方法呢？那就是来自Dave Cheney的CGo方式：

文件id.c：

#include "runtime.h"

int64 ·Id(void) {
    return g-&gt;goid;
}

#include "runtime.h"

int64 ·Id(void) {

return g->goid;

}

文件id.go:

package id

func Id() int64

package id

func Id() int64

完整代码参见junk/id.

这种方法的问题在于你需要开启CGo, CGo存在一些缺点，具体可以参见这个大牛的cgo is not Go. 我相信在你绝大部分的工程项目中，你是不希望开启CGo的。

4. 通过汇编获取goroutine id

如果前面三种方法我们都不能接受，有没有第四种方法呢？那就是通过汇编获取goroutine id的方法。原理是：通过getg方法（汇编实现）获取到当前goroutine的g结构地址，根据偏移量计算出成员goid int的地址，然后取出该值即可。

项目goroutine实现了这种方法。需要说明的是，这种方法看似简单，实际上因为每个go版本几乎都会有针对g结构的调整，因此goid int64的偏移并不是固定的，更加复杂的是，go在编译的时候，传递的编译参数也会影响goid int64的偏移值，因此，这个项目的作者花了非常多精力来维护每个go版本g结构偏移的计算，详见hack目录。

这个方法性能好，原理清晰，实际使用上稳定性也不错（我们在部分不太重要的线上业务使用了这种方法）。但是，维护这个库也许真的太累了，最近发现作者将这个库标记为“DEPRECATED”，看来获取goroutine id是条越走越远的不归路?

5. 通过汇编获取伪goroutine id

虽然方法4从原理和实际应用上表现都不错，但是毕竟作者弃坑了。回到我们要解决的问题上：我们并不是真的一定要获取到goroutine id，我们只是想获取到goroutine的唯一标识。那么，从这个角度看的话，我们只需要解决goroutine标识唯一性的问题即可。

显然，上面作者也想清楚了这个问题。他新开了一个库go-tls, 这个库实现了goroutine local storage，其中获取goroutine id的方式是：用方法4的汇编获取goroutine的地址，然后自己管理和分配goroutine id。由于它获取到的并不是真正的goroutine id，因此我将之称为伪goroutine id。其实现的核心代码如下：

var (
    tlsDataMap  = map[unsafe.Pointer]*tlsData{}
    tlsMu       sync.Mutex
    tlsUniqueID int64
)

...

func fetchDataMap(readonly bool) *tlsData {
    gp := g.G() // 1. 获取g结构地址

    if gp == nil {
        return nil
    }

    // Try to find saved data.
    needHack := false
    tlsMu.Lock()
    dm := tlsDataMap[gp]

    if dm == nil &amp;&amp; !readonly {
        needHack = true
        dm = &amp;tlsData{
            id:   atomic.AddInt64(&amp;tlsUniqueID, 1), // 2. 分配伪goroutine id
            data: dataMap{},
        }
        tlsDataMap[gp] = dm
    }

    tlsMu.Unlock()

    // Current goroutine is not hacked. Hack it.
    if needHack {
        if !hack(gp) {
            tlsMu.Lock()
            delete(tlsDataMap, gp)
            tlsMu.Unlock()
        }
    }

    return dm
}

var (

tlsDataMap = map[unsafe.Pointer]*tlsData{}

tlsMu sync.Mutex

tlsUniqueID int64

)

...

func fetchDataMap(readonly bool) *tlsData {

gp := g.G() // 1. 获取g结构地址

if gp == nil {

return nil

}

// Try to find saved data.

needHack := false

tlsMu.Lock()

dm := tlsDataMap[gp]

if dm == nil && !readonly {

needHack = true

dm = &tlsData{

id: atomic.AddInt64(&tlsUniqueID, 1), // 2. 分配伪goroutine id

data: dataMap{},

}

tlsDataMap[gp] = dm

}

tlsMu.Unlock()

// Current goroutine is not hacked. Hack it.

if needHack {

if !hack(gp) {

tlsMu.Lock()

delete(tlsDataMap, gp)

tlsMu.Unlock()

}

return dm

}

获取g结构地址。
分配伪goroutine id.

这种方式基本没有什么不能接受的hack实现，从原理上来说也更加安全。但是获取到不是你最开始想要的goroutine id，不知你能否接受?

小结

获取goroutine id是一条不归路，目前也没有完美的获取它的方式。如果你一定要使用goroutine id，先想清楚你要解决的问题是什么，如果没有必要，建议你不要走上这条不归路。尽早在团队中推广使用context, 越早使用越早脱离对goroutine id的留恋和挣扎。

行思錄 | Travel Coder

Arch, Coding, Life

月度归档：2018年03月

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

nginx开启TLS 1.3的前置条件

Dockerfile

Nginx 开启 TLS1.3

验证TLS 1.3

参考资料

TLS1.3/QUIC 是怎样做到 0-RTT 的

TLS RTT

QUIC RTT

HTTP/2 over TLS 1.3 vs QUIC

总结

扩展阅读

Golang 获取 goroutine id 完全指南

1. 通过stack信息获取goroutine id

2. 通过修改源代码获取goroutine id

3. 通过CGo获取goroutine id

4. 通过汇编获取goroutine id

5. 通过汇编获取伪goroutine id

小结

Credit