标签 标准库 下的文章

Go 1.22新特性前瞻

本文永久链接 – https://tonybai.com/2023/12/25/go-1-22-foresight

美国时间2023年12月20日,Go官方宣布Go 1.22rc1发布,开启了为期2个多月的、常规的公测之旅,Go 1.22预计将于2024.2月份正式发布!

除了在官网下载Go 1.22rc1版本进行新特性体验之外,我们还可以通过在线的Go Playground选择“Go dev branch”来体验(相比下载安装,在线版本体验会有一些局限):

注:关于Go的多种安装方法,《Go语言第一课》专栏有系统全面的讲解,欢迎订阅阅读。

本文将和大家一起看看Go 1.22都会带来哪些新特性。不过由于目前为时尚早,下面列出的有些变化最终不一定能进入到Go 1.22的最终版本中,所以切记一切变更点要以最终Go 1.22版本发布时为准。

1. 语言变化

Go 1.22的语言特性变化主要是围绕for loop的

1.1 loopvar试验特性转正

Go 1.21版本中,作为试验特性loopvar在Go 1.22中正式转正。如果你还不知道这个特性是啥,我们来看一下下面这个最能说明问题的示例:

// go1.22-foresight/lang/for-range/for_range.go

package main

import (
    "fmt"
    "sync"
)

func main() {
    sl := []int{11, 12, 13, 14, 15}
    var wg sync.WaitGroup
    for i, v := range sl {
        wg.Add(1)
        go func() {
            fmt.Printf("%d : %d\n", i, v)
            wg.Done()
        }()
    }
    wg.Wait()
}

我们分别用Go 1.22rc1和Go 1.21.0来运行上面这段代码:

// 使用go 1.22rc1的运行结果:

$go run for_range.go
4 : 15
1 : 12
0 : 11
3 : 14
2 : 13

// 使用go 1.21.0的运行结果:
$go run for_range.go
4 : 15
4 : 15
4 : 15
4 : 15
4 : 15

之所以存在差异,是因为Go 1.22版本开始,for range语句中声明的循环变量(比如这里的i和v)不再是整个loop一份(loop var per loop),而是每次iteration都会有自己的变量(loop var per-iteration),这样在Go 1.22中,for range中的goroutine启动的闭包函数中捕获的变量是loop var per-iteration,这样才会输出5个不同的索引值和对应的切片值。

注:关于Go 1.22版本之前的for range的坑,《Go语言第一课》专栏有图文并茂的原理讲解,欢迎订阅阅读。

那传统的3-clause的for loop呢?其中的循环变量的语义是否也发生变化了呢?我们看下面示例:

// go1.22-foresight/lang/for-range/classic_for_loop.go

package main

import (
    "fmt"
    "sync"
)

func main() {
    sl := []int{11, 12, 13, 14, 15}
    var wg sync.WaitGroup
    for i := 0; i < len(sl); i++ {
        wg.Add(1)
        go func() {
            v := sl[i]
            fmt.Printf("%d : %d\n", i, v)
            wg.Done()
        }()
    }
    wg.Wait()
}

我们依然分别用Go 1.22rc1和Go 1.21.0版本运行这段代码,得到的结果如下:

// 使用go 1.22rc1的运行结果:

$go run classic_for_loop.go
0 : 11
4 : 15
2 : 13
3 : 14
1 : 12

// 使用go 1.21.0的运行结果:

$go run classic_for_loop.go
panic: runtime error: index out of range [5] with length 5

goroutine 20 [running]:
main.main.func1()
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:14 +0xc9
created by main.main in goroutine 1
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:13 +0x7f
panic: runtime error: index out of range [5] with length 5

goroutine 19 [running]:
main.main.func1()
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:14 +0xc9
created by main.main in goroutine 1
    /Users/tonybai/test/go/go1.22-foresight/lang/for-range/classic_for_loop.go:13 +0x7f
exit status 2

从输出结果来看,3-clause的for语句中声明的循环变量也变成了loop var per-iteration了。

在Go 1.22之前,go vet工具在遇到像上面代码那样在闭包中引用循环变量的情况时会给出警告,但由于Go 1.22的这个语义修正,go vet对于Go 1.22及以后版本(根据go.mod中的指示)的类似Go代码将不再报错。

不过就像Russ Cox在spec: less error-prone loop variable scoping这一issue中提及那样,该特性落地可能会带来不兼容问题,即对存量代码行为的破坏性改变。为此Go团队提供了一个名为bisect的工具,该工具可以检测出存量代码在for loop语义发生变更后是否会导致问题。不过该工具似乎只能与go test一起使用,也就是说你只能对那些被Go测试覆盖到的for loop进行检测。

目前spec: less error-prone loop variable scoping这一issue还处于open状态,也没有放入Go 1.22 milestone中,不知道后续是否还会存在变数!

1.2 range支持整型表达式

在Go 1.22版本中,for range后面的range表达式除了支持传统的像数组、切片、map、channel等表达式外,还支持放置整型表达式,比如下面这个例子:

// lang/range-expr-support-integer/main.go

func main() {
    n := 5
    for i := range n {
        fmt.Println(i)
    }
}

我们知道:for range会在执行伊始对range表达式做一次求值,这里对n求值结果为5。按照新增的for range后接整型表达式的语义,对于整数值n,for range每次迭代值会从0到n-1按递增顺序进行。上面代码中的for range会从0迭代到4(5-1),我们执行一下上述代码就可以印证这一点:

$go run main.go
0
1
2
3
4

如果n <= 0,则循环不运行任何迭代。

这个新语法特性,可以理解为是一种“语法糖”,是下面等价代码的“语法糖”:

for i := 0; i < 5; i++ {
    fmt.Println(i)
}

不过,迭代总是从0开始,似乎限制了该语法糖的使用范围。

1.3 试验特性:range-over-function iterators

在for range支持整型表达式的时候,Go团队也考虑了增加函数迭代器(iterator),不过前者语义清晰,实现简单。后者展现形式、语义和实现都非常复杂,于是在Go 1.22中,函数迭代器以试验特性提供,通过GOEXPERIMENT=rangefunc可以体验该功能特性。

在没有函数迭代器之前,我们实现一个通用的反向迭代切片的函数可能是像这样:

// lang/range-over-function-iterator/backward_iterate_slice_old.go

func Backward(s []E) func(func(int, E) bool) {
    return func(yield func(int, E) bool) {
        for i := len(s)-1; i >= 0; i-- {
            if !yield(i, s[i]) {
                return
            }
        }
        return
    }
}

下面是在Go 1.21.0版本中使用上面Backward函数的方式:

// lang/range-over-function-iterator/backward_iterate_slice_old.go

func main() {
    sl := []string{"hello", "world", "golang"}
    Backward(sl)(func(i int, s string) bool {
        fmt.Printf("%d : %s\n", i, s)
        return true
    })
}

我们用Go 1.21.0运行一下上述示例:

$go run backward_iterate_slice_old.go
2 : golang
1 : world
0 : hello

在以前版本中,这种对切片、数组或map中进行元素迭代的情况在实际开发中非常常见,也比较模式化,但基于目前语法,使用起来非常不便。于是Go团队提出将它们与for range结合在一起的提案。有了range-over-function iterator机制后,我们就可以像下面这样使用Backward泛型函数了:

// lang/range-over-function-iterator/backward_iterate_slice_new.go

func main() {
    sl := []string{"hello", "world", "golang"}
    for i, s := range Backward(sl) {
        fmt.Printf("%d : %s\n", i, s)
    }
}

相比于上面的老版本代码,这也的代码更简洁清晰了,使用Go 1.22rc1的运行结果也与老版本别无二致:

$GOEXPERIMENT=rangefunc  go run backward_iterate_slice_new.go
2 : golang
1 : world
0 : hello

但代价就是要理解什么样原型的函数才能与for range一起使用实现函数迭代,这的确有些复杂,本文就不展开说了,有兴趣的童鞋可以先看看有关range-over-function iterator的wiki先行了解一下。

2. 编译器、运行时与工具链

2.1 继续增强PGO优化

Go 1.20版本引入PGO(profile-guided optimization)后,PGO这种优化技术带来的优化效果就得到了持续的提升:Go 1.20实测性能提升仅为1.05%;Go 1.21版本发布时,官方的数据是2%~7%,而Go 1.21编译器自身在PGO优化过后编译速度提升约6%。

在Go 1.22中,官方给出的数字则是2%~14%,这14%的提升想必是来自Google内部的某个实际案例。

2.2 inline和devirtualize

在Go 1.22中,Go编译器可以更灵活的运用devirtualize和inline对代码进行优化了。

在面向对象的编程中,虚拟函数是一种在运行时动态确定调用的函数。当调用虚拟函数时,编译器通常会为其生成一段额外的代码,用于在运行时确定要调用的具体函数。这种动态调度的机制使得程序可以根据实际对象类型来执行相应的函数,但也带来了一定的性能开销。通过devirtualize优化技术,编译器会尝试在编译时确定调用的具体函数,而不是在运行时进行动态调度。这样可以避免运行时的开销,并允许编译器进行更多的优化

对应到Go来说,就是在编译阶段将使用接口进行的方法调用转换为通过接口的实际类型的实例直接调用该方法

注:我的《Go语言精进之路》一书中有对通过接口调用方法的原理的详尽说明,欢迎阅读。

关于内联优化,今年Austin Clements发起了inline大修项目,对Go编译器中的内联优化过程进行全面调整,目标是在Go 1.22中拥有更有效的、具有启发能力的内联,为后续内联的进一步增强奠定基础。该大修的成果目前以GOEXPERIMENT=newinliner试验特性的形式在Go 1.22中提供。

2.3 运行时

运行时的变化主要还是来自GC

Go 1.22中,运行时会将基于类型的垃圾回收的元数据放在每个堆对象附近,从而可以将Go程序的CPU性能提高1-3%。同时,通过减少重复的元数据的优化,内存开销也将降低约1%。不确定减少重复元数据(metadata)这一优化是否来自对unique包的讨论

2.4 工具链

在Go工具链改善方面,首当其冲的要数go module相关工具了。

在Go 1.22中,go work增加了一个与go mod一致的特性:支持vendor。通过go work vendor,可以将workspace中的依赖放到vendor目录下,同时在构建时,如果module root下有vendor目录,那么默认的构建是go build -mod=vendor,即基于vendor的构建。

go mod init在Go 1.22中将不再考虑GOPATH时代的包依赖工具的配置文件了,比如Gopkg.lock。在Go 1.22版本之前,如果go module之前使用的是类似dep这样的工具来管理包依赖,go mod init会尝试读取dep配置文件来生成go.mod。

go vet工具取消了对loop变量引用的警告,增加了对空append的行为的警告(比如:slice = append(slice))、增加了deferring time.Since的警告以及在log/slog包的方法调用时key-value pair不匹配的警告。

3. 标准库

最后,我们来看看标准库的变化。每次Go发布新版本,标准库都是占更新的大头儿,这里无法将所有变更点一一讲解,仅说说几个重要的变更点。

3.1 增强http.ServerMux表达能力

Go内置电池,从诞生伊始就内置了强大的http库,不过长期以来http原生的ServeMux表达能力比较单一,不支持通配符等,这也是Go社区长期以来一直使用像gorilla/muxhttprouter等第三方路由库的原因。

今年log/slog的作者Jonathan Amsterdam又创建了新的提案:net/http: enhanced ServeMux routing,提高http.ServeMux的表达能力。在新提案中,新的ServeMux将支持如下路由策略(来自http.ServeMux的官方文档):

  • “/index.html”路由将匹配任何主机和方法的路径”/index.html”;
  • “GET /static/”将匹配路径以”/static/”开头的GET请求;
  • “example.com/”可以与任何指向主机为”example.com”的请求匹配;
  • “example.com/{$}”会匹配主机为”example.com”、路径为”/”的请求,即”example.com/”;
  • “/b/{bucket}/o/{objectname…}”匹配第一段为”b”、第三段为”o”的路径。名称”bucket”表示第二段,”objectname”表示路径的其余部分。

下面就是基于上面的规则编写的示例代码:

// lib/servemux/main.go

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/index.html", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match /index.html`)
    })
    mux.HandleFunc("GET /static/", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match "GET /static/"`)
    })
    mux.HandleFunc("example.com/", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match "example.com/"`)
    })
    mux.HandleFunc("example.com/{$}", func(w http.ResponseWriter, req *http.Request) {
        fmt.Fprintln(w, `match "example.com/{$}"`)
    })
    mux.HandleFunc("/b/{bucket}/o/{objectname...}", func(w http.ResponseWriter, req *http.Request) {
        bucket := req.PathValue("bucket")
        objectname := req.PathValue("objectname")
        fmt.Fprintln(w, `match /b/{bucket}/o/{objectname...}`+":"+"bucket="+bucket+",objectname="+objectname)
    })

    http.ListenAndServe(":8080", mux)
}

我们使用curl对上述示例进行一个测试(前提是在/etc/hosts中设置example.com为127.0.0.1):

$curl localhost:8080/index.html
match /index.html

$curl example.com:8080/static/abc
match "example.com/"

$curl localhost:8080/static/abc
match "GET /static/"

$curl example.com:8080/
match "example.com/{$}"

$curl example.com:8080/b/mybucket/o/myobject/tonybai
match "example.com/"

$curl localhost:8080/b/mybucket/o/myobject/tonybai
match /b/{bucket}/o/{objectname...}:bucket=mybucket,objectname=myobject/tonybai

从测试情况来看,不同路由设置之间存在交集,这就需要路由匹配优先级规则。新版Go ServeMux规定:如果一个请求有两个或两个以上的模式匹配,则更具体(specific)的模式优先。如果P1符合P2请求的严格子集,也就是说,如果P2符合P1及更多的所有请求,那么P1就比P2更具体。

举个例子:”/images/thumbnails/”比”/images/”更具体,因此两者都可以注册。前者匹配以”/images/thumbnails/”开头的路径,后者则匹配”/images/”子树中的任何其他路径。

如果两者都不更具体,那么模式就会发生冲突。为了向后兼容,这一规则有一个例外:如果两个模式发生冲突,而其中一个模式有主机(host),另一个没有,那么有主机的模式优先(比如上面测试中的第二次curl执行)。如果通过ServeMux.Handle或ServeMux.HandleFunc设置的模式与另一个已注册的模式发生冲突,这些函数就会panic。

增强后的ServeMux可能会影响向后兼容性,使用GODEBUG=httpmuxgo121=1可以保留原先的ServeMux行为。

3.2 增加math/rand/v2包

在日常开发中,我们多会在生成随机数的场景下使用math/rand包,其他时候使用的较少。但Go 1.22中新增了math/rand/v2包,我之所以将这个列为Go 1.22版本标准库的一次重要变化,是因为这是标准库第一次为某个包建立v2版本包,按照Russ Cox的说法,这次v2包的创建,为标准库中的其他可能的v2包树立了榜样。创建math/rand/v2可以使Go团队能够在一个相对不常用且风险较低的包中解决工具问题(如gopls、goimports等对v2包的支持),然后再转向更常用、风险更高的包,如sync/v2或encoding/json/v2等。

新增rand/v2包的直接原因是清理math/rand并修复其中许多悬而未决的问题,特别是使用过时的生成器、慢速算法以及与crypto/rand冲突的问题,这里就不针对v2包举具体的示例了,对该包感兴趣的同学可以自行阅读该包的在线文档,并探索如何使用v2包。

同时,该提案也为标准库中的v2包的创建建立了一种模式,即v2包是原始包的子目录,并且以原始包的API为起点,每个偏离点都要有明确的理由。

想当初,go module刚落地到Go中时,Go module支持两种识别major的两种方式,一种是通过branch或tag号来识别,另外一种就是利用vN目录来定义新包。当时还不是很理解为什么要有vN目录这种方式,现在从math/rand/v2包的增加来看,足以体现出当初module设计时的前瞻性考量了。

3.3 大修Go execution tracer

Go Execution Tracer是解决Go应用性能方面“疑难杂症”的杀手锏级工具,它可以提供Go程序在一段时间内发生的情况的即时视图。这些信息对于了解程序随时间推移的行为非常宝贵,可辅助开发人员对应用进行性能改进。我曾在《通过实例理解Go Execution Tracer》中对其做过系统的说明。

不过当前版本的Go Execution Tracer在原理和使用方面还存在诸多问题,Google的Michael Knyszek在年初发起了Execution tracer overhaul的提案,旨在对Go Execution Tracer进行改进,使Go Execution Tracer可扩展到大型Go部署的Go执行跟踪。具体目标如下:

  • 使跟踪解析所需的内存占用量仅为当前的一小部分。
  • 支持可流式传输的跟踪,以便在无需存储的情况下进行分析。
  • 实现部分自描述的跟踪,以减少跟踪消费者的升级负担。
  • 修复长期存在的错误,并提供一条清理实现的路径。

在近一年的时间里,Knyszek与Felix Geisendorfer、Nick Ripley、Michael Pratt等一起实现了该提案的目标。

鉴于篇幅,这里就不对新版Tracer的使用做展开说明,有兴趣的童鞋可结合《通过实例理解Go Execution Tracer》中的使用方法自行体验新版Tracer。

注:新版Tracer的设计文档 – https://go.googlesource.com/proposal/+/ac09a140c3d26f8bb62cbad8969c8b154f93ead6/design/60773-execution-tracer-overhaul.md

3.4 其他

Go 1.4版本以来,syscall包新特性就已经被冻结,并在Go 1.11版本中被标记为不推荐使用(deprecate)。Go团队推荐gopher使用golang.org/x/sys/unix或golang.org/x/sys/windows。syscall包的大多数功能都能被golang.org/x/sys包替代,除了下面这几个:

syscall.SysProcAttr(类型os/exec.Cmd.SysProcAttr)
syscall.Signal(参考文献os.Signal)
syscall.WaitStatus(参考文献os.(*ProcessState).Sys)
syscall.Stat_t
... ...

由于syscall包已经弃用,IDE等工具在开发人员使用上述内容时总是得到警告!这引发了众多开发人员的抱怨。为此,在Go 1.22版本中,syscall取消了弃用状态,但其功能特性依旧保持冻结,不再添加新特性。

  • TCPConn to UnixConn:支持zerocopy

gnet作者Andy Pan的提案:TCPConn to UnixConn:支持zerocopy在Go 1.22落地,具体内容可以看一下原始提案issue

  • 新增go/version包

在Go 1.21版本发布后,Go团队对Go语言的版本规则做了调整,并明确了Go语言的向前兼容性和toolchain规则,Go 1.22中增加go/version包实现了按照上述版本规则的Go version判断,这个包既用于go工具链,也可以用于Gopher自行开发的工具中。

4. 小结

Go 1.22版本具有至少两点重要的里程碑意义:

  • 通过对loopvar语义的修正,开启了Go已有“语法坑”的fix之路
  • 通过math/rand/v2包树立了Go标准库建立vN版本的模式

“语法坑”fix是否能得到社区正向反馈还是一个未知数,其导致的兼容性问题势必会成为Go社区在升级到Go 1.22版本的重要考虑因素,即便决定升级到Go 1.22,严格的代码审查和测试也是必不可少的。

最后,感谢Go团队以及所有Go 1.22贡献者做出的伟大工作!

文本涉及的源码可以在这里下载。

5. 参考资料

-Go 1.22 Milestone – https://github.com/golang/go/milestone/298


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go TLS服务端绑定证书的几种方式

本文永久链接 – https://tonybai.com/2023/10/13/multiple-ways-to-bind-certificates-on-go-tls-server-side

随着互联网的发展,网站提供的服务类型和规模不断扩大,同时也对Web服务的安全性提出了更高的要求。TLS(Transport Layer Security)已然成为Web服务最重要的安全基础设施之一。默认情况下,一个TLS服务器通常只绑定一个证书,但当服务复杂度增加时,单一证书已然难以满足需求。这时,服务端绑定多个TLS证书就成为一个非常实用的功能。

Go语言中的net/http包和tls包对TLS提供了强大的支持,在密码学和安全专家Filippo Valsorda的精心设计下,Go提供了多种TLS服务端绑定证书的方式,本文将详细探讨服务端绑定TLS证书的几种方式,包括绑定单个证书、多个证书、自定义证书绑定逻辑等。我会配合示例代码,了解每种方式的使用场景、实现原理和优缺点。

注:本文假设读者已熟悉基本的TLS使用方法,并具备Go语言编程经验。如果你不具备Go语言基础知识,可以将学习我撰写的极客时间专栏《Go语言第一课》作为你入门Go的起点。

1. 热身:制作证书

为了后续示例说明方便,我们先来把示例所需的私钥和证书都做出来,本文涉及的证书以及他们之间的签发关系如下图:

注:示例使用的自签名根证书。

从图中我们看到,我们证书分为三个层次,最左边是CA的根证书(root certificate,比如ca-cert.pem),之后是根CA签发的中间CA证书(intermediate certificate,比如inter-cert.pem),从安全和管理角度出发,真正签发服务器证书的都是这些中间CA;最右侧则是由中间CA签发的叶子证书(leaf certificate,比如leaf-server-cert.pem),也就是服务器配置的服务端证书(server certificate),我们为三个不同域名创建了不同的服务器证书。

在这里,我们制作上述证书没有使用类似openssl这样的工具,而是通过Go代码生成的,下面是生成上述证书的代码片段:

// tls-certs-binding/make_certs/main.go

func main() {
    // 生成CA根证书密钥对
    caKey, err := rsa.GenerateKey(rand.Reader, 2048)
    checkError(err)

    // 生成CA证书模板
    caTemplate := x509.Certificate{
        SerialNumber: big.NewInt(1),
        Subject: pkix.Name{
            Organization: []string{"Go CA"},
        },
        NotBefore:             time.Now(),
        NotAfter:              time.Now().Add(time.Hour * 24 * 365),
        KeyUsage:              x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature | x509.KeyUsageCertSign,
        BasicConstraintsValid: true,
        IsCA:                  true,
    }

    // 使用模板自签名生成CA证书
    caCert, err := x509.CreateCertificate(rand.Reader, &caTemplate, &caTemplate, &caKey.PublicKey, caKey)
    checkError(err)

    // 生成中间CA密钥对
    interKey, err := rsa.GenerateKey(rand.Reader, 2048)
    checkError(err)

    // 生成中间CA证书模板
    interTemplate := x509.Certificate{
        SerialNumber: big.NewInt(2),
        Subject: pkix.Name{
            Organization: []string{"Go Intermediate CA"},
        },
        NotBefore:             time.Now(),
        NotAfter:              time.Now().Add(time.Hour * 24 * 365),
        KeyUsage:              x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature | x509.KeyUsageCertSign,
        BasicConstraintsValid: true,
        IsCA:                  true,
    }

    // 用CA证书签名生成中间CA证书
    interCert, err := x509.CreateCertificate(rand.Reader, &interTemplate, &caTemplate, &interKey.PublicKey, caKey)
    checkError(err)

    // 生成叶子证书密钥对
    leafKey, err := rsa.GenerateKey(rand.Reader, 2048)
    checkError(err)

    // 生成叶子证书模板,CN为server.com
    leafTemplate := x509.Certificate{
        SerialNumber: big.NewInt(3),
        Subject: pkix.Name{
            Organization: []string{"Go Server"},
            CommonName:   "server.com",
        },
        NotBefore:    time.Now(),
        NotAfter:     time.Now().Add(time.Hour * 24 * 365),
        KeyUsage:     x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature,
        ExtKeyUsage:  []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
        IPAddresses:  []net.IP{net.ParseIP("127.0.0.1")},
        DNSNames:     []string{"server.com"},
        SubjectKeyId: []byte{1, 2, 3, 4},
    }

    // 用中间CA证书签名生成叶子证书
    leafCert, err := x509.CreateCertificate(rand.Reader, &leafTemplate, &interTemplate, &leafKey.PublicKey, interKey)
    checkError(err)

    // 生成server1.com叶子证书
    leafKey1, _ := rsa.GenerateKey(rand.Reader, 2048)

    leafTemplate1 := x509.Certificate{
        SerialNumber: big.NewInt(4),
        Subject: pkix.Name{
            CommonName: "server1.com",
        },
        NotBefore: time.Now(),
        NotAfter:  time.Now().Add(time.Hour * 24 * 365),

        KeyUsage:    x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature,
        ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
        DNSNames:    []string{"server1.com"},
    }

    leafCert1, _ := x509.CreateCertificate(rand.Reader, &leafTemplate1, &interTemplate, &leafKey1.PublicKey, interKey)

    // 生成server2.com叶子证书
    leafKey2, _ := rsa.GenerateKey(rand.Reader, 2048)

    leafTemplate2 := x509.Certificate{
        SerialNumber: big.NewInt(5),
        Subject: pkix.Name{
            CommonName: "server2.com",
        },
        NotBefore: time.Now(),
        NotAfter:  time.Now().Add(time.Hour * 24 * 365),

        KeyUsage:    x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature,
        ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
        DNSNames:    []string{"server2.com"},
    }

    leafCert2, _ := x509.CreateCertificate(rand.Reader, &leafTemplate2, &interTemplate, &leafKey2.PublicKey, interKey)

    // 将证书和密钥编码为PEM格式
    caCertPEM := pem.EncodeToMemory(&pem.Block{Type: "CERTIFICATE", Bytes: caCert})
    caKeyPEM := pem.EncodeToMemory(&pem.Block{Type: "RSA PRIVATE KEY", Bytes: x509.MarshalPKCS1PrivateKey(caKey)})

    interCertPEM := pem.EncodeToMemory(&pem.Block{Type: "CERTIFICATE", Bytes: interCert})
    interKeyPEM := pem.EncodeToMemory(&pem.Block{Type: "RSA PRIVATE KEY", Bytes: x509.MarshalPKCS1PrivateKey(interKey)})

    leafCertPEM := pem.EncodeToMemory(&pem.Block{Type: "CERTIFICATE", Bytes: leafCert})
    leafKeyPEM := pem.EncodeToMemory(&pem.Block{Type: "RSA PRIVATE KEY", Bytes: x509.MarshalPKCS1PrivateKey(leafKey)})

    leafCertPEM1 := pem.EncodeToMemory(&pem.Block{Type: "CERTIFICATE", Bytes: leafCert1})
    leafKeyPEM1 := pem.EncodeToMemory(&pem.Block{Type: "RSA PRIVATE KEY", Bytes: x509.MarshalPKCS1PrivateKey(leafKey1)})

    leafCertPEM2 := pem.EncodeToMemory(&pem.Block{Type: "CERTIFICATE", Bytes: leafCert2})
    leafKeyPEM2 := pem.EncodeToMemory(&pem.Block{Type: "RSA PRIVATE KEY", Bytes: x509.MarshalPKCS1PrivateKey(leafKey2)})

    // 将PEM写入文件
    writeDataToFile("ca-cert.pem", caCertPEM)
    writeDataToFile("ca-key.pem", caKeyPEM)

    writeDataToFile("inter-cert.pem", interCertPEM)
    writeDataToFile("inter-key.pem", interKeyPEM)

    writeDataToFile("leaf-server-cert.pem", leafCertPEM)
    writeDataToFile("leaf-server-key.pem", leafKeyPEM)

    writeDataToFile("leaf-server1-cert.pem", leafCertPEM1)
    writeDataToFile("leaf-server1-key.pem", leafKeyPEM1)

    writeDataToFile("leaf-server2-cert.pem", leafCertPEM2)
    writeDataToFile("leaf-server2-key.pem", leafKeyPEM2)
}

运行这个程序后,当前目录下就会出现如下私钥文件(xx-key.pem)和证书文件(xx-cert.pem):

$ls *pem
ca-cert.pem     inter-cert.pem      leaf-server-cert.pem    leaf-server1-cert.pem   leaf-server2-cert.pem
ca-key.pem      inter-key.pem       leaf-server-key.pem leaf-server1-key.pem    leaf-server2-key.pem

制作完证书后,我们就来看看日常使用最多的绑定单一TLS证书的情况。

2. 绑定单一TLS证书

做过web应用的读者,想必对绑定单一TLS证书的实现方式并不陌生。服务端只需要加载一对服务端私钥与公钥证书即可对外提供基于TLS的安全网络服务,这里一个echo服务为例,我们来看下服务端的代码:

// tls-certs-binding/bind_single_cert/sever/main.go

// 服务端
func startServer(certFile, keyFile string) {
    // 读取证书和密钥
    cert, err := tls.LoadX509KeyPair(certFile, keyFile)
    if err != nil {
        log.Fatal(err)
    }

    // 创建TLS配置
    config := &tls.Config{
        Certificates: []tls.Certificate{cert},
    }

    // 启动TLS服务器
    listener, err := tls.Listen("tcp", ":8443", config)
    if err != nil {
        log.Fatal(err)
    }
    defer listener.Close()

    log.Println("Server started")

    for {
        conn, err := listener.Accept()
        if err != nil {
            log.Println(err)
            continue
        }
        handleConnection(conn)
    }
}

func handleConnection(conn net.Conn) {
    defer conn.Close()
    // 处理连接...
    // 循环读取客户端的数据
    for {
        buf := make([]byte, 1024)
        n, err := conn.Read(buf)
        if err != nil {
            // 读取失败则退出
            return
        }

        // 回显数据给客户端
        s := string(buf[:n])
        fmt.Printf("recv data: %s\n", s)
        conn.Write(buf[:n])
    }
}

func main() {
    // 启动服务器
    startServer("leaf-server-cert.pem", "leaf-server-key.pem")
}

根据TLS的原理,客户端在与服务端的握手过程中,服务端会将服务端证书(leaf-server-cert.pem)发到客户端供后者验证,客户端使用服务器公钥证书校验服务器身份。这一过程的实质是客户端利用CA证书中的公钥或中间CA证书中的公钥对服务端证书中由CA私钥或中间CA私钥签名的数据进行验签

// tls-certs-binding/bind_single_cert/client/main.go

func main() {
    caCert, err := ioutil.ReadFile("inter-cert.pem")
    if err != nil {
        log.Fatal(err)
    }

    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)

    config := &tls.Config{
        RootCAs: caCertPool,
    }

    conn, err := tls.Dial("tcp", "server.com:8443", config)
    if err != nil {
        log.Fatal(err)
    }
    defer conn.Close()

    // 每秒发送信息
    ticker := time.NewTicker(time.Second)
    for range ticker.C {
        msg := "hello, tls"
        conn.Write([]byte(msg))

        // 读取回复
        buf := make([]byte, len(msg))
        conn.Read(buf)
        log.Println(string(buf))
    }

}

这里我们使用了签发了leaf-server-cert.pem证书的中间CA(inter-cert.pem)来验证服务端证书(leaf-server-cert.pem)的合法性,毫无疑问这是会成功的!

// server
$go run main.go
2023/10/05 22:49:17 Server started

// client

$go run main.go
2023/10/05 22:49:22 hello, tls
2023/10/05 22:49:23 hello, tls
... ...

注:运行上述代码之前,需修改/etc/hosts文件,添加server.com的IP为127.0.0.1。

不过要注意的是,在这里用CA根证书(ca-cert.pem)直接验证叶子证书(leaf-server-cert.pem)会失败,因为根证书不是叶子证书的直接签发者,必须通过验证证书链来建立根证书和叶子证书之间的信任链。

3. 证书链

实际生产中,服务器实体证书和根证书分别只有一张,但中间证书可以有多张,这些中间证书在客户端并不一定存在,这就可能导致客户端与服务端的连接无法建立。通过openssl命令也可以印证这一点:

// 在make_certs目录下

// CA根证书无法直接验证叶子证书
$openssl verify -CAfile ca-cert.pem leaf-server-cert.pem
leaf-server-cert.pem: O = Go Server, CN = server.com
error 20 at 0 depth lookup:unable to get local issuer certificate

// 证书链不完整,也无法验证
$openssl verify -CAfile inter-cert.pem leaf-server-cert.pem
leaf-server-cert.pem: O = Go Intermediate CA
error 2 at 1 depth lookup:unable to get issuer certificate

// 需要用完整证书链来验证
$openssl verify -CAfile ca-cert.pem -untrusted inter-cert.pem leaf-server-cert.pem
leaf-server-cert.pem: OK

为此在建连阶段,服务端不仅要将服务器实体证书发给客户端,还要发送完整的证书链(如下图所示)。

证书链的最顶端是CA根证书,它的签名值是自己签名的,验证签名的公钥就包含在根证书中,根证书的签发者(Issuer)与使用者(Subject)是相同的。除了根证书,每个证书的签发者(Issuer)是它的上一级证书的使用者(Subject)。以上图为例,下列关系是成立的:

- ca-cert.pem的Issuer == ca-cert.pem的Subject
- inter1-cert.pem的Issuer == ca-cert.pem的Subject
- inter2-cert.pem的Issuer == inter1-cert.pem的Subject
... ...
- interN-cert.pem的Issuer == interN-1-cert.pem的Subject
- leaf-server-cert.pem的Issuer == interN-cert.pem的Subject

每张证书包含的重要信息是签发者(Issuer)、数字签名算法、签名值、使用者(Subject)域名、使用者公钥。除了根证书,每个证书(比如inter2-cert.pem证书)被它的上一级证书(比如inter1-cert.pem证书)对应的私钥签名,签名值包含在证书中,上一级证书包含的公钥可以用来验证该证书中的签名值(inter2-cert.pem证书可以用来验证inter1-cert.pem证书中的签名值)。

那么如何在服务端返回证书链呢?如何在客户端接收并验证证书链呢?我们来看下面示例。在这个示例中,客户端仅部署了根证书(ca-cert.pem),而服务端需要将服务证书与签发服务证书的中间CA证书以证书链的形式返回给客户端。

我们先来看服务端:

// tls-certs-binding/bind_single_cert/server-with-certs-chain/main.go

// 服务端
func startServer(certFile, keyFile string) {
    // 读取证书和密钥
    cert, err := tls.LoadX509KeyPair(certFile, keyFile)
    if err != nil {
        log.Fatal(err)
    }

    interCertBytes, err := os.ReadFile("inter-cert.pem")
    if err != nil {
        log.Fatal(err)
    }

    interCertblock, _ := pem.Decode(interCertBytes)

    // 将中间证书添加到证书链
    cert.Certificate = append(cert.Certificate, interCertblock.Bytes)

    // 创建TLS配置
    config := &tls.Config{
        Certificates: []tls.Certificate{cert},
    }

    // 启动TLS服务器
    listener, err := tls.Listen("tcp", ":8443", config)
    if err != nil {
        log.Fatal(err)
    }
    defer listener.Close()

    log.Println("Server started")

    for {
        conn, err := listener.Accept()
        if err != nil {
            log.Println(err)
            continue
        }
        handleConnection(conn)
    }
}

我们看到:服务端在加载完服务端证书后,又将中间CA证书inter-cert.pem attach到cert.Certificate,这样cert.Certificate中就构造出了一个证书链,而不单单是一个服务端证书了。

我们要注意证书链构造时的顺序,这里按照的是如下顺序构造证书链的:

- 服务端证书 (leaf certificate)
- 中间CA证书N
- 中间CA证书N-1
... ...
- 中间CA证书2
- 中间CA证书1

如果客户端没有根CA证书 (root certificate),在服务端构造证书链时,需要将根CA证书作为最后一个证书attach到证书链中。

下面则是客户端验证证书链的代码:

// tls-certs-binding/bind_single_cert/client-verify-certs-chain/main.go

func main() {
    // 加载ca-cert.pem
    caCertBytes, err := os.ReadFile("ca-cert.pem")
    if err != nil {
        log.Fatal(err)
    }

    caCertblock, _ := pem.Decode(caCertBytes)
    caCert, err := x509.ParseCertificate(caCertblock.Bytes)
    if err != nil {
        log.Fatal(err)
    }

    // 创建TLS配置
    config := &tls.Config{
        InsecureSkipVerify: true, // trigger to call VerifyPeerCertificate

        // 设置证书验证回调函数
        VerifyPeerCertificate: func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error {
            // 解析服务端返回的证书链(顺序:server-cert.pem, inter-cert.pem,inter-cert.pem's issuer...)

            var issuer *x509.Certificate
            var cert *x509.Certificate
            var err error

            if len(rawCerts) == 0 {
                return errors.New("no server certificate found")
            }

            issuer = caCert

            for i := len(rawCerts) - 1; i >= 0; i-- {
                cert, err = x509.ParseCertificate(rawCerts[i])
                if err != nil {
                    return err
                }

                if !verifyCert(issuer, cert) {
                    return errors.New("verifyCert failed")
                }

                issuer = cert
            }
            return nil
        },
    }

    conn, err := tls.Dial("tcp", "server.com:8443", config)
    if err != nil {
        log.Fatal(err)
    }
    defer conn.Close()

    // 每秒发送信息
    ticker := time.NewTicker(time.Second)
    for range ticker.C {
        msg := "hello, tls"
        conn.Write([]byte(msg))

        // 读取回复
        buf := make([]byte, len(msg))
        conn.Read(buf)
        log.Println(string(buf))
    }

}

// 验证cert是否是issuer的签发
func verifyCert(issuer, cert *x509.Certificate) bool {

    // 验证证书
    certPool := x509.NewCertPool()
    certPool.AddCert(issuer) // ok
    opts := x509.VerifyOptions{
        Roots: certPool,
    }
    _, err := cert.Verify(opts)
    return err == nil
}

从代码可以看到,当正常验证失败或没有使用正常验证的情况下,我们需要将InsecureSkipVerify设置为true才能触发证书链的自定义校验逻辑(VerifyPeerCertificate)。在VerifyPeerCertificate中,我们先用ca根证书校验位于证书链最后的那个证书,验证成功后,用验证成功的证书验证倒数第二个证书,依次类推,知道全部证书都校验ok,说明证书链是可信任的。

服务端绑定一个证书或一套证书链是最简单的,也是最常见的方案,但在一些场景下,比如考虑支持多个域名、证书轮换等,TLS服务端可能需要绑定多个证书以满足要求。下面我们就来看看如何为TLS服务端绑定多个证书。

4. 绑定多个TLS证书

这个示例的证书绑定情况如下图:

我们在服务端部署并绑定了三个证书,三个证书与域名的对应关系如下:

- 证书leaf-server-cert.pem 对应 server.com
- 证书leaf-server1-cert.pem 对应 server1.com
- 证书leaf-server2-cert.pem 对应 server2.com

注:在/etc/hosts中添加server1.com和server2.com对应的ip均为127.0.0.1。

// tls-certs-binding/bind_multi_certs/server/main.go

func main() {
    certFiles := []string{"leaf-server-cert.pem", "leaf-server1-cert.pem", "leaf-server2-cert.pem"}
    keyFiles := []string{"leaf-server-key.pem", "leaf-server1-key.pem", "leaf-server2-key.pem"}

    // 启动服务器
    startServer(certFiles, keyFiles)
}

// 服务端
func startServer(certFiles, keyFiles []string) {
    // 读取证书和密钥

    var certs []tls.Certificate
    for i := 0; i < len(certFiles); i++ {
        cert, err := tls.LoadX509KeyPair(certFiles[i], keyFiles[i])
        if err != nil {
            log.Fatal(err)
        }
        certs = append(certs, cert)
    }

    // 创建TLS配置
    config := &tls.Config{
        Certificates: certs,
    }

    // 启动TLS服务器
    listener, err := tls.Listen("tcp", ":8443", config)
    if err != nil {
        log.Fatal(err)
    }
    defer listener.Close()

    log.Println("Server started")

    for {
        conn, err := listener.Accept()
        if err != nil {
            log.Println(err)
            continue
        }
        handleConnection(conn)
    }
}

我们看到,绑定多个证书与绑定一个证书的原理是完全一样的,tls.Config的Certificates字段原本就是一个切片,可以容纳单个证书,也可以容纳证书链,容纳多个证书也不是问题。

客户端代码变化不大,我们仅是通过下面代码输出了服务端返回的证书的Subject.CN:

// tls-certs-binding/bind_multi_certs/client/main.go

// 解析连接的服务器证书
certs := conn.ConnectionState().PeerCertificates
if len(certs) > 0 {
    log.Println("Server CN:", certs[0].Subject.CommonName)
}

接下来我们通过client连接不同的域名,得到如下执行结果:

// 服务端
$go run main.go
2023/10/06 10:22:38 Server started

// 客户端
$go run main.go -server server.com:8443
2023/10/06 10:22:57 Server CN: server.com
2023/10/06 10:22:58 hello, tls

$go run main.go -server server1.com:8443
2023/10/06 10:23:02 Server CN: server1.com
2023/10/06 10:23:03 hello, tls
2023/10/06 10:23:04 hello, tls

$go run main.go -server server2.com:8443
2023/10/06 10:23:08 Server CN: server2.com
2023/10/06 10:23:09 hello, tls
... ...

我们看到,由于绑定多个域名对应的证书,程序可以支持访问不同域名的请求,并根据请求的域名,返回对应域名的证书。

5. 自定义证书选择绑定逻辑

无论是单一TLS证书、证书链还是多TLS证书,他们都有一个共同特点,那就是证书的绑定是事先已知的,是一种“静态”模式的绑定;有些场景下,服务端在初始化启动后并不会绑定某个固定的证书,而是根据客户端的连接需求以及特定规则在证书池中选择某个匹配的证书。在这种情况下,我们需要使用GetCertificate回调从自定义的证书池中选择匹配的证书,而不能在用上面示例中那种“静态”模式了。

我们来看一个自定义证书选择逻辑的示例,下面示意图展示了客户端和服务端的证书部署情况:

我们主要看一下服务端的代码逻辑变动:

// tls-certs-binding/bind_custom_logic/server/main.go

func startServer(certsPath string) {

    // 创建TLS配置
    config := &tls.Config{
        GetCertificate: func(info *tls.ClientHelloInfo) (*tls.Certificate, error) {
            // 根据clientHello信息选择cert

            certFile := fmt.Sprintf("%s/leaf-%s-cert.pem", certsPath, info.ServerName[:len(info.ServerName)-4])
            keyFile := fmt.Sprintf("%s/leaf-%s-key.pem", certsPath, info.ServerName[:len(info.ServerName)-4])

            // 读取证书和密钥
            cert, err := tls.LoadX509KeyPair(certFile, keyFile)
            return &cert, err
        },
    }
    ... ...
}

我们看到: tls.Config我们建立了一个匿名函数赋值给了GetCertificate字段,该函数的实现逻辑就是根据客户端clientHello信息(tls握手时发送的信息)按照规则从证书池目录中查找并加载对应的证书与其私钥信息。示例使用ServerName来查找带有同名信息的证书。

例子的运行结果与上面的示例都差不多,这里就不赘述了。

利用这种动态的证书选择逻辑,我们还可以实现通过执行外部命令来获取证书、从数据库加载证书等。

6. 小结

通过本文的介绍,我们全面了解了在Go服务端绑定单个、多个TLS证书的各种方式。我们首先介绍了生成自签名证书的方法,这为我们的示例程序奠定了基础。然后我们详细探讨了绑定单证书、证书链、多证书、定制从证书池取特定证书的逻辑等不同机制的用法、优劣势和适用场景。同时,在介绍每种用法时,我们都用代码示例进一步解释了这些绑定方式的具体实现流程。

单证书TLS简单易理解,运行性能优异。多证书TLS在提高性能、安全性、便利管理等方面有着重要意义。而自定义证书选取逻辑则更加灵活。通过综合运用各种绑定机制,可以使我们的Go语言服务器端更加强大和灵活。

本文示例所涉及的Go源码可以在这里下载。

注:代码仓库中的证书和key文件有效期为一年,大家如发现证书已经过期,可以在make_certs目录下重新生成各种证书和私钥并copy到对应的其他目录中去。

7. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats