18 | 传输链路，优化HTTP传输速度的小技巧
以优化链路传输为目的的前端设计原则未来或许不再适用
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了优化HTTP传输速度的技巧，重点介绍了HTTP/2的多路复用技术。作者首先指出了传统优化原则的局限性，以及连接复用技术的优势和缺陷。随后，详细解释了HTTP/2的多路复用技术，通过引入帧作为最小粒度的信息单位，实现了在同一个TCP连接中传输多个数据帧，并能轻松区分不同流中的数据，从而解决了HTTP/1.x中的队首阻塞问题。此外，文章还强调了HTTP/2的单域名单连接机制，使得合并资源和域名分片反而对性能提升不利。总的来说，本文通过对HTTP传输优化技术的发展历程和技术特点的深入分析，为读者提供了有益的参考和启发。 文章还讨论了在链路优化中除缓存、连接之外的另一个重要话题：压缩。HTTP早期就支持了压缩，对文本数据启用压缩的收益很高，而现代的Web服务器处理能力提升后，采用即时压缩，改善Web性能体验。然而，即时压缩与持久连接机制存在冲突，而HTTP/1.1通过分块传输解决了这一问题。到了HTTP/2，由于多路复用和单域名单连接的设计，不再需要刻意强调持久连接机制，但数据压缩仍然具有重要价值。 此外，文章还介绍了最新一代HTTP/3协议的设计重点，即QUIC传输协议的特点和优势。QUIC以UDP协议为基础，具有独立的可靠传输能力和面向移动设备的专门支持，为网络链路传输领域带来了新的可能性。 综上所述，本文深入剖析了HTTP传输优化技术的发展历程和技术特点，为读者提供了对HTTP/2多路复用技术和数据压缩的全面了解，同时也展望了未来HTTP/3协议的发展趋势。
请先领取课程
全部留言(13)
- 最新
- 精选
Jxin
QUIC相对于TCP补充: 1.自定义重传机制:TCP是通过采样往返时间 RTT 不断调整的，但这个采样存在不准的问题。第一次发送包A超时未返回，第二次重发包A，这时收到了包A的响应，但TCP并不能识别当前包A的响应是第一次发送还是第二次重发返回的，这时不管怎么减都可能出现计时偏长或过偏短的问题。而QUIC为每次发送包都打了版本号（包括重发），所以可以很好的识别返回的包是那次发送包的。进而计算就相对准确。 2.自定义流量控制：TCP 的流量控制是通过滑动窗口协议，是在连接上控制的窗口。QUIC也玩滑动窗口，但是力度是可以细分到具体的stream的。 其实应用层的协议多种多样，直播的RTMP，物联网终端的MQTT等等，但感觉都是两害取其轻的专项优化对症下药。只有QUIC，直面TCP的问题，通过应用层的编码实现，系统的提供更好的"TCP连接"。作者回复: 感谢补充
2020-12-2851
zhanyd关于多路复用技术，在网上看到一个例子： 比如你去餐厅吃饭，你点了一盘炒饭和果汁。 如果是HTTP/1.1，你就得叫两个服务员过来，一个服务员给你送炒饭，另一个服务员给你送果汁； 如果是HTTP/2，你只用叫一个服务员过来，这个服务员会同时把炒饭和果汁送过来。 HTTP/2 还有一个Server Push特性，允许服务器主动向客户端推送资源，比如客户端当前请求获取一个HTML页面，服务器会主动把相关的资源，比如：js，css同时推送给客户端，不用等客户端专门发起请求了。 比如你去餐厅吃饭，点了一盘炒饭，服务员猜你可能还会要一杯水，就把炒饭和水一起端给你了。作者回复: 关于server push，有一些隐藏的风险，这里既然提到了我就补充提示一下： 1. server push在HTTP/2协议中是一个可选（optional）特性，这意味着即使兼容HTTP/2，也不一定就是支持server push的。 2. server push在HTTP/2、gQUIC、HTTP/3中的实现细节并不完全一致，服务端的技术框架有可能会兼容屏蔽掉差异，但也有可能会产生额外的影响。 3. 最重要一点，目前主流的chromium浏览器内核在2020年末已经宣告即将移除对HTTP/2和gQUIC的server push的支持，也明确未来不会支持HTTP/3的server push。（https://www.ctrl.blog/entry/http2-push-chromium-deprecation.html） 所以，建议是：尽量不要依赖server push去设计功能。如果确实要做，可以考虑不依赖协议的支持，而是以最传统的基于长轮询的方式去做。就是以前的Comet推送。（https://en.wikipedia.org/wiki/Comet_(programming)）
2020-12-29433
漂泊的小飘我有点疑问，就是压缩和链接复用冲突的问题： 为什么不能先压缩再计算content-length呢？ chunk不就是先压缩再计算长度吗？ content length和chunk不都是字节流吗作者回复: 因为这样就必须先等压缩过程完全结束之后才能知道准确的content-length，才能开始向客户端返回响应。现代Web服务器都将TTFB作为最重要指标之一，通过On-The-Fly Compression一边响应一边压缩，因而放弃content-length。
2021-03-0513- Helios以前就是面试前会看看，看的也挺稀里糊涂的。 今天虽然听的也有点稀里糊涂，但是从时间线的维度还是深入了一些。2021-02-045
大力水手Jerry一课一思：如果已知服务端支持HTTP/2，则可以尽量采用HTTP/2，简化前端的开发tricks，提高编码的标准化程度。对于公司应用之间的请求，如果涉及较大数据量传输，如果基础设施支持，则可尝试HTTP/3，提升传输的效率。2021-03-151
昵称看了这么多节觉得这套课程是讲原理的，并没有涉及到具体的技巧之类的，就拿优化HTTP来说，并没有需要程序员专门做的事情，浏览器、运营商什么的已经实现好了，我们直接用就行，学习这套课就是弄懂了原理，打算跳槽的准备面试的可以看一看2023-08-29归属地：山西
李树增老师，请教个问题，在网络上没有找到相关资源可以解答： 1、静态字典和动态字典客户端和服务端都应该存一份，他们分别是存储在什么地方的？更新动态字典是如何保证数据映射的一致性的？2023-03-03归属地：浙江- 守望_Wilbur对于队首阻塞问题，这不是资源不够引起的么，解释不是队首非队首的原因吧，队列中的资源都可以被异步地获取去使用，造成阻塞是由于资源不足，那不就跟客户端或服务端预留资源这种模式无关了么2022-11-12归属地：广东
Allen应该还是http1.x的版本2021-12-23
在路上精彩，太精彩了！2021-07-01