阿里云「飞天发布时刻」2024来啦!新产品、新特性、新能力、新方案,等你来探~ 了解详情
写点什么

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

  • 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


公众号推荐:

跳进 AI 的奇妙世界,一起探索未来工作的新风貌!想要深入了解 AI 如何成为产业创新的新引擎?好奇哪些城市正成为 AI 人才的新磁场?《中国生成式 AI 开发者洞察 2024》由 InfoQ 研究中心精心打造,为你深度解锁生成式 AI 领域的最新开发者动态。无论你是资深研发者,还是对生成式 AI 充满好奇的新手,这份报告都是你不可错过的知识宝典。欢迎大家扫码关注「AI前线」公众号,回复「开发者洞察」领取。

2020-02-15 17:38752

评论 1 条评论

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

聚焦指标及管理,Kyligence 发布指标中台 SaaS 产品 Zen

Kyligence

数据分析 OLAP Kyligence 指标中台

MobLink iOS端快速集成文档

MobTech袤博科技

ios xcode

如何防范钓鱼网站诈骗?

郑州埃文科技

钓鱼网站 钓鱼诈骗 网络诈骗防范

MediaTek MT7915 Module 2T2R DR7915/Wallys Wi-Fi 6 Wave 1+ chipset

wallys-wifi6

MT7975 MT7915

2022vivo“千镜杯”正式开赛,为守护用户安全而战!

Geek_2d6073

【SSM】Mybatis系列——分页、使用注解开发、mybatis执行流程

胖虎不秃头

mybatis SSM框架 9月月更

Java 设置 Word 中的段落缩进方式

Geek_249eec

Java word 段落缩进

云原生数据库 Amazon DynamoDB 十年创新回顾

亚马逊云科技 (Amazon Web Services)

数据库 云原生

金蝶云星空&契约锁专场直播:帮企业从小处降本,从细节增效!

IT资讯搬运工

金融

尚硅谷ShardingSphere新版视频教程发布

小谷哥

学习WEB前端去哪里?

小谷哥

C站专家圈分享-低代码构建WebAPI的原理与体验

葡萄城技术团队

架构 低代码 开发 WebApi 前后端

多版本并发控制 MVCC

月明风清

2022 DEMO CHINA创新中国峰会收官,5大专场创业者PK,投资人脱口秀别开生面

创业邦

TiDB Hackathon 2022丨总奖金池超 35 万!邀你唤醒代码世界的更多可能性!

TiDB 社区干货传送门

黑客马拉松

云原生数据库前世今生

亚马逊云科技 (Amazon Web Services)

数据库 云原生

MySQL数据库之索引

Java快了!

:MySQL 数据库

什么样的人适合参加前端培训呢?

小谷哥

在上海想学WEB前端课程如何选择

小谷哥

如何写成高性能的代码(一):巧用Canvas绘制电子表格

葡萄城技术团队

html 前端 canvas html2canvas 纯前端表格技术

直播预告 | 在 CurveBS 上部署跨机 PolarDB for PostgreSQL 集群

阿里云数据库开源

数据库 postgresql 阿里云 开源 polarDB

Nginx 模块开发

C++后台开发

nginx 后台开发 中间件 后端开发 Nginx模块开发

OpenHarmony编译报错解决

坚果

OpenHarmony 9月月更

【SSM】Mybatis系列——多对一和一对多的处理、动态SQL

胖虎不秃头

mybatis SSM框架 9月月更

降本增效的利器——组件化开发

力软低代码开发平台

深度学习+大规模计算+大数据,谁才是未来的算力之王

Finovy Cloud

人工智能 云渲染

羊了个羊暴力通关玩法

大熊G

主流开源APM:Zipkin/Pinpoint/SkyWalking全面对比

穿过生命散发芬芳

APM 9月月更

阿里云云原生实时数仓升级发布,助力企业快速构建一站式实时数仓

阿里云大数据AI技术

大数据 数仓

前端培训与自学的区别

小谷哥

【SSM】Spring系列——Spring概述、第一个Spring程序、容器接口和实现类

胖虎不秃头

spring ssm 9月月更

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