系统性能调优必知必会
陶辉
智链达 CTO,前阿里云 P8 高级技术专家
36367 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 47 讲
系统性能调优必知必会
15
15
1.0x
00:00/00:00
登录|注册

15 | 如何提升HTTP/1.1性能?

音视频压缩
图片压缩
服务器和客户端的压缩处理
Huffman算法
文本文件压缩
base64编码
资源打包工具
合并小文件请求
共享缓存
私有缓存
缓存过期处理
时间维度
有损压缩
无损压缩
延迟发送请求
合并请求
减少重定向次数
缓存类型
缓存机制
重新编码减少响应大小
降低HTTP请求次数
缓存避免发送HTTP请求
HTTP/1.1性能优化

该思维导图由 AI 生成,仅供参考

你好,我是陶辉。
上一讲介绍了为应用层信息安全保驾护航的 TLS/SSL 协议,这一讲我们来看看最常用的应用层协议 HTTP/1.1 该如何优化。
由于门槛低、易监控、自表达等特点,HTTP/1.1 在互联网诞生之初就成为最广泛使用的应用层协议。然而它的性能却很差,最为人诟病的是 HTTP 头部的传输占用了大量带宽。由于 HTTP 头部使用 ASCII 编码方式,这造成它往往达到几 KB,而且滥用的 Cookie 头部进一步增大了体积。与此同时,REST 架构的无状态特性还要求每个请求都得重传 HTTP 头部,这就使消息的有效信息比重难以提高。
你可能听说过诸如缓存、长连接、图片拼接、资源压缩等优化 HTTP 协议性能的方式,这些优化方案有些从底层的传输层优化入手,有些从用户使用浏览器的体验入手,有些则从服务器资源的编码入手,五花八门,导致我们没有系统化地优化思路,往往在性能提升上难尽全功。
那么,如何全面地提升 HTTP/1.1 协议的性能呢?我认为在不升级协议的情况下,有 3 种优化思路:首先是通过缓存避免发送 HTTP 请求;其次,如果不得不发起请求,那么就得思考如何才能减少请求的个数;最后则是减少服务器响应的体积。
接下来,我们就沿着这 3 个思路看看具体的优化方法。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

HTTP/1.1协议在互联网应用中广泛使用,但其性能备受诟病。一篇文章提出了三种优化思路来提升HTTP/1.1协议的性能:通过缓存避免发送HTTP请求、减少请求的个数、减少服务器响应的体积。首先,通过缓存可以避免发送HTTP请求,提高性能。缓存将请求及其响应保存在客户端本地磁盘上,后续相同请求可直接使用缓存,避免网络请求。其次,减少HTTP请求的次数可以通过减少重定向次数、合并请求、延迟发送请求等方式实现。最后,减少服务器响应的体积也能提升性能。文章还介绍了缓存的工作原理、重定向请求的处理、合并请求的方式以及减少响应包体体积的方法。这些优化思路和方法可以帮助提升HTTP/1.1协议的性能。文章还提到了重新编码以减少响应的大小的方法,包括无损压缩和有损压缩。无损压缩通过压缩后不损失信息来减少资源体积,而有损压缩则通过牺牲质量来提高压缩比,主要针对图片和音视频。此外,文章还介绍了使用KeepAlive长连接替换短连接等方法来提升HTTP/1.1性能。总的来说,本文全面介绍了HTTP/1.1协议的优化策略,为读者提供了全面的优化思路。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《系统性能调优必知必会》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(9)

  • 最新
  • 精选
  • Geek_007
    FB也搞了一套压缩算法ZSTD,对比起来也比gzip性能强很多,不清楚这些压缩算法的原理是啥,怎么对比,希望老师之后能答疑一下。另外普通的json和pb有不同适合的压缩算法吗?怎么比较呢?

    作者回复: 你好Geek_007,这3个问题我的看法如下: 1、压缩算法的原理都是基于香农的信息论,将高频出现的信息用更少的比特编码。虽然原理是一致的,但实现上却有很大的差别,比如Huffman通过建立Huffman树来生成编码,而LZ77却是通过滑动窗口,这造成压缩比、压缩速度都很不相同。 2、比较它们的优劣,主要看3个指标: a. 压缩比,比如brotli的压缩比好于ZSTD。 b. 压缩与解压的速度,比如ZSTD比gzip速度快 c. 浏览器等中间件的支持程度,现在几乎所有浏览器都支持brotli(即br),但ZSTD少有支持 3、没有最适合算法,对具体的场景,比较方法参见第2点

    2020-06-01
    16
  • Geek_007
    图片压缩,腾讯说他们的TPG比Webp压缩的更小呢😀,不过除了他们内部这么说,没见过第三方资料的证明

    作者回复: 关键还是看浏览器对格式的支持程度。目前,IE、Firefox、Chrome等主流浏览器都支持webp,但TPG就不好说了,除非产品用户主要在使用 QQ浏览器^_^

    2020-06-01
    6
  • 新声带NewVoice
    尝试过http1.1 chunk子协议,可以在同一个连接上,服务端向客户端发送多次数据。

    作者回复: 没错,有些消息推送是用chunk实现的

    2020-06-08
    3
  • 皮特尔
    最近正准备用gzip优化我们的一个后端服务就看到了这一讲,赶快试试Brotli算法

    作者回复: 在实践中学习,赞!

    2020-06-01
    3
  • 安排
    base64编码的作用是啥呢?只是为了把不可见字符变成可见的吗?搜到的资料都讲base64的实现原理但是并没有讲base64编码的作用的,好像挺多地方用到这个编码了。

    作者回复: 是的,就是为了转换可见字符,这样更方便交换

    2020-06-01
    6
  • 有铭
    Accept 头部中的 q 质量因子 ====== 想问一下,当服务器接收到这样的请求后,是背后的应用层处理这个压缩,还是说,支持这个标准的Http服务器本身就可以“透明”的完成这个压缩工作
    2020-06-01
    3
  • 那时刻
    一般来说客户端和代理服务器之间是https协议,而代理服务器和源站之间可以只使用http协议,减少https协议额外的消息交互。 另外在减少http包体方面,老师文中提到图片压缩,而对于非图片的传输,如定义的json结构,可以通过简化json里key,value的字节数来减少传输包体大小。
    2020-06-01
    2
  • 上杉夏香
    如果上述方法都采用了。那么只能提高HTTP请求的并发度了。 1、对于客户端来说,多开TCP连接的数量。 2、对于服务器来说,可以将相同域名解析到不同的IP,然后提供同样的服务。 本质上,都是为了增加TCP连接的数量。
    2022-07-03
  • 上杉夏香
    如果上述方法都尝试过。那么只能提高http请求的并发度了。
    2022-07-03
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部