WEBGIS发展了这么多年，一些新东西出来兴许能让地图性能得到一些优化，加快地图访问和加载速度。
自2013年HTTP/2推出以来，HTTP/2已经得到了长足发展，知乎，豆瓣等国内大型平台也已经部分切换到HTTP/2了。它有多路复用请求、对请求划分优先级、压缩HTTP头、服务器推送流等优点，而且目前除了IE系列（Win10上IE11除外）外其它浏览器都已经支持了这一特性。
既然不阻塞，正好可以应用到WebGIS上面，地图服务通常是以瓦片的形式传输数据，以现在1920*1080分辨率显示屏打开二维地图通常需要加载40个png格式的瓦片图片，如果按Chrome浏览器同域下只有6个并发计算，需要请求7个批次，传输效率当然会比较低。
我从2年前就有了此设想，当时使用Node.js写了后端代码作为服务器，分别生成了一组单图大小为200kb左右的大图片和只有2kb的小图片做测试，当时得出结论为：HTTP/2在传输大量小图片时会有比较明显的效率提升，在传输大图片时效果就不是那么明显了。
最新的测试方案是基于nginx的，这套方案实现起来比较简单，把前端代码和瓦片资源放到nginx的目录里，再修改.conf文件的https部分就可以了，这种配置方式还可以同时访问http1.1和HTTP/2，测试很方便。HTTP/2配置如下：
server {
listen 443 ssl http2;
server_name localhost;
ssl_certificate ./cert/localhost.pem;
ssl_certificate_key ./cert/localhost-key.pem;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
root html;
index index.html index.htm;
}
}
实验证明三维框架上加载3dtile时http/2与http1.1相比效率几乎没有提升。所以开始根据猜测排查问题：
1.生成的ssh证书不合法，不被chrome信任，所以http/2实际是失效的。
2.换用mkcert工具生成可被chrome信任的合法证书后问题还在。怀疑是三维框架与二维框架资源加载机制和算法不太一样，这不是http/2慢不慢的问题，而是前端有没有向后端请求这个资源的问题。
3.搭建了二维框架的测试环境测试后仍然没效果。再从网上下载一批影像数据并搭建二维地图测试环境研究后觉得不是框架问题，应该是chrome浏览器又做了优化，去掉了http1.1的单域名下请求数量限制。
4.把单次瓦片请求量增大，仔细观察chrome的network请求时间信息后发现也不是chrome去掉了限制。很可能是本地测试时网络比较好的原因，虽然通过浏览器我们可以限制网速，但我们无法限制网络使它需要通过多个交换机，路由器，来增加数据传输和tcp连接握手的时间。简单讲就是http/2解决的就是tcp通过很多路由器实现多次握手造成的无用时间开销，但在本地测试时这些时间开销几乎是忽略不计的，而且由于http/2是基于https的，它还有一个加密的时间开销，所以就比http1.1慢了那么几毫秒。
5.花100块租了个阿里云来验证是不是本地网络的问题。实践证明，在阿里云上部署好后从我的笔记本上访问地图时http/2和http1.1的速度还是相差无几。难道单个图片还是不够小？（有个意外收获，对于做政企服务类的公司倒是可以试用一波阿里云的按量付费模式，不演示的时候还可以停掉不花钱）
6.翻看了以前的测试数据，拿小数据集测试的时候小的图片都只有几kb，现在每一张图都有上百kb，在之前的测试里面它应该算是大的图片了。重新编写了测试，发现在同时加载40张240kb大图时http/2与http1.1差异不明显，同时加载40个只有4kb的小图时http/2速度差不多是http1.1的两倍，如果换到400个小图同时并发时http/2的速度差不多是http1.1的4倍。由此可见是单个资源大小导致http/2和http1.1的差异不明显。
7.观察发现，在WebGIS中，一个影像瓦片至少有100kb，矢量瓦片可以小到几kb，所以当请求的瓦片数量一致时，http/2应用在矢量瓦片传输上应该会有比较明显的效果。
最终结论：
HTTP/2对WebGIS效率提升帮助不大，借机把地图服务更新到https让服务更安全倒是可以。
两年前就开始研究想把它应用起来解决WebGIS传输问题，现在的测试结果还是有些让我失望。
网友评论