你看那个 HTTP ,它飞起来了(二)

简介: 今天一起来研究Http协议的一些事情

3.3 多路复用

1.1版本中存在队首阻塞问题,因此如果客户端要发起多个并行请求来提升性能,必须使用多个 TCP 连接,这样就要承受更大延时和建链拆链成本,不能有效利用TCP链接。

由于2.0版本中使用新的二进制分帧协议突破了1.0的诸多限制,从根本上实现了真正的请求和响应多路复用

客户端和服务器将交互数据分解为相互独立的帧,互不影响地交错传输,最后再在对端根据帧头中的流标识符把它们重新组装起来,从而实现了TCP链接的多路复用。

如图展示了2.0版本的基于帧的消息通信过程(图片来自参考4):

微信图片_20220412192051.png

微信图片_20220412192209.png


3.4 首部压缩

A.Header 冗余传输

我们都知道 http 请求都有 header 部分,每个包都有并且相对于一条链接而言大部分的包的 header 部分都是相同的,这样的话每次传输相同的部分确实非常浪费

 

现代网络中每个网页平均包含100多个http请求,每个请求头平均有300-500字节,总数据量达到几十KB以上,这样可能造成数据延时,尤其复杂的WiFi环境或者蜂窝网络,这样只能看到手机在转圈,但是这些请求头之间通常几乎没有变化,在本已经拥挤的链路中多次传输相同的数据部分确实不是高效做法。

基于 TCP 设计的拥塞控制具有线增积减 AIMD 特性,如果发生丢包那么传输速率将大幅度下降,这样在拥挤的网络环境中大的包头意味着只能加剧拥塞控制造成的低速率传输

B.Http 压缩和犯罪攻击

在2.0版本的 HPACK 算法之前,http 压缩使用 gzip 去压缩,后来提出的 SPDY 算法对 Headers 进行特殊设计,但是它依旧使用的是 DEFLATE 算法

在后面的一些实际应用中发现 DEFLATE 和 SPDY 都有被攻击的危险,因为DEFLATE算法使用后向字符串匹配和动态 Huffman 编码,攻击者可以控制部分请求头部通过修改请求部分然后看压缩之后大小改变多少,如果变小了攻击者就知道注入的文本和请求中的某些内容有重复。

这个过程有点像俄罗斯方块的消除过程,这样经过一段时间的尝试数据内容就可能被全部搞清楚,由于这种风险的存在才研发出更安全的压缩算法。

C.HPACK 算法

2.0版本中HPACK算法在C/S中使用首部表来存储之前发送的键值对,对于相同的数据通信期间几乎不会改变的通用键值对只需发送一次即可。

极端情况如果请求头每次没有变化,那么传输中则不包含首部,也就是首部开销就是零字节如果首部键值对发生变化了,也只需要发送变化的数据,并且将新增或修改的首部帧会被追加到首部表,首部表在链接存活期始终存在, 并且由客户端和服务器共同更新和维护

简单说就是客户端和服务端共同维护了一个 key-value 的结构,发生变化时则更新传输,否则就不传输,这样相当于首次全量传输之后增量更新传输即可,这个思想在日常开发中也非常普遍,不用想的太复杂。

如图展示了首部表的更新过程(图片来自参考4)

微信图片_20220412192100.jpg

hpack算法的相关文档:

 

https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12

3.5 服务端推送

服务端推送是2.0版本新增的一个强大功能,和一般的一问一答式的C/S交互不同,推送式交互中服务器可以对客户端的一个请求发送多个响应,除了对最初请求的响应外还向客户端推送额外资源,无需客户端明确地请求也可以推送。

举个栗子:

想象一下你去餐厅吃饭,服务好的快餐厅在你点好一份牛肉面之后,还会给你送上餐巾纸、筷子、勺子甚至调料等,这样主动式的服务,节约了客人的时间并且提高了用餐体验。

在实际的 C/S 交互中这种主动推送额外资源的方法很有效,因为几乎每个网络应用都会包含多种资源,客户端需要全部逐个获取它们,此时如果让服务器提前推送这些资源,从而可以有效减少额外的延迟时,因为服务器可以知道客户端下一步要请求什么资源。

如图为服务端推送的简单过程(图片来自参考4)

微信图片_20220412192105.png

4. 总结

本文通过介绍 Http 协议的历史演进、各个版本的主要特征和优缺点、重点介绍了Http 2.0协议的一些特性,包括:SPDY协议、二进制分帧协议、多路复用、首部压缩、服务端推送等重要功能,篇幅有限不能展开太多

虽然 http 2.0版本协议有很多非常优秀的功能并且在2015年正式发布,现在国内外一些大厂基本都有使用 http 2.0承担部分请求,但是目前仍然未广泛普及

目前http3.0版本在2018年也推出来了,至于 http 2.0和 http 3.0的推广和普及是需要时间的,但是坚信我们的网络可以更安全、更快捷、更节约

本次的旅程就此结束啦,期待下一次的航行!

5.巨人的肩膀

  1. https://juejin.im/post/5d9abde7e51d4578110dc77f
  2. https://lixiaoyu.cc/2018/09/04/computer-network-12-http-version-differences/
  3. https://www.ibm.com/developerworks/cn/web/wa-http2-under-the-hood/index.html
  4. https://developers.google.com/web/fundamentals/performance/http2?hl=zh-cn
  5. https://hpbn.co/primer-on-web-performance/#latency-as-a-performance-bottleneck
  6. https://httpwg.org/specs/rfc7540.html
  7. https://juejin.im/post/5d033d3df265da1baa1e700e
  8. https://juejin.im/post/5da16e9ef265da5b76373d0e
相关文章
|
2天前
|
弹性计算 运维 搜索推荐
三翼鸟携手阿里云ECS g9i:智慧家庭场景的效能革命与未来生活新范式
三翼鸟是海尔智家旗下全球首个智慧家庭场景品牌,致力于提供覆盖衣、食、住、娱的一站式全场景解决方案。截至2025年,服务近1亿家庭,连接设备超5000万台。面对高并发、低延迟与稳定性挑战,全面升级为阿里云ECS g9i实例,实现连接能力提升40%、故障率下降90%、响应速度提升至120ms以内,成本降低20%,推动智慧家庭体验全面跃迁。
|
3天前
|
数据采集 人工智能 自然语言处理
3分钟采集134篇AI文章!深度解析如何通过云无影AgentBay实现25倍并发 + LlamaIndex智能推荐
结合阿里云无影 AgentBay 云端并发采集与 LlamaIndex 智能分析,3分钟高效抓取134篇 AI Agent 文章,实现 AI 推荐、智能问答与知识沉淀,打造从数据获取到价值提炼的完整闭环。
352 91
|
4天前
|
SQL 人工智能 自然语言处理
Geo优化SOP标准化:于磊老师的“人性化Geo”体系如何助力企业获客提效46%
随着生成式AI的普及,Geo优化(Generative Engine Optimization)已成为企业获客的新战场。然而,缺乏标准化流程(Geo优化sop)导致优化效果参差不齐。本文将深入探讨Geo专家于磊老师提出的“人性化Geo”优化体系,并展示Geo优化sop标准化如何帮助企业实现获客效率提升46%的惊人效果,为企业在AI时代构建稳定的流量护城河。
373 156
Geo优化SOP标准化:于磊老师的“人性化Geo”体系如何助力企业获客提效46%
|
4天前
|
域名解析 人工智能
【实操攻略】手把手教学,免费领取.CN域名
即日起至2025年12月31日,购买万小智AI建站或云·企业官网,每单可免费领1个.CN域名首年!跟我了解领取攻略吧~
|
10天前
|
人工智能 自然语言处理 前端开发
Qoder全栈开发实战指南:开启AI驱动的下一代编程范式
Qoder是阿里巴巴于2025年发布的AI编程平台,首创“智能代理式编程”,支持自然语言驱动的全栈开发。通过仓库级理解、多智能体协同与云端沙箱执行,实现从需求到上线的端到端自动化,大幅提升研发效率,重塑程序员角色,引领AI原生开发新范式。
880 156
|
3天前
|
数据采集 缓存 数据可视化
Android 无侵入式数据采集:从手动埋点到字节码插桩的演进之路
本文深入探讨Android无侵入式埋点技术,通过AOP与字节码插桩(如ASM)实现数据采集自动化,彻底解耦业务代码与埋点逻辑。涵盖页面浏览、点击事件自动追踪及注解驱动的半自动化方案,提升数据质量与研发效率,助力团队迈向高效、稳定的智能化埋点体系。(238字)
260 156
|
11天前
|
机器人 API 调度
基于 DMS Dify+Notebook+Airflow 实现 Agent 的一站式开发
本文提出“DMS Dify + Notebook + Airflow”三位一体架构,解决 Dify 在代码执行与定时调度上的局限。通过 Notebook 扩展 Python 环境,Airflow实现任务调度,构建可扩展、可运维的企业级智能 Agent 系统,提升大模型应用的工程化能力。