基础防盗链

主要是对客户端请求所携带的一些关键信息来验证请求的合法性，比如客户端请求IP，请求URL中携带的Referer。优点是规则简单，缺点是这些信息都可以伪造，可靠性较低。

IP访问控制

IP地址在互联网上具有唯一性，我们可以针对异常的请求客户端的IP进行限制，以达到访问控制的目的。
1. 支持对一个或多个IP的访问控制
2. 针对IP段进行限制
3. 对区域进行访问限制

Referer防盗链

Referer在HTTP协议中有特殊的用途，当浏览器向服务端发送请求时会带Referer头，告知该请求是从哪个链接来的。常用于页面访问统计，图片的防盗链。

流媒体直播同样适用，当发送请求到达CDN服务器后，CDN服务器检查客户URL中是否有符合预先规定的Referer，来决定禁止或允许该请求。

注意事项

  1. 应特别指明空引用的处理方式，即该请求头中没有携带Referer头部，通常是直接在浏览器访问该URL或通过非浏览器的方式访问时，请求头不会带有Referer头部，默认采用禁止空引用的方式，当然可以自定义规则。
  2. Refer很容易伪造，因此Referer防盗链安全性较低

高级防盗链

流媒体直播中，常采用时间戳防盗链、swf防盗链、回源鉴权防盗链等方式。时间戳防盗链的特点是加密的URL具有时效性，无法伪造，当到达过期时间后URL不再被允许访问，适合一些对“时效性”有要求的场景。使用时间戳防盗链需要内容提供商和CDN服务商配合，内容提供商负责生成加密的URL，CDN服务商负责根据预先设定的规则对URL进行合理化验证。时间戳是由于实现原理简单、可靠性高、推荐使用。

swf防盗链为RTMP协议所特有，其特点为客户需要提前将swf文件上传到CDN节点，有客户端和CDN节点在请求过程中基于规定的算法进行加密和解密验证，CDN验证通过则响应该请求，验证失败则拒绝。

回源鉴权的特点是CDN节点每次接收到的请求，都需要先回源进行验证，验证通过才认为请求合法，继续提供服务，适用于对防盗链有很高的实时性要求的场景。另外，一些具有特殊性的防盗链，CDN默认不支持的情况下也可以考虑采用回源鉴权的形式。

时间戳防盗链

原理

  1. 当用户发起请求视频播放时，用户的请求会被引导至客户端源站。例如，终端用户发送的请求URL为：http://www.example.com/test.flv
  2. 源站通过一系列参数共同加密生成一串密文wsSecret。
  3. 终端用户利用源站返回的URL，重新向服务商CDN发起请求。
  4. 服务商CDN节点进行验证，请求是否过期以及加密穿是否匹配。

目前服务商支持绝对时间和相对时间两种方式的时间戳防盗链控制。

  • 绝对时间控制方式原理如下：
    此方式用于生成密文的参数有过期时间wsTime、请求直播流、服务商key、ip地址串。假设过期时间为：4d024e80，用户请求的直播流为：test.flv，服务商key为：abc，ip请求地址为：192.168.2.1，对以上数据进行md5加密，得到一个md5密文，假设该密文为a1b2，则源站返回给用户的URL为：http://cdn.example.com/test.flv?wsSecret=a1b2&wsTime=4d024e80
    终端用户利用该URL重新向服务商节点发起请求。
    服务商进行验证：

    1. 根据过期时间wsTime和当前时间进行比较，确认请求是否过期。
    2. 根据约定的md5计算方式和密文，计算出md5加密串后和url中原始的加密串进行比较。
      只有1和2都验证通过，请求才会被认为是合法的。不合法的请求可以采取禁止访问或者302重定向到指定的url。

  • 相对时间控制方式原理如下：
    与绝对时间控制方式相比，相对时间控制方式使用参数keepTime和wsTime来共同决定过期时间，wsTime表示终端用户向源站请求url时，源站的机器时间，keepTime表示url 有效的时间长度，以秒为单位，以十六进制或十进制表示，同时keeptime作为参数加入加密串的计算。
    例如： rtmp://rtmpup4.pstatp.com/live/xxxxxx/xxxx?wsSecret=xxx&keeptime=7200&wsTime=xxx
    服务商节点判断该URL请求是否过期，方式如下：

  • 若当前时间 - wsTime < keepTime 时，表示URL请求未过期；
  • 若当前时间 - wsTime >= keeptime ，表示URL请求已过期；
  • 若keepTime为空，则按照发布点配置的默认过期时间来进行判断（如5分钟）。同样，相对时间控制方式除校验有效期之外，也需要校验md5加密串是否匹配。

使用方法

  1. 确认时间的表示格式。默认采用的是Unix时间戳的形式，比如1371982466表示时间是2013-06-23 18:14:26，支持其他一些时间表达格式，比如：
    • 20130623181426
    • 2013-06-23
    • 51c6ca82（推荐此表示方式，将十进制的1371982466采用16进制表示，有较好的隐蔽性）
  2. 需要确认使用绝对时间还是相对时间控制方式，使用相对时间控制的话还需要确认是否需要使用keepTime，不使用keepTime需要与客户确认默认配置的过期时长。
  3. 确认参与md5计算的相关参数，以及组合顺序。

注意事项：

  1. 时间戳防盗链默认支持，可以直接配置，不需要再次开发
  2. 当防盗链涉及的参数发生变更时，需要通知CDN进行配合更改，原则上密文一旦确定尽量不要发生变动，不然可能导致源和加速节点使用的密文不一致，请求全部验证不通过
  3. 使用IP进行md5计算可能带来一些问题：如果用户发送请求加密使用的IP1，而到CDN这边用的是另外一个IP2，这样就会被禁止访问。这在从4G切换到Wi-Fi时极易容易发生。

回源鉴权防盗链

原理：

  1. 终端用户向CDN请求视频内容，在请求中携带需要回源鉴权的参数。例如： http://www.test.com/live/channel.flv?key1=vaule1&key2=vaule2
  2. CDN节点可通过POST或者GET方式向用户鉴权服务器返回需要鉴权的参数，鉴权参数需要用户提前告知CDN。
  3. 鉴权服务器根据CDN传送而来的鉴权信息，进行防盗链判断，决定是否允许用户请求该直播视频，并将结果返回给CDN节点。
  4. CDN节点根据客户鉴权服务器返回的结果，响应或者拒绝终端用户的视频请求。

应用场景举例：

  1. 客户技术实力比较强，又不希望第三方公司知悉其防盗链原理时，可使用回源鉴权防盗链。
  2. CDN无法满足客户特殊防盗链需求时，可使用回源鉴权防盗链。

使用方法：

  1. 告知CDN，回源鉴权的参数
  2. 告知CDN，鉴权服务器地址。
  3. 告知CDN，回源鉴权的方式，目前支持get及post两种
  4. 告知CDN，鉴权结果，例如1代表成功，0代表失败
  5. 告知CDN，超时等待时间，及超时如何处理，例如，鉴权服务器3S不响应，就同意请求，或拒绝请求。

注意事项：

  1. 每次请求都需要先进行鉴权，在请求量较大时，需要考虑鉴权服务器的压力
  2. 该鉴权形式客户需要维护专门的鉴权服务器。