智能终端网页浏览首包时延的分析和优化

业务与运营Business & Operation智能终端网页浏览首包时延的分析和优化董帝烺中国联通福建省分公司 泉州 362000摘　要 文章首先从智能终端网页浏览的信令流程入手，阐述首包时延的概念以及主要组成部分(空口时延、DNS解析时延、TCP建立时延和发送请求时延)，通过对首包时延的各个阶段时延进行测试和分析，确定其关键阶段时延，最后通过无线侧的优化、无线Feature的应用和服务器及路由优化，使得浏览类业务的首包时延从721ms减少到454ms，提升了用户体验。关键词 智能终端；首包时延；优化；不连续接收；混合自动请求重传；无线Feature引言随着智能终端的普及化和功能的完善化，移动互联网迅猛发展，用户对于移动业务体验的要求越来越高。与此同时，移动网络结构日趋复杂，网络场景多样化，影响用户体验的因素越来越难以判断。如何衡量和评价用户感知，如何结合网络进行有效的评估和保障提升，并有效指导网络精准投资建设，是当前网络规划优化中面临的一个难题。传统的KPI指标已经不能反映出数据业务用户的体验，基于数据业务体验的端到端KQI感知评估体系还处于研究及应用推广中[1]。本文结合联通集团沃网络业务感知评估系统，特别是对泉州LTE网络网页浏览的首包时延这一短板指标的分析和优化提升，指导基于用户体验的网络规划和优化，打造“质量优、感知优、价值优”的匠心网络。估的指标为4G浏览类优良率，公式为：4G浏览类优良率=首包时延优良率×0.3+页面打开优良率×0.7。1.1 网页打开流程在智能终端浏览网页打开过程中，首先要建立无线信令链接；之后终端与高层网络握手(TCP建立过程)，握手确认后，获取页面建立相关信息[2]，并显示页面内容，具体见图1的流程。1 网页浏览的流程和时延联通集团沃网络业务感知评估系统是用嵌入手机营业厅的方式，采集智能终端用户浏览类业务的感知数据，评估浏览业务的智能终端用户体验。浏览类业务评

图1 网页打开流程图14

Business & Operation业务与运营1.2 网页打开时延在智能终端浏览网页打开的流程可以对应到以下几个阶段和时延[3]。1)空口建立时延。无线接入时延，此阶段智能终端收到上层浏览业务请求，完成空口随机接入和RRC连接建立，并发起SERVICE

REQUEST请求完成相关承载建立的过程[4]。2)DNS解析时延。DNS解析时延是智能终端浏览器客户端向DNS服务器查询目的域名的IP地址过程引入的时延。由于客户端在获取一次DNS查询结果后，会将此结果缓存，直到查询结果老化时间到，才会再次发起DNS查询。这就意味着DNS查询不是每次网页浏览业务必须经历的业务环节。3)TCP建立时延。TCP握手时延，在获取服务器IP地址后，客户端即发起对应IP的TCP链接建立请求，与服务器侧交互，完成TCP链接建立[5]。4)发送请求时延。GET-ACK时延是指从客户端发起第一个GET请求，获取浏览网页对应的html文件到收到服务器针对该TCP报文的TCP ACK的时延。5)接收响应时延。指的是客户端收到服务器下发的首个业务包到收到服务器下发的最后一个业务包的时延。在联通集团公司评价指标中：①首包时延指发起浏览请求到收到目标服务器响应第一个http 200 ok报文之间的时长，单位为ms。网页首包时延=空口建立时延+DNS解析时延+TCP建立时延+发送请求时延。②页面打开延时指发起浏览请求到收到整个HTTP页面下载完毕并渲染完成时长，单位为ms，页面打开时延=首包时延+接收响应时延，页面打开时延反映了用户从访问开始到首页下载完成需要的时间。图2 6月13日网页浏览测试2 首包时延的分析采用联通集团3月份原始数据进行统计分析，联通集团共采集9个网站的相关指标，泉州主要是百度、微博、新浪三个网站的首包时延优良率较差。其中百度的首包时延优良率仅2.98%，但百度的样本数占比最高为38.19%。本文针对百度的首包时延问题，进行详细的研究和分析。为方便统计分析，使用业务感知软件(移动互联网业务感知系统)对百度浏览类业务进行测试。相关结果如下，其中DNS解析时延30ms、建立连接时延55ms、发送请求时延636ms、首包时延721ms、页面打开时延1176ms。从软件统计来看首包时延较长，主要是发送请求时延比较长导致(见图2)。1)空口时延。在LTE系统中，处于空闲态的智能终端发起网页浏览业务，需要建立无线空口连接，智能终端会发起Service Request触发物理层初始随机接入，建立RRC连接，再通过初始直传建立传输NAS消息的信令连接，最后建立E-RAB，这整个过程称为空口接入过程。空口接入过程的时延相对比较短，大约有50ms，但空口接入过程受无线环境的影响较大，对空口时延会产生延迟。2)DNS解析时延。使用wireshark对抓取的数据包进行分析，软件测试显示DNS时延为30ms，单次测试后台信令共抓取到三次到的DNS请求，均值大概为30ms(见图3)。3)TCP建立时延。每次DNS分别对应一次TCP建立请求，多次抓包统计分析，DNS时延约为57ms(见图4)。4)发送请求时延。因百度网页进行了加密传输，首先是加密过程，接着是应用数据的传输。结合软件测试的时延统计，发送请求时延有可能以Client Hello为起15

业务与运营Business & Operation点，以百度服务器下发的第一个Application Data为结点统计的。第一次访问网址图3 DNS解析时延信令图163.177.151.98，从发起get请求到网页响应时延为156ms，到FIN时延为157ms(见图5)。后续访问网址为163.177.151.99或163.177.151.98，根据软件界面显示结果为636ms，信令节点见图6。多次测试分析中，在发送请求时延，大部分都是在636ms，个别存在发送请求时延只有156ms(见表1)。5)页面大小的分析。从上面的几个阶段时延来看，主要在于发送请求时延相对比较长。对发送请求时延较长的几次测试进行分析，首包从与服务器建立加密链路后又经过多个数据包，当页面大小(大于150KB)首包分解成了多个应用包，需要所有的包都全部获取到后才算完成，因此导致发送请求时延较长。如表2所示，页面大小会影响到发送请求时延，从而影响到首包时延。由于浏览百度时候，百度网页除了给出基本的百度网页内容(大概100KB)，还会按不同用户的使用习惯、曾经搜索的内容，给不同用户显示差异化增加的内容及百度广告的推送(大概60KB)。其广告推送还会参考UE终端的GPS推送附近的商家，因此，在商家参与较多的区域，更容易导致首包时延的增加。页面百度小页面百度大页面测试No1No2No3No4No5No6No7No8No9No10图4 TCP建立时延信令图图5 发送请求时延信令图（小包）图6 发送请求时延信令图（大包）表1 发送请求时延测试表IP地址163.177.151.98163.177.151.99163.177.151.99163.177.151.99163.177.151.99163.177.151.98163.177.151.98163.177.151.99163.177.151.99163.177.151.98发送请求时延/ms4635637633636636636页面大小/KB5164164表2 百度大小页面在各个阶段的时延图DNS时延/TCP建立时延发送请求时延首包时延/ms/ms/msms39416618页面打开时延页面大小/ms/KB7641209105.6164.716

Business & Operation业务与运营3 减少首包时延的优化方法首包时延在信令上由空口建立时延、DNS解析时延、TCP建立时延和发送请求时延几个部分组成，对这几个阶段的优化，主要涉及无线侧优化、无线Featrure应用和服务器、路由器的优化。由图8可见，在时域上时间被划分成一个个连续的DRX Cycle。每当UE被调度以初传数据时，就会启动(或重启)一个定时器drx-InactivityTimer，UE将一直位于激活态直到该定时器超时。drx-InactivityTimer指定了当UE成功解码一个指示初传的UL或DL用户数据的PDCCH后，持续位于激活态的连续子帧数。即每当UE有初传数据被调度，该定时器就重启一次。当UE在“OnDuration”期间收到一个调度时，UE会启动一个“drx-InactivityTimer”并在该Timer运行期间的每个子帧监听PDCCH。当“drx-InactivityTimer”运行期间收到一个调度信息时，UE会重启该Timer。当“drx-InactivityTimer”超时或收到DRX Command

MAC control element时：1)如果UE没有配置short DRX

cycle，则直接使用long DRX cycle；2)如果UE配置了short DRX cycle，UE会使用short DRX cycle并启动(或重启)“drxShortCycleTimer”，当“drxShortCycleTimer”超时，UE再使用long DRX cycle。在UE打开网页的过程中，由于UE终端的不连续接收，当在首包时延统计过程中终端处在休眠态，则会导致首包时延的增加；因此，可以通过调整DRX参数，降低UE进入休眠态的周期以减少首包时延，降低页面打开时延。3.1.3 增加HARQ重传次数HARQ混合自动重传请求是一种结合FEC(前向纠错)与ARQ(自动重传请求)方法的技术。FEC通过添加冗余信息，使得接收端能够纠正一部分错误，从而减少重传的次数。对于FEC无法纠正的错误，接收端会通过ARQ机制请求发送端重发数据。接收端使用检错码，通常为CRC校验，来检测接收到的数据包是否出错。如果无错，则接收端会发送一个肯定的确认(ACK)给发送端，发送端收到ACK后，会接着发送下一个数据包。如果出错，则接收端会丢弃该数据包，并发送一个否定的确认(NACK)给发送端，发送端收到NACK后，会重发相同的数据[9]。ARQ机制采用丢弃3.1 无线侧优化3.1.1 无线环境优化众所周知，空中接口的无线环境是错综复杂、急剧变化的。无线网络的优化主要在覆盖和质量上，通过对无线环境的优化，提升无线网络的覆盖和质量，减少网络的干扰和时延[6]。优化过程中应关注弱覆盖区的RSRP值提升，针对RSRP值低的区域，尝试调整基站天线方位角、俯仰角、增补基站或扇区、室外外引，调整RS功率等[7]。在RSRP较好的区域，减少网内外的干扰，提升SINR值，适当在RSRP与重叠覆盖系数上进行互换取舍，降低重叠覆盖率。3.1.2 避免处于休眠(DRX)基于包的数据流通常是突发性的，在一段时间内有数据传输，但在接下来的一段较长时间内没有数据传输。在没有数据传输的时候，可以通过停止接收PDCCH来降低功耗，从而提升电池使用时间，这就是DRX的由来[8]。DRX的基本机制是为处于RRC_CONNECTED态的UE配置一个DRX cycle。DRX cycle由“On Duration”和“Opportunity for DRX”组成：在“On Duration”时间内，UE监听并接收PDCCH(激活期)；在“Opportunity for DRX”时间内，UE不接收PDCCH以减少功耗(休眠期)，见图7。

图7 DRX Cycle示意图数据包并请求重传的方式。虽然这些数据包无法被正17

业务与运营Business & Operation则会发起Get/Post以及回应对应下行报文Ack等其他请求，对于发起这些请求都需要申请上行资源，在申请到上行资源之后才能发送这些请求，而使用正常的流程来申请上行资源的过程所耗费的时间较多，图8 DRX流程图导致整体网页访问时延过大。在图9的预调度流程中，基站侧通过识别http相关报文，判断终端是否需要进行回应，预估回应的字节大小以及时间点，在对应时间给予一个精准的授权，这样终端在需要发送上行数据时，不再需要走动态调度流程而是直接使用这个授权(不再使用流程图中的红色的虚线流程)，可以极大地改善了上行数据发送时延，进而改善网页的访问时延。HTTP预调度：通过对TCP端口进行识别，如果是识别为80/8080/443端口，当有下行数据包ENBWEB/DNS-Server确解码，但其中还是包含了有用的信息，如果丢弃了，这些有用的信息就丢失了。通过使用HARQ

with soft combining(带软合并的HARQ)，接收到的错误数据包会保存在一个HARQ buffer中，并与后续接收到的重传数据包进行合并，从而得到一个比单独解码更可靠的数据包(“软合并”的过程)。然后对合并后的数据包进行解码，如果还是失败，则重复“请求重传，再进行软合并”的过程[10]。HARQ对无线网络性能的影响：HARQ重传次数设置的越小，由HARQ重传导致的无线资源开销越小，但无线链路的可靠性越低；HARQ重传次数设置的越大，无线链路的可靠性越高，但由HARQ重传导致的无线资源开销越大。通过提升上下行的HARQ重传次数，可以增加传输成功的概率，进而缩短空口传输时延。决存在的问题。针对缩短首包时延，目前有以下一些无线Feature可以从流程上起到很好的作用。3.2.1 DNS代理功能DNS代理功能，指基站保存域名和IP的对应关系信息，UE请求的DNS查询，如果基站存在对应的域名和IP对应关系，eNB直接给UE发送DNS查询响应并同时把DNS请求发送给应用服务器，并根据影响结果更新域名和IP对应关系。3.2.2 预调度用户在访问网页时，一般都会发起TCP建链，TCP建链完成之后⭞

本文标签： 时延 请求 优化 发送 浏览