Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

「减少网络请求」的魔咒

  我们一直提倡减少 HTTP 请求的次数,但有时候减少过头也不好。将 HTTP 请求数限制在一个可以承受的最大范围内才是最好的做法。请求多了虽然会产生额外的数据通信,增加服务器负担,但也增加的 HTTP 的重传力度。要是网络非常不稳定,多请求反而会比单请求更快。

关于下载

  其实 TCP 是一个很坑的协议,平时使用 HTTP 下载时候就经常遇到卡死的情况。或者使用 FTP 传文件的时候经常卡死?要是工具没有提供断点续传,那简直会让人带恨。迅雷下载之所以快,很大一部分原因就是它使用了多通道下载,避免了单个 TCP 卡死的情况。只要资源充分,客户端总是可以跑到带宽的极限速度。不过虽然这样的下载方式很快,但它占用了太多资源,有时也会被人嫌弃。

合理分配连接

  做网络请求优化也是同样的概念,客户端如何才能快速获取到服务器的资源。或者说,在获取能力有限的情况下,如何才能先获取重要的资源。浏览器给单个域名提供的请求数量是有限的,所以无法像迅雷一样同时发起几十上百个 TCP 链接。我们还应该避免出现连接数耗尽的情况,合理分配链接。比如目前浏览器对单个域名分配的连接数普遍为 6 个,那么拿其中 3 个作为静态资源加载,再拿 2 个给 API 通信,剩下的预留给新页面。这么分配才符合共产主义的价值观!

关于实现

  遗憾的是浏览器并没有原生提供这么灵活的请求控制方案,很多时候需要通过自己的程序来解决。比如让所有静态资源都使用 LazyLoad,然后封装一个限制 XHR 数量的加载器。甚至对这些加载器设置一个可控的超时时间(原生 XHR 对象的 timeout 太扯淡)。这些都是可以实现的。

什么时候需要合并?

  最理想情况是根据网络环境来判断。在网络很稳定的环境中应该尽可能地合并请求,因为稳定的网络不怕 TCP 卡死问题。而在网络不太稳定但带宽充足的情况就应该减少合并。但问题是我们很难判断客户端的网络状况,而且这种东西不确定性太高。比如一个原本很稳定的网络,由于局域网突然有人开迅雷下种子,于是各种掉包。如果一开始就判断好用户的网络环境,很难在任何时候都管用。这个纠结的问题应该通过一种更高端的方式来解决,目前我还在摸索阶段,暂时无法提供一个成熟的方案。

总结

  减少请求数量,减少 HTTP 连接数,这个优化理念已经深入人心。但何时才应该合并,才是问题的关键。一味地合并请求,不去了解具体的原理,最终可能会适得其反。

网名:
54.198.108.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^