Web 技术研究所

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

关于合并请求的优化方式

  早期的Opera浏览器对客户端发起的相同GET请求默认采取合并的方式处理,多个重复的GET请求服务器只需要处理一次。虽然在HTTP上这么优化不适用于某些非REST的构架,但这个优化方式确实值得学习,而且未必局限于HTTP请求,用于其它方面也没问题。
  严格来说,HTTP中的GET方法是幂等,但在很多非REST构架中常常被作为非幂等方法来使用,比如被用于访问量统计等。只有在REST的构架中才能保证GET方法的幂等性。而且也只有幂等的方法,合并请求才不会产生副作用。比如一个资源在服务器端嵌入了请改次数统计的程序,客户端如果采取合并请求的优化方式就可能使这个资源的请求数减少,造成服务器端无法得到准确的统计数据。如果服务器端只是提供一个普通的资源,客户端采取合并请求不当不会产生副作用,还可以节省重复通信的成本。
  也就是说,这种优化方式不适用于所有场景,所以浏览器不该内置它,目前较新的Opera中已经没有再使用这种优化方式了。但这种优化方式确实对某些场景很有效!在前端的应用有点类似之前文章中介绍的SharedWorker解决长连接冗余问题。其实也不局限于长连接,即使是普通的GET请求。当第一个请求已经发起但尚未加载完成时又有同样的请求被发起,程序就可以把之后发起的请求拦截下来,等待第一个请求完成后把第一个请求响应的数据分发给后面的请求。就像人大代表,一个就代表了后面的一群,后面的人该干嘛干嘛,它们都是社会的劳动力,不必在这种地方浪费。当然我们还是比较公平的,资源的分发还是人人有份的,不存在奇怪的问题。
  这个概念也不局限于HTTP。比如服务器程序也经常需要大量重复的SQL查询,虽然数据库程序本身可能有缓存机制,但HTTP服务器和数据库服务器的通信也需要时间,我们应该尽可能地把重复的查询留在HTTP服务器上,只对数据库服务器发起一次查询就能满足多个有同样数据需求的请求。
  这种优化方式还存在一个微小的数据延迟问题。比如第一个请求发起后的数据在加载过程中资源产生了更新,之后的请求即使是在更新后发起,被合并到第一个请求上的话也无法获取到更新的数据。不过我认为这只是理论上存在的问题,只有忽略网络延迟的理想状态下才会成为问题。当我们刷新页面时,可能在页面加载过程中页面的数据就被服务器更新了,这时客户端加载到的依然是更新前的数据。也就是说,由于网络延迟,本身就存在数据无法达到实时状态的问题。前面的情况只要客户端认为自己的请求在数据更新之前被服务器处理就不存在任何逻辑问题。
  其实这个合并请求的优化方式也不是什么新概念了,在后端早已普及。只是由于前端API比较弱,迟迟没普及上。不过现在也开始随着一些前端API的出现而逐渐成熟了。
网名:
54.226.58.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^