一篇有关浏览器的研究报告

旧时模样 提交于 2020-04-05 21:07:56
如果要问开发与web有关的应用,使用最频繁和打交道最多的软件是什么,一定非浏览器莫属。作为一款程序员“最爱”的浏览器——Chrome,你是否关心过它的特性?本文将带你了解Chrome将如何处理你的请求与响应。

Chrome如何处理并发请求

无论你是否听说过RPC,说起请求-相应一定不会陌生。当前端(通常是JavaScript)开始发起一个请求的时候,我们会使用Promise来等待应答。根据http1.1的描述,客户端和服务端之间通过复用长连接(keep-alive)来提高通信效率。那么你是否考虑过,当你同时发送多个请求时,浏览器是如何将应答准确的返给Promise的呢?

http1.1协议有一段相关的描述:允许客户端同时发送多条请求,但是服务端必须按照请求的顺序返回响应[1]。说实话,我一直怀疑这句描述的真实性。首先,网络如何确保服务端收到的请求顺序一定与客户端发送顺序一致。其次,与客户端相比,服务端的压力都比较大,在处理业务运算之外还要额外保证应答顺序,是否具有可操作性。最后,与第一个问题类似,客户端如何确保收到的应答顺序就是服务端的发送顺序。

或许你会认为:http建立在tcp/ip协议之上,帧顺序的问题已经由下层协议保障了。请注意,tcp/ip的超时重发与帧校验机制只是保证了所有的帧数据都会被正确发送,并没有保证http报文顺序一致。事实上,互联网也无法保证帧的发送顺序与接收顺序一致,只是在帧结构中安排了一个类似id的字段,使得接收端在获取了完整的http包后可以根据这个字段将数据帧排序,并且在check到数据帧发生错误的时候能够让上一跳路由重发。因此如果按照[1]的描述,我们设想一个极端场景:客户端连续发送了多条请求,服务端发现第1个请求的某一帧数据发送错误,请求重发。与此同时,后续的请求都正确接收。那么服务端是先处理其它请求还是先缓存数据等到第1条请求被正确接收后再一起处理呢?抑或是将应答缓冲,等待之前的请求都处理完成以后才能发送?所有这些情况都会使得协议的实现变的非常困难。如果你曾经在项目中设计过WebSocket,就一定不难理解如何将多个业务请求服用到一条链接上,设计出让业务层能够方便使用的接口其实是非常困难的。

本着自己动手丰衣足食的原则,我尝试利用浏览器的异步请求功能(AJAX)发送多条请求,然后在服务端对每一条请求都休眠几秒来观察效果。

 对于Chrome浏览器而言,并不存在连续请求。每条连接上,一下条请求都是在等到上一条响应到达后才会发出,为了提高通信效率,浏览器允许的连接并发数为6条。或许你会问,在使用JavaScript发送请求的时候并没有等待操作。那是因为JavaScript只是一种与浏览器交互的语言,真正执行请求功能的是在浏览器中运行的C/C++代码。我曾经利用H5的<video>播放流媒体服务器上的rtmp流,结果也发现Chrome最多只能支持6个画面,这也从侧面印证了浏览器存在请求并发上限的情况。

WebSocket是否存在并发上限

Chrome浏览器普通请求的连接并发数为6条,那么同样作为WebSocket的长连接是否也存在相似的情形呢?为了我也做了一个简单的测试,结果发现并没有。无论你同时初始化多少条WebSocket连接,都可以正确的和服务端建立连接。

 

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!