通用浏览器插件技术概况与分析

目录

主要的浏览器插件技术

其它类浏览器插件技术

http通信

websocket通信

Firebreath相关介绍

浏览器控件发展趋势

---

 

浏览器插件是应用范围比较广的技术，因为一旦涉及到b/s模式开发，总会出现web端解决不了的情况，比如操纵硬件或本地文件等。即使html5的出现增强了web端的功能，但是就目前技术和发展趋势来看，浏览器插件技术无法被替代。然而在浏览器插件技术上，几大浏览器厂商一直“各自为政”，特别是谷歌，更是傲娇，给国内的开发者带来很多麻烦。

主要的浏览器插件技术

目前主要的浏览器插件技术有以下几种：

• ActiveX 控件

ActiveX控件是 ie 浏览器的专属技术，也是个比较古老的技术，国内各大银行的网银插件基本都是用ActiveX开发的，所以在使用网银转账的时候，很多网站都仅支持ie。但是近些年来随着手机支付技术的普遍（支付宝，手机银行，微信等），在网银支付这一块ActiveX技术也在逐渐没落。

• NPAPI 插件

NPAPI 插件同样是个逐渐没落的技术。浏览器基本是三巨头的天下（ie，谷歌和火狐），其实我觉得也就算两巨头，因为火狐虽然有自己的内核，但是在技术发展上有点唯谷歌马首是瞻的感觉，谷歌支持啥它就跟着来，谷歌要抛弃啥它也跟着来。国内比较主流的国产浏览器也基本同时使用了ie和谷歌的内核，比如qq、360这样的浏览器就同时支持双方的插件技术。之所以说NPAPI逐渐没落是因为谷歌浏览器自从v45版本后就不支持NPAPI了，火狐也宣布会抛弃NPAPI技术，现在要想使用NPAPI就必须降低浏览器版本。

为啥抛弃NPAPI呢，按谷歌官方的说法是NPAPI不安全，因为它又能操作本地文件又能控制硬件容易被不法分子使用。这一点我必须狠狠吐槽一下，怕摔倒就不走路了吗，我们为啥要用浏览器插件啊，大部分情况下不就是为了操作本地文件或硬件吗。比如某些情况下我需要插上ukey来验证身份，你谷歌说哎呀不安全，你插的ukey是微软系统加载的，我们的浏览器没法直接控制，你还是别用了吧~~~说的好听点是谷歌技术思路追求完美，说的难听的就是仗着自己牛叉就肆意妄为，完全不在乎开发者的想法，这一点苹果公司和谷歌很像，希望他们早点把自己作垮台。

• PPAPI 插件

PPAPI插件是谷歌用来替换NPAPI的，它使用了沙箱机制，所有操作全在沙箱内部完成。按谷歌的说法这是保证安全性的最佳方案。这种模式无法操作谷歌浏览器进程外的任何东西，所以如果需要开发能够控制外部设备的浏览器插件，PPAPI是不行的。在国内，PPAPI的意义不大，因为国内的商业项目使用插件的目的很多时候就是为了操纵本地设备。

• 谷歌本地消息机制（Native messaging）

这种技术是谷歌特有的一种，本质上不是插件而是扩展（关于谷歌插件和扩展的区别可以参考http://www.cnplugins.com/tool/the-diff-between-extensions-plugin.html），它的原理是在谷歌扩展中启动一个单独的进程，通过扩展和这个进程进行通信，业务操作都在这个外部进程中。因为是外部进程和谷歌沙箱没有依属关系，在这个进程中干什么都可以，包括操作本地文件和外部设备。

关于Native messaging 相关技术的具体介绍可以参考https://blog.csdn.net/lee353086/article/details/49362811。这种技术虽然能够满足插件开发的各种需求，但是有一个非常棘手的麻烦——谷歌太作了！自从v67版本后，谷歌浏览器不支持离线安装扩展，开发者开发完插件必须上传到谷歌商店上——只能在线安装。由于众所周知的原因，在国内基本没法使用谷歌商店，当然使用开发者模式还是可以离线安装的，但是商业化的时候总不能要求客户用开发者模式来安装产品吧。

这种现象，其实是有解决方法的，但是很不正规，说不定哪一天就不能用了，原理上就是使用hook或者破解技术强行修改谷歌浏览器的chrome.dll来绕过限制，这就属于黑客技术了，实际操作会非常麻烦。虽然现在可行，但是长期来看这种技术不可取。

Native messaging本地消息通信的demo和 破解安装的工具可以从这下载https://download.csdn.net/download/u010810750/10927754

其它类浏览器插件技术

上述几种浏览器插件技术基本上就是各浏览器厂商官方提供的“标准”技术了。综合来看如果要实现比较通用的跨浏览器插件解决方案只用以上方案是不太可行的，这才有了 “类浏览器插件技术”。

“类浏览器插件技术”这个名字是我随便起的，因为它根本就不算插件。解决思路原理上很简单，细节上比较复杂。主要原理就是创建一个本地进程来容纳业务功能，使用 js 脚本支持的通信协议来和这个本地进程通信来进行业务操作。这种方式和谷歌的Native messaging非常像，只是Native messaging是谷歌浏览器特有的，而且有着离线安装方面的缺陷，我们要实现的方案是通用的，理论上支持所有的浏览器，因为它只和js的特性有关。

比较靠谱的技术有两种：

http通信

这种方式就是在外部做一个http服务器（具体技术方案可参考https://blog.csdn.net/u010810750/article/details/81778731），js通过post或者get来和本地http服务进行通信。

这种方案首先需要解决一个跨域的问题，因为js端和本地http服务肯定不是一个域，关于跨域限制这里就不多说了，大家可以自行百度，这里只说解决方案。http跨域解决方案可行的只有两种：

一种是服务端core跨域，这种方式是服务端跨域，具体可参考https://blog.csdn.net/u014344668/article/details/54948546。解决方式其实就是在服务端返回的时候加上Access-Control-Allow-Origin就行了，例如：

	 mg_send_header(conn, "Access-Control-Allow-Origin","*");//允许所有外部跨域
	 mg_send_header(conn, "Access-Control-Allow-Methods","*");
	 mg_send_header(conn, "Content-Type","application/json");
	 mg_send_header(conn, "charset","UTF-8");
	 mg_send_header(conn, "Server","wz simple httpd 1.0");
	 mg_send_header(conn, "Connection","close");

Access-Control-Allow-Origin为*的时候指允许所有外部域和本域之间的跨域，如果是其它具体域名，比如“http://www.baidu.com”，就是指只允许百度和本域之间的跨域。

另一中跨域方式是jsonp，关于jsonp跨域的原理不在冗述，感兴趣的可以自行百度，具体方法可以参考https://www.jb51.net/article/112904.htm。jsonp跨域的缺陷在于js端只能使用get方式，如果通信数据比较大的时候需要特殊处理。

websocket通信

websocket没有跨域限制，而且是长连接，传递大数据比较方便。缺陷是低版本的浏览器，比如ie8就不支持websocket，需要js端用http协议来模拟websocket。

还有一个问题，是websocket和http通信都存在的，就是混合域问题。

混和域指的是浏览器在https域下的时候原则上是不允许和http域通信的。意思就是当web端使用https的时候，如果不修改浏览器配置，本地服务要么是https服务器，要么是websockets服务器。在实际项目中做一个https或者websockets服务器成本是比较昂贵的，因为要买证书。如果是内网环境就更麻烦了，浏览器根本没有办法验证证书的合法性，只能是修改浏览器安全配置比如 添加信任站点等。但是如果到了非要修改浏览器配置的地步，就根本没有必要搭建https或者websockets类型的本地服务了，因为混合域问题也是可以通过修改浏览器配置来解决的，至少在目前所有的浏览器都是可以通过修改配置来绕过混合域问题的。

而且本地的https或者websockets服务在安全性上没有任何意义，因为证书在本地，任何人都可以绕过TLS的防御。所以关于混合域问题，目前没有完美的解决方案。

不管是websocket还是http本地服务，都额外需要开端口，本地服务肯定需要一个端口才能起来。在某些商业项目上可能会有安全性的限制，这也是一个缺陷。

Firebreath相关介绍

firebreath是前些年在谷歌没有废除NPAPI技术的时候一个比较流行的插件，它融合了ie的activex，谷歌的npapi，提出了统一接口而且支持linux系统，是前些年最完美的插件解决方案，具体可以参考https://blog.csdn.net/luoweifu/article/details/44603645。

目前还是可以使用的只是不支持高版本的谷歌，目前比较成熟的版本是1.7版本。如果想使用NPAPI技术，特别有linux平台开发需求的时候，推荐直接使用firebreath1.7。

目前还有个未完成的firebreath2.0版本，目的是为了解决NPAPI被废弃的问题，开发团队的想法也是通过支持谷歌本地消息机制和websocket或者http来实现通用版本。但是这个版本进度很慢，我感觉会无疾而终。

浏览器控件发展趋势

目前的浏览器市场，谷歌是最有话语权的，但是它完全不考虑开发者的实际需求。ie插件技术支持比较完善，但是微软在浏览器这一块也是日薄西山，国内的商业浏览器都是吃这两个巨头剩下的饭，没什么自主创新能力。再加上国内政策上的限制，国内开发者在浏览器插件开发上非常被动，目前基本属于各自瞎搞的状态。

浏览器控件的使用也逐渐偏向特化，比如之前大众都使用的网银ukey，现在也基本被手机代替了，商业化的项目现在是还没统一规范。浏览器插件的应用我感觉会逐步偏向特殊行业，比如国企和事业单位的社会服务和内部办公使用，这一块国家已经明确开始国产化的进程，如果进展的比较顺利的话应该会由政府牵头来形成统一的浏览器插件标准甚至是完全自主的国产浏览器。这一天能不能到来不好说，即使能到来也不是短期能有的结果，相信国内苦逼的开发者在很长时间内还会“凑合的过日子”。不过长期看来，去谷歌化会是最终的结果，因为谷歌的不走寻常路那一套在国外还有的混，但是在中国内地，和国情冲突太大，我相信谷歌的产品和技术最终会被淘汰，同样命运的还有苹果公司，毕竟——这是在中国....................................