@justNoBody github 上搜仓库名，可以搜到 fork

觉得可以看看这个，应该比较容易：
TLS1.2： https://tls.ulfheim.net/
TLS1.3： https://tls13.ulfheim.net/

没做错误处理、自己处理一下
server 端：
cert, err := tls.LoadX509KeyPair(*cert, *key)

CA := x509.NewCertPool()
file, err := ioutil.ReadFile(*ca)
CA.AppendCertsFromPEM(file)

tlsConfig := tls.Config{
GetCertificate: func(info *tls.ClientHelloInfo) (*tls.Certificate, error) {
return &cert, nil
},
ClientAuth: tls.RequireAndVerifyClientCert,
ClientCAs: CA,
// ...
}

客户端：
cert, err := tls.LoadX509KeyPair(*cert, *key)

CA := x509.NewCertPool()
file, err := ioutil.ReadFile(*ca)
CA.AppendCertsFromPEM(file)

tlsConfig := tls.Config{
Certificates: []tls.Certificate{cert},
RootCAs: certPool,
ClientAuth: tls.RequireAndVerifyClientCert,
ClientCAs: certPool,
// ...
}

@daoqiongsi1101 http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server 对于 HTTP/1 upstream ，可以通过 max_conns 限制连接数、keepalive 限制连接池。

先说一下 HTTP/1 、HTTP/2 、HTTP/3：
HTTP/1 在单个 TCP 上以 keep-alive 的形式复用，按照“请求-响应-请求-响应”的顺序进行，后面的请求会受到前面请求的阻塞，叫做“线头阻塞 Head-of-line blocking” https://en.wikipedia.org/wiki/Head-of-line_blocking
HTTP/2 在单个 TCP 上分帧复用连接，多个请求可以同时发送、同时接收。但这个“同时”只是在应用层的 HTTP 协议眼中看起来是“同时”的，而在传输层的 TCP 眼中来看还是串行的。就是将多个 HTTP 请求响应拆成小片，然后在单个 TCP 连接中交替（也不一定是交替）传输。所以仍然存在“线头阻塞”，只不过是 TCP 层面的线头阻塞。
HTTP/3 将传输层协议给替换掉了，改成了基于 UDP 的 QUIC ，由于 UDP 属于无状态的，所以传输层的包也是同时发送了，这就消除了传输层的线头阻塞。

回到你这个链接里讨论的不支持 HTTP/2 ，总结一下原因：
1 ，支持 HTTP/2 作为 upstream ，那么所有连接复用同一个 TCP ，会受到 TCP 线头阻塞和拥塞控制问题的影响，对 nginx 来说，会使得事情变得复杂
2 ，用单个连接传输，几乎消除了连接数的限制，但是实际上 nginx 本身也没有主动做这样的限制（除非你自己指定 max_conns ），所以这个没啥意义
3 ，（感觉也是最主要的一点）实现 HTTP/2 进行单路复用，需要对 upstream 模块做重大修改，风险比较高
If you still think that talking to backends via HTTP/2 is something needed - feel free to provide patches.（翻译：老子嫌麻烦不想做，你要觉得有必要，你做好了把 patch 提交上来）

所以，风险大于收益，他们觉得没有实现的必要。
这也是 2015 、2016 年的帖子了，那时候 HTTP/2 才刚起步。
现在 HTTP/3 的时代快来了，云厂商都在部署 h3 了，不知道是不是 nginx 的时代已经快过去了？（瞎说的）

@daoqiongsi1101 所以啊，你只要想一想，你 10 个 goroutine 请求是同时请求的，还是有先后顺序的？肯定是同时的啊。

实际上，同时并发请求数受到操作系统的限制（端口数、ulimit 、maxfiles 之类的），为了避免达到操作系统限制，同时降低建立 TCP 的开销，所以浏览器才会实现较小的并发限制。
实际上，具体是看你 golang 代码怎么写的。多个 goroutine 是用的同一个 http.Client 还是不同的，单域名连接数配置的多少。
如果是使用默认的 http.Client 来请求的话，那么走的就是默认的 http.Transport 配置，里面指定的单域名连接数 MaxConnsPerHost 默认是 0 ，也就是不限制。那么你只要没有达到操作系统限制，并发就是能建立多少 TCP 就建立多少 TCP 来并发请求，所以 10 个 goroutine 就是 10 个 TCP 。
而另外，可以针对单个 http.Client 对象来限制连接数，那么使用同一个实例来请求就会受到限制，达到限制就会阻塞等待。

另外注意，这个连接数跟连接池关系不大。默认的 http.Transport 的连接池有两个配置：全部连接池大小 MaxIdleConns 默认是 100 、单域名连接池大小 DefaultMaxIdleConnsPerHost 默认是 2 。这两个配置不影响并发请求的 TCP 连接数。

假设现在是单域名，单域名连接池大小 DefaultMaxIdleConnsPerHost 是 2 ，MaxConnsPerHost 并发数设置了 5 。那么此时你开了 10 个 goroutine 并发，并且每个请求都是 1 秒响应，则会发生这样的情况（实际情况可能受各种竞争因素影响）：
1 ，建立 5 个 TCP 连接并发，剩余 5 个连接阻塞等待。
2 ，5 个连接请求结束，只有 2 个 TCP 连接进入连接池复用，剩余 3 个 TCP 连接被 close 。
3 ，剩下的 5 个连接开始请求，其中 2 个复用之前连接池中的 TCP 连接，另外 3 个则建立新的 TCP 连接进行请求。
4 ，所有请求都结束，连接池中持有 2 个连接等待复用，其余连接都被 close 。
5 ，如果没有更多请求了，则连接池中的连接在超时（ IdleConnTimeout ）后被自动 close 。或者等待 TCP 自己的 keepalive 超时规则（ tcp_keepalive_time 、tcp_keepalive_intvl 、tcp_keepalive_probes ）来关闭连接。

等下，HTTP/1.1 的请求，并行不是复用同一个 TCP 啊？串行才是复用同一个 TCP 的啊！队头阻塞也是复用同一个 TCP 连接的串行 HTTP ，后面的请求要等待前面的请求响应啊。
Chrome 并发连接数限制是指创建的 TCP 的连接数啊，并且仅限 HTTP/1 。

HTTP/1 还没有分帧并发的技术，所有数据都是串行发送的，不存在你说的“并发请求、顺序响应”。要实现并发，就得建立多条 TCP ，在多个 TCP 连接上同时请求。
HTTP/1 的 keep-alive 是指一轮 请求-响应 结束后，不关闭 TCP 连接，可以直接在当前 TCP 连接上进行新的 HTTP 请求-响应。

本地启个 v2ray 后台进程，出口自己配路由指定不同域名走不同代理，或者不走代理。然后 Chrome 启动直接全局代理 127.0.0.1

@markgor 并发数限制在 HTTP/2 下不一样了。
HTTP/1 下限制连接数是因为 HTTP/1 的特性，单个连接上只能串行传输，要并行传输就得要建立多个 HTTP/TCP 连接，而这个连接是有开销的，并且操作系统对这个也有上限，所以浏览器实现的时候就需要限制连接数。
但 HTTP/2 不一样了，浏览器针对一个主机始终只建立一个 TCP 连接，在这一个连接上进行多路复用并行传输 HTTP ，所以并发数理论上是无限的了。实际上浏览器端和服务端可以通过 HTTP/2 的 SETTINGS_MAX_CONCURRENT_STREAMS 配置来协商并发数限制。

@pcell excel 也存在问题，但是现在比较新的版本都做了近似补偿： https://docs.microsoft.com/en-us/office/troubleshoot/excel/floating-point-arithmetic-inaccurate-result
比如输入公式：=1.333+1.225-1.333-1.225 可以得到 0 ，但是输入 =(1.333+1.225-1.333-1.225) 就得到了 -2.22045E-16

@knowckx #18： https://go.dev/blog/constants#numbers 所有纯数字表达式（包括四则运算的结果、复数等）都是常量，会在编译时给你替换好。

经过测试，应该确定确实是 iOS Safari 的 bug ，应该是 safari 在做优化的时候，只考虑了 translate 而忘记考虑 scale 的影响了，具体现象：
你同时为图片增加了 translateX 和 scale ，图片原本宽度为 620px ，它发现你 translateX(-1000px) 之后，图片应该已经在可见范围之外了，并且动画运动到 translateX(-1100px) 全程都应该在可见范围之外，所以直接将动画“优化”掉不执行了，反正效果就是元素在原来的位置消失，在动画结束之后再在新位置显示出来，那就直接不计算动画了，直接“跳刀 blink”即可。
但是它没料到实际上你同时为图片增加了 scale(2.5)，把图片放大了，此时图片宽度变成了 1550px ，动画全程都在可见范围之内了，导致这个“优化”露馅了。

按照这个理论，你将动画改为从 translateX(620px) 变化到 translateX(621px) 就会触发 bug ，但是只要某一个值小于 620px （图片原始宽度），bug 就不会复现。

@Mutoo #3 给出的用 matrix 的解决方案，应该是绕过了这个 bug ，将 translateX 和 scale 的结果融合进同一个矩阵，Safari 就会考虑完整的变换结果之后再进行动画的优化。

应该可以给 webkit 提 issue 了。

所以……为啥日常要用 root 身份……

你的消息队列里存的是消息通知，而不是消息内容？？
用到消息队列，应该是缓解数据库那边的压力吧？如果你的消息可以直接入数据库，那应该没必要用消息队列了？新消息来了先写数据库，然后判断用户是否在线，在线的话就推一条新消息通知，用户阅读的时候再查数据库获取数据。
如果消息量比较大的话，就先把消息放到消息队列，消息入队的时候不通知用户，队列直接输出对接到数据库入库。写完数据库再判断用户是否在线，在线推送。

至于轮询和 websocket 的选择，看具体的业务实时性：1 、实时性要求非常低，那么完全可以不推送，用户刷新的时候获取新消息（ V2EX 貌似就是这个模式），2 、web app ，用户很少会刷新页面，而实时性要求不高的话，用轮询 30 秒、1 分钟，3 、要求实时性高的场景，则使用 websocket ，几乎是实时的。
轮询需要接口能够承受住刷新请求，websocket 需要服务端能够持有足够多的 socket 连接。
至于 #6 的 push 消息，使用场景不太一样，主要用于用户没有访问你的网站时也可以收到通知推送（类似于手机 APP 的后台被杀掉，也还是可以通过 FCM/APNs 收到实时推送消息）。你需要注册一个 service worker ，然后用户不需要打开你的网站也可以收到消息推送（只要浏览器在运行，sw 就能在后台接收消息推送），消息推送的形式是通过浏览器的 notification 弹窗（用户必须先授权弹窗）。

@Newyorkcity #26 滑动输入就是输入的时候，手指完全不离开屏幕，在键盘上连线，把拼音字母按顺序连起来。
比如全键盘下要输入“你好”，就在 n 上按下，然后依次滑动到 i 、h 、a 、o 上，然后松开，不用特别精确，中间经过的其他按钮无所谓。9 键也是类似，在 6 上按下，然后依次滑动到 4 、2 、6 上，然后松开。
用习惯的话打字会更快。
目前我只知道 Google 的 Gboard 键盘是支持的，iOS 和 Android 都支持。iOS 自带的貌似只有新版系统的英文全键盘支持。其他输入法没用过不知道。

感觉这个 14 键理论上也是能支持的（毕竟 Gboard 的 9 键都能支持），就看具体使用的输入法有没有这个功能了。

Type-C 算 USB 吗？那 Type-A 呢？