Tony Bai - Part 104

十二月 14, 2021

本文永久链接 – https://tonybai.com/2021/12/14/the-misconception-of-using-docker-to-break-out-of-6w-ports-of-the-client

近期的一个项目刚刚完成了第一个版本的开发，经过一段时间的自测与集成测试，功能问题已经不是重点了。项目在初期设定了性能目标，压测与性能优化势在必行，因此这一阶段我们都在做压测前的准备，包括压测方案、环境部署、各种工具的开发等。在互联网大厂的一波接着一波的熏陶与教育下，但凡一个有点用户量的系统，交付前不压测与优化一下，似乎都不好意思上线^_^。

压测准备阶段逃不过“模拟并发连接数量”这一环节，我们第一次压测设定的系统运行背景是100w的并发长连接。那么怎么构造出这么多的并发连接呢？有经验的朋友可能知道这句话中隐含的“难点”，那就是一个客户机最多向外面建立65535-1024+1=64512个连接。为什么会这样呢？这是因为一个TCP连接由一个四元组唯一确定，这个四元组是（源端口，源地址，目的地址，目的端口）。这个四元组中的源端口是一个16bit的短整型，它的表示范围是0~65535。但1024及以下的端口号通常为系统保留，因此用户可用的端口号仅剩下64512个。

当一个客户机向服务端建立TCP连接时，四元组中的目的地址、目的端口是固定的，客户机通常只有一个IP地址，这样源地址也是固定的，于是唯一的变数就是源端口了。而源端口在这种情况下仅有64512种变化，因此客户机向外建立的连接数量也就受到了限制。

于是有人想到了Docker容器。由于容器具有独立的网络命名空间以及独立的IP地址，这样容器可以向外建立的连接就不受到宿主机的限制，真的是这样么？

下面我们在一台宿主机上用多个容器模拟的“客户机”向该宿主机上的一个Server程序建立连接，我们看是否能突破6w壁垒。下面是server端程序的代码(仅作示例，勿要深究)：

// https://github.com/bigwhite/experiments/tree/master/break-out-of-6w-ports/server/server.go

func main() {
    l, err := net.Listen("tcp", "0.0.0.0:9000")
    if err != nil {
        fmt.Println("error listening:", err.Error())
        return
    }
    defer l.Close()
    fmt.Println("listen ok")
    var mu sync.Mutex
    var count int

    for {
        conn, err := l.Accept()
        if err != nil {
            fmt.Println("error accept:", err)
            return
        }

        fmt.Printf("recv conn from [%s]\n", conn.RemoteAddr())
        go func(conn net.Conn) {
            var b = make([]byte, 10)
            for {
                _, err := conn.Read(b)
                if err != nil {
                    e, ok := err.(net.Error)
                    if ok {
                        if e.Timeout() {
                            continue
                        }
                    }

                    mu.Lock()
                    count--
                    mu.Unlock()
                    return
                }
            }
        }(conn)

        mu.Lock()
        count++
        mu.Unlock()
        fmt.Println("total count =", count)
    }
    select {}
}

这个server程序运行于宿主机上(宿主机的各个资源参数需要你自行调整，比如：/proc/sys/fs/file-max、/proc/sys/fs/nr_open等，可参考这里)，并监听9000端口，每accept一个来自客户机的TCP连接，就会创建一个goroutine来处理这个TCP连接。

客户机模拟客户端连接的程序如下：

// https://github.com/bigwhite/experiments/tree/master/break-out-of-6w-ports/client/client.go

func main() {
    var count = 25000
    for i := 0; i < count; i++ {
        go func() {
            conn, err := net.Dial("tcp", "192.168.49.6:9000") // 192.168.49.6是宿主机地址
            if err != nil {
                fmt.Println("net.Dial error:", err)
                return
            }

            for {
                _, err := conn.Write([]byte("ping"))
                if err != nil {
                    fmt.Println("conn.Write error:", err)
                    return
                }
                time.Sleep(100 * time.Second)
            }
        }()
    }
    select {}
}

从代码中可以看到，每个客户机客户端程序会向服务端建立25000个TCP长连接。这里将client端放入基于alpine:3.14.2 image的容器中运行，容器中每个程序可以对外建立的连接数量我们可以通过下面命令的输出计算出来：

$ docker run alpine:3.14.2 cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999

> 60999-32768+1
28232

代码中每个client建立25000个连接，在28232范围之内，正常建立全部连接不是问题。实际的试验结果也证明了这一点：我们启动server后，逐一用下面命令启动多个client：

$go build client.go
$docker run -v /Users/tonybai/Go/src/github.com/bigwhite/experiments/break-out-of-6w-ports/client/client:/root/client alpine:3.14.2 /root/client

创建三个client后，我们很快就能看到Server端完成了75000个连接的创建：

listen ok
recv conn from [172.17.0.2:50238]
... ...
recv conn from [172.17.0.4:35202]
total count = 74997
recv conn from [172.17.0.4:35282]
total count = 74998
recv conn from [172.17.0.4:33168]
total count = 74999
recv conn from [172.17.0.4:44703]
total count = 75000

我们看到，在同一个宿主机上利用容器充当客户端我们轻松突破客户端可用端口的限制。

那么如果server程序在另外的一个主机上呢? 我们是否还可以这么顺利的建立如此多的连接呢？我们来试一下，执行的命令与过程与上面大致相同，但server端在建立64000左右连接后，无论再加入几个client向服务端建立连接，server端的总连接数也不会向上了。你或许怀疑server端程序有问题？其实不是，此时如果你在另外一台机器上向server建立连接，连接可以很快的建立成功。

问题还是出在了Docker所在的那台宿主机上了。为什么各个客户端建立不上连接了呢？从server端的一些输出日志可见端倪：

// 192.168.49.6是客户端所在宿主机的ip地址

recv conn from [192.168.49.6:11431]
total count = 64001
recv conn from [192.168.49.6:28365]
total count = 64002

我们看到无论docker容器内ip地址是多少，从宿主机连出来后的ip都是192.168.49.6（宿主机的ip地址），默认情况下，Docker容器访问宿主机外部的主机时，其源地址和端口都会被SNAT成宿主机的IP及某一个随机端口，下面是一个简略的SNAT转换表：

我们看到docker中的请求经过NAT后其源ip转换为宿主机的源ip地址192.168.49.6，源端口为宿主机的一个随机端口(1024~65535范围内)。客户端发出请求后，server端处理并返回响应，响应回到宿主机后，NAT会根据上面的转换表，根据nat后的源ip、nat后的源port、目的ip和目的port找到唯一的源ip和源port，并将替换数据包中相应的字段，这样数据包才能返回给对应的容器中的客户端程序。这样当目的ip、目的port以及nat后的源ip都是“固定值”的情况下，就只能要求nat后的源port不能重复，而nat后的源port的可选范围却只能为1024~65535，当nat后的源port耗尽，容器中的客户端程序就再也无法与server建立新连接了。

我们再重新审视一下nat转换表，nat后的源port是自动分配的，目的port是知名port，不能变化，剩下的只有nat后的源ip地址与目的ip地址是可变动的要素。每新增一种nat后的源ip或目的ip，都可以新增加64521(65535-1024+1)个到server端的TCP连接容量。

下面我们就以添加多个目的ip的方式为例，看看docker如何突破6w可用端口的约束。我们的server服务器是一台ubuntu 20.04的虚拟机，我们可以通过修改netplan配置的方式为enp0s8网卡（连接内部网络, ip为192.168.49.5）添加额外两个ip：192.168.49.15和192.168.49.25。

$ cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    enp0s3:
      addresses: [10.0.2.15/24]
      gateway4: 10.0.2.2
      nameservers:
        addresses: [8.8.8.8,127.0.0.53]
      dhcp4: no
    enp0s8:
      addresses: [192.168.49.5/24,192.168.49.15/24,192.168.49.25/24]
      gateway4: 192.168.49.1
      nameservers:
        addresses: [8.8.8.8,127.0.0.53]
      dhcp4: no
  version: 2

执行sudo netplan apply后，我们可以看到enp0s8网口上配置的三个ip信息如下，

3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:f1:bb:67 brd ff:ff:ff:ff:ff:ff
    inet 192.168.49.5/24 brd 192.168.49.255 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet 192.168.49.15/24 brd 192.168.49.255 scope global secondary enp0s8
       valid_lft forever preferred_lft forever
    inet 192.168.49.25/24 brd 192.168.49.255 scope global secondary enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fef1:bb67/64 scope link
       valid_lft forever preferred_lft forever

现在我们将按下图所示通过docker向server建立75000个连接(每个容器建立25000个)：

我们改造一下server程序，让其不仅输出RemoteAddr，还要输出LocalAddr：

// https://github.com/bigwhite/experiments/tree/master/break-out-of-6w-ports/server/server1.go

fmt.Printf("recv conn from [%s], localaddr: [%s]\n", conn.RemoteAddr(), conn.LocalAddr())

为了方便向client传入要连接的server的地址，我们也改造一下client：

// https://github.com/bigwhite/experiments/tree/master/break-out-of-6w-ports/client/client_with_remoteaddr.go

var remoteIP string

func init() {
    flag.StringVar(&remoteIP, "rip", "", "remoteIP")
}

func main() {
    flag.Parse()
    var count = 25000
    for i := 0; i < count; i++ {
        go func() {
            conn, err := net.Dial("tcp", remoteIP+":9000")
            if err != nil {
                fmt.Println("net.Dial error:", err)
                return
            }

            for {
                _, err := conn.Write([]byte("ping"))
                if err != nil {
                    fmt.Println("conn.Write error:", err)
                    return
                }
                time.Sleep(100 * time.Second)
            }
        }()
    }
    select {}
}

接下来我们就将新client放入容器中执行，并分别用三个remote ip向server建立连接：

$go build -o client client_with_remoteaddr.go

$docker run -v /Users/tonybai/Go/src/github.com/bigwhite/experiments/break-out-of-6w-ports/client/client:/root/client alpine:3.14.2 /root/client -rip 192.168.49.5

$docker run -v /Users/tonybai/Go/src/github.com/bigwhite/experiments/break-out-of-6w-ports/client/client:/root/client alpine:3.14.2 /root/client -rip 192.168.49.15

$docker run -v /Users/tonybai/Go/src/github.com/bigwhite/experiments/break-out-of-6w-ports/client/client:/root/client alpine:3.14.2 /root/client -rip 192.168.49.25

我们很快就在server的log中看到所有连接都建立成功了：

... ...
recv conn from [192.168.49.6:43505], localaddr: [192.168.49.25:9000]
total count = 74998
recv conn from [192.168.49.6:43483], localaddr: [192.168.49.25:9000]
total count = 74999
recv conn from [192.168.49.6:47790], localaddr: [192.168.49.25:9000]
total count = 75000

并且当我们以37816这个端口为例，我们查询一下日志：

$ grep 37816 server.log
recv conn from [192.168.49.6:37816], localaddr: [192.168.49.5:9000]
recv conn from [192.168.49.6:37816], localaddr: [192.168.49.15:9000]
recv conn from [192.168.49.6:37816], localaddr: [192.168.49.25:9000]

我们看到有三个来自192.168.49.6:37816的连接，但目的地址均不相同，这也印证了我们的分析是正确的。

以上就是对使用docker突破客户端可用端口的限制的误区的分析，所谓的误区即当客户端与server在同一台宿主机上可突破6w端口，就认为客户端与server在不同主机上时不需做任何改变也同样可以突破6w。上面的分析证实了我们要么增加服务端的ip，要么增加客户端的ip，或对两者的ip进行同时增加，后两个情况大家可以自行进行试验，这里就不赘述了。

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强，欢迎大家加入！

img{512x368}

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展；短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

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

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite
“Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：
img{512x368}

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

惊了！原来Go语言也有隐式转型

十二月 2, 2021

0 条评论

本文永久链接 – https://tonybai.com/2021/12/02/go-has-implicit-type-convertion

我的极客时间专栏《Go语言第一课》上线后收到了很多学员的反馈，大家提出了很多显然是经过认真思考的高水平问题。有些时候我也会被这些问题所“难倒”，比如昨天我在后台看到的这个问题。

我把这个问题整理为下面代码文本，方便大家copy和重现问题：

package main

type MyInt int
type MyMap map[string]int

func main() {
    var x MyInt
    var y int
    x = y     // 会报错: cannot use y (type int) as type MyInt in assignment
    _ = x 

    var m1 MyMap
    var m2 map[string]int
    m1 = m2 // 不会报错
    m2 = m1 // 不会报错
}

结合上面代码，我将这位学员的问题重新描述一下：MyInt与int是不同的两个类型，MyMap与map[string]int也是不同的两个类型，为何将int型变量赋值给MyInt型变量时需要做显式转型，而将map[string]int变量赋值给MyMap型变量就不需要显式转型呢？

我们知道：Go是强调类型安全的静态编译型语言，在Go语言中，不同类型变量是不能在一起进行混合计算的，这是因为Go希望开发人员明确知道自己在做什么，这与C语言的“信任程序员”原则完全不同，因此你需要以显式的方式通过转型统一参与计算各个变量的类型。比如：上面问题中MyInt虽然底层类型(underlying type)是int，但MyInt与int是两个不同的类型，因此它们之间的相互赋值需要通过显式转型来进行，否则Go编译器将报错，这个没有任何疑问。

估计此时大家也都会异口同声的问：那“m1 = m2”呢？为何这一句不需要显式转型呢？MyMap的底层类型是map[string]int，但MyMap与map[string]int也是两个不同的类型啊！千万不要告诉我：int与map[string]int这两个原生类型的待遇有不同！

事实上这个问题的关键就在于int与map[string]int的确有不同。

在Go中，我们定义一个类型一般通过type关键字进行，比如：

type T1 int
type T2 T1

在Go中，使用上述类型声明语句定义的类型T1、T2被称为defined type，中文称为“具定义类型”。在type alias加入Go之前，这种类型还被称为named type（具名类型），顾名思义，这个类型是有名字的。这个其实也很好理解。但问题的关键是Go语言的原生类型是否都是defined type。

好在Go语言规范中对各个内置的原生类型做了明确规定：

所有数值类型都是defined type；(这里面就包含int)
字符串类型string是defined type；
布尔类型bool是defined type。

就这些，没了？没了！这就意味着map、数组、切片、结构体、channel等原生复合类型(composite type)都不是defined type。

我们离真相越来越近了！我们再回到最初的问题中。int与MyInt都是defined type，因此它们两者之间相互赋值是需要显式转型的。map[string]int不是defined type，MyMap是defined type，那么它们直接的赋值是怎么规定的呢？

Go语言规范中关于Assignability的规则中有下面这一条规定：

x's type V and T have identical underlying types and at least one of V or T is not a defined type.
如果x的类型V与类型T具有相同的底层类型，并且V和T至少有一个不是defined type，那么x可以赋值给类型T的变量。

我们用问题中的代码来套一下这个规则。我们有一个MyMap类型的变量m1，MyMap类型与map[string]int类型具有相同的底层类型map[string]int，并且map[string]int类型不是一个defined type，那么我们可以将m1直接赋值给map[string]int类型的变量m2，反之亦可。

到这里，上面的问题算是解答完毕了。我们再来扩展一下，看一些Go其他原生但非defined type的类型赋值的例子，例子中这些赋值都不会报编译错误：

package main

type MyMap map[string]int
type MySlice []byte
type MyArray [10]int
type MyStruct struct {
    a int
    b string
}
type MyChannel chan int

func main() {
    var m1 MyMap
    var m2 map[string]int
    m1 = m2 // 不会报错
    m2 = m1 // 不会报错

    var sl1 MySlice
    var sl2 []byte
    sl1 = sl2 // 不会报错
    sl2 = sl1 // 不会报错

    var arr1 MyArray
    var arr2 [10]int
    arr1 = arr2 // 不会报错
    arr2 = arr1 // 不会报错

    var s1 MyStruct
    var s2 struct {
        a int
        b string
    }
    s1 = s2 // 不会报错
    s2 = s1 // 不会报错

    var c1 MyChannel
    var c2 chan int
    c1 = c2 // 不会报错
    c2 = c1 // 不会报错
}

对于上面这种在底层类型相同且至少有一个类型不是defined type的两个类型变量间赋值的情况，是不是很眼熟。没错，它和Go的无类型常量隐式转型十分相似，虽然背后的原理是不同的：

type MyInt int
const a = 1234
var n MyInt = a

Go总体来说是推崇显式哲学的，那怎么来理解这种隐式转型呢？我觉得至少有两点：

首先这种转型更多是在编译器保证类型安全性的前提下进行的，不会出现溢出或未定义行为。

其次，这种隐式转型一定程度减少了代码输入，对开发体验的提升有帮助。

最后，感谢《Go语言101》作者老貘兄在这个问题上给予我的点拨，国内在Go语言语法细节上理解最到位最深入的人非老貘兄莫属^_^。

img{512x368}

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite
“Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：
img{512x368}

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

使用Docker容器突破客户端6w可用端口的误区

惊了！原来Go语言也有隐式转型

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

文章

评论

分类

归档

链接

开源项目

翻译项目

使用Docker容器突破客户端6w可用端口的误区

惊了！原来Go语言也有隐式转型

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

文章

评论

分类

标签

归档

链接

开源项目

翻译项目