【实践】视频播放成功率下降很多？可能是你**管理的方式不对！
一、背景
某个客户原来业务使用了mp3作为播放格式，随着业务的发展，发现优质的内容经常被成批的下载，这样对客户来说是非常严重的损失，考虑到用户的播放需求需要在web浏览器也能够正常播放，以及整体改造成本，最终选择了HLS标准加密的方案来保护用户的内容。
接入加密播放以后，发现一个较严重的问题，客户端的播放成功率下降非常多，经过多方排查发现，这是因为特殊字符引发的一个问题。在解密播放的时候我们通过EXT-X-KEY中的URI无法正常获取到解密的KEY，后者是拿到的KEY不对。所以初步怀疑是业务服务器对**管理有问题。
本篇文章是由阿里云视频云高级技术专家王海华撰写，来记录本次问题的排查、解决方案与后续避免措施。
二、分析排查
通过跟客户业务服务器联调发现：播放器发起如下请求：
返回的是请求非法，根据业务方判断是MtsHlsUriToken的值不对！
打印了业务服务端获取到和url请求之前的各自的MtsHlsUriToken参数值发现：
IDXBq4HcS6VGUIh4iyUk3R2QnlGMS2MnWukBTqGhC oZxdeieVrAHVUU iwHN1kN
并非是之前下发的
IDXBq4HcS6VGUIh4iyUk3R2QnlGMS2MnWukBTqGhC+oZxdeieVrAHVUU+iwHN1kN
对比发现非常明显，url里面参数的特殊字符被转义给弄丢失了。跟客户沟通下来发现用户的业务服务环境是：spring boot 2.0 ，web容器是Tomcat。通过查阅资料和Tomcat的源码发现Tomcat默认会对URL的参数进行URLDecode导致了url里面的特殊字符被转义给丢失了，产生了一开始的问题。
整个问题排查过程还是比较简单的，但是从我们这个场景里面涉及到的交互非常多，很多环节都需要客户进行参与，我们如何能保证后续不出现这一类问题呢？我们可以从整个全链路的流程上来梳理一下。先看看整个HLS安全播放的整体业务流程。
三、安全播放之HLS标准加密
为了了解整件事情过程我们先了解一下整个HLS标准加密业务架构，业务流程和一些技术细节。
1. HLS标准加密之加密（转码生产流程）
先看一下我们如何得到一个加密的视频的。时序图如下：
名词解释
- 业务服务器：由客户开发，主要用户出发转码任务和接收回调（播放地址）
- MPS转码服务：进行转码加密；
- KMS：**管理服务；
- DK：秘钥明文（用户加密转码和解密播放的真正密文）；
- EDK：秘钥密文（经过加密的DK）；
关键步骤说明：
- 通过MediaId 从KMS生成秘钥（DK和EDK），后续可以通过EDK和MediaId重新从KMS中获取DK；
- 生成m3u8的时候在文件中加入：#EXT-X-KEY:METHOD=AES-128,并在URI=中添加MediaId + Ciphertext两个参数，后续业务服务器可以通过这两个参数中重新获得DK；
经过以上的步骤，加密后的视频（m3u8文件 和 加密后的ts文件）已经在OSS中了；
2. HLS标准加密之解密（解密播放流程）
要对视频进行解密播放有以下几个关键步骤：
- 拿到播放地址；
- 拿到秘钥；
- 解密播放；
同样我们也看看整个播放环节的业务流程和一些技术细节。
时序图如下：
关键步骤说明：
- 标准加密视频播放的时候需要业务服务器保护和颁发解密秘钥，获取播放地址的时候用户业务服务器需要判断请求是否合法，比如是否是登录用户等；
- 播放地址加上一个参数：MtsHlsUriToken，该参数有业务服务器生成，该主要用于后续获取解密key的时候进行合法认证；
- 标准加密场景中，m3u8中会添加扩展字段：#EXT-X-KEY:METHOD=AES-128,URI=，其中的URI一般都是指的是业务服务器，用来认证请求合法性和返回秘钥key；
- CDN业务中会自动修改m3u8的文件，把MtsHlsUriToken参数直接拼接在#EXT-X-KEY:METHOD=AES-128,URI= 之后；
- 播放器拿到 EXT-X-KEY-URI 后请求对应的服务器并拿到key；
- 播放器用这个key解密后续的ts文件进行播放；
- 建议：DK可以根据MediaId进行本地缓存，没有必要每次都从KMS中去获取；
四、后面如何避免？
- 建议MtsHlsUriToken参数值不要带URL的特殊字符；
- 如果用户无法避免MtsHlsUriToken重带有特殊字符则需要对MtsHlsUriToken参数值进行UrlEncode，我们的播放器逻辑和CDN逻辑不对参数做任何的修改；
- 需要让客户在对接的时候关注Web容器对URL的Decode处理；
五、附录衍生知识
1.form的enctype属性为编码方式，常用有两种：application/x-www-form-urlencoded和multipart/form-data，默认为application/x-www-form-urlencoded。
2.如何对Url中的非法字符进行编码:
Url编码通常也被称为百分号编码（Url Encoding，also known as percent-encoding），是因为它的编码方式非常简单，使用%百分号加上两位的字符——0123456789ABCDEF——代表一个字节的十六进制形式。Url编码默认使用的字符集是US-ASCII。
例如a在US-ASCII码中对应的字节是0x61，那么Url编码之后得到的就是%61，我们在地址栏上输入http://g.cn/search?q=%61%62%63，实际上就等同于在google上搜索abc了。又如@符号在ASCII字符集中对应的字节为0x40，经过Url编码之后得到的是%40。
对于非ASCII字符，需要使用ASCII字符集的超集进行编码得到相应的字节，然后对每个字节执行百分号编码。对于Unicode字 符，RFC文档建议使用utf-8对其进行编码得到相应的字节，然后对每个字节执行百分号编码。如"中文"使用UTF-8字符集得到的字节为0xE4 0xB8 0xAD 0xE6 0x96 0x87，经过Url编码之后得到"%E4%B8%AD%E6%96%87"。
如果某个字节对应着ASCII字符集中的某个非保留字符，则此字节无需使用百分号表示。例如"Url编码"，使用UTF-8编码得到的字节是 0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81，由于前三个字节对应着ASCII中的非保留字符"Url"，因此这三个字节可以用非保留字符"Url"表示。最终的Url编码可以简化 成"Url%E7%BC%96%E7%A0%81" ，当然，如果你用"%55%72%6C%E7%BC%96%E7%A0%81"也是可以的。