兰州TD下载率、时延优化经验总结V1.0.pptxVIP

兰州TD数据业务时延优化经验总结目录现网问题现象现网问题分析优化方案实施优化效果评估现网问题现象Ping包时延较长对兰州和平凉进行百度服务器Ping包时延测试，随着包长度的增大兰州时延出现明显的激增，平凉时延增大不明显。打开网页时延较长FTP下载时延较长服务器包长兰州TD时延平凉TD时延百度服务器128211.4721976300.001024696.48314.00使用搜狗浏览器进行打开新浪主页时延测试，发现时延较大并且受网络的忙闲程度影响较大。使用FlashFXP下载8M文件，统计下载时间和下载速率如右图，发现下载速率和下载时长受网络忙闲程度影响较大。时段时延忙时45-55秒闲时27-31秒时段下载速率下载时长忙时727.5kbps99秒闲时923.1kbps76秒问题分析-核心网分析核心网侧存在丢包核心网侧存在乱序核心网侧存在数据分片业务平台下发数据有时延从测试业务看，互联网业务（包括新浪浏览、互联网下载）核心网存在偶尔丢包情况。整体丢包比例在0.1%以下。从终端时延感知分析，由于核心网丢包后，通过无线侧传递到终端后，终端再上发重传请求，再通过核心网上发服务器，这一过程相对耗时较长，造成时延较长不利于用户感知。在页面访问和互联网下载中，核心网侧下发的TCP数据存在乱序，由于乱序的数据包时间间隔较小一般不会引起终端的重传请求，但也存在少量由于终端收到的TCP层数据乱序引起终端连续发送3次DupACK引发的快速重传或超时重传，造成时延增大。数据在通过SGSN传输后，存在IP数据再次分片的现象，不利于传输效率的提升，对时延有一定的影响。通过Iu接口部分数据统计，粗略分析发现分片数据约占整体业务数据量的4.3%。在页面访问和无线音乐业务测试中，发现终端上发GET请求并收到ACK确认后，SP服务器过了较长时间才开始下发数据，造成时延大，感知不好。从打开新浪页面的响应时延统计（即HTTP的200OK响应消息到GET请求消息之间的时长），大部分时延在60-80ms，但有近3%的请求响应时延大于200ms，个别请求响应时延大于1秒。但该问题涉及服务器厂家，仅核心网优化还无法解决。问题分析-无线侧分析空口物理层上行存在误块空口物理层下载存在译码错误TCP层存在丢包、乱序、重传优化措施NodeB对等层重传：RNC的FP层收到NodeB对等层的QE218和CRCI校验错误，导致重传，影响时延。QE218是由于NodeB物理层数据接收不全，导致无法正确译码或误块。分析发现NodeB侧没有收到终端的有效信号，终端没有发送数据。并非所有的QE218都会导致重传，但含有有效数据的QE218会导致上行重传，影响时延。接收功率过低导致重传：通过对CRCI校验错误时的log分析，NodeB让终端上调发送功率，但是终端侧上调不明显，从而NodeB接收到的信号功率过弱，产生CRCI校验错误，无法正确译码数据，导致上行重传，影响时延。空口下行丢包：空口下行丢包导致下行数据接收不全要求进行重传，导致时延较长。终端物理层译码错误：RNC的RLC层下发的数据，经过NodeB的物理层，到达终端的物理层后，终端给NodeB反馈译码错误，要求重传。NodeB重传了4次，终端仍然反馈译码错误，导致上层RNC的RLC层数据进行多次重传，影响时延。无线侧参数配置不合理核心网丢包乱序：无线侧利用抓包工具Wireshark分析发现核心侧侧存在TCP层存在丢包、乱序、重传现象，影响时延。空口物理层丢包乱序：空口物理层存在丢包和译码错误导致TCP层丢包、乱序，引起TCP层的重传，影响时延。4B事件门限过于宽松：FTP下载开始前，RNC给终端分配的上行速率是32kbps，在FTP下载开始很短的时间内，终端上报4B测量报告，RNC将终端上行调整为16kbps，上行速率不升反降。4A事件门限不宜满足：整个下载过程中，上行速率一直在16kbps左右。没有触发一次4A事件门限，导致下载速率过低。优化方案实施-核心网侧核心网侧优化手段TCP代理功能开启：需要RNC侧开启“TCP代理”功能，核心网需要把“TCP代理”功能由GGSN或者防火墙来实现（以华为为例目前暂未实现)。数据分片问题优化：修改防火墙的MSS值后TCP协议的分片从14％左右的分片率降低到2％左右，但是无法从根本上解决UDP协议的分片，如果要解决，需要修改全网SGSN、GGSN、交换机、防火墙的MTU值，操作涉及范围太大且对网络影响非常大，因此不建议进行修改。对热门网站增加cache缓存：利用缓存加速设备，对于一些热门网站的页面整体进行缓存，避免终端与服务器的直接交互，加快请求-响应的回复时间，缩短时延，提高用户感知。优化方案实施-无线侧参数名称优化前配置优化后配置参数含义当前配置的解释一、二、三类业务4A事件门限8