2020CES-美国拉斯维加斯电子展中国展商统计

2020年美国拉斯维加斯消费类电子产品展览会(CES2020)
举办时间:2020年1月07日~10日,展览四天
举办地点:拉斯维加斯会展中心
主办单位:美国消费者技术协会(简称CTA)

2020CES-美国拉斯维加斯电子展中国展商统计

2020CES-美国拉斯维加斯电子展中国展商统计展馆产品分类:
LVCC中央大厅(Central):以视听为主,大型企业做宣传的地方;
LVCC 北馆(North):苹果专区、汽车电子专区等;
LVCC南馆(South):
S1:数码音频类、家用连接器, 
S2:数字成像、影像产品、综合电子区、会议室、游戏专区、数码健康专区、3D打印、智能机器人、智能穿戴、综合电子区 
S3、S4:电脑周边,个人通讯类、无线通讯、家庭影院,互联网信息技术 ,综合电子区 
Venetian金沙馆(Sands)二楼:专业展区,按产品分配,有积分;

新南广场馆:国家馆、不分产品、按国家为区域按国家分区; 

2020CES-美国拉斯维加斯电子展中国展商统计

 2020CES-美国拉斯维加斯电子展中国展商统计

往届中国参展商的数据统计:
2010年第43届CES,有超过 2500 个企业参展,有 20000 多个新产品展出,其中 中国参展企业超过 300 家,包括了联想、华为、漫步者、海信、TCL、海尔、华硕、汉王等厂商。
这一年,CES 首次邀请中国企业家代表作主题演讲,演讲者是海信集团董事长周厚健。
2011年第44届CES,参展企业达到 2500 个,中国有超过 400 家企业参展,在 CES 参展规模上排名第三,最终达成价值 3153 万美元的贸易合同和 5799 万美元的意向性贸易协议。
2012年第45届CES,3100 家展商,仅参展的深圳企业就超过了 300 家。
2013年第46届CES,微软第一次缺席 CES,海信果断出击,仅用 45 分钟即与美国/电视服务提供商 Dish Network 盘下了原本属于微软的展位。
2014年第47届CES,1200 多家中国企业参展。
2015年第48届CES,全球展商3700家,中国企业1300多家。
2016年第49届CES,展览会上,共有来自150个国家的4300多家展商参加,中国企业1400多家,约20000多个新产品在展会上推出,展出净面积19万平方米,展览总面积为38万平方米,观众超过15.3万人次,其中国际观众达3.4万人次,5000家媒体报道此次盛会,共举办41场主旨演讲,200场学术研讨会,同期颁发了年度创新产品奖。其中Microsoft、IBM、Intel、MOTO、索尼、松下、三洋、夏普、先锋、东芝、飞利浦及中国的海尔、海信、康佳、联想等百余家国际大型知名企业参展。其中中国企业占参展总数的1/6,CES展正在成为彰显中国企业实力的国际舞台。
2017年第50届CES,中国企业占据重要地位,中国参展商2017将再次膨胀,达到1416家左右。
2018年第51届CES,中国参展商达到1500家左右,其中深圳企业482家
2019年第52届CES,中国参展商持续高涨,达到1500家以上,其中深圳企业临近500家

2020CES观展总结

CES2020在拉斯维加斯正式开幕,热衷科技创新的前哨用户,怎能错过全球创新风向标的“消费电子大展CES”!

美国时间1月7日,王煜全、吴声、万维钢三维老师终于“会师”完毕,3W组合正式合体,已开启在拉斯维加斯的前哨考察团观展之行。接下三天来将带领大家,洞察展会背后的产业趋势,挖掘全新产品背后的商业机会,梳理商业背后的逻辑。

下面为大家带来王煜全老师第一天的观展总结!

| 航空公司首次参展,“平行现实”值得重视

今年Delta航空公司首次参加CES,是第一次航空公司来参展。这件事本身体现了CES的一个姿态:从传统的只看重科技,扩展到了整个消费品领域,甚至现在连服务也越来越重视科技。

演讲里最吸引我的是Delta航空提到的“平行现实(Parallel Reality)。这个概念。可以说是原来“环境智能(Ambient Intelligence)升级版。我们希望跟环境能有一个背景层的智能互动的,就是说我有什么需求,环境是知道的。

比如我走到商店橱窗前,橱窗给我展示的商品就是我想买的。我看到广告牌,上面展示的广告就是我想看的,甚至我连续走过两个广告位,它们展示的广告是连续的,当然更不用说其他的互动了。

如果我每一次去到一个陌生环境,还需要我手动输入个人信息,环境才知道怎么跟我互动,这肯定是低效的。所以这件事其实由来已久,就是如何能够有更强的环境智能,但是一直解决不好。因为首先是需要有足够强的智能,然后需要有足够强的互动能力,现在这两件事慢慢都解决了。

CES2020新机会:航空公司来了智能家居全面开花,以色列抱团创新

一方面人工智能不断发展,机器对人的理解甚至会超过人类自己。我们今天在金沙展馆的时候也看到了,有一个重要概念,叫预测性技术(Predictive Technology)。

人工智能的未来并不是给我们分析现状,而是告诉我基于现状会发生什么、未来会怎么样。面对消费者,更重要的不是知道他的特征,而是知道消费者将会需要什么商品,甚至在什么时候要什么商品,才能更好地给他服务。

所以人工智能使得环境对人的理解达到这地步了。另外一个就是互动技术的发展。现在随着5G到来,IoT迎来蓬勃发展。IoT的核心是物跟物的互联。

一直有个说法,当各种智能设备兴起,手机可能会消亡。我认为这是错的。为什么呢?因为手机是一个核心节点,是一个强大的随身的智能助理。它对你的理解超过所有其他设备,因为它天天随身跟着你。甚至你的智能可穿戴设备的数据,也都会同步到手机里进一步去处理和解读。所以手机是你的最随身最懂你的智能终端。

那就意味着手机将会和环境产生大量的互动。而所谓平行现实,也就是说现实能够跟你随时实现互动,你走到哪,这个懂你的环境就会跟到哪里。这个平行现实的实现,很有可能是通过物物互动来实现的。手机和环境产生智能连接,手机对你进行解读,产生预判,知道你想要什么,然后连接周围的环境,把相应的服务或者内容推给你。

CES2020新机会:航空公司来了智能家居全面开花,以色列抱团创新

当然另一种可能性是,环境中的设备本身也能进行大量的信息采集了。我们看到另一个趋势就是,显示成了一个独立产业,以前我们叫电视机或者叫电脑显示器,现在显示器就是一个独立产业,显示屏越来越智能化。

现在出现一个变化就是,以后大多数显示屏上都会带上摄像头。因为和环境互动要完成一个闭环,要有数据的采集分析、解读和输出。传统的显示屏是一个标准的数据输出设备,现在显示屏实现了智能化,分析解读也有了。但是数据的采集是没有的,所以才会造成显示是千人一面的,所有人看都是一样的内容。

如果有摄像头,能够捕捉到人脸,知道是谁正在看,就可以给他推送他想看的东西,甚至可以实现从不同角度看到的图像是不一样的,这在技术上是可实现的。当然也可以和手机结合,实现内容精准推送。

这是一个更加完美的未来世界,你走到任何一个环境,它都是随身的,懂你的,能够和你实现个性化互动的。

| 以色列的创新,要辩证的思考学习

今天我们看了CES比较有特色的尤尼卡公园的展馆,尤其深入了解了以色列展区。额。以色列科技创新的特色是,一方面和中国一样勤奋,愿意在模式创新上动脑筋,比如说在没有电网的地方弄个临时的电动车充电站,这个市场比较狭小,因为全世界没有电网地方越来越少,那种地方基本上是人烟稀少的,可能就不适合电动车去那儿。

另一方面,值得我们思考的是,以色列的优势是知道怎么对接高校科技,首先以色列有好高校,还有美国大量的高校里面都有是犹太裔科学家,以色列还有一批人才很精通直接从科技做转化。

但是问题是,以色列公司的目标市场一般是锁定美国的,做完转化实现量产和推向市场,甚至将来上市,都是往美国走的。我们知道的很多知名的以色列企业,其实只是根在以色列,发展都在美国,比如著名的Mobileye。

大多数以色列企业还没有发展到对接量产的阶段,在很早期就会往美国转移。所以位于以色列的企业,一般都还在研发期的早期,在做原型设计。在研发期,它们就会往美国转移。到了美国以后,这些企业才会考虑市场、考虑量产。

中国现在有一个现实的问题,就是我们还没有办法对接太早的科技企业。中国的企业都比较偏后期,科技企业到了需要大规模量产的时候,中国企业能解决。但是还在产品原型设计改进的时候,中国企业就帮不上忙。

所以,以色列企业为什么不可以学,不是说人家的精神不可学,是说跟中国现有的制造型企业没有办法严丝合缝对接上,中间有个鸿沟。而这个沟是在美国得到弥补的,不是在以色列。

CES2020新机会:航空公司来了智能家居全面开花,以色列抱团创新

这方面,中国的企业家确实需要进一步提升我们的产业对接能力,我们也在寻找真正有意愿和实力的“科技制造家“,希望能够跟他们一起对接全球科技创新,推动中国产业升级。

| 智能家居明显升级,会不会全面开花?

智能家居整体上比前几年更落地了,2C的产品越来越多,但其实中美的模式不太一样,美国是相对有中心系统的智能家居布局,它的中心是智能音箱。现在的胜出者其实已经有了,第一是亚马逊,第二是谷歌,苹果可能还有一系列的机会,其他的胜出者就不容易了,大格局基本上定了。

格局确定之后,大家也就容易做事了,因为智能家居产品基本和亚马逊和谷歌联通就覆盖掉90%的市场了,这也是为什么美国智能家居的大量的对接的产品多起来的原因,因为一旦标准化了,就敢放手去把我的系统接进去。

当然本身这些企业也在做各种努力,比如我们今天看了亚马逊的展馆,他的车载系统看似不是家居,但实际上后台是Alexa智能语音互动系统,表面是音箱,核心是智能语音互动。

另外,比如我前一阵刚买了一个新的微波炉,就是智能语音互动的。一旦语音互动的核心解决了,大家就会想我如何介入了,所以就开始滚雪球。

CES2020新机会:航空公司来了智能家居全面开花,以色列抱团创新

中国始终没有形成这样一个前台的核心,前台核心要以硬件载体音箱为主,但是中国什么东西都是千团大战,音箱也是三四十家智能音箱,甚至更多智能音箱大战。

但实际上他们忽略了一个事实,智能音箱的核心不是智能音箱,而是用智能音箱作为硬件载体,后台是软件的语音互动支撑平台。中国语音互动支撑平台水平不够,只顾打音箱战了,所以到最后造成了一个结局就是,因为大家都有音箱,所以谁也不愿意介入对方的系统,反倒造成一些大的玩家没有办法整合,是分裂的。

从后台做整合是更科学的做法,就是不考虑前台的问题了,谁是第一接入点不重要,但是后台遵循同样的规则更重要。尤其是像涂鸦智能,我们为什么看好,因为它是一个相对第三方的开放平台。

如果阿里接入百度平台,百度接入腾讯平台,大家都是不放心的,但是不管百度、阿里还是腾讯接入涂鸦平台,这是可以的,因为你基本上就是一个后台。

所以中国的特点是前台不清晰,前台的争夺就还会延续很久,甚至说可能会出现无霸主的局面。但是后台能统一,这和国外是不太一样的。

CES2020新机会:航空公司来了智能家居全面开花,以色列抱团创新

另外一个原因也很有意思,这在西方不太存在,因为西方都是独立的house,中国是大规模建商品房,现在大量的商品房造成了一个前装市场,就是说我实际上跟开发商谈,开发的时候,就把智能家居就引入了。

引入智能家居的时候,其实也要考虑这个问题,不愿意过分的品牌化,如果引入涂鸦智能这样的平台,我引入谁都是合理的,因为作为一个后台,我接入谁都可以接。但如果引入的是阿里的系统,首先得罪了百度,其次为什么要替阿里做宣传对吧?所以这就是涂鸦智能这样平台的机会,因为更偏向后台赋能,而且它的选择性更强,前台要用什么都可以。

所以中国的住房前装市场更集中居住的特点,也是涂鸦能够迅速起来的一个重要原因。我们今天在CES展台看到涂鸦的增长速度开始放快,原因很简单,就是他在前装积累了足够用户数的时候,他的to C市场,也就是它的后装市场就容易启动了。

但这个机会,地产自己做未必能走通。地产企业进入科技领域其实犯过很多错误,地产自己做智能家居平台肯定是错误之一。为什么?因为体量不够大,地产和阿里、百度有同样问题,地产不会用竞争对手地产公司的平台,我不会让你知道我的老底的。

那么就会带来一个问题,只能是地产自己的公司来做,但是中国的地产公司没有一家大到垄断到1/2,1/3的市场,虽然单个体量很大,但是整体来说比例很小,市场覆盖率不够。

另外一个很严重的问题是特别容易产生路径依赖,因为这是自己公司的产品,做成什么样都行,没有检验标准也没有第三方来评价如何算更好,这样的产品是没有办法做好的。

| CES创新奖应该更加创新

今天我们带大家去看了创新奖的集中展示区,总的来说并不那么令人惊艳。很多早就出现的概念,稍微做个改动,换个马甲就又推出来了,这肯定不是创新奖原来的目的,创新奖肯定是希望选最优的东西。

CES2020新机会:航空公司来了智能家居全面开花,以色列抱团创新

另一个问题是创新奖需要企业必须要来参加评选,咱们团里就有企业说他错过了,本来有很好的产品但是没来参评,那更不用说还有很多创新项目根本不来参加CES。所以如果只能在参加CES的小范围之内评奖,就会有偏差。

所以,我们计划在前哨大会上推出一个评选优秀科技消费品的奖项,会更公正一点,不管你来不来,只要产品够好,都给评上。我们的榜单就会在今年的前哨大会上揭晓,到时候请大家看看我们会评出怎样的创新产品。

CES第一天看展总结就到这里,明天我们继续。

伴随CES第一天结束,第一场晚间论坛也已成功举办,未来两天万维钢、吴声、王煜全三位老师的3W组合,将每晚持续给大家带来烧脑的思想盛宴,几位老师的精彩发言,我们将陆续整理,分享给大家,敬请期待。

智能家居控制入口研究

站在5年后的今天再审视这个议题,我们会发现情况在发生变化,据艾瑞咨询《2018年中国智能家居研究报告》[2] 中的调研结果,智能家居从业者眼中最看好的用户入口排名如下:

调研显示的结果极为分散,经过对“入口”概念的漫长争夺,智能家居从业者对入口仍无共识。

王学集表示,自己在创业初期也在寻找入口级设备的机会,直到半年后才逐渐意识到智能家居行业可能并没有一个确定的入口。他认为:

“智能家居是以AI的技术驱动了多设备联动,形成围绕式人机合一体验,目前看来很难有一个非常明确的设备能做到这样的水平。”

公共 NTP 服务器地址大全 Public NTP Server

NTP 是 Network Time Protocol 的简称,也就是网络时间协议。而 NTP 服务器是可以通过网络来同步时间的服务器。Windows 自带的 NTP 服务器都在美国,有时间经常无法访问。再加上有朋友跟我留言,想让我收集一下 NTP 服务器,所以建立了此页面。

本页优先提供国内可以使用的 NTP 服务器地址,然后也收集了一些国外知名的 NTP 服务器地址,提供给大家选择。

个人建议,国内用阿里云、国外用谷歌或者苹果。也有朋友经过测试苹果在国内也是可以使用的,大家可以试试看。

附:Windows 10 修改时间服务器的方法

如果有什么问题或建议可以跟我留言,戳⇒ 联系我

国内知名公共 NTP 服务器地址
Chinese Public NTP Server

[国内 NTP 服务器] · 国际 NTP 服务器

国家授时中心 NTP 服务器
NTSC NTP Server

ntp.ntsc.ac.cn

中国 NTP 快速授时服务
NTP ORG CN

cn.ntp.org.cn

教育网

edu.ntp.org.cn

国际 NTP 快速授时服务
Pool NTP ORG

cn.pool.ntp.org

阿里云公共 NTP 服务器
Aliyun NTP Server

time.pool.aliyun.com

time1.aliyun.com

time2.aliyun.com

time3.aliyun.com

time4.aliyun.com

time5.aliyun.com

time6.aliyun.com

time7.aliyun.com

腾讯云公共 NTP 服务器
Tencent Cloud NTP Server

time1.cloud.tencent.com

time2.cloud.tencent.com

time3.cloud.tencent.com

time4.cloud.tencent.com

time5.cloud.tencent.com

教育网(高校自建)
EDU NTP Server

ntp.sjtu.edu.cn

ntp.neu.edu.cn

ntp.bupt.edu.cn

ntp.shu.edu.cn

国际 NTP 服务器
Global Public NTP Server

[国际 NTP 服务器] · 国内 NTP 服务器

国际 NTP 快速授时服务
Pool NTP ORG

pool.ntp.org

0.pool.ntp.org

1.pool.ntp.org

2.pool.ntp.org

3.pool.ntp.org

asia.pool.ntp.org

谷歌公共 NTP 服务器
Google NTP Server

time1.google.com

time2.google.com

time3.google.com

time4.google.com

苹果公司公共 NTP 服务器
Apple NTP Server

time.apple.com

time1.apple.com

time2.apple.com

time3.apple.com

time4.apple.com

time5.apple.com

time6.apple.com

time7.apple.com

微软 Windows NTP 服务器
Microsoft Windows NTP Server

time.windows.com

美国标准技术研究院 NTP 服务器
NIST NTP Server

time.nist.gov

time-nw.nist.gov

time-a.nist.gov

time-b.nist.gov

香港天文台公共 NTP 服务器
Hong Kong Observator NTP Server

stdtime.gov.hk

浏览器开发模式:ServiceWorkers in Firefox and Chrome管理

Chrome和Firefox为用户提供了在浏览器中管理已注册Service Worker的选项,包括从浏览器中删除Service Worker的选项。

服务工作者是大多数现代浏览器支持的一项新兴功能,使站点和服务无需在浏览器中打开即可与浏览器进行交互。

将它们视为按需流程,可以使用推送通知和数据同步,或者使站点脱机工作。

当前没有将Web浏览器设计为在Service Worker在浏览器中注册时始终提示用户。当前,大多数情况下,这是作为后台进程发生的。

管理服务人员

显示通知

服务工作者可以自动注册,也可以在用户接受提示后注册。Pinterest是在Chrome或Firefox中访问该网站时会自动注册的网站。

用户不清楚这是因为它发生在后台。

Chrome和Firefox没有提供有关如何管理以前添加到浏览器的Service Worker的明确信息。尽管存在功能,但它们在此时或多或少对用户隐藏了,如果需要从浏览器中删除以前注册的工作人员,这将是一个问题。

本指南为您提供了在Firefox和Chrome中管理工作人员的方法。

有用的信息

  • 是注册服务工作者的页面。
  • 范围是指Service Worker控制的页面(接受来自其中的获取和消息事件)。
  • 脚本列出了Service Worker JavaScript文件的URL。

在Mozilla Firefox中管理服务人员

Firefox管理服务人员

Firefox用户可以通过以下方式在浏览器中管理所有注册的Service Worker:

  1. 在新选项卡或当前选项卡中加载about:serviceworkers,例如,通过复制和粘贴地址或将其添加书签并以此方式加载。
  2. Firefox在页面上显示所有注册的Service Worker。列出了每个Service Worker及其来源,范围,当前Worker URL,缓存名称和其他信息。
  3. 单击“取消注册”以从Firefox删除Service Worker,或单击“更新”以从其来源请求更新。

在Mozilla Firefox中禁用服务工作者

火狐禁用服务工作者

Firefox用户可以通过以下方式(通过我们广泛的Firefox隐私和安全设置指南列表)禁用浏览器中的Service Worker :

  1. 在浏览器的地址栏中加载about:config,然后按Enter。
  2. 确认如果显示通知,请小心。
  3. 使用搜索字段查找dom.service
  4. 找到dom.serviceWorkers.enabled,然后双击首选项名称以将其设置为false。这样做会禁用Mozilla Firefox中的Service Workers功能。

要撤消更改,请重复此过程,但请确保在完成操作后将首选项的值设置为true。

在Google Chrome中管理服务人员

镀铬服务人员
  1. 您需要在Chrome网络浏览器中加载chrome:// serviceworker-internals /网址,以打开已注册工作人员列表。
  2. Chrome显示的信息与Firefox略有不同,其中包括控制台日志,可能会派上用场。
  3. 点击取消注册按钮以从浏览器中删除所选项目,或开始激活它。

在Google Chrome中禁用服务人员

目前似乎没有办法在Chrome浏览器中禁用该功能。如果您找到了一种方法,请在下面发表评论,我将尽快更新文章。

Redis CPU使用率过高问题的排查

Redis CPU占用过高会导致所有使用Redis的客户端性能大幅下降,可能的原因中其中一个是大量的请求,尤其是keys命令请求过多,查询流程:

  1. 使用info和monitor命令(这两个命令也可以登录之后使用,不过有可能造成client的crash)

redis-cli -h 192.168.1.2  -a ‘passwd’ info 

Clients

connected_clients:25
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:1

Memory

used_memory:24022936
used_memory_human:22.91M
used_memory_rss:27422720
used_memory_rss_human:26.15M
used_memory_peak:76894968
used_memory_peak_human:73.33M
total_system_memory:33566736384
total_system_memory_human:31.26G
used_memory_lua:43008
used_memory_lua_human:42.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.14
mem_allocator:jemalloc-4.0.3

Persistence

loading:0
rdb_changes_since_last_save:3502
rdb_bgsave_in_progress:0
rdb_last_save_time:1575614696
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

Stats

total_connections_received:8119852
total_commands_processed:287772910835
instantaneous_ops_per_sec:23686
total_net_input_bytes:8372810113180
total_net_output_bytes:1471697139442
instantaneous_input_kbps:676.85
instantaneous_output_kbps:129.54
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:158935
evicted_keys:0
keyspace_hits:188709502
keyspace_misses:6948953
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:823
migrate_cached_sockets:0

Replication

role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

CPU

used_cpu_sys:3372080.50
used_cpu_user:404838.31
used_cpu_sys_children:851.85
used_cpu_user_children:5934.84

Cluster

cluster_enabled:0

Keyspace

db0:keys=14078,expires=1209,avg_ttl=150542
db6:keys=878,expires=682,avg_ttl=42691293

redis-cli -h 192.168.1.2 -a ‘ passwd ‘ monitor 

info命令会显示当前的状态,monitor会显示当前的客户端的命令请求;

  1. 使用慢查询 

redis-cli -h 192.168.1.xx  -a ‘ passwd ‘ slowlog get (reset替换get清空旧的log)

这个命令会显示出最近一段时间内的耗时较久的查询。

这几个命令综合起来,基本可以找到是哪些命令频繁调用造成系统繁忙。

一般来说,都是大量调用keys命令并使用通配符造成的。

记一次 Laravel 应用性能调优经历

这是一份事后的总结。在经历了调优过程踩的很多坑之后,我们最终完善并实施了初步的性能测试方案,通过真实的测试数据归纳出了 Laravel 开发过程中的一些实践技巧。

0x00 源起

最近有同事反馈 Laravel 写的应用程序响应有点慢、20几个并发把 CPU 跑满… 为了解决慢的问题,甚至一部分接口用 nodejs 来写。

而我的第一反应是一个流行的框架怎么可能会有这么不堪?一定是使用上哪里出现了问题。为了一探究竟,于是开启了这次 Laravel 应用性能调优之旅。

0x01 调优技巧

这次性能测试方案中用到的优化技巧主要基于 Laravel 框架本身及其提供的工具。

  1. 关闭应用debug app.debug=false
  2. 缓存配置信息 php artisan config:cache
  3. 缓存路由信息 php artisan router:cache
  4. 类映射加载优化 php artisan optimize
  5. 自动加载优化 composer dumpautoload
  6. 根据需要只加载必要的中间件
  7. 使用即时编译器(JIT),如:HHVM、OPcache
  8. 使用 PHP 7.x

除了以上优化技巧之外,还有很多编码上的实践可以提升 Laravel 应用性能,在本文中暂时不会做说明。(也可以关注我的后续文章)

1. 关闭应用 debug

打开应用根目录下的 .env 文件,把 debug 设置为 false。

APP_DEBUG=false

2. 缓存配置信息

php artisan config:cache

运行以上命令可以把 config 文件夹里所有配置信息合并到一个 bootstrap/cache/config.php 文件中,减少运行时载入文件的数量。

php artisan config:clear

运行以上命令可以清除配置信息的缓存,也就是删除 bootstrap/cache/config.php 文件

3. 缓存路由信息

php artisan route:cache

运行以上命令会生成文件 bootstrap/cache/routes.php。路由缓存可以有效的提高路由器的注册效率,在大型应用程序中效果越加明显。

php artisan route:clear

运行以上命令会清除路由缓存,也就是删除 bootstrap/cache/routes.php 文件。

4. 类映射加载优化

php artisan optimize --force

运行以上命令能够把常用加载的类合并到一个文件中,通过减少文件的加载来提高运行效率。这个命令会生成 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json 两个文件。

通过修改 config/compile.php 文件可以添加要合并的类。

在生产环境中不需要指定 --force 参数文件也可以自动生成。

php artisan clear-compiled

运行以上命令会清除类映射加载优化,也就是删除 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json 两个文件。

5. 自动加载优化

composer dumpautoload -o

Laravel 应用程序是使用 composer 来构建的。这个命令会把 PSR-0 和 PSR-4 转换为一个类映射表来提高类的加载速度。

注意:php artisan optimize --force 命令里已经做了这个操作。

6. 根据需要只加载必要的中间件

Laravel 应用程序内置了并开启了很多的中间件。每一个 Laravel 的请求都会加载相关的中间件、产生各种数据。在 app/Http/Kernel.php 中注释掉不需要的中间件(如 session 支持)可以极大的提升性能。

7. 使用即时编译器

HHVM 和 OPcache 都能轻轻松松的让你的应用程序在不用做任何修改的情况下,直接提高 50% 或者更高的性能。

8. 使用 PHP 7.x

只能说 PHP 7.x 比起之前的版本在性能上有了极大的提升。

嗯,限于你的真实企业环境,这个也许很长时间内改变不了,算我没说。

0x02 测试方案

我们使用简单的 Apache ab 命令仅对应用入口文件进行测试,并记录和分析数据。

  1. 仅对应用的入口文件 index.php 进行测试,访问 “/” 或者 “/index.php” 返回框架的欢迎页面。更全面的性能测试需要针对应用的更多接口进行测试。
  2. 使用 Apache ab 命令。ab -t 10 -c 10 {url}。该命令表示对 url 同时发起 10 个请求,并持续 10 秒钟。命令中具体的参数设置需要根据要测试的服务器性能进行选择。
  3. 为了避免机器波动导致的数据错误,每种测试条件会执行多次 ab 命令,并记录命令执行结果,重点关注每秒处理的请求数及请求响应时间,分析并剔除异常值。
  4. 每次对测试条件进行了调整,需要在浏览器上对欢迎页进行访问,确保没有因为测试条件修改而访问出错。如果页面访问出错会导致测试结果错误。

服务器环境说明

所有脱离具体环境的测试数据都没有意义,并且只有在相近的条件下才可以进行比较。

  1. 这套环境运行在 Mac 上,内存 8G,处理器 2.8GHz,SSD 硬盘。
  2. 测试服务器是使用 Homestead 搭建的。虚拟机配置为单核 CPU、2G 内存。
  3. 服务器 PHP 版本为 7.1,未特殊说明,则标识开启了 OPcache。
  4. 测试的 Laravel 应用程序采用 5.2 版本编写。app\Http\routes.php 中定义了 85 个路由。
  5. 测试过程中除了虚拟机、终端及固定的浏览器窗口外,没有会影响机器的程序运行。

以上的数据,大家在自己进行测试时可以参考。

0x03 测试过程及数据

1. 未做任何优化

1.1 操作

  • 按照以下检查项执行相应的操作。
  • 运行 ab -t 10 -c 10 http://myurl.com/index.php

基础检查项

  • .env 文件中 APP_DEBUG=true
  • 不存在 bootstrap/cache/config.php
  • 不存在 bootstrap/cache/routes.php
  • 不存在 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json
  • app/Http/Kernel.php 中开启了大部分的中间件
  • 浏览器访问 Laravel 应用程序欢迎页确保正常访问

1.2 数据记录

2. 关闭应用debug

2.1 操作

  • 在步骤 1 基础上修改 .env 文件中 APP_DEBUG=false
  • 浏览器访问 Laravel 应用程序欢迎页确保正常访问。
  • 运行 ab -t 10 -c 10 http://myurl.com/index.php

2.2 数据记录

2.3 对比结果

与步骤 1 结果比较发现:关闭应用 debug 之后,每秒处理请求数从 26-34 上升到 33-35,请求响应时间从 大部分 300ms 以上下降到 290ms 左右,效果不太明显,但确实有一定的提升。

注意:这部分与应用中的日志等使用情况有比较大的关联。

3. 开启缓存配置信息

3.1 操作

  • 在步骤 2 基础上,运行 php artisan config:cache,确认生成 bootstrap/cache/config.php
  • 浏览器访问 Laravel 应用程序欢迎页确保正常访问。
  • 运行 ab -t 10 -c 10 http://myurl.com/index.php

3.2 数据记录

3.3 对比结果

与步骤 2 结果比较发现:开启配置信息缓存之后,每秒处理请求数从 33-35 上升到 36-38,请求响应时间从 290ms 左右下降到 260ms 左右,效果不太明显,但确实有一定的提升。

4. 开启缓存路由信息

4.1 操作

  • 在步骤 3 基础上,运行 php artisan route:cache,确认生成 bootstrap/cache/routes.php
  • 浏览器访问 Laravel 应用程序欢迎页确保正常访问。
  • 运行 ab -t 10 -c 10 http://myurl.com/index.php

4.2 数据记录

4.3 对比结果

与步骤 3 结果比较发现:开启路由信息缓存之后,每秒处理请求数从 36-38 上升到 60 左右,请求响应时间从 260ms 下降到 160ms 左右,效果显著,从 TPS 看,提升了 70%。

5. 删除不必要的中间件

5.1 操作

  • 在步骤 4 基础上,注释掉不必要的中间件代码。
  • 浏览器访问 Laravel 应用程序欢迎页确保正常访问。
  • 运行 ab -t 10 -c 10 http://myurl.com/index.php

注意:这次测试中我注释掉了所有的中间件。实际情况中应该尽量只留下必要的中间件。

5.2 数据记录

5.3 对比结果

与步骤 4 结果比较发现:删除了不必要的中间件之后,每秒处理请求数从 60 左右上升到 90 左右,请求响应时间从 160ms 下降到 110ms 左右,效果非常明显,从 TPS 看,提升了 50%。

6. 开启类映射加载优化

6.1 操作

  • 在步骤 5 基础上,运行 php artisan optimize --force,确认生成 bootstrap/cache/compiled.php 和 bootstrap/cache/services.json
  • 浏览器访问 Laravel 应用程序欢迎页确保正常访问。
  • 运行 ab -t 10 -c 10 http://myurl.com/index.php

6.2 数据记录

6.3 对比结果

与步骤 5 结果比较发现:做了类映射加载优化之后,每秒处理请求数从 90 上升到 110,请求响应时间从 110ms 下降到 100ms 以下,效果还是比较明显的。

7. 关闭 OPcache

7.1 操作

  • 在步骤 6 基础上,关闭 PHP 的 OPcache,并重启服务器。通过 phpinfo() 的 Zend OPcache 确认 OPcache 已经关闭。
  • 浏览器访问 Laravel 应用程序欢迎页确保正常访问。
  • 运行 ab -t 10 -c 10 http://myurl.com/index.php

7.2 数据记录

7.3 对比结果

与步骤 6 结果比较发现:关闭 OPcache 之后,每秒处理请求数从 110 下降到 15,请求响应时间从 100ms 以下上升到 650ms 以上。开启与关闭 OPcache,数据上竟有几倍的差别。

此后,我重新开启了 PHP 的 OPcache,数据恢复到步骤 6 水平。

0x04 踩过的坑

1. [LogicException] Unable to prepare route [/] for serialization. Uses Closure.

在运行 php artisan route:cache 命令时报这个错误。

原因:路由文件中处理“/”时使用了闭包的方式。要运行该命令,路由的具体实现不能使用闭包方式。

修改方案:将路由的具体实现放到控制器中来实现。

2. [Exception] Serialization of ‘Closure’ is not allowed.

在运行 php artisan route:cache 命令时报这个错误。

原因:路由文件中定义了重复的路由。

修改方案:排查路由文件中的重复路由并修改。尤其要注意 resource 方法很可能导致与其方法重复。

3. [RuntimeException] Invalid filename provided.

在运行 php artisan optimize --force 命名时报这个错误。

原因:在加载需要编译的类时没有找到相应的文件。5.2 版本的 vendor/laravel/framework/src/Illuminate/Foundation/Console/Optimize/config.php 中定义了要编译的文件路径,但不知道为什么 /vendor/laravel/framework/src/Illuminate/Database/Eloquent/ActiveRecords.php 没有找到,所以报了这个错误。

修改方案:暂时注释掉了以上 config.php 中的 ../ActiveRecords.php 一行。

4. InvalidArgumentException in FileViewFinder.php line 137: View [welcome] not found.

在运行 php artisan config:cache 之后,浏览器上访问 Laravel 应用程序欢迎页报这个错误。

原因:Laravel 应用程序服务器是通过 Homestead 在虚拟机上搭建的。而这个命令我是在虚拟机之外运行的,导致生成的 config.php 中的路径是本机路径,而不是虚拟机上的路径。所以无法找到视图文件。

修改方案:ssh 到虚拟机内部运行该命令。

0x05 实践技巧

坑也踩了,测试也做过了。这里针对这次经历做个实践技巧的简单总结。

1. 有效的 Laravel 应用程序优化技巧

  1. 关闭应用debug app.debug=false
  2. 缓存配置信息 php artisan config:cache
  3. 缓存路由信息 php artisan router:cache
  4. 类映射加载优化 php artisan optimize(包含自动加载优化 composer dumpautoload
  5. 根据需要只加载必要的中间件
  6. 使用即时编译器(JIT),如:HHVM、OPcache

2. 编写代码时注意事项

  1. 路由的具体实现放到控制器中。
  2. 不定义重复的路由,尤其注意 resouce 方法。
  3. 弄清各中间件的作用,删除不必要的中间件引用。

0x06 下一步

以上的调优技巧及编码注意事项主要针对框架本身,在真正的业务逻辑编码中有很多具体的优化技巧,在此没有讨论。

后续的优化重点将会放在具体编码实践上:

  1. 使用 Memcached 来存储会话 config/session.php
  2. 使用专业的缓存驱动器
  3. 数据库请求优化
  4. 为数据集书写缓存逻辑
  5. 前端资源合并 Elixir

0x07 写在最后

网上看到很多框架性能对比的文章与争论,也看到很多简单贴出了数据。这些都不足以窥探真实的情况,所以有了我们这次的实践,并在过程中做了详实的记录。在各位读者实践过程中提供参考、比较、反思之用。对于这次实践有疑问的读者,也欢迎提出问题和意见。

不多说了,要学习更多技术干货,请关注微信公众号:up2048。

– EOF –

原文有图参考: https://segmentfault.com/a/1190000011569012

Wi-Fi现场勘测,分析,故障排查

越 来越多的家庭和企业转向WiFi网络作为其首选的互联网接入的提供方式。无线网络对于终端用户更为便捷,使每个人都能够充分利用其移动设备的优势。无线网络相比传统的有线网络而言,也免除了线接的烦扰和限制。

从管理员的角度来说,WiFi网络虽然有很多的优势,但同时也伴随有一系列必须予以解决的其他挑战。这不仅仅只是为您的所有用户提供充足的连接的问题。您还需要了解您的网络的其他方面,如覆盖区域和信道重叠。

对于我们部分使用家庭WiFi网络的用户而言,我们就是自己的网络管理员。如果您是这样的情况或只是一位具有好奇心的终端用户,您需要了解的您的网络的其中一大特性就是WiFi信号强度。这个值对于您的网络活动效率是一个决定性的因素。让我们深度了解一下WiFi信号以及它们是如何影响您的无线网络使用的。

什么是WiFi信号?

WiFi网络使用无线电波来在不同的设备之间建立通信。这些设备可能包括计算机,移动手机,平板电脑或网络路由器。无线网络路由器是互联网或其他以太网络有线连接和无线连接设备之间的接口。

路由器对从WiFi网络用户那里接收来的无线电信号进行解码并将它们传至互联网。反过来,路由器会将从互联网接收的数据由二进位数据转换成无线电波,传送至使用同一网络的设备。

产生WiFi信号的无线电波使用的2.4 GHz和5 GHz的频带。这些频率要高于电视或手机所使用的频率,相对较低频率能够传递更多的数据。

WiFi信号在传输数据时使用的是802.11网络标准。WiFi网络采用了一系列不同协议的变体。您将会了解到的部分最常见的协议包括2.4GHz频带所使用的802.11n以及5GHz频带主要使用的802.11ac。其他协议您可能还会看到802.11b,它与802.11g是最慢标准。

良好的WiFi信号强度是怎样的?

整个网络覆盖区域内的WiFi信号强度直接影响着用户高效处理各种网络活动的能力。在深入探析怎样的信号强度才适合您进行相应的WiFi网络活动之前,让我们讨论一下 WiFi信号强度是如何测量的

信号强度是以dBm为单位的。它指的是分贝毫瓦,以从0到-100内的负值表示。因此,-40的信号相比-80的信号更强,因为-80距离0更远,因此是一个更小的数字。

dBm是一个对数性的,而不是线性的,这意味着信号强度之间的变化并不是平滑渐进式的。从这个层面来说,3 dBm的不同会使之前的信号强度减半或提升一倍。

能够影响到您的WiFi表现的背景噪音等级也是用dBm表示的。对于噪音等级而言,数值越接近0,就表示噪音等级越高。经测量的-10 dBm的噪音要高于-40 dBm的噪音。

下表揭示了您应当努力实现的最低信号强度,只有达到才能将您的WiFi网络用于各种不同目的。

信号强度限定符适合用途
-30 dBm极好这是可实现的最大信号强度,适用于任何一种使用情景。
-50 dBm极好此极好的信号强度适于各种网络使用情形。
-65 dBm非常好建议为智能手机和平板电脑提供支持。
-67 dBm非常好此信号强度对于网络电话和流媒体视频的使用是足够的。
-70 dBm可接受该等级是确保实现稳定的数据包传输的最低信号强度要求,对于网页冲浪和收发邮件的使用是足够的。
-80 dBm不良实现基本连接,但数据包传输不稳定。
-90 dBm非常差大多都是噪音,抑制大多数功能的实现。
-100 dBm最差全是噪音。

哪些因素会影响到WiFi信号强度?

能够影响到您的网络WiFi信号的有 一系列不同因素。其中部分因素有:

路由器位置

路由器位置的各个不同方面会影响到良好信号的传输表现。这些包括:

  • 路由器的高度 – 您应当将您的路由器尽可能放到高处。将它放在地板或较低的搁板上将影响到其提供强烈信号的能力。

  • 中心位置 – 如果您的路由器放在您的住宅或办公室的中心位置,那么您将获得 最佳WiFi信号覆盖。将路由器放在家里的角落将会导致WiFi信号泄漏并降低您的信号覆盖区域内的信号强度。

  • 来自其他设备的干扰 – 微波炉和无线电话可能使用的是与您的 WiFi路由器相同的频率,能够产生对信号等级造成影响的背景噪音。

  • 墙壁和地板 – 如果在连接设备的位置可以清楚地看到路由器的位置,那么您将会获得最佳WiFi信号。穿越 墙壁和地板进行传输的信号的强度会大打折扣。

保持您的路由器的更新

将您的路由器的设置改成自动固件升级以保持其处于高效运作状态。阶段性地重启您的路由器也是一个比较好的做法,有利于实现良好的信号覆盖。

距离路由器的距离

需要较强信号的设备,如那些用于玩游戏或观看视频的设备,将它们放在靠近路由器的位置可能会获得更好的信号表现。在一些情况下,您可能需要通过使用像路由器这样的附加设备来 扩展您的WiFi信号范围以增强WiFi信号强度。

mysql文本替换

UPDATE w_zshop_goods_sku_images SET path = REPLACE(path, ‘http://qq.com’,’https://qq.com’);
UPDATE w_zshop_commodities SET details = REPLACE(details, ‘http://qq.com’,’https://qq.com’);
UPDATE w_zshop_commodities SET params = REPLACE(params, ‘http://qq.com’,’https://qq.com’);
UPDATE w_users SET profile = REPLACE(profile, ‘http://qq.com’,’https://qq.com’);
UPDATE w_zshop_banners SET pic = REPLACE(pic, ‘http://qq.com’,’https://qq.com’);
UPDATE w_zshop_order_coms SET pic = REPLACE(pic, ‘http://qq.com’,’https://qq.com’);

coturn 添加redis实现对转发流量和转发时长的统计

前言

虽然已经用 coturn 来作为 webrtc 的转发服。 但是我们只做了一个最基本的静态key的加密校验而已。但是对于转发的流量和转发的时长,却没法统计。
但是事实上,对于转发的流量和时长对于我们的业务来说是非常必要的。
刚好 coturn 有提供了一个统计的redis配置,redis-statsdb,这个是就是 turnserver 会将一些统计的数据存到 redis 中。 然后我们去取就行了。
所以要在配置文件里面加上这一个配置:

1
redis-statsdb=”ip=59.57.xx.xx dbname=13 port=6379 connect_timeout=30″

具体文档:

-O, –redis-statsdb Redis status and statistics database connection string, if used (default – empty, no Redis stats DB used). This database keeps allocations status information, and it can be also used for publishing and delivering traffic and allocation event notifications. The connection string has the same parameters as redis-userdb connection string.https://github.com/coturn/coturn/wiki/turnserver
也就是这个参数是用来做状态统计的。 可以用来发布和传递流量, 还有断开和连接的webhook通知。通过这个统计的redis db,我们可以得到这一次转发的开始时间,结束时间,以及转发的流量。
大概的一个截图就是:

1

这边还有更详细的说明: schema.stats.redis
状态的key就是:

1
turn/user/<username>/allocation/<id>/status

举例:

1
turn/realm/pano/user/1531994598:fe909a0a4cde20be0a7bb9fbfdc8d6dc_21_24_18154723/allocation/003000000000002028/status
1

他的值有可能是 new lifetime=… 或者是 refreshed lifetime=…

一个用户名下可能有多个状态。
然后是订阅:

  • 通过订阅: turn/realm/*/user/*/allocation/*/status 这个主题,可以得到一些事件,比如 deleted 事件
  • 通过订阅: turn/realm/*/user/*/allocation/*/traffic 这个主题,可以得到一些信息,比如流量, 当这个配置被删除的时候, 也可以得到通知。

如果是订阅所有的配置,那么就是 turn/realm/*/user/*/allocation/*/total_traffic
因为不能过期,所以redis 的配置文件,要配置这两个:

1
2
timeout 0
tcp-keepalive 60

分析

假设我们已经在使用webrtc的应用上连接上turn server了,并且已经在转发了。那我们就可以看下这个redis跑的统计数据都是什么样的?
接下来先在redis 先sub一下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
127.0.0.1:6379[13]> psubscribe turn/realm/*
Reading messages… (press Ctrl-C to quit)
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417691:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003326/status”
4) “new lifetime=600”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/status”
4) “new lifetime=600”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/003000000000003700/status”
4) “refreshed lifetime=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/003000000000003700/status”
4) “deleted”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/003000000000003700/total_traffic”
4) “rcvp=0, rcvb=0, sentp=0, sentb=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/traffic”
4) “rcvp=1610, rcvb=1607159, sentp=438, sentb=22052”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/traffic”
4) “rcvp=1385, rcvb=1404252, sentp=663, sentb=31187”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/traffic”
4) “rcvp=1407, rcvb=1442093, sentp=641, sentb=30066”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/traffic”
4) “rcvp=1383, rcvb=1408780, sentp=665, sentb=31146”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417691:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003326/status”
4) “refreshed lifetime=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417691:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003326/status”
4) “deleted”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417691:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003326/total_traffic”
4) “rcvp=0, rcvb=0, sentp=0, sentb=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/status”
4) “refreshed lifetime=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417691:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003327/status”
4) “new lifetime=600”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417691:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/003000000000003705/status”
4) “new lifetime=600”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/status”
4) “deleted”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/total_traffic”
4) “rcvp=5785, rcvb=5862284, sentp=2407, sentb=114451”
1

可以看到进行一次连接的话,会分配好几条临时会话。 从下图来看的话,可以看到有 4 条,其实这四条都属于同一个连接。

接下来我们一条一条来分析:

  • 刚开始建立了一条 3326 的临时channel , 生命周期是 600s,也就是 10分钟
  • 然后又建立了一条 3324 的临时channel
  • 接下来的三条分别是,刷新一条 3700 的临时channel ,lifetime 为0,说明是要删除,所以接下来就收到一条 delete 的状态,说明这个临时topic要删除,然后当删除的时候,就会将这一段时间的流量(total_traffic )也传上来。
  • 接下来的4条,全部都是 3324 这一个topic的流量信息。包括收到的字节和发送的字节
  • 接下来的三条是3326,分别是将lifetime 为0,然后delete,最后关于这条临时channel 的流量过来。
  • 接下来的一条是 3324 这一条的lifetime 为 0, 然后是两条新的临时channel 的建立, 然后就是 3324 收到 delete 的状态,和总流量的通知。

总结一下:

1. 一次的webrtc 的turnserver 转发,其实会分配了好几个临时的 channel。

2. 每个 channel 的生命周期和对应的状态

每个 channel 刚开始创建的时候,生命周期只有 600s, 这个可以在 配置文件设置:

1
2
3
4
5
# Uncomment to set the lifetime for the channel.
# Default value is 600 secs (10 minutes).
# This value MUST not be changed for production purposes.
#
#channel-lifetime=600

而且刚开始创建就会有状态通知,内容就是 new lifetime=600
虽然每个channel的生命周期都是 600s, 但是并不意味着,600s 之后,这个channel就会被删除,其实不是的,这个是可以被续的,也就是如果这个 channel 被续了,那么就会有这个状态通知:

1
2
3
4
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532403222:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/004000000000003897/status”
4) “refreshed lifetime=600”

这个说明被续了一个周期了。当然也有不续的,这时候也会有这个状态,不过这时候 lifetime 是 0:

1
2
3
4
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532415366:07a9939e437c9bca97f67b4b74de6a2f_21_24_22819787/allocation/004000000000003905/status”
4) “refreshed lifetime=0”

一旦 lifetime 为0, 就说明这个channel要被删除了。 这时候就会收到 delete 状态:

1
2
3
4
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532415366:07a9939e437c9bca97f67b4b74de6a2f_21_24_22819787/allocation/000000000000001816/status”
4) “deleted”

这时候就说明这条channel已经被删除了。
而且每一个channel 的最长生命周期是可以配置的,默认是 3600s:

1
2
3
4
5
# Uncomment if you want to set the maximum allocation
# time before it has to be refreshed.
# Default is 3600s.
#
#max-allocate-lifetime=3600

所以一个完整的 channel 周期就是 创建-> 续周期(一次以上) -> 删除 (如果续的是 0)
针对这个,我后面试了一下, 在一次长达 一个多小时的webrtc连接, 那个转发流量的channel, 续周期续了7次, 一次 600s, 总的是 7 * 600 = 4200, 比3600 还大了,但是也还没有断开,所以这个也有点奇怪???

3. 流量信息

每一条channel 在生命周期之内,如果有进行流量转发的话,那么就会每隔一段时间就会有 traffic 这个状态过来,注意,如果是 stun 或者 local 这种不走转发的,那么是没有这个事件的:

1
2
3
4
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/traffic”
4) “rcvp=1383, rcvb=1408780, sentp=665, sentb=31146”

而且每次的channel 的生命周期结束之后,也就是 delete 状态,也会收到这一条生命周期的所有的转发流量数据。

1
2
3
4
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532417569:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003324/total_traffic”
4) “rcvp=5785, rcvb=5862284, sentp=2407, sentb=114451”

跟 traffic 不一样, traffic 是真的是转发有流量,才会每隔一段时间抛一次,而 total_traffic 是必会有的,不管是穿透还是转发, 只不过如果是穿透的话,那就是都是 0,比如:

1
2
3
4
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532415366:07a9939e437c9bca97f67b4b74de6a2f_21_24_22819787/allocation/004000000000003905/total_traffic”
4) “rcvp=0, rcvb=0, sentp=0, sentb=0”

每一个 delete 状态,都会跟着一个 total_traffic 事件。 而里面的 这些参数,其实都是 traffic 的所有对应参数的总和。
这四个参数分别是:

1
2
3
4
rcvp: 收到的数据包
rcvb: 收到的字节(byte)
sentp: 发送的数据包
sentb: 发送的字节(byte)

所以我们如果要统计这一次转发的时长的话,那么就要记录这次连接的所有的channel。也就是如果这一次的转发,有5个channel,那么就第一个channel创建的时候,就是开始时间, 当所有的channel 都断开的时候,那么就是结束时间。 一定要所有的channel 都断开,才算转发结束,
而且中间还会有不断的新的channel被创建,这些新的channel也要加入到map里面去。然后每一个channel断开,就从map里面去掉, 一直到最后map为空的话,才算转发结束。算转发的总流量也是一样,每一个channel都会有一段流量。 当所有的channel都断开的时候,加起来就是总的转发流量。

代码实现

刚开始是这样子写的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
package main

import (
“errors”
“fmt”
github.com/garyburd/redigo/redis
“iGong/util/log”
“strconv”
“strings”
“sync”
“time”
)

type OnlineTimeBucket struct {
Data map[string]*OnlineTimeBucketSub
Locker *sync.Mutex
}

func NewOnlineTimeBucket() *OnlineTimeBucket {
return &OnlineTimeBucket{
Data: make(map[string]*OnlineTimeBucketSub),
Locker: &sync.Mutex{},
}
}

type OnlineTimeBucketSub struct {
Timer map[string]*OnlineTime
}

type OnlineTime struct {
Start int64
End int64
Delete bool
TotalTraffIc bool
Rcvp int
Rcvb int
Sentp int
Sentb int
}

var onlineTimeBucket *OnlineTimeBucket
var serverTime = time.Now().Unix()

/*
turn/realm/pano/user/1531882310:7ed1019263ce5e09f3d40a1ca15ae992_21_24_18152992/allocation/000000000000000495/status new lifetime=600
turn/realm/pano/user/1531881513:7ed1019263ce5e09f3d40a1ca15ae992_21_24_18152992/allocation/001000000000000462/status refreshed lifetime=0
turn/realm/pano/user/1531882310:7ed1019263ce5e09f3d40a1ca15ae992_21_24_18152992/allocation/004000000000000899/status deleted
turn/realm/pano/user/1531881513:7ed1019263ce5e09f3d40a1ca15ae992_21_24_18152992/allocation/001000000000000462/total_traffic rcvp=18612, rcvb=894124, sentp=104268, sentb=114206669
turn/realm/pano/user/1531881926:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/004000000000000896/traffic rcvp=1847, rcvb=2052114, sentp=201, sentb=10652
*/

func TurnServerStats() {
conn, err := RedisTurn.GetConn()
sub := redis.PubSubConn{Conn: conn}
if err != nil {
log.Error(err)
}
defer conn.Close()
onlineTimeBucket = NewOnlineTimeBucket()
sub.PSubscribe(“turn/realm/*”)

for {
switch n := sub.Receive().(type) {
//case redis.Message:
// fmt.Printf(“Message: %s %s\n”, n.Channel, n.Data)
case redis.PMessage:
err = forwardStats(n)
if err != nil {
continue
}

case error:
fmt.Printf(“error: %v\n”, n)
return
}
}

}

func forwardStats(data redis.PMessage) (err error) {
fmt.Printf(“PMessage: %s %s %s\n”, data.Pattern, data.Channel, data.Data)
event, deviceId, channel, err := decodeChannel(data.Channel)
if err != nil {
log.Error(err)
return err
}
log.Info(event, deviceId)
switch event {
case “status”:
//统计时长 和在线状态
onlineStatus := decodeDataWithStatus(data.Data)
log.Info(onlineStatus)
addOnlineTime(deviceId, channel, onlineStatus)
case “total_traffic”:
//统计流量 这个事件过来说明转发已经结束 并且只有一个会话是有值的
trafficMap, err := decodeDataWithTraffic(data.Data)
if err != nil {
return err
}
//rcvp 接收到的包数量 rcvb 接收到的流量 sentp 发送的包数量 sentb 发送的包流量
log.Info(trafficMap)
addFlow(deviceId, channel, trafficMap)

}
return

}

func decodeChannel(channel string) (event string, deviceId, channelId string, err error) {
args := strings.Split(channel, “/”)
if len(args) != 8 {
err = errors.New(“channel fail .”)
return
}
event = args[7]
deviceId = strings.Split(args[4], “:”)[1]
channelId = args[6]
return

}

func decodeDataWithStatus(data []byte) (onlineStatus int) {
args := strings.Split(string(data), “=”)
switch args[0] {
//新建
case “new lifetime”:
onlineStatus = 0
//刷新
case “refreshed lifetime”:
onlineStatus = 1
//移除
case “deleted”:
onlineStatus = 2
default:
onlineStatus = 1
}
return
}
func decodeDataWithTraffic(data []byte) (stats map[string]int, err error) {
args := strings.Split(string(data), “,”)
if len(args) != 4 {
err = errors.New(“traffic data fail”)
return
}
stats = make(map[string]int)
for _, v := range args {
statsInfo := strings.Split(v, “=”)
s, _ := strconv.Atoi(statsInfo[1])
stats[strings.TrimLeft(statsInfo[0], ” “)] = s
}
return
}

//记录转发时长
func addOnlineTime(deviceId, channelId string, onlineStatus int) {
if onlineStatus == 1 {
return
}
onlineTimeBucket.Locker.Lock()
timer := time.Now().Unix()
if _, ok := onlineTimeBucket.Data[deviceId]; !ok {
j := new(OnlineTimeBucketSub)
j.Timer = make(map[string]*OnlineTime)
onlineTimeBucket.Data[deviceId] = j
}
switch onlineStatus {
case 0:
log.Info(“new life_time”)
var onlineModel = new(OnlineTime)
onlineModel.Start = timer
onlineTimeBucket.Data[deviceId].Timer[channelId] = onlineModel
case 2:
log.Info(“delete life_time”)
if _, ok := onlineTimeBucket.Data[deviceId].Timer[channelId]; !ok {
var onlineModel = new(OnlineTime)
onlineModel.Start = serverTime
onlineTimeBucket.Data[deviceId].Timer[channelId] = onlineModel
}
onlineTimeBucket.Data[deviceId].Timer[channelId].End = timer
onlineTimeBucket.Data[deviceId].Timer[channelId].Delete = true
}
onlineTimeBucket.Locker.Unlock()

}

//记录转发流量并入库
func addFlow(deviceId, channelId string, trafficMap map[string]int) {
onlineTimeBucket.Locker.Lock()
if _, ok := onlineTimeBucket.Data[deviceId]; !ok {
j := new(OnlineTimeBucketSub)
j.Timer = make(map[string]*OnlineTime)
onlineTimeBucket.Data[deviceId] = j
}

onlineTimeBucket.Data[deviceId].Timer[channelId].Rcvb = trafficMap[“rcvb”]
onlineTimeBucket.Data[deviceId].Timer[channelId].Rcvp = trafficMap[“rcvp”]
onlineTimeBucket.Data[deviceId].Timer[channelId].Sentb = trafficMap[“sentb”]
onlineTimeBucket.Data[deviceId].Timer[channelId].Sentp = trafficMap[“sentp”]
onlineTimeBucket.Data[deviceId].Timer[channelId].TotalTraffIc = true
var isDelete = true
for _, v := range onlineTimeBucket.Data[deviceId].Timer {
if v.Delete == false || v.TotalTraffIc == false {
isDelete = false
}
}

if isDelete {
//计算时间,,流量
var rcvb, rcvp, sentb, sentp int
var end int64
start := time.Now().Unix()
for _, v := range onlineTimeBucket.Data[deviceId].Timer {
rcvb += v.Rcvb
rcvp += v.Rcvp
sentp += v.Sentp
sentb += v.Sentb
if start > v.Start {
start = v.Start
}
if end < v.End {
end = v.End
}
}
accountInfo := strings.Split(deviceId, “_”)
if len(accountInfo) < 4 {
log.Info(“deviceId len fail “, deviceId)
}
total_time := onlineTimeBucket.Data[deviceId].Timer[channelId].End – onlineTimeBucket.Data[deviceId].Timer[channelId].Start
err := InsertTurnServerLogs(accountInfo[3], accountInfo[0], accountInfo[1], accountInfo[2], start, end, total_time, rcvp, rcvb, sentp, sentb)
if err != nil {
log.Error(err)
}
onlineTimeBucket.Data[deviceId].Timer = nil
delete(onlineTimeBucket.Data, deviceId)
}

onlineTimeBucket.Locker.Unlock()
}

按照上面的算法来做的话,当我在用web测试的时候,会出现一个情况:

就是如果 coturn 的连接断开了。但是对于这个username, 他还是会保持一两条临时 channel

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532433896:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/000000000000001857/traffic”
4) “rcvp=1466, rcvb=1325047, sentp=582, sentb=29696”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532433896:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003357/status”
4) “refreshed lifetime=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532433896:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003357/status”
4) “deleted”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532433896:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003357/total_traffic”
4) “rcvp=0, rcvb=0, sentp=0, sentb=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532433896:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/000000000000001857/status”
4) “refreshed lifetime=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532433896:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/003000000000003734/status”
4) “new lifetime=600”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532433896:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/001000000000003358/status”
4) “new lifetime=600”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532433896:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/000000000000001857/status”
4) “deleted”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532433896:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/000000000000001857/total_traffic”
4) “rcvp=1466, rcvb=1325047, sentp=582, sentb=29696”
1

明明我连接断开了,但是又重新连接了两条。而且这两条根本不会释放

这个就会导致 isDelete 的条件没法成立,因为总有新的链接没有释放。
而且后面还发现,一次转发,虽然有好几条channel存在,但是真正转发流量的channel只有一条,而且过了一个多小时,还是没有断。所以原则上我们只要去判断这一条channel,就可以知道本次转发的时长和流量了。 其他的channel都不要管。但是如果是stun这种穿透的,因为没有转发流量,所以根本不知道那一条的channel,才是起作用的那一条????

后面发现这种情况其实是一个bug, 之所以浏览器刷新还保持两条turn channel 是因为浏览器在刷新的时候,其实没有明确的给手机端发送断开webrtc的信号。导致手机端其实还不知道webrtc断开了。所以手机端其实是对turnserver连接进行重连了, 这也是为啥会有新的两条channel 的问题。
我试了其他端,比如 ios 端,如果是断开的话,是不会有遗留turnserver 的channel 的,最后全部都会被清掉。因此对于web端,在刷新浏览器,或者是退出页面的时候,都要给手机的发送断开webrtc的信号,并且断开本地的webrtc连接。
所以web端的代码得改下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// 关掉 webrtc
stopWebRtcServer: function () {
var self = this;
// 给手机端发送一个webrtc 关闭的指令
self.mqttSocket.pub(
self.subCommonStr + ‘toTarget’,
{
“method”: “webrtc.stop”,
},
{
useAes: true,
}
).done(function (data) {
console.log(“%c accept stop:” + JSON.stringify(data), “color:red”);
});
// 清空状态统计的定时
clearTimeout(self.rtcStateMap.timeId);
// 关闭signal长连接
self.mqttSocket.close();
// 关闭webrtc 连接
self.rtcSocket.close();
},

其中 rtcSocket 的 close 事件为:

1
2
3
4
5
6
7
close: function(){
// 停止 video 传输
var video = this._pc.getRemoteStreams()[0].getVideoTracks()[0];
video.stop();
// 关掉 pc 对象
this._pc.close();
}
1

先停止video传输,再释放掉 pc 对象。这时候本来 webrtc work 的时候,是这样的:

看到的消息就是:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/001000000000004071/status”
4) “new lifetime=600”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/004000000000004390/status”
4) “new lifetime=600”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/000000000000002210/status”
4) “new lifetime=600”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/004000000000004390/status”
4) “refreshed lifetime=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/004000000000004390/status”
4) “deleted”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/004000000000004390/total_traffic”
4) “rcvp=0, rcvb=0, sentp=0, sentb=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/001000000000004071/traffic”
4) “rcvp=1546, rcvb=1442311, sentp=502, sentb=24802”
1
1

就是建了3条 channel ,然后删掉一条 390 ,保留两条, 后面分别是 210 和 071

这时候我点击 停止webrtc 按钮,图片传输就会停止了。这时候webrtc 就断开了。

这时候就收到了断开的消息了, 210 和 071 都断开了:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/000000000000002210/status”
4) “refreshed lifetime=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/001000000000004071/status”
4) “refreshed lifetime=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/000000000000002210/status”
4) “deleted”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/000000000000002210/total_traffic”
4) “rcvp=0, rcvb=0, sentp=0, sentb=0”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/001000000000004071/status”
4) “deleted”
1) “pmessage”
2) “turn/realm/*”
3) “turn/realm/pano/user/1532677507:ac5fa606abf5ae9d02bd4206625b4911_21_24_18152992/allocation/001000000000004071/total_traffic”
4) “rcvp=4595, rcvb=4367095, sentp=1549, sentb=74756”
1

这时候channel 就全部为空了。

所以要这样才可以。 但是问题来了,刚才是我们手动点击 停止 webrtc 按钮的,当然流程是对的。
但是如果是直接刷新浏览器呢,那可是来不及处理的????
事实上也是有这个问题,如果直接刷新浏览器,并且不作处理的时候,就会出现最早之前的那种情况,就是手机端认为还连着,所以 turnserver 又建了两条新的 channel 。
所以我后面加了这个事件 onbeforeunload

1
2
3
4
5
6
// 这时候要设置一个unload事件,不然如果直接浏览器刷新的话,手机端是不知道webrtc不用了,他还会连接 turnserver, 导致turnserver 的session 一直在,后面没法算时间
// 设置unonload, 防止直接刷新浏览器的时候,没有传 webrtc.stop 指令
window.onbeforeunload = function(){
self.stopWebRtcServer();
return true;
};
1

每次用户刷新的时候,这时候就会弹出这个窗口,当用户点击 重新加载的时候, 这时候 stop 操作就已经处理完了。

因此就成功关闭了,缺点就是用户每次刷新都会弹窗,并且要点击重新加载。

所以服务端来说的话,整个连接过程中创建的channel 都要做判断,只有当channel 全部断掉的时候, 才判断这个连接结束,这时候才要算时间。虽然每一次连接都有一条channel 在发送流量。所以如果 traffic 有值的话,那么就是这一条有流量统计。所以如果有收到有流量的 total_traffic 的事件 ,那么应该就是 relay 的连接断开了。这时候就可以计算时长并入库了。
所以修改后的代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
package main

import (
“errors”
“fmt”
github.com/garyburd/redigo/redis
“iGong/util/log”
“strconv”
“strings”
“sync”
“time”
)

type OnlineTimeBucket struct {
Data map[string]*OnlineTimeBucketSub
Locker *sync.RWMutex
}

func NewOnlineTimeBucket() *OnlineTimeBucket {
return &OnlineTimeBucket{
Data: make(map[string]*OnlineTimeBucketSub),
Locker: &sync.RWMutex{},
}
}

type OnlineTimeBucketSub struct {
Timer map[string]*OnlineTime
}

//map 存在线时间,结束时间-开始时间,,结束之后再存入表

type OnlineTime struct {
Start int64
RefreshedFlow int64
End int64
Delete bool
TotalTraffIc bool
Rcvp int
Rcvb int
Sentp int
Sentb int
}

var onlineTimeBucket *OnlineTimeBucket
var serverTime = time.Now().Unix()

/*
turn/realm/pano/user/1531882310:7ed1019263ce5e09f3d40a1ca15ae992_21_24_18152992/allocation/000000000000000495/status new lifetime=600
turn/realm/pano/user/1531881513:7ed1019263ce5e09f3d40a1ca15ae992_21_24_18152992/allocation/001000000000000462/status refreshed lifetime=0
turn/realm/pano/user/1531882310:7ed1019263ce5e09f3d40a1ca15ae992_21_24_18152992/allocation/004000000000000899/status deleted
turn/realm/pano/user/1531881513:7ed1019263ce5e09f3d40a1ca15ae992_21_24_18152992/allocation/001000000000000462/total_traffic rcvp=18612, rcvb=894124, sentp=104268, sentb=114206669
turn/realm/pano/user/1531881926:26e4cd38fa6fc39fa8fc40fb25fe558c_21_24_18152649/allocation/004000000000000896/traffic rcvp=1847, rcvb=2052114, sentp=201, sentb=10652
*/

func TurnServerStats() {
conn, err := RedisTurn.GetConn()
sub := redis.PubSubConn{Conn: conn}
if err != nil {
log.Error(err)
}
defer conn.Close()
onlineTimeBucket = NewOnlineTimeBucket()
sub.PSubscribe(“turn/realm/*”)

for {
switch n := sub.Receive().(type) {
//case redis.Message:
// fmt.Printf(“Message: %s %s\n”, n.Channel, n.Data)
case redis.PMessage:
err = forwardStats(n)
if err != nil {
continue
}
case error:
fmt.Printf(“error: %v\n”, n)
return
}
}
}

func forwardStats(data redis.PMessage) (err error) {
fmt.Printf(“PMessage: %s %s %s\n”, data.Pattern, data.Channel, data.Data)
event, deviceId, channel, err := decodeChannel(data.Channel)
if err != nil {
log.Error(err)
return err
}
log.Info(event, deviceId)
switch event {
case “status”:
//统计时长 和在线状态
onlineStatus := decodeDataWithStatus(data.Data)
log.Info(onlineStatus)
addOnlineTime(deviceId, channel, onlineStatus)
case “traffic”, “total_traffic”:
//统计流量 这个事件过来说明转发已经结束 并且只有一个会话是有值的
trafficMap, err := decodeDataWithTraffic(data.Data)
if err != nil {
return err
}
//rcvp 接收到的包数量 rcvb 接收到的流量 sentp 发送的包数量 sentb 发送的包流量
log.Info(trafficMap)
addFlow(deviceId, channel, trafficMap, event)

}
return
}

func decodeChannel(channel string) (event string, deviceId, channelId string, err error) {
args := strings.Split(channel, “/”)
if len(args) != 8 {
err = errors.New(“channel fail .”)
return
}
event = args[7]
deviceId = strings.Split(args[4], “:”)[1]
channelId = args[6]
return
}

func decodeDataWithStatus(data []byte) (onlineStatus int) {
args := strings.Split(string(data), “=”)
switch args[0] {
//新建
case “new lifetime”:
onlineStatus = 0
//刷新
case “refreshed lifetime”:
onlineStatus = 1
//移除
case “deleted”:
onlineStatus = 2
default:
onlineStatus = 1
}
return
}
func decodeDataWithTraffic(data []byte) (stats map[string]int, err error) {
args := strings.Split(string(data), “,”)
if len(args) != 4 {
err = errors.New(“traffic data fail”)
return
}
stats = make(map[string]int)
for _, v := range args {
statsInfo := strings.Split(v, “=”)
s, _ := strconv.Atoi(statsInfo[1])
stats[strings.TrimLeft(statsInfo[0], ” “)] = s
}
return
}

//记录转发时长
func addOnlineTime(deviceId, channelId string, onlineStatus int) {
if onlineStatus == 1 {
return
}
timer := time.Now().Unix()
if _, ok := onlineTimeBucket.Data[deviceId]; !ok {
j := new(OnlineTimeBucketSub)
j.Timer = make(map[string]*OnlineTime)
onlineTimeBucket.Locker.Lock()
onlineTimeBucket.Data[deviceId] = j
onlineTimeBucket.Locker.Unlock()
}
onlineTimeBucket.Locker.RLock()
switch onlineStatus {
case 0:
log.Info(“new life_time”)
var onlineModel = new(OnlineTime)
onlineModel.Start = timer
onlineTimeBucket.Data[deviceId].Timer[channelId] = onlineModel
case 2:
log.Info(“delete life_time”)
if _, ok := onlineTimeBucket.Data[deviceId].Timer[channelId]; !ok {
var onlineModel = new(OnlineTime)
onlineModel.Start = serverTime
onlineTimeBucket.Data[deviceId].Timer[channelId] = onlineModel
}
onlineTimeBucket.Data[deviceId].Timer[channelId].End = timer
onlineTimeBucket.Data[deviceId].Timer[channelId].Delete = true
}
onlineTimeBucket.Locker.RUnlock()

}

//记录转发流量并入库
func addFlow(deviceId, channelId string, trafficMap map[string]int, event string) {
if _, ok := onlineTimeBucket.Data[deviceId]; !ok {
j := new(OnlineTimeBucketSub)
j.Timer = make(map[string]*OnlineTime)
j.Timer[channelId].Start = time.Now().Unix()
onlineTimeBucket.Locker.Lock()
onlineTimeBucket.Data[deviceId] = j
onlineTimeBucket.Locker.Unlock()

} else {

}
onlineTimeBucket.Locker.RLock()
if event == “total_traffic” {
onlineTimeBucket.Data[deviceId].Timer[channelId].Rcvb = trafficMap[“rcvb”]
onlineTimeBucket.Data[deviceId].Timer[channelId].Rcvp = trafficMap[“rcvp”]
onlineTimeBucket.Data[deviceId].Timer[channelId].Sentb = trafficMap[“sentb”]
onlineTimeBucket.Data[deviceId].Timer[channelId].Sentp = trafficMap[“sentp”]
onlineTimeBucket.Data[deviceId].Timer[channelId].TotalTraffIc = true
var isDelete = true
if trafficMap[“rcvb”] == 0 {
//当穿透的时候流量为0,并且不会保存回话,所以需要判断所有会话是否关闭 当转发的时候,流量会大于0 ,但是可能会保留回话,所以转发的时候只需要判断流量过来就可以结束
for _, v := range onlineTimeBucket.Data[deviceId].Timer {
if v.Delete == false || v.TotalTraffIc == false {
isDelete = false
}
}
}
if isDelete {
onlineTimeBucket.Locker.RUnlock()
insertFlowLogs(deviceId)
return
}
} else {
onlineTimeBucket.Data[deviceId].Timer[channelId].RefreshedFlow = time.Now().Unix()
}

onlineTimeBucket.Locker.RUnlock()
}

func insertFlowLogs(deviceId string) {
log.Info(“start insertFlowLogs=>”,deviceId)
var rcvb, rcvp, sentb, sentp int
var end int64
start := time.Now().Unix()
for _, v := range onlineTimeBucket.Data[deviceId].Timer {
rcvb += v.Rcvb
rcvp += v.Rcvp
sentp += v.Sentp
sentb += v.Sentb
if start > v.Start {
start = v.Start
}
if end < v.End {
end = v.End
}
}
accountInfo := strings.Split(deviceId, “_”)
if len(accountInfo) < 4 {
log.Info(“deviceId len fail “, deviceId)
}

err := InsertTurnServerLogs(accountInfo[3], accountInfo[0], accountInfo[1], accountInfo[2], start, end, end-start, rcvp, rcvb, sentp, sentb)
if err != nil {
log.Error(err)
}
onlineTimeBucket.Locker.Lock()
onlineTimeBucket.Data[deviceId].Timer = nil
delete(onlineTimeBucket.Data, deviceId)
onlineTimeBucket.Locker.Unlock()
}

//程序关闭时调用,,记录 使用时长
func forceInsertTurnServerUseLogs() {
onlineTimeBucket.Locker.Lock()
log.Info(“start forceInsertTurnServerUseLogs”)
for k, v := range onlineTimeBucket.Data {
//取其中一个的开始时间就可以
var start = time.Now().Unix()
var end = time.Now().Unix()
var rcvb, rcvp, sentb, sentp int
for _, v := range v.Timer {
rcvb += v.Rcvb
rcvp += v.Rcvp
sentp += v.Sentp
sentb += v.Sentb
if start > v.Start {
start = v.Start
}
}
useTime := end – start
accountInfo := strings.Split(k, “_”)
if len(accountInfo) < 4 {
log.Info(“deviceId len fail “, k)
}
err := InsertTurnServerLogs(accountInfo[3], accountInfo[0], accountInfo[1], accountInfo[2], start, end, useTime, rcvp, rcvb, sentp, sentb)
if err != nil {
log.Error(err)
}
}
onlineTimeBucket.Locker.Unlock()
}

如果是穿透的话,因为没有流量,所以每次收到 total_traffic的时候,都要判断是不是所有的channel 都断开了。如果是的话,那么就是连接断开了。这时候就统计时长并且入统计。