写点什么

为了让携程上万员工上好网,他们做了这些

  • 2020-02-15
  • 本文字数:4770 字

    阅读完需:约 16 分钟

为了让携程上万员工上好网,他们做了这些

引言

随着移动互联网的飞速发展,WiFi 也已经成为企业办公网络必不可少的基础设施。越来越多的企业对无线办公网产生了极为刚性的品质需求。曾经“WiFi 不好影响工作”的玩笑,放在今天已成为事实。


遗憾的是,许多无线办公网建成后的使用品质与预期存在不小的差别,“网络不好”的抱怨不绝于耳又难以解决,究其原因,主要是由于“交付与运维没有到位”。


对于任何网络系统来说,在设备规格满足需求的情况下,规划、交付和运维水平决定了实际使用效果。但相对于有线网络,WiFi 网络的质量受到更多因素的干扰,更易引起质量下降且排查困难。这给 Wifi 网络的交付与运维带来了很大的挑战。


本文基于实践经验,定位于为 WiFi 组网提供从交付到运维阶段的技术赋能,从以下两方面为企业 WiFi 的 IT 管理者提供一些借鉴与启发。


1)了解 WiFi 运维方法论;


2)提升 WiFi 运维能力。

一、携程 WiFi 平台概述

2015 年携程总部进驻凌空 SOHO。依托主流厂商解决方案,完成无线 WiFi 全面覆盖。目前共计部署 AP 信息点 600+,覆盖达 10+万平方米,,日均活跃终端突破 7000,峰值下行吞吐量超过 1Gbps。


逻辑拓扑(见图 1)



图 1

二、开局篇

首先需要明确,文档主要专注于 WiFi 品质的优化工作,其它相关工作应结合企业自身环境及需求完成基础建设。


开局涉及网络规划、网络交付两个阶段。开局似建筑过程中的地基环节,只有地基打好了,才能起高楼。


大型企业实现 WiFi 高密度部署,确保用户体验的主要挑战:


1)无线的全面覆盖;


2)无线容量与干扰的平衡;


3)内网的安全威胁。

2.1 无线的全面覆盖

以携程为例,办公区域面积大,结构复杂。无线信号的覆盖需要综合考虑建设结构、穿透损耗及布线等具体情况。WiFi 有效覆盖涉及 AP 覆盖、AP 容量两方面,了解 AP 覆盖的基础知识,对 360 度的无死角覆盖及 AP 选型将有极大帮助。


AP 覆盖的有效范围取决于 AP 和终端之间的链路预算。链路预算计算公式如下:终端接收信号强度=AP 发射功率+AP 发射天线增益-空间传输距离衰减-障碍物损耗+终端接收天线增益。其中,空间距离对信号的衰减如下:



为满足移动办公场景下 BYOD 不同类型终端(便携笔记本、智能手机、PAD、哑终端等)的接入体验,终端信号强度及 AP 覆盖半径建议值如下:


  • 重点覆盖区域终端接收信号电平应大于-65dBm;

  • 普通覆盖区域终端接收信号电平应大于-75dBm;

  • 空间开阔且用户较少时,AP 覆盖半径<20 米;

  • 空间开阔且用户密集时,AP 覆盖半径 5~8 米为宜;

  • 存在少量障碍物遮挡且用户数分布适中时,AP 覆盖半径以 8~12 米;

  • 存在大量障碍物遮挡时,重点考虑障碍物对信号的衰减,建议对小空间单独 AP 覆盖。

2.2 信道的配置优化

对于密集和数据流量需求高的场景,密集布放 AP 是提升用户体验的一种重要手段。但密集布放常常导致信道之间的相互干扰,从而影响用户体验。大型移动办公必须对 WLAN 信道进行统一规划并实施。


携程网 WiFi 遵循:双拼蜂窝覆盖、交叉复用原则(见图 2),保证信道间不相互干扰。



图 2 双频蜂窝覆盖


WiFi 系统主要应用两个频段:2.4GHz 和 5.0GHz。由两个频段自身信道的特性,在高密度的场景下需要尽量的抑制 2.4G 射频,避免低速用户传输对网络传输的影响。

2.3 内网的安全威胁

同一 vlan 内、不同 vlan 间通讯的终端应采用隔离技术,有效防止终端之间传输大量文件损耗 AP 有限的带宽资源,也防止终端之间的任意互访有可能导致的数据窃取、文件中毒等恶意行为,最大限度地确保办公安全,提高办公效率。

三、运维篇

开局篇网络优化只是打好了地基。长期良好的 WiFi 上网品质,是以贯穿整个 WiFi 系统生命周期的优化工作为基础,需要持续投入。


WiFi 运维的痛点:


1)设置参数多,网络优化难。WiFi 网的优化相对来说复杂,包含了射频领域的专业知识,甚至多数情况下无法直接找到优化网络的设置项及设置值,只能通过多维度的数据看到幕后端倪。


2)网络体验数据难以收集和展现。单凭文字描述已经很难达到预期效果,如何量化网络服务水平,将直接制约网络信息部门的工作成果评估。


以上两大烦恼,揪其主要原因在于大多数企业对 WiFi 的运维简单拷贝有线网运维经验,主要依靠厂商提供的网优功能,仅从系统设备层面对系统的健壮性进行监控,而很少从提供用户服务体验的角度建立、健全监控机制。

3.1 规划有效的 KPI 参数

任何网络平台的搭建都有其原生的管理系统管理平台。多数情况,原生管理系统仅从设备性能角度出发,列举尽可能的参数指标。WiFi 系统环境多变,参数繁杂,监控数据的搜集涉及许多层面的知识(诸如功率、信道规划等)。


如果不对其进行梳理,只是简单实现对其有无的监控,则很难发挥这些数据价值,对整个系统缺乏有效评估:一方面导致运维处于被动式的排障;另一方面导致排障阶段出现类似“瞎子摸象”的困局。


解决问题的关键是把“概况-体验”结合,一方面借鉴有线网络运维经验,甄别原有监控平台的各项指标,遴选出全局、局部二个层面的 KPI 综合评分,建立全网主动运维能力;另一方面加强对用户体验的关注,利用自身开发平台,纵深收集用户网络层指标,从用户可用性角度建立用户层面的 KPI 指标。


携程结合自身的运维经验,


  • 全局、局部的 KPI 考量、汇总表如下:


维度指标名称适用场景
认证服务器服务器基础全局WiFi路径设备级监控
服务状态(死活)
ACAC名称全局WiFi基础网络质量监控
在线时长
CPU实时利用率
内存实时利用率
接口流量统计
APAP名称区域性WiFi基础网络质量监控
AP CPU利用率
AP 内存利用率
AP 接口速率
接入终端
接入成功率
接入掉线率
上/下线监控
射频信道利用率
噪声强度


  • 自建监控平台,为用户提供用户角度 KPI 呈现入口,同时将生硬、专业的参数指标转化为网络可达性、可用性指标:(示例见图 3)



图 3

3.2 量化系统基准及用户评估体验

WiFi 网缺乏量化的数据评估,一直以来是无线网用户体验难有提升空间的原因。WiFi 运维下经常会听到用户反馈“上网慢”等模糊性体验的抱怨之声。在此情况下,因为缺乏有效的基准数据和用户体验量化值,从而造成网络运维人员心理评估基线与用户实际需求管理之间的沟通障碍。


一方面报障阶段数据缺失,运维人员不能准确理解用户抱怨点,造成疲于奔命的解释和漫无目的的查找原因;另一方面解决效果缺乏数据支撑,对用户模棱两可的回答造成用户被忽悠的感觉。WiFi 运维工作处于两难的困境。

3.3 部署“探针“,量化服务基准值

建立用户体验指标,我们就需要广泛收集终端网络访问闭环周期内的相关指标。但由于用户终端设备的私有属性及手机平台的限制,无法通过实际用户终端持续有效的获取用户信息。


对此,携程网络运维团队另辟蹊径,基于“树莓派”产品进行开发,模拟用户 Http 访问,通过拨测方式收集、统计 DNS 解析时长、WEB 连接时长、下载速度等信息,从而实现“基准分析“模块,用直观的方式呈现 WiFi 网络的运行情况。


用户微信的使用效果经常是企业“WiFi 好不好”的直接体现。微信通讯协议:为保证稳定,微信用长链接和短链接相结合,微信划分了 http 模式(short 链接)和 tcp 模式(long 链接),分别应对状态协议和数据传输协议。


1)short.weixin.qq.com 主要用途:


  • 用户登录验证;

  • 好友关系(获取,添加);

  • 消息 sync (newsync),自有 sync 机制;

  • 获取用户图像;

  • 用户注销;

  • 行为日志上报。

  • 朋友圈发表刷新


2)long.weixin.qq.com 主要用途:


  • 接受/发送文本消息;

  • 接受/发送语音;

  • 接受/发送图片;

  • 接受/发送视频文件等。


基于上述说明,携程利用探针程序,通过以下指标,从 DNS 解析–>TCP 连接–>客户端准备–>服务器响应–>数据传输进行阶段监测。(见图 4)



图 4

3.4 量化用户体验值

针对用户反馈无量化问题,携程在内部“程里人”系统下嵌入无线自检工具。用户可主动在终端发起测试,将问题时段的“信号采样“及”WEB 下载速度“直接上报至后台系统,解决用户体验与数据量化之间的矛盾。(示例见图 5)



图 5

四、排障篇

WiFi 排障存在两大难点:


1)网络故障难以重现。很多时候用户反映 WiFi 网问题,需要至现场反复确认,很多问题由于无法重现当时情景,导致无法及时得到处理,从而影响用户体验和服务效率;


2)企业 WiFi 多采用有线无线融合运维,WiFi 存在“背锅”问题。对很多终端用户来说,WiFi 就是互联网,一旦有问题他们就会反馈“WiFi 不好”。“WiFi 不好”背后存在太多可能性,例如互联网接入等出现问题,但由于用户终端缺乏检测手段,很难有效将故障从有线、无线层面进行界定。


解决上述问题的关键在于对用户数据包历史的留存。

4.1 建立用户数据流量包追踪

有线环境对于个体问题定位的终极解决方案就是抓包分析。借鉴该思路,WiFi 排障问题上我们也希望尽可能获取靠近用户终端侧数据包。 考虑 WiFi 传输层的加密及终端环境多变,故障现象短暂等因素,WiFi 环境下终端抓包具有很大局限性。为此则需要从网络层对用户的数据包进行留存。


有了上述思路,数据采样收集点的位置选择则尤为重要。综合三方面考虑:1、尽可能靠近用户侧;2、规避加密传输;3、明确划分有线、无线端。


对此,携程在无线与有线对接点部署“流量采集器”(逻辑图示见图 6),以上帝视角忠实记录了从现在往前一端时间内无线网络的完整数据,排障阶段不管是对历史记录的回溯,还是对复现过程中的模型建立,提供了有效的数据样本。



图 6

五、案例篇

通过上述 WiFi 全生命周期监控健全与优化,经过内部实践,切实对问题的排查起到了的事半功倍之效。


案例一,利用“流量采集器”,对 PTK 兼容性引发的网络故障的定位和解决


内部某用户反馈:iPhoneXS 在连接一段时间后概率性无法上网。通过基础监控平台,我们发现问题时段,故障用户关联的无线设备及用户自身终端的信号状态均正常,但网络通讯中断。


通过“流量采集器”回溯故障时间的用户数据包(见图 7),通过分析,发现其数据流具有以下特点:1)故障前用户存在较大的流量下载行为;2)故障时间段 AC 层面转发正常。




图 7


基于存档数据包分析,故障有效定位在 AC 与终端之间。模拟故障前后用户数据特性,结合实际环境配置参数,问题很快在厂商实验环境得到复现,至此发现问题的根本原因为:iPhone BCM 芯片终端不支持 PTK 密钥更新,PTK 定时更新会触发终端概率性不回报文,导致通信中断。通过关闭设备 PTK 定时更新功能,故障问题得到根本解决。


案例二,结合监控指标及数据流分析,定位跨 AC 访问优化


某用户终端上报某时间段 WiFi 通讯中断。我们通过无线设备综合评分情况,定位该区域网络整体质量达标,故障现象属于个体问题。


进一步向下通过日志绘制出用户的漫游轨迹,发现问题发生在终端跨 AC 建联后。结合“流量采集器”的数据包,可以观察到终端的下行报文还会转发到漫游前 AC 设备。分析组网结构(见图 8),怀疑跨 AC 前后 MAC 表项与 ARP 表项不统一导致。经过问题复现,上述怀疑得到确认。


经过厂商跟进,确认为交换机存在 CPUCAR 设备偏小问题,导致 ARP 上送过程中有限速丢弃情况,交换机上 arp 表项无法及时刷新到漫游后的流量接口上,导致流量转发异常。


针对上述问题,我们主要通过以下优化措施,对问题进行了有效解决:


1)优化 AP 点位拓扑,尽可能避免同区域的跨 AC 漫游;


2)适当调整 CP car 避免 arp 丢包;


3)网关设备部署 mac 联动 arp,解决 arp 刷新问题.;


4)进行端口隔离,避免资源消耗。



图 8

六、展望

WiFi 优化操作应该基于广泛全面的数据支撑,而不是凭感觉、凭经验,虽然在此之上我们已探索一二,但 WiFi 运维仍大有可为。


如何依托有效的数据搜集,通过机器学习,感知指标变化,提供基于用户体验闭环的智能运维将成为未来之路。携程网将与其它大型网络平台,携手并进演进之路,让“无线办公”变得“无限精彩”。


作者介绍


孙颖, 携程技术保障中心网络管理团队高级工程师。从事 IT 互联网网络运维工作十余年,目前负责 IT 网络及 WiFi 网络设计、建设及运维。


本文转载自公众号携程技术(ID:ctriptech)。


原文链接


https://mp.weixin.qq.com/s/4b9uzHnVF641dWXh2cJtpA


2020-02-15 17:38918

评论 1 条评论

发布
用户头像
流量采集器用的什么?有详细的方案可以分享吗?
2021-06-30 19:24
回复
没有更多了
发现更多内容

个推TechDay直播回顾 | 分享基于Flink的实时数仓搭建秘诀 附课件下载

个推

数据湖 实时数仓 flink window 数仓建设 大数据仓库

我们总结了 3 大使用建议,并首次公开 Nacos3.0 规划图 | Nacos 开源 4 周年

阿里巴巴中间件

阿里云 开源 微服务 云原生 nacos

如何梳理企业流程管理?

优秀

业务流程管理 主业务流程梳理

LeaRun低代码平台 助力中小企业快速开发MES系统

力软低代码开发平台

个推TechDay直播回顾 | 分享基于Flink的实时数仓搭建秘诀

个推

复享光学发布ZURO系列光谱仪 助力中国半导体产业国产化

硬科技星球

如何守护数据安全? 这里有一份RDS灾备方案为你支招

京东科技开发者

数据库 安全 灾备 主机安全 RDS

我们总结了弹性伸缩的五个条件与六个教训

阿里巴巴云原生

阿里云 分布式 云原生 弹性伸缩

Redis 主从复制演进历程与百度智能云的实践

Baidu AICLOUD

数据库 redis 底层原理

低代码开发平台的功能有哪些?低代码“功能清单”一览

优秀

低代码 企业级低代码平台

别搞Java面试八股文背诵版了! 真卷不动了...

退休的汤姆

Java 程序员 面经 社招 秋招

亚信科技、清华AIR、英特尔成功举办WAIC智能算网与绿色计算论坛

亚信AntDB数据库

数据库 AntDB 国产数据库 AntDB数据库

基于GitLab CI的kubectl镜像配置

白粥

gitlab k8s gitlab ci kubectl

Alibaba最新发布!耗时182天肝出来1028页分布式全栈手册太香了

了不起的程序猿

Java 阿里巴巴 分布式 java程序员

助你成为专业终端人,阿里巴巴第三届终端练习生计划开启报名!

阿里技术

前端 移动开发

十问 RocketMQ:十年再出发,到底有何不同?

阿里巴巴中间件

阿里云 RocketMQ 云原生 中间件

《MySQL自传》

MySQL 数据库 玖章算术 叶正盛 斗佛

腾讯云5G边缘计算拿下Linux基金会奖项,降低40%云游戏网络时延

科技热闻

零基础如何参加大数据培训机构?

小谷哥

wallys IPQ8072 4x4 2.4G & 5G /QCN9074 11ax 4x4 6G M.2

wallys-wifi6

QCN9074 IPQ8072

深圳web前端技术培训学习费用

小谷哥

新零售标杆 SKG 全面拥抱 Serverless,实现敏捷交付

阿里巴巴中间件

阿里云 Serverless 云原生

Docker 向全面集成 containerd 又迈进一步

张晓辉

Docker 容器 Containerd

深度操作系统20.7正式发布!

深度操作系统

国产操作系统 deepin 深度操作系统 深度 deepin20.7

JavaScript 装饰器介绍

掘金安东尼

前端 9月月更

上海WEB前端培训机构有什么推荐的

小谷哥

惠州等保测评机构有几家?电话多少?

行云管家

等保 等级保护 等级测评 惠州

设计模式的艺术 第九章适配器设计模式练习(OA系统需要提供一个加密模块,将用户机密信息(例如口令、邮箱)加密再存储在数据库,系统已经定义好数据库操作类。为了提高开发效率,现需要重用已有的加密算法,这些算法封装在一些由第三方提供的类中,有些甚至没有源代码)

代廉洁

设计模式的艺术

技术科普:如何应用视觉显著性模型优化远控编码算法?

贝锐

算法 编码器 视觉策略 远程控制 向日葵

《数字经济全景白皮书》证券数字化篇 重磅发布!

易观分析

金融 证券

从实例出发,算力网络到底是如何编排的?

鲸品堂

算力网络

为了让携程上万员工上好网,他们做了这些_技术管理_孙颖_InfoQ精选文章