【LTE实战】TD-LTE调度不饱满导致下载速率低问题

1、网格测试过程中遇到的调度不饱满导致下载速率低问题，分享给大家!问题描述：近期，在网格大会战过程中，LTE网格组发现多个站点在无线环境良好的情况下，下载速率无法达到峰值的情况，如下为金陵城二-1小区测试速率，速率始终只能在50M-60M上下。而该站点的配置在正常情况下应该在80M以上。共发现该问题的有：郭家山二搬迁、新生土于港、金陵村二、伊刘村、浦口二、柳塘村、浦江学院、燕江路、宝塔街T、大桥村、浦口审计学院试扩、林家凹试扩等12个站点。问题分析:针对该问题进行了长达1个月的反复抓包、测试定位，分析发现引发该问题的原因有多种情况，下面是详细分析。1 .无线侧初步分析排除终端和笔记本、FTP服务器

2、问题：对这几个站点，进行更换终端、笔记本等方法进行测试，现象一样，且同样的笔记本、终端在其他站点上速率正常，可达到峰值。排除这方面的问题排除无线环境因素：测试时对测试位置进行多次选点，在RSRP/SIN将都远大于极好点的位置进行测试，MC湃级可基本维持在27以上，但是速率表现一样。同样的位置进行UDP整包，速率可达到峰值。如下图，至此可基本排除无线环境问题。测试组对问题站点的小区PRB限制为48/24,测试速率基本稳定在对应的峰值速率上。也说明问题不在空口上，怀疑进入基站的数据不足。在基站的S1口做镜像抓包，同时在FTP服务器上也做WIRESHAR外包，发现S1口的下行数据存在乱序和丢包的现象

3、，丢包率大约为千分之一，这个有可能导致速率的下降。村二|伊刘村|2 .传输链路不稳及丢包问题根据以上分析，首先怀疑传输侧问题，将存在问题站点提交传输分析，传输侧反馈郭家山二搬迁、新生土于港链路不稳，并进行处理；燕江路传输侧存在明显丢包，并对异常进行处理；根据传输侧反馈，项目安排复测：新生土于港和燕江路问题解决，郭家山二搬迁1、2小区速率恢复正常，3小区下载速率依然较低；由于同站所有小区共用传输，因此该站3小区问题非传输导致；站点中兴答复当前版本郭家山二链路不稳，已处理3.20.01新生珏港链路不稳，已处理3.20.01燕江路存在明显丢包，已处理3.20.00

4、.40.15.013 .参数设置问题传输整改后郭家山二仅3小区仍存在问题，因此小区参数设置嫌疑较大，将3小区参数与1、2小区进行对比，发现上行BO参数设置不合理，参照1、2小区进行设置后，3小区下载速率恢复正常，并对其他未解决站点参数也进行核查，发现金陵村二存在同样问题，修改后也恢复正常。4 .传输侧带宽设置不合理由于传输侧反馈无其他明显异常，定位至此，有点山穷水尽了。回过头再次梳理之前的定位过程，从中找些蛛丝马迹。根据1.抓包分析，从基站、终端侧抓包看，S1下行存在1/1000的丢包，因此再次安排上站抓包，站点：伊刘村。方法是在基站和PTN设备之间接入第3方交换机，在连接第三方交换机时发现，

5、端口速率始终无法达到千兆，而第3方交换机直接和基站传输口相连，则可以达到千兆，怀疑传输侧配置为100M光口而非1000M,将该问题反馈传输核查，经传输改配后，重新连接PTN和基站，复测速率正常。这种情况有一个特点：在物理设备-机架-机框-板卡-以太网节点下，目前正在使用的端口，配置工作模式为自适应，实际工作模式为100M。对全网进行核查发现还有浦江学院、浦口审计学院试扩、林家凹试扩等站点存在同样问题。传输侧反馈如下，经处理几个站点均恢复正常：站点中兴答复伊刘村传输侧配置为强制100M浦江学院传输侧配置为强制100M浦口审计学院试扩传输侧配置为强制100M林家凹试扩基站上PTN设备安装为155M

6、光模块以下是该种情况下，OMCE核查的节点:5 .上行BLER导致速率持续偏低针对柳塘村速率持续偏低的问题，上站抓包：该站没有明显丢包，但是从基站可以看到空口有心电图状的BLER刺，峰值约10%从拉网速率趋势看，曾有一小段时间空口无BLER对应的速率可以稳定在80M左右，因此可以看出，下载速率高低，与测试点空口BLER有直接关系，空口BLER会导致下载速率持续偏低。经过外场测试人员寻找，在柳塘村可以找到空口环境较好的测试点，这些测试点空口无明显BLER测试速率可在90M,这一现象也能说明，下载速率与BLER的关系。6 .上行反馈晚点到达服务器和终端丢包通过在柳塘村寻找无线环境好的测试点，测试速

7、率可在90M以上，但也有偶尔掉坑现象，针对此种情况进行抓包和CDLlk务日志分析，发现掉坑的时候有突发重传，重传的原因有2中：上行ACK1IJ达服务器时间点晚导致服务器重传终端侧抓包分析：在500746行收到了SN为904789478的原始包紧接着在500748行对500746行和500747行报文进行确认ACK(ipid:30556),如图：在501077行，收到SN为904789478的重传包服务器侧：在939644行对SN:904789478包首次进行发送在939931对SN:904789478包进行重传，此时按照TCP协议，超时重传会导致速率陡降。然而，在服务器对SN:90478947

8、8重传后的939936行收到了终端对原始包的确认，说明原始包的ACK（ipid:30556）并没有丢,只是到服务器时晚了上行ACK晚点到达服务器的原因应该与下述发现的传输时延突发异常变大有关。在做业务过程中，基站对EPC进行长PING操作，会偶尔出现超大时延现象，如图：终端接收丢包在126424行，抓包看终端已收到SN为3564609387的原始包，然而终端后续却一再确认SN为3564609387的包丢失（红色部分）直到在126917行收到服务器的对SN为3564609387报文的快速重传才恢复正常总结上述抓包分析：1）上行TCPACK晚点到达服务器导致重传；2）业务过程中PINGEPC存在超

9、大时延是导致ACK晚点的最重要原因；3）重传为瞬时突发，绝大部分时间无重传，且重传发生时伴随速率下降；4）怀疑终端或笔记本性能问题会导致在业务长时间保持中收到数据处理不过来而丢掉；二|上述四点解释了测试过程中出现的现象：业务较长时间能够保持锋速，偶尔出现掉坑，长时间持续业务时速率波动幅度会变大。7 .终端反馈0窗口报文导致速率低针对宝塔街站上站测试抓包，经过分析，该站点BLER相对较高，但导致业务速率低的更重要原因为终端会反馈0窗长报文，一旦出现该问题，当前下载线程则处于停滞状态直至终端上报窗长恢复，每次发生停滞时间120ms-900ms不等，停滞时间内速率为0。5线程下载测试，57秒的抓包中

10、，发生约20次0窗口事件，而且，0窗长发生时往往伴随着丢包，如此，必然会导致速率低，如图，在65419行发生0窗口事件，直到65466行恢复,停滞时长约800ms。解决措施及结果：综上多种情况分析：调度不满导致速率低问题，经过传输整改链路、改配端口模式均能有效解决该问题。问题结论;引起调度不满导致速率低问题有以下几种因素：1 .传输问题传输明显丢包；传输端口模式配置错误;传输链路不稳；2 .参数设置问题：上行BO设置不合理；3 .测试点空口环境查，BLER高导致速率持续偏低；4 .传输大时延使上行ACK晚点到达服务器，引发重传，最终导致下载速率低;5 .终端问题终端性能问题导致业务长时间保持中

11、收到数据处理不过来而丢弃，引发重传;终端反馈0窗口报文，导致速率偏低。问题描述：近期，在网格大会战过程中，LTE网格组发现多个站点在无线环境良好的情况下，下载速率无法达到峰值的情况，如下为金陵城二-1小区测试速率，速率始终只能在50M-60M上下。而该站点的配置在正常情况下应该在80M以上。国共发现该问题的有：郭家山二搬迁、新生土于港、金陵村二、伊刘村、浦口二、柳塘村、浦江学院、燕江路、宝塔街T、大桥村、浦口审计学院试扩、林家凹试扩等12个站点。问题分析：针对该问题进行了长达1个月的反复抓包、测试定位，分析发现引发该问题的原因有多种情况，下面是详细分析。1.正线侧初步分析排除终端和笔记本、FT

12、P服务器问题：对这几个站点，进行更换终端、笔记本等方法进行测试，现象一样，且同样的笔记本、终端在其他站点上速率正常，可达到峰值。排除这方面的百排除无线环境因素：测试时对测试位置进行多次选点，在RSRP/SIN将都远大于极好点的位置进行测试，MC湃级可基本维持在27以上，但是速率表现一样。同样的位置进行UDP整包，速率可达到峰值。如下图，至此可基本排除无线环境问题。片emfi事7RNKMgLBM_MM#一>w*M«war-rM-GITTITJrTt4-3L“I1HI4”l1111lE-1;JIalwwuM11T:工-.rr1工I3i-mn:as:lw：=s：=rsk.测试组对问题

13、站点的小区PRB限制为48/24,测试速率基本稳定在对应的峰值速率上。也说明问题不在空口上，怀疑进入基站的数据不足。在基立的S1口做镜像抓包，同时在FTP服务器上也做WIRESHAR外包，发现S1口的下行数据存在乱序和丢包的现象，丢包率大约为千分之一，这个有可能导致速率的下降dErOCrgWg仆003。四暮MW10»0gwQQK00#0QCib4G0CO；00«Mw仃器E源署要“s忸备黄帆雨”旬好潞需«1|1总宅翼的“MF-西«or«lcC用11口白工54£b$4工*，7nIM，BIkl4ITffn*<ai-D，力4>ft

14、&上,F4:05cf34看、1«<仆*。6*<*蚱Fl*THaaB。曜日令&&a。*亡。27F。单后则"%工/白"0400*£!工匚1&1*rodoFQQOO汩,锣445细:,$&+工工了、1arfr曲守T«C44-4o-sC幻3。Mi-a*血X2位抬,zd.71一，噌<中&D&1H9皿MTaQ。49#不甲*4-1DTI+tfriAe695-Qj141kb>les.on»1re（11WK-bieicpturwl（ULWb11j II.WR：?Hg.附：魄：

15、&（M：01：Ml01：d.）.Mt：Rm.Mei>V7（01：tt：CI2：M：CH!c7：I事tMtriwLPTHacjatmraim.sfcs工kl也linMt：10x0.4,iwae.o.<.m）+5"TuqrsptfitgkelearcPortsa08峥。DitFort:cowtiittMTps门口Ml） K号TurwMlIhgKE&al lEffFiPrpC（K0H%5rc：工弧九孑QCLIM,；2mo.Mt；10.1,.11?£151第办11门 CcmroTfEftra】.5TCEUI9M1<WH>4Wt;，1L聃d1M

16、3*5N甯1*工，£71.*$lb XQ（1141电）jTf3c®3廿外*岫*#，限上ffrE弋eg)nr*pjs日事一留父之&*鼻¥*E'Q.QQELgXPiltwInvqirmilA4E_hy4l，e=f5mliCl«vO»M0(1108MCMa82gMg.oUKMHJiiftieiMrtWCrt«oIV>ari1«*加irci10>>J.l.13LlO-fl.l.LSI.<CiSt:11B.1O.fl.4-211J.u»#rxnqrmFTE"，

17、1.SreWTI“，加'(XKMO.MCPtTtIC0«m«Ct-hfT.EHCOMli上0E:TwrvwlInqk蹴acqi:Ekwpt&twqi，工m【a”专,垃ga*MTW.H,ctt口。九i上©j-Tr.*n»tlSoniCwrtrglPTEJ?l-i.>!.tT'：Pdrt：ftlllft(娘，1,嘴0r»ort；修什1ru/rj.'E：ieure«jparie&19IaM411MtTon|3crt：它"r，LH5fMi1(1117)(jTr."tIrKt*.

18、;5njifi*-t?白，(rvlifl¥*nijmtw*-1heat；4tIJJ1>12(celJtseq；rf*>WEJ*h1齐JU.bHwliinyMriTnuBtaBi*i%(r4l4f1v0二1rutArf)HMdtrImphE工中Ibyt”.-T©FY.Jhihnt屯Fl.，网.也4tg"|"，T-d，卜t!I打I11。"IJ1鸟4打2.传输链路不稳及丢包问题根据以上分析，首先怀疑传输侧问题，将存在问题站点提交传输分析，传输侧反馈郭家山二搬迁、新生土于港链路不稳，并进行处理；燕江路传输侧存在明显丢包，并对异常进行处理；根

19、据传输侧反馈，项目安排复测：新生土于港和燕江路问题解决，郭家山二搬迁1、2小区速率恢复正常，3小区下载速率依然较低；由于同站所有小区共用传输，因此该站3小区问题非传输导致；站点中兴答复当前版本郭家山二链路不稳，已处理3.20.01新生珏港链路不稳，已处理3.20.01燕江路存在明显丢包,已处理3.20.013.参数设置问题传输整改后郭家山二仅3小区仍存在问题，因此小区参数设置嫌疑较大，将3小区参数与1、2小区进行对比，发现上行BO参数设置不合理，参照1、2小区进行设置后，3小区下载速二率恢复正常，并对其他未解决站点参数也进行核查，发现金陵村

20、二存在同样问题，修改后也恢复正常。4.传输侧带宽设置不合理由于传输侧反馈无其他明显异常，定位至此，有点山穷水尽了。回过头再次梳理之前的定位过程，从中找些蛛丝马迹。根据1.抓包分析，从基站、终端侧抓包看，S1下行存在1/1000的丢包，因此再次安排上站抓包，站点：伊刘村。方法是在基站和PTN设备之间接入第3方交换机，在连接第三方交换机时发现，端口速率始终无法达到千兆，而第3方交换机直接和基站传输口相连，则可以达到千兆，怀疑传输侧配置为100M光口而非1000M,将该问题反馈传输核查，经传输改配后，重新连接PTN和基站，复测速率正常。这种情况有一个特点：在物理设备-机架-机框-板卡-以太网节点下，

21、目前正在使用的端口，配置工作模式为自适应，实际工作模式为100M。对全网进行核查发现还有浦江学院、浦口审计学院试扩、林家凹试扩等站点存在同样问题。传输侧反馈如下，经处理几个站点均恢复正常：站点中兴答复伊刘村传输侧配置为强制100M浦江学院传输侧配置为强制100M浦口审计学院试扩传输侧配置为强制100M林家凹试扩基站上PTN设备安装为155M光模块以下是该种情况下，OMCE核查的节点:5.上行BLER导致速率持续偏低针对柳塘村速率持续偏低的问题，上站抓包：该站没有明显丢包，但是从基站可以看到空口有心电图状的BLER毛刺，峰值约10%从拉网速率趋势看，曾有一小段时间空口无BLER对应的速率可以稳定

22、在80M左右，因此可以看出，下载速率高低，与测试点空口BLER有直接关系，空口BLER会导致下载速率持续偏低。经过外场测试人员寻找，在柳塘村可以找到空口环境较好的测试点，这些测试点空口无明显BLER测试速率可在90M,这一现象也能说明，下载速率与BLER的关系。6.1行反馈晚点到达服务器和终端丢包通过在柳塘村寻找无线环境好的测试点，测试速率可在90M以上，但也有偶尔掉坑现象，针（寸此种情况进行抓包和CDL业务日志分析，发现掉坑的时候有突发重传，重传的原因有中:上行ACKIU达服务器时间点晚导致服务器重传终端侧抓包分析：在500746行收到了SN为904789478的原始包500746013-1

23、2-0516:7:32.591984lu.176.20S.；192.16B«1«1QQTDS5007472013-12-0316:47:32,591010,176,201,Z192.168.1,100TDS5007482013-12-0316：47：3Z.592007192,168>1,1001O-L76.2O3,2TCPT*一一44.CW一¥*%3一JWAWW4/Jrt-VAWW>"W41*4ui-%,p£；、WiWki"TotAlLan9thJ14Q0_<XgeHvi>jcarlQni0x48a5(1B59

24、7>tFlags:0x0?CDort*t-Frapragrentoffset:0T$fligt口Hvo:63protocol:tcp(d)neacferchecksum:Oxifelccorrectsource;皿176.203.2()Dt5Xination:19?.169.1.100(19?-168.1.100)-TransiwHslomcontrolProtocol*SrcPort:udrawgraph(2545),D5tPort:onlvls1<Sourceport:udrawgr<2542)port：CMinivlslon(1135)Egtre

25、ai_甸dex131*Sjqi#encenunber:9047847821002001M09ee040030ff4eee00004'，*，loN0o.89o3«40.Qf6dA紧接着在500748行对500746行和500747行报文进行确认ACK(ipid:30556),如图:16:47:32*59?007192,1.10066Qfnnl$。074。？Q13T2lCG16:47:32.5928?10.176；。九2TOS1414unkncTot11Length:幻_二呸N上士哽0"上(305555二-Fl4gs:0x0(DofTt<ragventjFrign

26、xoffset:0Timerolive:aprotocol:tcp(6)Headerchecksun:0x2bacorrectsoiree:192,160,1,100(192.168.1,100)Dytdon：10.X7Q,203+2(10,17.203.J)*TrinsmlsslonControlProtQcalrsrePort:otriftlvlslonDstPort:udriwgrph(2542).Sourceport:omMvIslortOe$t5nationport：udrawgrph(2542)STfeimTn加x：J，-qu»ne-pwgr：908®951rg

27、_蟆7hg】.dge>»电ntnijiber:90479217r_.在501077行，收到SN为904789478的重传包TlrrtIDHwe：6Prouxol：TCP(6)*.H«idcrchackskrt：Qx)MdcorrecxS(Xr«：10.17528.2UO,176,203.2)DW-iWlon：192.168.1*100。92.1例.1,100)Trnsin-issoricomrolProrocol*SrcPorr：udr«wgriph(257'.MtPort：cnMvBlon(1135)15eq:9(M739$ou3port

28、:3*cr鼻典QMN)testInatIon口orc：orwriluUlon(11”)(strainInrififrU四丝anunper:917尹以喟二二服务器侧：在939644行对SN:904789478包首次进行发送1UenFtficat1on:oms：5_>,fTagTi-OXOJrn>oi,mTngnenfT-Fragmentoffset:0T3peto11vet64Protocol:tcp+H»d«rcheek£u?:0x04fecorrect£0uf<6：(10.176.203,2)Desxlrtio

29、n：10«116.7.183(10.116*7,183)-Tran5ms5ionControlProtocol.SrcPoet:udrawgraph<2$4；),05TPort:omn1vl5ionIT”：Sourceport：udrawaph(2542)tX$tH4t1onport:omniul$ion(1135)streamQ如jZ55smnmtb«r:904789478一-在939931对SN:904789478包进行重传，此时按照TCP协议，超时重传会导致速率陡降。"：N:Q3.。的Q。1PQ7$.?OM2T£P至offntT目即£

30、;5有珏*噌"*21至峥$生攻§；里:g瓦”且1戮尹一*一楚17cL一ee93943201J-12-0316:54:03.083910.11ft.7.18310.17t.203,2TCP6ftonn1v1$1on>Xtf6nfVl£4T1on70x4974.Fla<jsFflxoJiDon-rriSemT"Fr«gvent5(?t：0Timetolive；64PTOTOCfll：TCP6).ch«<k$in：oxotjf(correct&>ur<C：。菊,28,2U0,176,i0i.2>D

31、4iHMTl0ft：10,116,7,183(10.116*7*183)Tr«n$nH»1onc«rtrolProtocolsrcPort:uchr«wgr«ph(2542),OfTpoft：onnlvHlon(1135),E”W<7Ifourc»port：udc*9r*.ph0"2)MGTlNtSnport：gf>1”“lQh<11J5)JtewnUe*吁L£gqu典curnnber；937g经7g.；然而，在服务器对SN:904789478重传后的939936行收到了终端对原始包的确认，说明原

32、始包的ACK(ipid:30556)并没有丢,只是到服务器时晚了Timetolive:62Protocol:TCP(6),Headerchecksum:OxddQ4correctSource:10,116.7.183(10,116.7*183)口$t1natSon；1Q.176*2Q3*2(10.X76.203.2)-TransmissioncontrolProxocoLsrcport:omn1v1slDn(1135),osxPort:udrwgripsourceport:omnlvlslon(1135)Destinationport:udrawgraph(2542)streamindex:7

33、1sequencenuaibr:19DRf<9511>4_g财gaggntninbr:上行ACK晚点到达服务器的原因应该与下述发现的传输时延突发异常变大有关。在做业务过程中，基站对EPC进行长PING操作，会偶尔出现超大时延现象，如图:I458bytesfrorrfromTVW.hd*/S3100.6B.253.4ueq,=ziuiseq"2432VCTFTtt1=61tine=3.614nsns458bvtesfron1W,68.253.43w2433tt161tlfM"3.571ns458bytesfron108.6B.253-4seq=2434tt1

34、74;61tinte=3.552ns4S8bytesfronseq=:2435tt1-61tim=G.690ns4S8bvtesfronseqfc2436tt1061tine*3.642458bvtesfron100.68,253.4seq"2437ttl=feltIm"3.913ns458Fron100.68,253.4seq-2438tt1=61tine=3.918ns4S8bytesfron180.68.253,4seqrt243?ttl-6ltine-3-830ns4S»bytesfron100.68.253

35、.4stq=,2440tt1=61tirie=3.39目ns4S8bytefi'On100.68.253<4seq2441ttl=6111tie'3-?S?ns4S8byS蠡fwin106.68253.4seq-2442tine3.677ms4S8hyt匕£Fron1肛£8.253.4$eq=2443tt1=61tine.303ns4S8byte台Fonseq=2444tt1-61tine-449.346ns458bytesfron皿68.253.4seq;2445ttl=61tim心*519ns458fron100.68.25

36、3.4seq-2446ttl=61tipte=3.465ns4S8bytesffon5eq=244?ttl-6ltine43«402ns458bytesfron1M.6S.2S3.4seq=2448tt1=61tine=3.343ns4S8bytesfi*onseq-2449tt1-61tine=3.7fi6ns4S8bytesfron1岫.6L253.4seq*2458tt1=61tine3.740PIG458458bytesfronseq=2451tt1=61tine*3.691nsbytesfron100.

37、68,253.4se(|=2452tt1=61time皿3.442ns458bytesfronseq=2453tt1=61tine-7,lM7ns终端接收丢包在126424行，抓包看终端已收到SN为3564609387的原始包，然而终端后续却一再确认SN为3564609387的包丢失（红色部分）1264242013*12-0417:26:23.(X)40610.17轧？03.2一8TCP2126425：013-12-0417:26：23,0041?10.176.205.；192.168.1,100TCPM1264262013-12-0417:26:

38、23,0094251W.1d8,1,100TCPi1264272013-12-0417:26:23.00?*42900TCP141TCP1264292013-12-0417:26:23.0044310.176.20281264312013-12*0417:26:23.00$d57IQ.176.20.；00TCP1264332013-12-041九26:23.00X7。10.176,201,2工92.1WWOOTCPrdenrifRaglan:0x4275(17013)»Fl

39、ag玉：CxO2(Don'tfragment)Fragmentoffsec:0t5wgto1Ive:63Protocol:TCP(6)*Headerchecksm:0x5c4ccorrectSource:10,176,203.?()X穴3MHqm192,168.1.100(00)iTranfflt1$sioncontrolProtocol,SrcPort:icp-dlscovtry0822),dstport:murreyQ£ourc&port：acp-dlscov9ry(3822)D«srlnitlonport:

40、mumy(1123)i*ctex;1一Sguencenmber：356460938/.*'h=FAi-.a.0.BK.直到在126917行收到服务器的对SN为3564609387报文的快速重传才恢复正常1268652013-12-0417:26:23.04537910.176.20342192.168.1,100Fp一1313X-©HD打4-U4>?1"*£"1WwX/«ZD.Lf-«)二。-X-XWU工1-*-izesez2013-12-041Z:26:23.MMOQ192.13,1,100TC

41、P14112和172013T2-W17:6:23,O56Q4210.1764203.£192/168.X,100TCP140；U6918;013-12-M17226223.O5W53101176-203.219Z.168.1.100T-prlr*nf仆中+CfF«/*rt<rk，,一dIcientIfIcidon：0夏4q1(175O8>rFlags:0x02(Don*rFragment)dnoffset:0TlnretoMve:63proiocol:tcp(65Meaderchecksum:Qk5369correctSource:10.176*203.2(10

42、.176.203,2)Destination：197,168.1.10008.16&1,100)-Transmissioncontrolprotocol,srcf*ort:acp-dtscovary(MS22).dkPort:iturry(USourceport:acp-dlfcover/(3822)OesTinatlonport:murray(1125)(StreartindeKJJ-ieqL#enc*nuibtr：35646095B7_1Nfixt-sequCTTfiftUflDer''：35&4610723).“凡.i总结上述抓包分析：1）上行TCPACK晚点到达服务器导致重传；2）业务过程