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

如果要问开发与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连接，都可以正确的和服务端建立连接。