只因把 https 改成 http，带宽减少了 70%！

主要观点总结

文章主要关于Boot+Cloud项目的学习，针对高并发采集服务上行带宽问题，通过了解TLS Handshake和HTTP协议来优化请求大小，同时介绍了使用Keep-Alive来减少TLS握手次数的方法。此外，还推荐了一个电商系统开源项目mall及其视频教程。

关键观点总结

关键观点1: 高并发采集服务导致的上行带宽问题

文章起因是一个高并发的采集服务上线后，100m的上行很快被打满。通过对请求的分析，发现TLS Handshake占用了大部分带宽。

关键观点2: HTTP与HTTPS协议对比

在不是必须使用https的场景下，使用http会更加节省带宽。因为省去TLS Handshake的过程，可以大大减少传输大小。

关键观点3: 使用Keep-Alive优化HTTPS请求

对于必须使用https的场景，可以通过使用Keep-Alive来减少每次请求时的TLS握手次数。但需注意keep-alive的超时时间设置。

关键观点4: 推荐的电商系统开源项目mall

文章推荐了一个基于SpringBoot3和Vue的电商系统mall，后端支持多模块和微服务架构，可通过Docker和K8S部署。包括完整的订单流程、商品、权限等功能。

文章预览

Boot+Cloud项目学习： macrozheng.com 作者：麦麦麦造 来源：juejin.cn/post/7409138396792881186 起因 是一个高并发的采集服务上线后，100m的上行很快就被打满了。因为这是一条专线，并且只有这一个服务在使用，所以可以确定就是它导致的。 但是！这个请求只是一个 GET 请求，同时并没有很大的请求体，这是为什么呢？ 于是使用 charles 重新抓包后发现，一个 request 的请求居然要占用 1.68kb 的大小! 其中TLS Handshake 就占了 1.27kb。 这种情况下，需要的上行带宽就是： 1.68*20000/1024*8=262.5mbps 也就说明100mbps的上行为何被轻松打满 这或许是一个对你有用的开源项目 ，mall项目是一套基于 SpringBoot3 + Vue 的电商系统（Github标星60K），后端支持多模块和 2024最新微服务架构 ，采用Docker和K8S部署。包括前台商城项目和后台管理系统，能支持完整的订单流程！涵盖商品、订单、 ………………………………