现在位置:首页 >
发表在 2020年04月 的所有文章
-
MySQL This function has none of DETERMINISTIC, NO SQL...错误1418 的原因分析及解决方法 (转)
解决方法: 解决办法也有两种, 第一种是在创建子程序(存储过程、函数、触发器)时,声明为DETERMINISTIC或NO SQL与READS SQL DATA中的一个, 例如: CREATE DEFINER = CURRENT_USER PROCEDURE `NewProc`() DETERMINISTIC BEGIN #Routine body goes here... END;; 第二种是信任子程序的创建者,禁止创建、修改子程序时对SUPER权限的要求,设置log_bin_trust_routine_creators全局系统变量为1。 设置方法有三种: 1.在客户端上执行SET GLOBAL log_bin_trust_function_creators = 1; 2.MySQL启动时,加上--log-bin-trust-function-creators选贤,参数设置为1 3.在MySQL配置文件my.ini或my.cnf中的[mysqld]段上加log-bin-trust-function-creators=1 -
Windows server 2012公用网络修改为专用网络
普通环境路径如下: 【控制面板】--【系统和安全】--【管理工具】--【本地安全策略】--【网络列表管理器策略】--【网络】--【网络位置】,设定之后也可以设定一下【用户权限】 域控环境路径如下: 不像Windows Server 2003 ,Windows Server 2012 域控制器的管理工具中没有“域安全策略”,修改域策略在新的“组策略管理”中: 开始> 控制面板 > 系统和安全 > 管理工具 > 组策略管理(或者用命令 gpmc.msc) > 林 [domain] > 域 > [domain] > Default Domain Policy > 点击右键,编辑,打开“组策略管理编辑器” > 计算机配置 > 策略 > Windows 设置 > 安全设置 > 网络列表管理器策略 > 网络 > 网络位置 , 修改之后如未生效,可以通过命令 gpupdate 来刷新组策略。 -
单位内部DNS架设及域名解析服务
越来越多的企业将企业内部局域网通过光缆、交换机等高速互连设备连接起来,形成较大规模的中型网络,网络上的主机和用户也随之日渐增多。作为 Internet的缩影,企业内部网上的各类服务器(如WWW服务器、FTP 服务器、E-mail服务器及各种备份服务器)也会随着业务量的增加而迅速增多,有些企业甚至给其内部的用户提供WWW虚拟主机服务。这样一来,系统的维护会越来越繁琐,一大堆IP地址让人无法记忆。这时候您就应当考虑给您的内部网建一个域名服务器(DNS)了。 一、确定内部网域名解析的范围 Internet上的域名服务,由分布在世界各地的众多的域名服务器提供。域名服务的理解,牵涉到DNS网络体系结构、分布式数据库等理论知识,在此不做过多的阐述。笔者仅以在NT Server 4.0服务器上建立域名服务器为例,实例介绍内部网络中域名服务器的建立方法。 笔者假设您要在内部网络中提供以下服务器的域名解析: WWW 服务器1: www1.mydom.com.cn 192.168.0.150 WWW 服务器2: www2.mydom.com.cn 192.168.0.151 FTP 服务器1: ftp-Server1.com.cn 192.168.0.250 FTP 服务器2: ftp-Server2.com.cn 192.168.0.251 Email服务器: mail.mysvr.com.cn 192.168.0.253 域名服务器: dns.com.cn 192.168.0.100 二、实现域名解析的软件安装与配置 首先要保证NT Server服务器安装和运行正常(NT Server应该安装的补丁包(SP5或SP6)都已经安装);服务器的网卡及网络参数配置正确,安装了“TCP/IP”网络通信协议且设置了合适的 IP 地址,服务器能与网络上的电脑正常通信。本例中,假设NT Server的主机名为:“MYSERVER”,IP 地址为:“192.168.0.100”。 1.安装和启动“DNS Service”服务:打开“控制面版”,双击“网络”图标,进入网络设置界面。选择“服务”标签,单击“添加”按纽,选择“Microsoft DNS服务器”后,按“确定”按纽。安装程序拷贝一些必需的文件后,回到网络设置界面。 这时,按“确定”按纽,安装程序会自动进行一番设置,然后要求重新启动机器。机器重新启动后,在“开始/程序/管理工具(公用)”选单下会出现“DNS 服务器”选单项。这时再打开“控制面版/服务”,应能看到“Microsoft DNS Server”服务已经启动(如果没有启动,可以手工启动)。 2.域名服务器配置:执行“开始/程序/管理工具(公用)/DNS服务器”,出现“域名服务管理器”操作界面。进行域名服务器的创建和分级域名的建立,最后设置主机域名对应的 IP 地址。 1)建立DNS服务器名:选择域名服务管理器窗口左侧的“服务器清单”,点击鼠标右键,执行弹出选单的“新建服务器”命令,弹出“添加DNS服务器”窗口,在文本框中输入DNS服务器即NT Server的主机名或IP地址,并确定。本例中假设输IP地址为:“192.168.0.100”。这时,新建的DNS服务器名 “192.168.0.100”就出现在 DNS 服务器清单中。 2)建立反向查询区域:反向查询区域存放反向域名解析必需的记录信息,提供给一些需要进行反向域名解析的应用。最好先建立“反向查询区域”,然后再建立“区域”,这样会给添加记录带来很大的方便。 选择刚刚新建的DNS服务器名,单击右键,执行弹出选单中的“新建区域”命令,出现“为192.168.0.100创建新区域”窗口。区域类型选“主要”,点击“下一步”;在区域信息的“区域名”文本框中反向输入“www1.mydom.com.cn 192.168.0.150”所对应的IP地址,并在后面再加上“.in-addr.arpa”,即为:“150.0.168.192.in- addr.arpa”;再点击“区域文件”文本框,该文本框中会自动出现“150.0.168.192.in-addr.arpa.dns”的内容;左键单击“下一步”,再单击“完成”。这样,“www1.mydom.com.cn 192.168.0.150”对应的反向查询区域“150.0.168.192.in-addr.arpa”就建立好了。 三、DNS客户端的设置 客户端DNS的配置,运行“控制面板”中的“网络连接”,在打开的窗口中鼠标右键单击“本地连接”,选择“属性”,在“本地连接属性”对话框中选择“Internet协议(TCP/IP)”/“属性”,出现如图1.18所示对话框,在“首选DNS服务器”处输入DNS服务器的IP地址,如果还有其他的DNS服务器提供服务的话,在“备用DNS服务器”处输入另外一台DNS服务器的IP地址。 如果有多台DNS服务器,请单击图中的“高级”按钮,在DNS标签下逐一添加多个DNS服务器的IP地址,DNS客户端会依序向这些DNS服务器查询。 -
配置内网DNS实现内部域名解析
配置内网DNS实现内部域名解析 服务器 实战目的: ü 配置内网的DNS服务器实现内网服务器的域名解析。 ü 配置内网的DNS服务器减少到Internet的域名解析流量。 ü 配置内网的DNS服务器实现Internet上服务器的域名解析。 网络环境: 企业场景: 在微软河北技术支持中心,有一个内部办公网站,网络管理员打算员工使用访问WebServer,有一个内部用的FTP站点,网络管理员打算办公人员使用ft访问FTPServer,内部有一个邮件服务器Mailserver,网络管理员打算办公人员使用mai访问该服务器。 域名没有在Internet上注册,因此内部员工的计算机要想解析、ft和mai域名,必须使用内网的DNS服务器DNSServer。 办公人员除了访问内网的服务器,还需要访问Internet,因此DNSServer必须能够将访问Internet的域名解析请求转发到Internet服务器上的DNS。 2.1.1 配置内网的DNS服务器 任务: ü 配置DNSServer使用Internet上DNS服务器。 ü 配置DNSServer使用Internet上的DNS根提示。 ü 创建正向区域 步骤: 1. 在DNSServer上,更改本地连接的TCP/IP协议属性使用Internet上的DNS服务器作为首选的DNS服务器。 2. 右击DNSServer服务器,点击“属性”,在根提示标签下,选中rootDNS.ns,点击“删除”。 3. 在出现的警告提示符下,点击“是”。 4. 右击DNSServer,点击“配置DNS服务器”。 5. 在出现的欢迎使用DNS服务器配置向导对话框,点击“下一步”。 6. 在选择配置操作对话框,选择“只配置根提示”,点击“下一步”。 7. 在正在完成DNS服务器配置向导对话框,点击“完成”。 8. 打开DNSServer服务器属性,在根提示标签下,可以看到已经添加了Internet上默认的根DNS服务器。选中IP地址未知的根DNS服务器,点击“编辑”。 9. 在出现的编辑名称服务器记录对话框,点击“解析”。 10. 可以看到能够解析出正确的IP地址,点击“确定”。 11. 右击“正向查找区域”,点击“创建区域”。 12. 在出现的欢迎使用新建区域向导对话框,点击“下一步”。 13. 在出现的区域类型对话框,选择“主要区域”,点击“下一步”。 14. 在区域名称对话框,输入,点击“下一步”。 15. 在区域文件对话框,保持默认的选择和文件名,点击“下一步”。 16. 在动态更新对话框,选择“不允许动态更新”,点击“下一步”。 17. 在正在完成新建区域向导对话框,点击“完成”。 18. 右击区域,点击“新建主机”。 19. 在新建主机对话框,输入www和IP地址10.7.10.45,点击“添加主机”。 20. 添加ftp和mail主机记录。 2.1.2 在内网计算机上测试 任务: ü 配置Sales计算机使用内网的DNS服务器DNSServer作为首选的DNS服务器。 ü 使用nslookup测试内网服务器的域名解析,测试Internet上域名解析。 ü 查看内网DNS服务器缓存的结果。 步骤: 21. 在Sales计算机上,更改本地连接,配置计算机使用内网的DNS服务器DNSServer作为首选的DNS服务器。 22. 在命令行界面下输入nslookup,测试内网域名域名解析,测试Internet 中域名解析。 23. 在DNSServer服务器上,打开DNS管理工具,点击“查看”à“高级”。 24. 点击“显示缓存的查找”,可以看到缓存的结果。如果内网中的其他客户端再次解析相同的Internet域名,DNSServer服务器就会从缓存中查找结果,这样就会减少到Internet的域名解析流量。 -
全网最全免费电子地图软件,27大类,106种风格,总有一款适合你
说到电子地图大家并不陌生,百度高德日常逛街必备,google earth 科研探险工作者的最爱。 网上各类电子地图浏览软件不计其数,但有没有一款软件能把所有常见的地图服务都包括了呢? 今天小编给大家推荐一款非常好用强大的地图浏览软件,迈高图。 这款软件不管你是科研工作者,学生、老师、探险者、设计师还是工程师都非常实用,下面我们一起看看它有多强大。 1.拥有最全的地图资源 据小编不完全统计,迈高图支持超过27个大类,超过106种风格或子类型的地图,可以说全网最全。 2.高质量的地图显示 迈高图收集的地图资源质量非常高,显示效果极佳。 同样是google卫星图,迈高乐显示的速度比其他同类软件效果好,速度更快。 3.丰富的配套工具 支持面积量算。 支持距离量算。 支持剖面生成显示。 支持专业的校准,包括四参数、七参数精确配准。 POI搜索、定位。 要素标绘。 高清打印截图。 4.支持极速下载 所见即所得,几乎所有的地图都支持下载,输出各类软件使用格式,支持拼接高清大图。 5.专业性极强 地质图、植被图、海洋地图、地形图、温度图、辐射图,人口专题、景观专题、区划图、水系图、地表覆盖图等等。太多了,小编用着有点爽,感觉有点飘,哈哈。 地表覆盖图 地质图 地形图 海洋地图 总之,如果你需要一个全功能的电子地图软件,这款就够了。 -
服务器和云服务器的优缺点
物理服务器 指实实在在、存在的硬件专用独立主机或服务器设备,性能和稳定性都比较强,因此,价格也相对比较昂贵,需要用户自己根据需求进行配置、管理及运维。简单来说,物理服务器可以把它理解为一台“电脑”,实际上所有网站的程序都在这个“电脑”上运行。 云服务器 指通过虚拟化技术将一台独立服务器虚拟成多个小的服务器,每个云服务器的运行和管理都完全独立,具有单独的操作系统,可分配独立公网IP地址、超大磁盘、操作系统Windows/Linux、内存、CPU资源等,网站运行环境和空间安全都需要用户自己去配置,对用户的技术能力有一定要求的。 云服务器是云计算服务的重要组成部分,是面向各类互联网用户提供综合业务能力的服务平台。平台整合了传统意义上的互联网应用三大核心要素:计算、存储、网络,面向用户提供公用化的互联网基础设施服务。 服务器和云服务器的优缺点 物理服务器 VS 云服务器 成本优化 物理服务器而言,无论用还是不用,设备就在那里,成本就在那里,照样算钱! 云服务器遵循按需购买,按照使用量付费的原则,具有成本低、弹性伸缩、管理便捷等特点。 服务优化 物理服务器服务常规指实体服务器托管和租用两种服务类型,实体服务器托管是由用户自行购买硬件发往机房托管,期间设备的监控和管理工作均由用户单方独立完成,IDC数据中心提供IP接入、带宽接入、电力供应和网络维护等,租用是由IDC数据中心租用实体设备给客户使用,同时负责环境的稳定,用户无需购买硬件设备; 云服务器服务是指是从基础设施(Iaas)到业务基础平台(PaaS)再到应用层(SaaS)的连续的整体的全套服务,IDC数据中心将规模化的硬件服务器整合虚拟到云端,为用户提供的是服务能力和IT效能。 相较传统IDC服务模式,云计算IDC增值服务是相关于传统IDC增值服务的升级,是云计算数据中心下对传统IDC服务的升级版!云计算IDC情况下,可获得具备高扩展性和高可用的计算能力,用户也再无需担心硬件设备的性能限制等带来的问题。 资源优化 物理服务器,在硬件服务器的基础进行有限的整合,例如多台虚拟机共享一台实体服务器性能。 云服务器可通过资源集约化实现的动态资源调配,云计算可以实现横向/纵向的弹性资源扩展和快速调度,传统IDC提供的资源难以承受短时间内的快速再分配,且不说企业等待的时间成本,本身而言容易造成资源闲置和浪费! 云服务器而言,通过更新的技术实现资源的快速再分配,可以在数分钟甚至几十秒内分配资源实现快速可用,可以有效地规避资源闲置的风险。此外,传统IDC远不如云计算IDC那样可以跨实体服务器,甚至实现跨数据中心的大规模有效整合。 效率优化 云计算IDC服务相较传统IDC服务,前者采取更加灵活的资源利用方式,通过技术提升和优化使用户从硬件设备的管理和运维工作中解脱出来,专注内部业务的开发和创新,由云服务商负责云平台本身的稳定,通过这种责任分担模式使整个平台的运行效率获得提升! 售后优化 首先,云服务器归于基本电信增值服务,所以其服务提供商需要获得工信部的批阅以具有相应的运营资质。云服务商对国家方针政策的了解,备案等业务流程的支持,也是确保客户可以合法合规的运营。再者,当服务器使用过程出现问题时,需要运营商的协助才可以解决,这种情况需要任何时候都可以找到主机商的售后支持,大多数云服务商而言都会提供7*24小时的云服务器售后支持服务,这点也可以打消用户的使用顾虑,让用户安心、放心! -
不重启Java服务,如何对线上代码快速热更新?
需要热更新代码的场景 (1)当线上服务器出现问题时,有些时候现有的手段不足以发现问题所在,可能需要追加打印日志或者增加一些调试代码,如果我们去改代码重新部署,会破坏问题现场,可以通过热部署的手段来增加调试代码 (2)线上出现紧急bug,通过Review代码找到问题,修改好后打包部署的流程可能比较久,可以通过热部署代码及时解决问题 Arthas的使用 使用阿里巴巴开源的Java诊断工具---Arthas,他可以附着在我们的Java服务器进程上面,查看服务器状态,jvm状态等各种参数指标,还可以进行热更新 1、下载启动Arthas wget https://alibaba.github.io/arthas/arthas-boot.jarjava -jar arthas-boot.jar 2、启动后会显示当前机器上面所有的java进程,选择我们需要监控/修改的进程,输入序号回车 3、一些常用命令,如果线上出现问题,可以通过以下命令查看各项指标是否有异常 dashboard——当前系统的实时数据面板thread——查看当前 JVM 的线程堆栈信息jvm——查看当前 JVM 的信息sysprop——查看和修改JVM的系统属性sysenv——查看JVM的环境变量getstatic——查看类的静态属性 (1)打印前五名最消耗CPU的线程,可以及时找到CPU过高的代码位置 thread -n 5 (2)查看某个函数的调用堆栈 stack <类全包名> <函数名> (3)查看某个函数的哪个子调用最慢,耗时最久的调用会标红显示,可以方便找出某个功能中最耗时的操作 trace <类全包名> <函数名> (4)监控某个函数的调用统计数据,包括总调用次数,平均运行时间,成功率等信息 monitor <类全包名> <函数名> 4、输入exit可以退出当前的连接,但是附着在服务器进程上的Arthas依然在运行,完全退出可以输入shutdown 热更新 1、首先找到我们需要更新代码的全包名,通过jad命令将线上正在运行的代码反编译出来 jad --source-only <全包名> > <导出目录+文件名> 2、拿到java代码后,我们根据需求来修改代码,需要注意的是这里热更新代码的实际原理是调用Java基础类java.lang.instrument.Instrumentation的redefineClasses方法,他可以通过修改字节码来替换已有的class文件,其中有诸多的限制: (1)比如不能增加或删除field/method (2)没有退出的函数不能生效,比如一个函数体内是一个where(true)循环,永远不会结束,那么我们修改的代码也永远不会生效 我们可以在函数中增加一些代码,比如增加日志打印等 3、修改好代码后,我们要找到这个这个类对应的类加载器,再去加载这个class,执行如下命令会返回类加载器的对象地址 sc -d <全包名> | grep classLoaderHash 4、通过内存编译将Java文件编译成Class文件 mc -c <类加载器的对象地址> <Java文件所在目录+文件名> 5、最后,我们通过命令将class文件进行热更新 redefine <Class文件所在目录+文件名> 6、更新完毕不出意外会立即生效,这时候就可以去验证代码是否生效了 -
软件定义数据中心,是虚拟化、软件化数据中心的一切资源,专门的软件会代替专门硬件,贯穿整个数据中心。
1、基础设施层 在软件定义数据中心的最底层是硬件基础设施,主要包括服务器、存储和各种网络交换设备。 2、资源抽象层 在软件定义数据中心,硬件的能力需要被抽象成为能够统一调度管理的资源池。在这一层次,主要有以下一些关键技术帮助完成虚拟化和池化的工作。主要包括: ●软件定义计算: 软件定义的计算是针对x86系统的虚拟化技术,它可以将x86系统转变成通用的共享硬件基础架构,原先多台服务器完成的工作可以整合到少数服务器完成。 ●软件定义存储: 软件定义的存储可以对存储资源进行抽象化处理,它把应用于服务器的先进技术运用于存储领域,可对异构存储资源进行抽象化处理,以支持存储的池化、复制和按需分发,并以应用为中心进行消费和管理,最终实现基于策略的自动化。 ●软件定义网络: 软件定义的网络与安全会创建一个二层到七层的网络服务,通过创建软件驱动型抽象层将网络连接与安全组件与底层物理网络基础架构完全分离,因此它可以确保硬件独立性,使得网络连接与安全服务摆脱与硬件绑定的限制。 3、资源管理层 要统一管理虚拟化之后的资源,不仅仅是将状态信息汇总、显示在同一个界面,还需要能够用一套统一的接口更进一步集中管理这些资源,如让用户对数据中心中的计算、存储、网络资源进行集中管理,并能提供相关权限控制、数据备份、高可靠等额外的特性。 4、应用服务层 比资源管理更贴近最终用户的是一系列的服务,对于配置这些服务来说 ,软件定义数据中心的独特优势是自动化。绝大多数部署的细节都是预先定义的,管理员只需要调整几个参数就能完成配置。 -
SD-WAN技术到底是什么?
SD-WAN是一种全新的网络管理方式, SD-WAN,是利用成熟的软件技术(如智能路由调度、应用优化、TCP 优化、QOS 等),结合和传统网络资源(互联网、窄带专线、MPLS、LTE、裸光纤等等)高度融合,最大限度发挥传统资源的性能,核心是让用户自主对广域网智能管理,用户可以按照预期的策略对广域网的流量进行调度,整合 MPLS、专线、裸光纤、互联网、LTE 等多种网络线路资源,进行广域网的流量调度,使能普通互联网线路专线级别,降低流量成本,提高多线带宽利用率。 SD-WAN典型架构图 核心功能:基于多线智能调度和链路质量优化,提升业务体验 QOE探测:高频率探测overlay隧道时延、丢包、抖动等QOE参数 智能应用调度引擎:智能选路引擎,保障业务可续可用 构建隧道:解耦底层路由、构建隧道封包传输 SD-WAN VS VPN VS 物理专线 易运维:全局设备、链路、应用流量可视化 -
实时视频直播客户端技术盘点Native、HTML5、WebRTC、微信小程序
1、前言 2017 年 12 月,微信小程序向开发者开放了实时音视频能力,给业内带来广阔的想象空间。连麦互动视频直播技术在 2016 年直播风口中成为视频直播的标配,然而只有在原生的 APP 上才能保障良好的用户体验。 那时候,在微信小程序中无法进行实时音视频互动。微信小程序在去年 12 月宣布开放实时音视频能力,再加上去年 6 月苹果宣布即将支持 WebRTC,业内一下子千树万树梨花开,前途一片光明。 连麦互动直播技术和微信小程序以及 WebRTC 能产生怎么样的化学作用?开发者在微信小程序或者浏览器 WebRTC 上实现连麦互动直播技术的时候,需要知道什么和考虑什么? 连麦视频直播的客户端主要包括:原生 APP、浏览器 H5、浏览器 WebRTC、微信小程序。浏览器上的应用包括 H5 和 WebRTC,前者可以拉流观看,后者可以实现推流和拉流。 2、视频直播客户端技术之Native APP 原生 APP 终端音视频引擎的结构框图如下,基本包括了音频引擎、视频引擎和网络传输,合称实时语音视频终端引擎。这里还包含底层的音视频采集和渲染,还有网络的输入输出能力,这是操作系统开放的能力。 原生 APP 有个天然的好处,它是直接和操作系统打交道的,操作系统开放的资源和能力它都可以直接用,比如说音视频的采集渲染,还有网络的输入输出。套用一句时髦的广告语:“没有中间商赚差价”,直接和操作系统对接,可以获得比较好的用户体验。 在原生 APP 上实现连麦直播的优势是,对上面所说的七个环节有较好的把控,可以获得比较低的延迟,能自研实现语音前处理 3A 算法,包括回声消除,还有对抖动缓冲策略和码率自适应的策略都有比较好的把控。另外,可以自主选择使用 RTMP 协议还是基于 UDP 的私有协议,对抗弱网环境更加有保障。 市面上比较流行的前处理技术,比如美颜、挂件、变声等,原生 APP 都可以通过开放前处理接口让开发者实现或者对接这些技术。为什么要强调这个呢?因为浏览器 WebRTC 和微信小程序都没有开放前处理接口,开发者没有办法自行实现或者对接第三方的美颜或者挂件等技术模块。 在原生 APP 上,开发者可以得到全面的把控能力,让用户可以获得更好的体验。主流的视频直播平台都有自己的原生 APP 平台,而浏览器和微信小程序相对来说是辅助的。原生 APP 的用户体验是最好的,而且对开发者来说也是最可控的。 在原生 APP 上实现连麦直播的劣势是什么呢?开发门槛高,开发周期长、人力成本高。另外,从获取用户和传播的角度来讲,也没有浏览器和微信小程序那么便利。 3、视频直播客户端技术之浏览器(HTML5) 浏览器 H5 就像一个硬币有两面,有好处也有劣势,好处是开发成本低,容易传播,劣势是只能拉流,不能推流,不能做到多个用户连麦直播。另外,在浏览器 H5 上延迟也是比较大。如果使用 RTMP 或者 HTTP-FLV,延迟会在 1 秒到 3 秒之间,如果用 HLS 延迟会大于 8 秒甚至 10 秒,这么大的延迟就根本就不允许实现连麦直播。 使用这三种协议都是通过浏览器 H5 中的播放器来播放的。在多主播连麦互动的场景中,一个播放器里面只能播一路视频流,三个主播就得三个播放器,因此看不到多个主播同框连麦互动的情形。如果要看到多个主播同框互动的画面,就必须把多路流混合成一路流,在单个播放器里面播放。 另外,浏览器 H5 的源代码是开放的。如果在浏览器上把音视频终端引擎实现了,相当于对外公开了所有核心的源代码。因此,还没有见过哪个厂商在浏览器 H5 上完整地把音视频引擎真正做出来。即使你愿意做出来,浏览器也不会允许你这样做,开发者和操作系统之间隔着浏览器,如果浏览器不把操作系统的核心能力开放给开发者,开发者就不能自主采集和渲染,不能掌控网络输入输出,类似流控码控等功能无法实现。 在浏览器 H5 中也可以通过 websocket 来传输,用 jsmpeg 来播放,视频编解码的格式用 mpeg1。 mpeg1 是一个比较老的媒体格式,所有浏览器都支持。在浏览器中使用 jsmpeg 播放器播放 mpeg1,所有浏览器也可以支持。这么做可以获得比较低的延迟,但是还是无法推流,没办法实现连麦直播。 4、视频直播客户端技术之浏览器(WebRTC) 大家可能会觉得很遗憾,浏览器 H5 虽然很容易传播,开发简单但是体验欠佳,不能连麦直播。那么在浏览器上能不能推流,能不能实现连麦直播呢?答案是可以的,那就要用到 WebRTC。 这里说的 WebRTC 是指已经被内嵌到浏览器里面,被浏览器支持的 WebRTC,而不是 WebRTC 的源代码。部分主流浏览器内嵌了 WebRTC,对开发者开放了浏览器的实时音视频能力。 上图是 WebRTC 的结构图。我们可以看到 WebRTC 包括了音频引擎,视频引擎、传输引擎等,最底层的虚线框表示可以重载,也就是说浏览器把最底层的音视频渲染和网络传输的底层能力开放给开发者,开发者可以根据自己的需求选择是否进行重载。音频引擎中,包括了两个编解码器:iSAC 和 iLBC,前者针对宽带和超宽带的音频编解码,后者针对窄带音频编解码。 音频引擎还包括了音频抖动缓冲,回声消除和噪音抑制模块等。抖动缓冲中的 NetEQ 算法可以说是 WebRTC 里面的精华之一。 视频引擎中,包括了 VP8 和 VP9 的视频编解码器,甚至是即将到来的 AV1。视频引擎还包括视频抖动缓冲和图像质量增强等模块。传输引擎,WebRTC 使用的是 SRTP(Secured Realtime Transport Protocol)安全实时传输协议。 最后,WebRTC 采取 P2P 的通信方式,没有媒体服务器等后端的实现。以上是 WebRTC 的简单介绍。 浏览器 WebRTC 一般的优势和劣势这里就不再重复,请大家自行百度,这里只说重点。浏览器 WebRTC 的好处就是实现了相对完整的音视频终端引擎,允许在浏览器上推流,可以实现连麦直播。 然而,浏览器 WebRTC 也有不足: 没有开放前处理接口,美颜和挂件这些模块没办法接入第三方的或者自研方案; 媒体服务器后端没有实现,开发者要实现媒体服务器,然后通过开源 WebRTC 网关(比如说 janus)接入; 编解码器、抖动缓冲和语音前处理 3A 等能力只能依靠 WebRTC,不能自行定制化; 部分主流浏览器是不支持 WebRTC 的,特别是苹果的浏览器。虽然说去年苹果宣布支持 WebRTC, 但是目前 iOS Safari 最新版本对 WebRTC 的支持并不好,iOS Safari 的主流版本并不支持 WebRTC,在 iOS 上面微信浏览器也是不支持 WebRTC 的。 由于 WebRTC 不提供媒体服务器的实现,因此需要把浏览器 WebRTC 接入到媒体服务器后端,这个可以是自研的,也可以是第三方的服务。浏览器 WebRTC 和媒体服务器后端之间的协议和媒体格式是不一样的,因此要做协议和格式的转换。WebRTC 用的基于 UDP 的 SRTP,需要把它转换成媒体服务器的基于 UDP 的私有协议。另外,媒体格式也需要转换,因为 WebRTC 中语音视频格式默认用的是 VP8 或者 VP9。同时实时传输网络中有关信令调度也需要做一些调整。浏览器 WebRTC 和媒体服务器后端之间的接入层也可以采用开源的 WebRTC Gateway(比如说 janus)来实现。 浏览器是类似操作系统的一种超级应用,它坐拥重要的流量入口,然而它也是开发者和操作系统之间的“中间商”。开发者通过 WebRTC 获得浏览器开放的实时音视频能力,然而也必须要承受 WebRTC 带来的痛苦。 5、视频直播客户端技术之微信小程序 微信小程序是什么?是跑在微信上面的轻型应用。微信是什么?是类操作系统的超级应用。这些特征和浏览器以及 H5 是不是很接近?H5 是浏览器支持的轻型应用,而浏览器是类操作系统的超级应用。浏览器背后是各大国际科技巨头,不像微信这样背后只有腾讯一个互联网巨头。因此,从这个角度来看,微信小程序、浏览器 WebRTC 和 H5 是有相通之处的。 微信小程序可以类比为浏览器 H5 那样的客户端和服务器的结构。其中 HTML 对应微信小程序的 WXML,CSS 对应小程序的 WXSS,小程序的脚本语言和 JS 是一样的,只是框架不一样。微信小程序提供了两个标签,一个是<live-pusher>,一个是<live-player>。<live-pusher>就是推流,<live-player>就是拉流,可以实现单向直播或者连麦直播。小程序提供两种模式:LIVE 和 RTC,LIVE 支持单向直播,RTC 支持低延迟的连麦直播。目前微信小程序推流采用 RTMP 协议,如果要和私有协议互通,需要进行协议转换。 微信小程序开放了实时音视频能力,对业界来说是重大利好。然而,根据上面的信息和逻辑,我们也看到采用微信小程序实现连麦互动直播的好处和不足。 好处有三点: 1)开发成本低,开发周期短,基本和 H5 的开发难度差不多; 2)很容易传播和获客,充分利用好微信的优质流量; 3)可以推流和拉流,允许实现连麦直播和实时语音视频通话。 不足有四点: 1)你会受制于微信小程序的实时音视频能力,比如说,如果它的回声消除有某些问题,你只能等微信团队按照自己的节奏来优化,而自己没有任何办法去优化; 2)小程序没有开放前处理接口,只能使用小程序自带的美颜或者变声功能(如果有),不能对接自行研发或者第三方的美颜或者变声模块; 3)通过 RTMP 协议推流和拉流,不能和基于 UDP 的私有协议互通连麦。如果要实现和基于 UDP 的私有协议互通连麦,就必须要增加接入层来转换协议格式甚至媒体格式; 4)没有实现后端媒体服务器,开发者必须要自行实现媒体服务器,或者把微信小程序接入到第三方的实时通信网络。 浏览器通过 WebRTC 开放了浏览器的实时音视频能力,而微信通过小程序开放了微信的实时音视频能力,在两个类操作系统的平台上允许开发者去实现连麦直播和实时音视频通话。然而,无论 WebRTC 还是小程序只是在终端上带你入门,对开发者来说,要真正实现整套系统,还有很多工作需要做的。 如果要将微信小程序接入实时音视频传输网络,中间得有接入服务器,我们叫接入层。在接入层我们需要做协议的转换,比如说,如果实时音视频传输网络是使用基于 UDP 的私有协议,那么要把 RTMP 协议转为基于 UDP 的私有协议。还有媒体格式的转换,如果和实时传输网络的媒体格式不一样,还需要进行转换。 6、视频直播客户端技术之WebRTC 通过WebView接入小程序 还有别的方法在小程序上做连麦直播互动吗?必须要使用微信小程序开放的语音视频能力吗?也不一定。下图展示了我在市面上看过的一个技术方案,它绕过了微信小程序实时语音视频能力,通过微信小程序 WebView 组件实现了连麦直播的方案。这里和大家分享一下。 这个方案的基本思路是利用 WebView 的浏览器特点,在 WebView 内使用 WebRTC 的 Web API,从而在小程序上获得实时音视频能力。上图是这个方案的架构图。最底层是微信小程序的基础能力。上一层是 WebView,微信小程序的 WebView 类似浏览器,那么就可能会支持 WebRTC。然而必须要注意到,微信小程序的 WebView 在安卓平台上支持 WebRTC,但在 iOS 平台上面不支持 WebRTC。 虽然这个方案理论上也能在微信小程序上实现连麦直播,但是它有以下的局限性: 1)在 iOS 平台上,微信小程序不支持这个方案,上面已经说过; 2)小程序 WebView 不是完整的浏览器,要比普通浏览器表现差而且有很多的限制; 3)开发者和操作系统之间隔了好几层:微信底层,小程序,WebView,WebRTC,然后才是开发者的小程序应用。每一层的抽象都会带来性能上的消耗,都会影响到最终的体验。 这个方案本质上还是一个基于 WebRTC 的解决方案,没有用到微信小程序开放的实时音视频能力,而是快速地借助 WebView 组件,剑走偏锋,十分讨巧地在微信小程序里使用了 WebRTC。 7、本文小结 连麦直播技术逐步在原生 APP, 浏览器 H5,浏览器 WebRTC,微信小程序上延伸,衍生出更加丰富的生态,提供更加便捷和良好的用户体验,对视频直播平台和用户来说是好消息。然而,欲带皇冠,必承其重。特别是在浏览器 WebRTC 和微信小程序上,开发者要充分理解这些类型终端的特点和局限,才能更好地在上面利用连麦直播技术进行创新,服务用户。