基于IPTV的互动电视消息系统研究与实践.docx
《基于IPTV的互动电视消息系统研究与实践.docx》由会员分享，可在线阅读，更多相关《基于IPTV的互动电视消息系统研究与实践.docx（9页珍藏版）》请在冰点文库上搜索。
基于IPTV的互动电视消息系统研究与实践
基于IPTV的互动电视消息系统研究与实践
[摘要]简要介绍了互动电视的应用场景，分析了IPTV原有消息系统存在的问题，提出了新建互动电视消息推送系统的整体解决方案及关键技术。
[关键词]互动电视IPTV消息推送
1.引言
移动互联网时代，随着移动终端TV应用、互联网电视的出现，用户看电视节目的方式越来越多，传统看电视（含IPTV）的模式已经不能满足用户对信息多元化的要求，传统电视正在逐步丧失对用户的粘性。
由于政策限制的原因，电视目前依然是家庭中的核心娱乐工具和流量中心，IPTV需要打破电视的孤岛效应，发挥电视流量中心的价值，将传统电视与移动互联网融合，形成“互联网+”的运营模式。
IPTV面向移动互联网转型，需要建立内容与人、人与人的关联关系，让用户可以充分参与内容、发现人，让看电视更加有趣、更加好玩。
基于IPTV的互动电视消息推送服务，提供电视与移动端融合的互动电视娱乐产品，将为用户带来独一无二的电视收看新体验。
2.互动电视应用场景
本文提出的“互动电视”可以理解为“互联网+电视”。
互动电视就是利用互联网化的手段，将“观众”（被动接收信息）转化为“用户”（主动信息交互）。
本文谈到的互动电视应用基于现有IPTV业务，为IPTV运营方提供可广泛应用的直播及点播多屏互动增强服务，使得目标用户能够更加深入地参与到直播/点播节目当中，更加便捷地获取信息、参与互动、购买商品及使用服务，从而提升用户体验、增强用户黏性，并拓展IPTV的后向收入来源。
该产品的主要形态包括丰富的IPTV电视互动应用，电视与手机、平板等移动终端的多屏互动应用等。
2.1弹幕、社交
弹幕、社交是互动电视产品为前向用户提供的社交类消息互动应用。
如图1所示，用户在观看电视时，可选择加入当前节目、影片的讨论组/聊天室，在观看节目过程中，用户可通过手机、平板等移动终端向互动电视后端系统发送消息，点评节目内容，所发消息将通过弹幕的方式显示在观看相同节目的同组用户的电视屏幕上。
有了弹幕、社交，用户不再孤独的看电视，可与其他朋友共享观看节目的乐趣。
2.2竞猜、投票、问答
如图2所示，在用户观看电视直播过程中，结合具体的播出内容，在电视屏幕弹出一个小窗口，展示精彩的互动内容，包括竞猜、投票、趣味问答等，用户可以立即拿起遥控器参与活动。
使用竞猜、投票、问答等应用，让用户充分参与到各类电视节目中，增强了观看电视的乐趣。
例如目前流行的综艺节目（跑男）中竞猜比赛结果，电视台愿意合作，用户也能积极参与。
2.3预约提醒、内容推荐
如图3所示，节目预约应用用于提醒用户某节目即将播出，当然，用户需要在预约操作界面设定好预约提醒。
例如某电视台每天8点播出某部电视剧，用户预约了观看提醒。
当预约的节目即将播出时，屏幕弹框告知用户预约的节目即将播出，用户可按某个键快速切换到该节目。
内容推荐应用根据用户在IPTV上的使用行为（或者热播排行等），在特定的场景下（例如用户刚登陆、新内容上线等）以消息推送的方式主动为用户推荐用户感兴趣的内容。
2.4商业广告、购物
视频内容的视觉冲击力以及节目商业元素的包装能力奠定了电视节目优质的“大卖场”导购性质。
当用户所观看的电视节目中有植入商品时，在用户产生消费欲望的第一时间将该商品信息推送给用户并引导购买。
此应用可以充分挖掘电视节目的衍生性商业价值，在满足用户需求的同时为运营商带来可观的附加价值。
电视中嵌入式商业广告场景如图4所示：
3.传统消息系统的局限性
现有的电视消息（以下简称TVMS）系统的建设时间比较早，主要的目标是支持传统IPTV业务的消息能力，并没有考虑互动电视（IPTV与移动互联网应用融合）的业务需求，不能有效支撑上述互动电视的应用。
另一方面，TVMS的技术实现方案与IPTV平台、机顶盒紧耦合，实施改造升级难度大、代价高。
3.1互动消息不实时
由于TVMS消息实现机制的限制，当前TVMS消息下发主要采用的是轮询方式，轮询的时间间隔为10分钟，不能满足消息实时下发应用的需求。
在直播节目中，竞猜、投票、问答等应用需要和节目播出的内容密切相关，消息实时下达的能力是不可或缺的。
3.2机顶盒升级改造困难
现有的消息系统的技术实现方案是在机顶盒内置后台服务器，从而接受TVMS的消息通知。
机顶盒与TVMS之间是紧耦合的关系，如果希望现有的机顶盒支持实时消息推送能力，机顶盒与TVMs后台必须进行同步改造升级。
IPTV机顶盒正在向智能机顶盒过渡，但是在此期间，智能机顶盒与非智能机顶盒将并存，而其非智能机顶盒的占比超过7成。
以广东IPTV为例，占比高的华为智能机顶盒具备XMPP通信协议栈，版本升级改造还有可行性，而其他品牌的智能机顶盒的实现方案还不明确。
另外，现网还有大量的非智能机顶盒（多个品牌和版本），如果采用机顶盒固件升级的方式支持实时互动消息，无论采用何种技术方案都不具备可操作性。
3.3性能瓶颈
以广东IPTV为例，TVMS目前运营的指标数据为每台服务器大约支持2000TPS，性能存在瓶颈，不足以支撑400万用户大规模的实时消息推送。
依赖现有的技术方案进行扩容改造，性价比低，因此必须另辟蹊径。
3.4信息展现方式呆板
TVMS仅支持传统IPTV业务的消息能力，例如公告通知基本采用“单一的文字+屏幕上/下的滚动显示”的展现方式。
TVMS需要考虑丰富多彩的互动电视的业务需求，支持富媒体的消息能力。
另外，在展现方式上要求多种多样，例如直播互动中的竞猜活动、弹幕社交等多种应用场景。
4.消息推送系统的重构
为了解决现网TVMS出现的这些实际问题，同时适应互动电视业务的深度运营、精细化运营以及快速迭代的要求，需要对现有的TVMs系统进行重构，本文将介绍在广东IPTV试点互动电视消息推送系统（以下简称消息推送系统）的实践经验。
4.1业务目标
基于新建的消息推送系统提供的消息通道，第三方可提供互动消息类应用，这些应用同时面向前向用户及后向合作伙伴。
前向用户使用IPTV的互动类消息应用，可以从电视中获取更多信息并积极参与电视内容的进程，增强用户观看电视的乐趣；后向合作伙伴则可以通过广告、竞猜、投票等应用接触到前向用户，以达到广告投放的目的。
互动消息类应用在前文已有描述，这里不再赘述。
4.2建设原则
为支持互动电视消息类应用，新建的消息推送系统不能对现有的IPTV业务系统（例如EPG、MEM等）进行大的改造。
在技术实现方案选择中，不能涉及对现有机顶盒进行固件升级的方案，技术方案需要尽量降低对现有平台（业务）的影响，避免困难度较高的技术改造。
新建的消息推送系统需要支持大规模的实时消息推送能力，以广东IPTV为例，预期的并发用户量不少于50万，消息实时推送时间不超过5s的延迟。
新建的消息推送系统需要具备良好的可扩展性，随着用户访问量的增加，系统的技术架构能够支持平滑扩展，而且系统容量的扩展不影响现有的系统架构和现网应用。
为提高系统的并发处理及实时响应能力，尽量减少比较复杂的业务逻辑。
新建的消息推送系统将不提供消息审核的机制，下发消息内容的审核由第三方应用（或IPTV现有审核机制）进行审核，消息推送系统将信任第三方应用直接下发的消息。
新建的消息推送系统向第三方应用提供消息下发的接口，向机顶盒提供消息推送的接口。
在接口的设计上，需要采用互联网业界流行的方案，接口能够支持根据业务的发展增加新的能力，同时避免对系统进行大规模的修改。
4.3系统架构
消息推送系统架构如图5所示：
系统主要包含以下模块：
（1）消息管理
面向第三方应用提供消息下发接口，接收外部系统发起的消息；持久存储接收到的下发消息；运营人员可审核第三方应用的接入，审核下发消息的合法性。
（2）接入分发
根据业务运营的情况，系统将部署多台消息推送服务器，消息推送服务器向接入分发服务器进行注册；用户接入消息推送系统，将根据均衡负载的原则为接入的用户分配消息推送服务器。
（3）消息分发
消息管理服务器将接收并存储第三方业务系统指定下发的消息，由于存在多台消息推送服务器，因此消息分发服务器根据用户接入的消息推送服务器，将消息由消息管理服务器转发到合适的消息推送服务器，再由消息推送服务器下发给接入的用户。
（4）消息推送
缓存即将发送给用户的消息。
以推送的方式向机顶盒/客户端推送实时消息；支持公告群发、指定条件用户群发、针对单个用户消息、点对点消息（单用户对单用户、单用户对多个用户）等。
外部系统主要包括：
（1）第三方业务系统：
实现具体的互动电视应用，利用消息推送系统向机顶盒下发消息，并接收机顶盒的用户反馈。
（2）机顶盒/客户端：
除IPTV的原有的直播/点播节目播放功能外，接入消息推送系统，接收该系统下发的消息，按要求在电视屏幕上进行消息内容的展示，接收用户的操作并反馈回第三方业务系统。
4.4业务流程
用户登录后即时推送流程如图6所示：
（1）客户端访问接入分发服务器，通过认证后，获得消息推送服务器地址；
（2）客户端连接消息推送服务器，服务器向消息分发服务器发送用户上线的通知；
（3）消息分发服务器将用户上线的通知转发给消息管理服务器；
（4）消息管理服务器查询需要发送给用户的消息，并发送到消息分发服务器；
（5）消息分发服务器将消息转发到消息推送服务器，由消息推送服务器将消息发送给客户端。
消息群发流程如图7所示。
（1）消息推送服务器在消息分发服务器上登记注册；
（2）消息管理服务器接收到来自业务系统的消息，指示要群发给指定的用户；
（3）消息管理服务器保存消息，并将消息发送到消息分发服务器；
（4）消息分发服务器将消息发送给已登记注册的消息推送服务器；
（5）消息推送服务器将消息发送给指定的客户端。
4.5系统接口
消息推送系统提供两方面的接口：
第一为面向第三业务系统提供消息下发指令的接口；第二为针对机顶盒提供实时消息推送的接口。
（1）面向第三方业务系统的接口
第三方业务系统的后台对接消息推送系统，由第三方业务系统向消息推送系统发送消息。
接口调用时可采用签名+时间戳进行调用的安全认证，接口的技术实现采用HTTP+JSON的方式。
（2）面向机顶盒的接口
在对应的EPG页面中嵌入javascript脚本，Ajax异步访问，支持HTTP长连接实现消息推送。
根据不同的业务场景可分别设计不同的页面模板，在EPG页面根据要求进行消息展示。
5.关键技术
5.1异步IO通信，维持高并发长连接
为满足消息推送的实时性需求，需要由服务器在有消息产生的时候，主动将消息通过网络推送给客户端。
因此，客户端与服务器之间需要保持长连接，并通过一个心跳协议维持长连接可用性。
一般的消息推送系统多采用套接字（socket）及私有通信协议实现长连接，这要求服务端与客户端都使用特定程序。
但在IPTV业务中，由于存在大量不同型号终端，其性能、配置差异大，难以对所有终端进行程序升级。
现网无论哪种型号的IPTV机顶盒都带有浏览器，支持HTTP协议，因此可采用HTTP协议模拟长连接方式，在IPTV系统中实现消息推送。
在实际消息推送的应用中，需要获得消息推送的客户端达数十万甚至上百万，单台服务器需要维持的长连接并发数量巨大。
因此传统的连接一线程的HTTP服务器同步10线程模型不适用于此类场景，需要采用异步10的方式实现服务器程序。
图8显示了采用异步10模式的系统处理网络请求的过程，处理线程和网络连接（每一个socket）并非一一对应，而是采用了独立的线程处理所有socket请求。
基于这种架构，系统能够保持长连接数只受限于内存容量的同时，不会因为需要为每个连接分配一个工作线程而上下文频繁切换，进而导致系统性能的急剧下降。
当连接的客户端数量变多时，可通过适当增加处理线程数的方式来提高服务器的并发处理能力。
5.2服务端维持连接状态，提高消息推送效率
消息推送需支持在线消息及离线消息，其中，离线消息一般是客户端连上后，由服务器从持久化存储中读取后推送给客户端。
通常情况下，浏览器支持的HTTP协议采用一问一答的形式进行数据通信。
客户端发起一次HTTP请求，服务器将请求保持，待有消息到达时响应客户端请求，完成一次消息推送。
客户端收到应答后，立即向服务器再次发起请求，进入下一次消息推送等待状态。
由此可见，在客户端收到应答到客户端再次发起请求存在一个空档期，这时如果服务器需要向该客户端推送消息，需要等待客户端发起请求。
客户端的这个状态既非离线，也非在线，可称之为“等待”状态。
尽管系统在设计时可以将“等待”状态简单地视为客户端离线，等到客户端处于在线状态时，再从持久存储中检查是否需要向客户端推送消息，但这样的设计将导致服务器频繁访问持久存储，显著降低系统的处理能力。
因此，服务器需要维持客户端的连接状态，只有当客户端是从离线变成在线状态时，才从持久存储中加载需要推送给客户端的消息，在客户端连接状态变成离线之前，都在内存中维持需要推送给客户端的消息。
这种处理方式将显著提高服务器的消息推送能力。
5.3页面脚本
（1）支持业务灵活扩展
采用HTTP长连接实现消息推送可方便地适配IPTV上所有EPG（ElectronicProgramGuide，电子节目指南）业务场景。
只需要根据具体的消息推送业务场景，设计并编辑好场景的页面模板，在对应的EPG页面中嵌入javascript脚本，即可快速集成消息推送功能，而且无需更新机顶盒固件，也无需修改原有EPG页面的业务代码。
HTTP长连接消息推送脚本分为两部分：
1）基础通信模块：
通过ajax异步请求维持客户端（即浏览器页面）与服务器之间的HTTP长连接，并响应服务器推送的消息，根据消息的类别调用对应的模板，完成消息展现。
2）业务场景模板：
不同的业务场景可分别设计不同的页面模板，在模板中实现具体的业务流程。
模板设计都支持基础通信模块的回调接口调用，当基础通信模块收到服务器下发的消息时，将调用业务场景模版进行消息展示。
（2）简洁可靠的安全认证
在实施过程中，由于页面javascript脚本发起的请求容易被伪造，因此需要对客户端的请求进行认证，以确保到达服务器的请求是合法的。
由于页面脚本很容易被获取，因此采用在javascript脚本中对请求进行加密签名的方法是不可行的。
变通的方式是在嵌Xjavascript脚本的JSP/PHP页面中嵌入一段代码，客户端按预订规则生成一个字符串令牌并赋值给一个javascript变量，然后在javascript脚本发送的请求中带上该变量作为一个请求参数。
消息推送服务器则采用相同的规则生成令牌，并与请求中带上的令牌进行对比，二者相同则认为该请求是合法的。
消息推送服务器将记录令牌的认证结果，在客户端的会话有效期内无需再次进行认证。
6.结束语
研发互动电视产品技术的目标是为IPTV的合作伙伴提供实现各种创新业务的实时互动基础能力，构建一个互利共赢的生态环境。
IPTV要面向移动互联网转型，互动电视应用将成为突破口之一。
本文简要介绍的互动电视产品解决方案已经在广东IPTV平台进行了试点，并取得良好的效果。
事实证明，这是目前唯一可行的、可覆盖全网的IPTV实时精准互动解决方案。
升级会员 