breeze/srs

mirror of https://github.com/ossrs/srs.git synced 2026-01-12 00:05:45 +08:00

Page: migrate_v4_CN_drm

Pages

Table of Contents

Refer Authentication
Token Authentication
TokenTraverse
Access服务器
推流认证

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

HOME > CN > DRM

DRM

Note: 如果觉得Github的Wiki访问太慢，可以访问 Gitee 镜像。

DRM重要的功能就是防盗链，只有允许的用户，才能访问服务器的流。有多种DRM的方式：

refer防盗链：检查用户从哪个网站过来的。譬如不是从公司的页面过来的人都不让看。
token防盗链：用户在播放时，必须先申请token，SRS会回调http检查这个token合法性。
FMS token tranverse：边缘RTMP服务器收到每个连接，都去上行节点验证，即token穿越认证。
Access服务器：专门的access服务器负责DRM。譬如adobe的access服务器。
推流认证：adobe的RTMP推流时，支持几种认证方式，这个也可以归于防盗链概念。

Refer Authentication

SRS支持refer防盗链，adobe的flash在播放RTMP流时，会把页面的http url放在请求中， as客户端代码不可以更改。当然如果用自己的客户端，不用flash播放流，就可以随意伪造了；尽管如此，refer防盗链还是能防住相当一部分盗链。

配置Refer防盗链，在vhost中开启refer即可，可以指定publish和play的refer：

# the vhost for antisuck.
vhost refer.anti_suck.com {
    # refer hotlink-denial.
    refer {
        # whether enable the refer hotlink-denial.
        # default: off.
        enabled         on;
        # the common refer for play and publish.
        # if the page url of client not in the refer, access denied.
        # if not specified this field, allow all.
        # default: not specified.
        all           github.com github.io;
        # refer for publish clients specified.
        # the common refer is not overrided by this.
        # if not specified this field, allow all.
        # default: not specified.
        publish   github.com github.io;
        # refer for play clients specified.
        # the common refer is not overrided by this.
        # if not specified this field, allow all.
        # default: not specified.
        play      github.com github.io;
    }
}

备注：SRS1/2的Refer配置方法和SRS3不一致，SRS3兼容SRS1/2的配置方法。

Token Authentication

token类似于refer，不过是放在RTMP url中，或者在connect的请求参数中：

token在RTMP url，譬如：rtmp://vhost/app?token=xxxx/stream，这样服务器在on_connect回调接口中，就会把url带过去验证。参考：HTTP callback
token在connect的参数中：as函数NetConnection.connect(url, token)，服务器也可以拿到这个token。注意：SRS目前不支持。

token比refer更强悍，可以指定超时时间，可以变更token之类。可惜就是需要服务器端做定制，做验证。 SRS提供http回调来做验证，已经有人用这种方式做了，比较简单靠谱。

举个常用的token认证的例子：

用户在web页面登录，服务器可以生成一个token，譬如token=md5(time+id+私钥+有效期)=88195f8943e5c944066725df2b1706f8
服务器返回给用户一个地址，带token，譬如：rtmp://192.168.1.10/live?time=1402307089&expire=3600&token=88195f8943e5c944066725df2b1706f8/livestream
配置srs的http回调，on_connect http://127.0.0.1:8085/api/v1/clients;，参考：HTTP callback
用户播放时，srs会回调那个地址，解析请求的内容，里面的tcUrl就有那些认证信息。按同样的算法验证，如果md5变了就返回错误，srs就会拒绝连接。如果返回0就会接受连接。

TokenTraverse

Token防盗链的穿越，指的是在origin-edge集群中，客户播放edge边缘服务器的流时，边缘将认证的token发送给源站进行验证，即token穿越。

FMS的edge和FMS的origin使用私有协议，使用一个连接回源取数据，一个连接回源传输控制命令，譬如token穿越就是在这个连接做的。参考：https://github.com/ossrs/srs/issues/104

token认证建议使用http方式，也就是说客户端连接到边缘时，边缘使用http回调方式验证token。像fms那种token穿越，是需要走RTMP协议，其他开源服务器一般都不支持这种方式（中国特色）。

SRS可以支持类似fms的token穿越，不过实现方式稍微有区别，不是采用fms edge的私有协议，而是每次新开一个连接回源验证，验证通过后边缘才提供服务。也就是边缘先做一个完全的代理。

SRS这种方式的特点是：

在token认证上，能和fms源站对接，fms源站感觉不到什么区别。
每次边缘都会新开连接去验证，开销会大一些；而且只限于connect事件验证，马上验证过后就会收到disconnect事件。
会导致源站的短连接过多（连接验证token，断开），不过可以加一层fms edge解决，这样比所有都是fms edge要好。

对于源站短连接过多的问题，可以加一层fms边缘缓解，假设1000个客户端连接到边缘：

srs => 客户fms 这种方案，会有1000个连接去回源验证，然后断开。
srs => cdn-fms => 客户fms 这种方案，会有1000个连接去cdn的fms去验证，只有1个连接去客户那边验证。

SRS的token穿越(traverse)的配置，参考edge.token.traverse.conf：

listen              1935;
vhost __defaultVhost__ {
    cluster {
        mode            remote;
        origin          127.0.0.1:19350;
        token_traverse  on;
    }
}