起因 TLS Handshake是什么来头，竟然如此大? 要注意的是
起因
是一个高并发的采集服务上线后，100m的上行很快就被打满了。
因为这是一条专线，并且只有这一个服务在使用，所以可以确定就是它导致的。
但是！这个请求只是一个 GET 请求，同时并没有很大的请求体，这是为什么呢？
于是使用 charles 重新抓包后发现，一个 request 的请求居然要占用 1.68kb 的大小!
其中TLS Handshake 就占了 1.27kb。
这种情况下，需要的上行带宽就是：1.68*20000/1024*8=262.5mbps
也就说明100mbps的上行为何被轻松打满
TLS Handshake是什么来头，竟然如此大?
首先要知道HTTPS全称是：HTTP over TLS，每次建立新的TCP连接通常需要进行一次完整的TLS Handshake。在握手过程中，客户端和服务器需要交换证书、公钥、加密算法等信息，这些数据占用了较多的字节数。
TLS Handshake的内容主要包括：
客户端和服务器的随机数 支持的加密算法和TLS版本信息 服务器的数字证书（包含公钥） 用于生成对称密钥的“ Pre-Master Secret”
这个过程不仅耗时，还会消耗带宽和CPU资源。
因此想到最粗暴的解决方案也比较简单，就是直接使用 HTTP，省去TLS Handshake的过程，那么自然就不会有 TLS 的传输了。
那么是否真的有效呢？验证一下就知道。
将请求协议改成 http 后：
求头确实不包含 TLS Handshake了!
整个请求只有 0.4kb，节省了 70% 的大小
目标达成
因此可以说明：在一些不是必须使用 https 的场景下，使用 http 会更加节省带宽。
同时因为减少了加密的这个过程，可以观察到的是，在相同的并发下，服务器的负载有明显降低。
那么问题来了
如果接口必须使用 https那怎么办呢?
当然还有另外一个解决方案，那就使用使用 Keep-Alive。
headers 中添加 Connection: keep-alive 即可食用。
通过启用 Keep-Alive，可以在同一TCP连接上发送多个HTTPS请求，而无需每次都进行完整的TLS Handshake，但第一次握手时仍然需要传输证书和完成密钥交换。
对于高并发的场景也非常适用。
要注意的是
keep-alive 是有超时时间的，超过时间连接会被关闭，再次请求需要重新建立链接。
Nginx 默认的 keep-alive 超时是 75 秒，Apache HTTP 服务器 通常默认的 keep-alive 超时是 5 秒。
ps：如果你的采集程序使用了大量的代理 ip那么
keep-alive的效果并不明显～～最好的还是使用 http
如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读：
一张图看懂微服务架构路线 基于Spring Cloud的微服务架构分析 微服务等于Spring Cloud？了解微服务架构和框架 如何构建基于 DDD 领域驱动的微服务？ 微服务架构实施原理详解 微服务的简介和技术栈 微服务场景下的数据一致性解决方案 设计一个容错的微服务架构
作者：麦麦麦造
来源：juejin.cn/post/7409138396792881186
版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
我们都是架构师！
关注架构师(JiaGouX)，添加“星标”
获取每天技术干货，一起成为牛逼架构师
技术群请加若飞：1321113940 进架构师群
投稿、合作、版权等邮箱：admin@137x.com
