Amir Zmora
加快了H.264和DTLS的认证速度
Chrome 52 beta的更新日志中写道此次更新修复了超过30个bug，并且在Chrome中支持H.264，以及改变了DTLS默认认证生成算法以获得更好的私密性和更出色的表现。这个版本会在7月26号那天发布给你的浏览器。
浏览器支持WebRTC H.264是IETF所要求的，并且对浏览器的互操作性以及和传统视频系统的连接性都十分的重要。
Chrome浏览器中WebRTC H.264的改善
在Chrome中支持H.264最早是Google在Chrome 50版本中提出的，但是那时有很多的限制，一些限制在Chrome 52版本中的H.264实现中得到了解决。
以下是改善的内容：
H.264目前能应用于所有桌面平台版本的Chrome。
硬件加速编码现在可以在OS X系统上使用。就像之前所说过的，硬件加速对整体表现和电池使用寿命都十分重要（不仅是针对移动端，对笔记本电脑和高性能服务器来说也是如此）。
在Windows版本的Chrome中，H.264编码所使用的还是SW编解码器，并且这个编解码器在未来的几个版本中还会是最佳选择。
WebRTC中的ECDSA：更安全、更快的表现
另外一项新加入Chrome 52的特征是，WebRTC中ECDSA（Elliptic Curve Signature Algorithm）的默认使用方式，替代了目前在DTLS握手中正在使用的1024位RSA秘钥。做出这项改变的原因有两个：速度，加密能力。
#速度：
之前的算法（1024位RSA）需要1秒左右来处理。由于ICE进程所导致的通话建立时间过长对于VoIP来说是一个大问题，而之前的算法又增加了额外的延时。在这里所采取的全新的算法（ECDSA）更快。有多快呢？大概是RSA的几千倍。
#加密能力：
1024位RSA的加密能力在当今的应用环境下是不够的。窃取RSA秘钥需要对大量的整数进行分解，而这项工作随着处理能力的增长也变得越来越简单，并且十分高效的算法已经被开发了出来。
我并不是一个加密方面的专家，但是ECC（Elliptic Curve Cryptography）能够用小的多的公共秘钥来给你提供同等级的安全保护。Chrome 52现在使用的是256位的ECC公共秘钥，它所能提供的安全级别与3072位的RSA公共秘钥所能提供的一样，但是ECC要快的多，所以使用它可以减少几秒的通话建立延时。
要注意互操作性之间的差别
将Chrome浏览器的默认算法更换到ECDSA可能会与目前还未支持它的系统产生互操作性的问题。尽管Google没有说RSA已经完全出局，但是总有一天一定会发生的。在一篇WebRTCStandards上的文章我们提到了这个事实—ECDSA目前是强制在WebRTC中实现的，这样以来Google在Chrome 52版本中所做的更改就说的过去了。在更新日志中还有更多关于Chrome 52版本的细节。
