@securityCoding
@killergun
@dalei

好的，谢谢解答！

@ragnaroks 请问 Int64 的话会有什么问题呢？

万一你看到它在偷偷用你电脑跟母星发消息这可怎么整？

@tin3w5 真到这一步，人家有 1W 种办法弄死你，唉

@watzds 这个不错，比我的抓包目测清楚，感谢！

也谢谢你们的建议
@louiswang002
@zhuzhibin

@MeteorCat
@lostberryzz
@unixeno

感谢这么晚回复，我要睡了，你们也早点睡吧，谢谢各位指导！！！

@MeteorCat 套了 cdn，不过我本地修改 hosts 直连的服务器，跟 cdn 没关系，cdn 大概会在原有延迟数字上加 60ms 吧

@keyfunc
@Zhuzhuchenyan
@watzds

经过实验，我发现**一个 curl 命令跑多个链接**的话，只要在一个会话里面，就可以用 keep-alive 长连接，因此跑了 20 多条数据的总时间换算一下延迟确实是忽略不计的，但是用 postman 点击发送或者 **多个 curl 命令，每个 curl 跑 1 个链接**的话，就没有用到 keep-alive，每个都是单独会话

因此我猜想 ssl 第一次请求都很慢，但是如果是长连接保持，接下来的连接就不用计算证书合法性了，所以还是要在一个会话里才能看出问题。

是否可以这样理解？

@Zhuzhuchenyan @watzds 感谢那么晚回复，我服务器在某大厂云的香港服务器，ping 也就 40ms 左右，我在想总不能开启 https 能增加 90ms 延迟，要么我的 postman 点击按钮的验证延迟的测算方法有问题，要么就是配置上的问题，
@watzds 我抓包看 Header Connection: keep-alive 都是默认开启的

@keyfunc 我用 postman 连续点击的 send，延迟就是上面的延迟，还是说我每次 点击 send 都算单独的一次访问？

@dzdh linux

谢谢各位解答，这样我就放心了
@yfwl
@Ptu2sha

@nonduality
@chaleaoch
@lixuda
感谢提供指导！

@lixuda 我觉得用它封装好的性能最好，判断太多代码也显得不整洁

@wuwukai007 有道理，谢谢！

@zeroDev 我一直潜意识认为报错会有额外的性能开销，所以就感觉用 try 处理正常业务逻辑很奇怪

@zeroDev 好的 我瞧瞧

@wuwukai007
我看它文档里面还真是 try 出来的，真原始啊