W3C的规范中给出了一个方法来获得现在的网络状态navigator.connection；根据Working Draft 29 November 2012协议规范我们可以从接口中获得bandwidth（带宽，M/s）和metered两个参数的值；还提供了一个监听方法，来时刻监听接入环境的变化情况。现实中我们发现很多浏览器并没有返回bandwidth值，而且遵守了Working Draft 07 June 2011的协议返回给我们type（类型，wifi/2g/3g/4g）。
我们接下来就看看各家的支持情况
| Android 2.3+ Browser | UC | Dolphin | QQ浏览器 | Baidu | Firefox | Chrome | Opera Mini | Maxthon |
| Yes | No* | Yes | Yes* | Yes | Yes(New) | No | No | Yes |
说明下在iPhone中任何浏览器都无法得到相关信息。
通过上面的说明，我们发现还是可以通过这个参数了解很大一部分用户的联网情况的，并且为他们提供更加优质的体验。
接下来我们重点说说各浏览器的返回情况。
大部分浏览器会返回一个int型的类型，其中的特例是QQ浏览器，返回的就是类型名称，对应关系如下
| 返回值 | QQ返回值 | 类型 |
| 0 | unknown | UNKNOWN |
| 1 | ethernet | ETHERNET |
| 2 | wifi | WIFI |
| 3 | 2g | CELL_2G |
| 4 | 3g | CELL_3G |
| 5 | 4g | CELL_4G（中国现在也会出现这个值，是hspa+） |
| ? | none | NONE |
接下去是一个更大的特例，这就是firefox，他使用了新版规范，所以返回的是bandwidth；不过很奇怪的是只要是wifi或3G他就返回20，如果是2G返回的就是0.1953125；每次都一样不管现在网络状态到底是多少。这个问题还会继续跟进。
给大家提供一个demo地址：http://demo.jb51.net/js/2015/net.html
Demo中对不支持connection的浏览器直接返回了{type:0}，这样就很便利解决了某些浏览器不支持的问题；对于不支持又能上网的浏览器处理为“unknown”当然也是合乎情理的。
很多工程师觉得这个功能支持还不好，还是先不使用的好；但是我觉得只要错误能被处理，风险能被把控，为什么不给那些先天优秀的客户提供更友好的体验呢。
今天同学说到让后端判断速度，这个可能有点难；不过确实可以通过每次的异步请求去得到用户大概的速度（加载的时间和文件大小其实前端都能得到），然后在选择性的提供某些服务，之后也准备向这个方向上多思考下。
下载本文