CN108924108B - 一种用于客户端的通信方法及电子设备 - Google Patents

Abstract

本公开的提供了一种用于客户端的通信方法电子设备，方法包括：获取服务器发送的随机字段r及验证次数times，times≥1；对随机字段r进行times次计算，得到验证字段k；将验证字段k加入到请求数据中后发送至服务器；获取服务器发送的合法性判断结果，其中，合法性判断结果是通过服务器对所述随机字段r进行times次计算，得到计算结果K，比较计算结果K是否等于请求数据中的验证字段k，如果是，则合法性判断结果为合法，否则，所述合法性判断结果为不合法。

Description

一种用于客户端的通信方法及电子设备

技术领域

本公开涉及一种用于客户端的通信方法及电子设备。

背景技术

随着互联网技术的发展，直播越来越受到用户的喜爱，观众在观看直播时，能够通过弹幕与主播进行交流互动。同时，直播平台也不断增加功能，使得主播和观众能够更好的进行互动和交流。通常的在直播时，可以将观众和主播的画面显示到直播中，从而使得观众可以观看到主播和其他观众实时地进行连麦沟通的直播。然而目前大多数主播并没有独立开发连麦的功能，而是通过接入第三方平台开发的连麦软件开发工具包(SoftwareDevelopment Kit，SDK)，而第三方平台则只会有视频数据，没有直播间主播和用户观众的数据，因此对于直播平台来说则需要开发独立的功能来对主播观众进行连麦时的数据传输，包括：将连麦的观众进行关联、管理观众的连麦请求、管理观众的退出连麦、主播连麦功能开闭管理、观众的连麦请求处理等等。同时存在一些非法的观众通过恶意的协议程序来刷连麦请求，从而其能够排列到连麦的请求列表的靠前位置，由于其破解了连麦的请求协议，所以其绕过客户端，直接通过编写的脚本来发送连麦协议，从而能够比绝大多数要更快的进行连麦。

发明内容

本公开鉴于上述问题，提供一种用于客户端的通信方法及电子设备，能够有效地对直播过程中的连麦进行管理，杜绝恶意地通过脚本来发送连麦协议而从出现麦序混乱的问题。

本公开的一个方面提供了一种用于客户端的通信方法，包括：获取服务器发送的随机字段r及验证次数times，times≥1；对所述随机字段r进行times次计算，得到验证字段k；将所述验证字段k加入到请求数据中后发送至所述服务器；获取服务器发送的合法性判断结果，其中，所述合法性判断结果是通过所述服务器对所述随机字段r进行times次计算，得到计算结果K，比较计算结果K是否等于请求数据中的验证字段k，如果是，则合法性判断结果为合法，否则，所述合法性判断结果为不合法。

可选地，将所述验证字段k加入到请求数据中后发送至所述服务器，还包括：将所述验证字段k加入到请求数据中后，对所述请求数据进行加密，并将加密后的请求数据发送至所述服务器。

可选地，对所述请求数据进行加密，包括：采用共享秘钥对所述请求数据进行加密，其中，所述共享秘钥由所述服务器的公钥和所述客户端的公钥组成。

可选地，服务器为直播平台服务器，客户端为主播客户端，其中，所述方法还包括：向所述直播平台服务器发送第一功能开启的消息，以使得所述直播平台服务器向观众客户端开启第一功能的接口；接收所述直播平台服务器发送的第一功能请求，其中，该第一功能功能请求由所述观众客户端通过所述第一功能的接口发送至所述直播平台服务器。

可选地，服务器为直播平台服务器，客户端为观众客户端，其中，所述方法还包括：获取所述直播平台服务器发送的第一功能的接口；向所述直播平台服务器发送第一功能请求，以使得所述直播平台服务器将该第一功能请求转发至主播客户端。

本公开另一方面还提供一种安装有客户端的电子设备，包括：通信器，用于与服务器通信；处理器；存储器，其存储有计算机可执行程序，该程序在被所述处理器执行时，使得所述处理器执行：获取服务器发送的随机字段r及验证次数times，times≥1；对所述随机字段r进行times次计算，得到验证字段k；将所述验证字段k加入到请求数据中后发送至所述服务器；获取服务器发送的合法性判断结果，其中，所述合法性判断结果是通过所述服务器对所述随机字段r进行times次计算，得到计算结果K，比较计算结果K是否等于请求数据中的验证字段k，如果是，则合法性判断结果为合法，否则，所述合法性判断结果为不合法。

可选地，处理器将所述验证字段k加入到请求数据中后发送至所述服务器，还执行：将所述验证字段k加入到请求数据中后，对所述请求数据进行加密，并将加密后的请求数据发送至所述服务器。

可选地，处理器对所述请求数据进行加密，包括：采用共享秘钥对所述请求数据进行加密，其中，所述共享秘钥由所述服务器的公钥和所述客户端的公钥组成。

可选地，服务器为直播平台服务器，客户端为主播客户端，其中，所述处理器还执行：向所述直播平台服务器发送第一功能开启的消息，以使得所述直播平台服务器向观众客户端开启第一功能的接口；接收所述直播平台服务器发送的第一功能请求，其中，该第一功能功能请求由所述观众客户端通过所述第一功能的接口发送至所述直播平台服务器。

可选地，服务器为直播平台服务器，客户端为观众客户端，其中，所述处理器还执行：获取所述直播平台服务器发送的第一功能的接口；向所述直播平台服务器发送第一功能请求，以使得所述直播平台服务器将该第一功能请求转发至主播客户端。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了本公开实施例提供的用于客户端的通信方法的流程图。

图2示意性示出了本公开实施例提供的直播平台中连麦交互过程。

图3示意性示出了根据本公开的安装有客户端的电子设备的框图。

具体实施方式

根据结合附图对本公开示例性实施例的以下详细描述，本公开的其它方面、优势和突出特征对于本领域技术人员将变得显而易见。

在本公开中，术语“包括”和“含有”及其派生词意为包括而非限制；术语“或”是包含性的，意为和/或。

在本说明书中，下述用于描述本公开原理的各种实施例只是说明，不应该以任何方式解释为限制公开的范围。参照附图的下述描述用于帮助全面理解由权利要求及其等同物限定的本公开的示例性实施例。下述描述包括多种具体细节来帮助理解，但这些细节应认为仅仅是示例性的。因此，本领域普通技术人员应认识到，在不背离本公开的范围和精神的情况下，可以对本文中描述的实施例进行多种改变和修改。此外，为了清楚和简洁起见，省略了公知功能和结构的描述。此外，贯穿附图，相同参考数字用于相似功能和操作。

图1示意性示出了本公开实施例提供的用于客户端的通信方法的流程图。

如图1所示，方法包括如下操作：

S1，获取服务器发送的随机字段r及验证次数times，times≥1。

在上述操作S1中，客户端请求连接(本公开可采用TCP连接等长连接)服务器时，服务器针对每一个登录到直播平台的客户端，生成一个16位长度的随机字段r＝rand()，其中，rand()为系统提供的一个随机函数。同时，服务器记录此随机字段r，用于后续的验证。

另外，服务器还增加了一个times(times大于等于1)字段，用于告知客户端对随机字段的计算次数。本公开实施例中，times的优选值大于1，实现对随机字段的多次计算，以增加破解难道，例如，times＝400。

S2，对随机字段r进行times次计算，得到验证字段k。

在上述操作S2中，采用MD5算法随机字段r进行times次计算：

For(int i＝0；i<times；i++)；R＝md5.create(r)；

其中，每次循环都是对r字段计算md5值，并且上次计算的md5结果作为下次计算的输入，从而最终得到对服务器生成的r字段计算了times次数的md5值，即为验证字段k。由于计算md5会消耗一定的cpu资源，从而times次数越大则消耗的CPU资源越多。

S3，将验证字段k加入到请求数据中后发送至服务器。

假设现有请求数据的协议格式如下：

type@＝voicelinkclientreq/roomid@＝4392/uid@＝2569874/ts@＝1520128375/。其中“type@＝voicelinkclientreq”表示此条请求是连麦请求，“roomid@＝4392”表示请求连麦的主播房间号，“uid@＝2569874”表示请求连麦的客户端的用户ID号，“ts@＝1520128375”表示此条协议的时间戳信息。

在上述操作S3中，将验证字段k加入到上述请求数据中，使得该请求数据为：

type@＝voicelinkclientreq/roomid@＝4392/uid@＝2569874/ts@＝1520128375/k@＝fae0b27c451c728867a567e8c1bb4e53/”。其中，k@＝fae0b27c451c728867a567e8c1bb4e53为对r进行times次计算后得到的32位的数值k。

另外，本操作还对请求数据进行加密，并将加密后的请求数据发送至服务器，例如：

AES.Encrypt(“type@＝voicelinkclientreq/roomid@＝4392/uid@＝256 9874/ts@＝1520128375/k@＝fae0b27c451c728867a567e8c1bb4e53/”,ShareKey)；

其中，AES.Encrypt则是加密算法AES加密算法的加密接口，ShareKey是加密使用的共享秘钥，其中，共享秘钥由服务器的公钥和客户端的公钥组成。下面将详细介绍共享秘钥的生成过程：

当客户端登录到服务器时，服务器会依据用户信息来生成一对秘钥。同时为了保障每个用户的秘钥信息不一致，提高破解门槛，将用户的账号以及随机数据做为私钥信息，从而保障每个用户私钥都不一致。本公开实施例采用非对称RSA加密算法来生成一对公钥和私钥。具体则私钥可以使用随机数生成，公钥则调用RSA的接口函数可以生成对应的公钥，私钥和公钥是唯一配对的关系。

私钥是通过如下操作实现的：首先，通过调用系统函数rand生成一段随机数据Randdata＝rand()。其次，依通过调用Md5函数的接口Md5.Create来对用户ID和随机数据和当前时间戳信息以及随机数拼接到一起计算其Md5值，从而得到私钥，其表达式如下：

ClientPrivatekey＝Md5.Create(UserId+TimeStamp+randdata)。

公钥是通过调用RSA的生成配对钥匙接口RSA.CreatePair来生成，其表达式如下：

ClientPublickey＝RSA.CreatePair(ClientPrivatekey)；

至此，服务器生成了一对公钥和私钥。

同时，客户端也会生成一套公钥私钥信息。其中，客户端使用随机数据和时间戳来生成私钥，从而尽可能保障不同客户端是不一样的私钥和公钥。

私钥是通过如下操作实现的：首先，通过调用系统函数rand生成一段随机数据Randdata＝rand()。其次，依通过调用Md5函数的接口Md5.Create来对随机数据和当前时间戳信息以及随机数拼接到一起计算其Md5值，从而得到私钥，其表达式如下：

ClientPrivatekey＝Md5.Create(TimeStamp+randdata)。

公钥是通过调用RSA的生成配对钥匙接口RSA.CreatePair来生成，其表达式如下：

ServerPublickey＝RSA.CreatePair(ServerPrivatekey)。

至此，客户端生成了一对公钥和私钥。

还需说明的是，服务器在生成公钥和私钥后，将其生成的公钥发送至客户端，客户端收到服务器下发的公钥后，则将自己生成的公钥发送给服务器。也就是说，服务器和客户端互换各自的公钥，其目的是生成一个共享秘钥，并且客户端和服务器生成的共享秘钥是同一个值，具体实现如下：

服务器将服务器的公钥ServerPublickey发送给客户端；

客户端将客户端的公钥ClientPublickey发送给服务器；

服务器生成共享秘钥：

ShareKey＝RSA.CreateShareKey(ClientPublickey,ServerPrivatekey)；

客户端生成共享秘钥。

ShareKey＝RSA.CreateShareKey(ServerPublickey,ClientPrivatekey)。

S4，获取服务器发送的合法性判断结果，其中，合法性判断结果是通过服务器对所述随机字段r进行times次计算，得到计算结果K，比较计算结果K是否等于请求数据中的验证字段k，如果是，则合法性判断结果为合法，否则，所述合法性判断结果为不合法。

在上述操作S4中，当服务器获取到客户端发送的请求数据后，首先采用共享秘钥对该请求数据进行解密，得到明文的请求数据。同时，服务器内部还采用与操作S2一致得到方法得到计算结果K，比较计算结果K是否等于请求数据中的验证字段k，如果是，则合法性判断结果为合法，以允许客户端的进一步操作。否则，合法性判断结果为不合法，拒绝客户端的请求。

在本公开实施例中，客户端为主播客户端，其中，方法还包括：向直播平台服务器发送第一功能开启的消息，以使得直播平台服务器向观众客户端开启第一功能的接口；接收直播平台服务器发送的第一功能请求，其中，该第一功能功能请求由观众客户端通过第一功能的接口发送至直播平台服务器。

在本公开实施例中，服务器为直播平台服务器，客户端为观众客户端，其中，所述方法还包括：获取直播平台服务器发送的第一功能的接口；向直播平台服务器发送第一功能请求，以使得直播平台服务器将该第一功能请求转发至主播客户端。

其中，该第一功能为观众与主播进行连麦的连麦功能。为了实现连麦功能，本公开实施例需要在主播客户端和观众客户端集成第三方的连麦SDK，该连麦SDK具有将主播的声音画面传递到连麦的观众客户端，同时也能将其他观众客户端的声音和视频传递到主播客户端。集成的SDK具备一对多的连麦功能，直播平台服务器会管理一个直播间主播和观众的连麦，同时直播平台服务器会开启整个房间的连麦功能，并告知第三方SDK，连麦功能开启。第三方平台也会对连麦进行计费等功能。首先在集成SDK时，通常的都会注册一个直播平台的账号，从而为直播平台会分配一个应用APPID，那么直播平台所有的使用中都必须携带此APPID，第三方连麦才会认可是合法的连麦SDK，从而才能给正常的进行连麦的功能。因此，无论是在主播客户端还是观众客户端都需要进行连麦SDK的注册：

RtcEnginertcEngine＝RtcEngine.create(ctx,appid,myRtcEventHandler)；

其中最重要的则是填入参数APPID，告诉第三方连麦SDK平台，用户身份是直播平台的用户。

图2示意性示出了本公开实施例提供的直播平台中连麦交互过程。

如图2所示，当主播开始直播时，主播客户端可选择开启连麦功能和关闭连麦功能，其中，开启连麦功能时，该主播房间的所有观众可以请求与主播连麦，而关闭连麦功能时，观众无法请求与主播连麦。

上述连麦功能的开启或关闭的消息会从主播客户端发送至直播平台服务器，直播平台服务器将该消息广播到所有观众，告知当前主播是否开启了连麦的功能。具体地，该消息可以是voicelinkreq消息，voicelinkreq消息具有一个enable字段，用于表示连麦功能开启或关闭，其中，type@＝voicelinkreq/enable@＝1表示开启连麦功能，type@＝voicelinkreq/enable@＝0表示关闭连麦功能。

主播客户端开启连麦功能后，直播平台服务器会向观众客户端开启连麦功能的接口，用户通过观众客户端中的接口向直播平台服务器发送连麦请求voicelinkclientreq，以使得直播平台服务器将该连麦请求voicelinkclientreq转发至主播客户端中。具体地，直播平台服务器会将所有观众客户端的请求生成一个请求列表，并将该请求列表转发到主播客户端，用于让主播客户端选择一个连麦的观众客户端。主播客户端选择其中一个连麦的观众客户端后，会发送一个连麦请求至直播平台服务器，直播平台服务器将该连麦请求转发至对应的观众客户端，以此达到开启连麦功能的目的。同样地，主播客户端拒绝某个观众客户端的连麦请求时，也会向直播平台服务器发送一个拒绝消息，直播平台服务器将该拒绝消息转发至对应的观众客户端。同理，主播客户端也可以主动断开与观众客户端正在进行的连麦，从而主播将观众踢出连麦，那么观众客户端也会收到从直播平台服务器转发过来的踢出连麦的消息，客户端收到此消息则会断开连麦，同时，直播平台服务器也会从当前与主播客户端的连麦列表中删除掉该观众客户端。

对于直播平台客户端来说，在增加了连麦的基础上，则需要在协议处理逻辑中进行协议的处理，增加处理连麦请求的协议处理。为了更好的设计协议逻辑处理，本公开实施例采用协议分发机制，将连麦协议独立的分发到连麦逻辑中，从而不对现有直播平台协议进行干扰，同时运营时，也可以通过直播平台服务器的下发开关来关闭连麦的逻辑处理。具体实现如下：

本公开实施例首先会定义一个连麦相关的处理逻辑类，来封装连麦的所有逻辑：

其中编写了客户端各个连麦的逻辑，包括开始连麦，结束连麦，比如开始连麦则需要调用第三方的SDK来开启连麦功能，并且发送消息到直播平台开始连麦请求。

其中ProcessMessage(message)则是处理所有连麦的协议逻辑。

那么本文会在消息处理逻辑分发处进行消息的分发。

首先客户端会通过网络socket来不断的收取服务器的消息，收到消息后则会调用客户端的消息分发机制，将连麦的消息过滤出来，并发送给连麦的处理逻辑。

编写while循环来不断的收取网络消息：

While(true)

{

Socket.recv(message)；

通过socket来收取网络消息message；

DispatchMessage(message)；

将收到的消息进行分发和处理。

}

首先取出消息的类型：

Void DispatchMessage(message)；

{

Type＝Parse(message)；

并判断消息类型是不是连麦相关消息，具体则是判断：

voicelinkclientreq

voicelinkreqagree

voicelinkreqreject

voicelinkkick等消息。

如果是则将此消息分发给连麦处理逻辑进行处理。

If type＝＝voicelinkclientreq

||type＝＝voicelinkreqagree

||type＝＝voicelinkreqreject

||type＝＝voicelinkkick

{

VoiceLink.ProcessMessage(message)；

}

}

通过上述操作，完成了客户端的连麦协议处理及分发。

另外，在本公开实施例中，直播平台服务器会维护主播连麦的状态信息，也会维护当前连麦的所有观众的信息，同时主播与观众的信息交互都是通过直播平台服务器来进行转发。直播平台服务器也会管理主播的连麦用户数量，连麦的观众的请求数，以及对观众的连麦请求进行权限控制，低等级的用户不提供连麦功能等。

当主播关闭直播间或者退出连麦时，直播平台服务器需要广播给当前连麦的客户端以及其他观众，告知观众断开连麦。

当主播开播开启连麦时，需要更新当前状态，广播当前主播开启连麦功能。

当观众主动断开连麦请求时，直播平台服务器会转发次消息到主播端，告知某个观众关闭了连麦请求。

直播平台服务器还需要对观众主播进行连接的维护，当有观众由于网络波动断开时，也会主动的去侦听用户的连接情况。

当主播开启连麦功能，直播平台服务器会告知连麦SDK的服务器，当前主播开启连麦功能。

由于连麦的数据传输在第三方SDK平台，需要对主播、观众进行连麦的客户端加入心跳的消息机制，如果主播在连麦，那么主播客户端每隔一个固定的时间，会发送一个心跳消息，从而直播平台服务器知道当前连麦是成功的并且在持续连麦中，同时正在连麦的观众客户端也会发送一个连麦的心跳消息到直播平台服务器，从而直播平台服务器知道此观众连麦是正常的。如果直播平台服务器没有收到心跳消息，说明客户端断开了链接，从而服务器会广播其他客户端该观众客户端断开了连麦，同时如果是网络抖动，则该观众客户端还会进行连麦重连，直播平台服务器也会接收该观众客户端的重连请求，将其加入到连麦中。

综上所述，当客户端登录到直播平台服务器时，服务器会生成一段随机字段和验证次数，客户端收到数据后则会依据客户端的算法来对服务器下发的随机字段进行计算，并且计算次数是服务器下发的验证次数。通过上述技术方案，对于刷连麦功能的黑客来说，必须需要破解了本公开的算法才能正确的连麦，如果黑客破解不成功则连麦请求会失败，即使黑客破解了协议，也必须依据服务器的验证次数来进行计算，其无法绕过服务器的验证，必须进行这么多的计算次数，从而其发送连麦的请求频率不会很高，起到了二层的保护作用。

如图3所示，电子设备300包括处理器310、计算机可读存储介质320、通信器330。该电子设备300可以执行上面参考图1描述的方法，以进行消息处理。

具体地，处理器310例如可以包括通用微处理器、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器310还可以包括用于缓存用途的板载存储器。处理器310可以是用于执行参考图1描述的根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

计算机可读存储介质320，例如可以是能够包含、存储、传送、传播或传输指令的任意介质。例如，可读存储介质可以包括但不限于电、磁、光、电磁、红外或半导体系统、装置、器件或传播介质。可读存储介质的具体示例包括：磁存储装置，如磁带或硬盘(HDD)；光存储装置，如光盘(CD-ROM)；存储器，如随机存取存储器(RAM)或闪存；和/或有线/无线通信链路。

计算机可读存储介质320可以包括计算机程序321，该计算机程序321可以包括代码/计算机可执行指令，其在由处理器310执行时使得处理器210执行例如上面结合图1所描述的方法流程及其任何变形。

计算机程序321可被配置为具有例如包括计算机程序模块的计算机程序代码。例如，在示例实施例中，计算机程序321中的代码可以包括一个或多个程序模块，例如包括321A、模块321B、……。应当注意，模块的划分方式和个数并不是固定的，本领域技术人员可以根据实际情况使用合适的程序模块或程序模块组合，当这些程序模块组合被处理器310执行时，使得处理器310可以执行例如上面结合图1所描述的方法流程及其任何变形。

尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。

Claims (10)

1.一种用于客户端的通信方法，包括：

获取服务器发送的随机字段r及验证次数times，times＞1；

对所述随机字段r进行times次计算，得到验证字段k；

将所述验证字段k加入到请求数据中后发送至所述服务器；

获取服务器发送的合法性判断结果，其中，所述合法性判断结果是通过所述服务器对所述随机字段r进行times次计算，得到计算结果K，比较计算结果K是否等于请求数据中的验证字段k，如果是，则合法性判断结果为合法，否则，所述合法性判断结果为不合法。

2.根据权利要求1所述的用于客户端的通信方法，所述将所述验证字段k加入到请求数据中后发送至所述服务器，还包括：

将所述验证字段k加入到请求数据中后，对所述请求数据进行加密，并将加密后的请求数据发送至所述服务器。

3.根据权利要求2所述的用于客户端的通信方法，所述对所述请求数据进行加密，包括：

采用共享秘钥对所述请求数据进行加密，其中，所述共享秘钥由所述服务器的公钥和所述客户端的公钥组成。

4.根据权利要求1所述的用于客户端的通信方法，所述服务器为直播平台服务器，所述客户端为主播客户端，其中，所述方法还包括：

向所述直播平台服务器发送第一功能开启的消息，以使得所述直播平台服务器向观众客户端开启第一功能的接口；

接收所述直播平台服务器发送的第一功能请求，其中，该第一功能功能请求由所述观众客户端通过所述第一功能的接口发送至所述直播平台服务器。

5.根据权利要求1所述的用于客户端的通信方法，所述服务器为直播平台服务器，所述客户端为观众客户端，其中，所述方法还包括：

获取所述直播平台服务器发送的第一功能的接口；

向所述直播平台服务器发送第一功能请求，以使得所述直播平台服务器将该第一功能请求转发至主播客户端。

6.一种安装有客户端的电子设备，包括：

通信器，用于与服务器通信；

处理器；

存储器，其存储有计算机可执行程序，该程序在被所述处理器执行时，使得所述处理器执行：

获取服务器发送的随机字段r及验证次数times，times＞1；

对所述随机字段r进行times次计算，得到验证字段k；

将所述验证字段k加入到请求数据中后发送至所述服务器；

获取服务器发送的合法性判断结果，其中，所述合法性判断结果是通过所述服务器对所述随机字段r进行times次计算，得到计算结果K，比较计算结果K是否等于请求数据中的验证字段k，如果是，则合法性判断结果为合法，否则，所述合法性判断结果为不合法。

7.根据权利要求6所述的安装有客户端的电子设备，其中，所述处理器将所述验证字段k加入到请求数据中后发送至所述服务器，还执行：

将所述验证字段k加入到请求数据中后，对所述请求数据进行加密，并将加密后的请求数据发送至所述服务器。

8.根据权利要求7所述的安装有客户端的电子设备，所述处理器对所述请求数据进行加密，包括：

采用共享秘钥对所述请求数据进行加密，其中，所述共享秘钥由所述服务器的公钥和所述客户端的公钥组成。

9.根据权利要求6所述的安装有客户端的电子设备，所述服务器为直播平台服务器，所述客户端为主播客户端，其中，所述处理器还执行：

向所述直播平台服务器发送第一功能开启的消息，以使得所述直播平台服务器向观众客户端开启第一功能的接口；

接收所述直播平台服务器发送的第一功能请求，其中，该第一功能功能请求由所述观众客户端通过所述第一功能的接口发送至所述直播平台服务器。

10.根据权利要求6所述的安装有客户端的电子设备，所述服务器为直播平台服务器，所述客户端为观众客户端，其中，所述处理器还执行：

获取所述直播平台服务器发送的第一功能的接口；

向所述直播平台服务器发送第一功能请求，以使得所述直播平台服务器将该第一功能请求转发至主播客户端。

Images