【LTE實戰(zhàn)】TD-LTE調(diào)度不飽滿導致下載速率低問題

1、網(wǎng)格測試過程中遇到的調(diào)度不飽滿導致下載速率低問題，分享給大家!問題描述：近期，在網(wǎng)格大會戰(zhàn)過程中，LTE網(wǎng)格組發(fā)現(xiàn)多個站點在無線環(huán)境良好的情況下，下載速率無法達到峰值的情況，如下為金陵城二-1小區(qū)測試速率，速率始終只能在50M-60M上下。而該站點的配置在正常情況下應該在80M以上。共發(fā)現(xiàn)該問題的有：郭家山二搬遷、新生土于港、金陵村二、伊劉村、浦口二、柳塘村、浦江學院、燕江路、寶塔街T、大橋村、浦口審計學院試擴、林家凹試擴等12個站點。問題分析:針對該問題進行了長達1個月的反復抓包、測試定位，分析發(fā)現(xiàn)引發(fā)該問題的原因有多種情況，下面是詳細分析。1 .無線側(cè)初步分析排除終端和筆記本、FTP服務器

2、問題：對這幾個站點，進行更換終端、筆記本等方法進行測試，現(xiàn)象一樣，且同樣的筆記本、終端在其他站點上速率正常，可達到峰值。排除這方面的問題排除無線環(huán)境因素：測試時對測試位置進行多次選點，在RSRP/SIN將都遠大于極好點的位置進行測試，MC湃級可基本維持在27以上，但是速率表現(xiàn)一樣。同樣的位置進行UDP整包，速率可達到峰值。如下圖，至此可基本排除無線環(huán)境問題。測試組對問題站點的小區(qū)PRB限制為48/24,測試速率基本穩(wěn)定在對應的峰值速率上。也說明問題不在空口上，懷疑進入基站的數(shù)據(jù)不足。在基站的S1口做鏡像抓包，同時在FTP服務器上也做WIRESHAR外包，發(fā)現(xiàn)S1口的下行數(shù)據(jù)存在亂序和丟包的現(xiàn)象

3、，丟包率大約為千分之一，這個有可能導致速率的下降。村二|伊劉村|2 .傳輸鏈路不穩(wěn)及丟包問題根據(jù)以上分析，首先懷疑傳輸側(cè)問題，將存在問題站點提交傳輸分析，傳輸側(cè)反饋郭家山二搬遷、新生土于港鏈路不穩(wěn)，并進行處理；燕江路傳輸側(cè)存在明顯丟包，并對異常進行處理；根據(jù)傳輸側(cè)反饋，項目安排復測：新生土于港和燕江路問題解決，郭家山二搬遷1、2小區(qū)速率恢復正常，3小區(qū)下載速率依然較低；由于同站所有小區(qū)共用傳輸，因此該站3小區(qū)問題非傳輸導致；站點中興答復當前版本郭家山二鏈路不穩(wěn)，已處理3.20.01新生玨港鏈路不穩(wěn)，已處理3.20.01燕江路存在明顯丟包，已處理3.20.00

4、.40.15.013 .參數(shù)設(shè)置問題傳輸整改后郭家山二僅3小區(qū)仍存在問題，因此小區(qū)參數(shù)設(shè)置嫌疑較大，將3小區(qū)參數(shù)與1、2小區(qū)進行對比，發(fā)現(xiàn)上行BO參數(shù)設(shè)置不合理，參照1、2小區(qū)進行設(shè)置后，3小區(qū)下載速率恢復正常，并對其他未解決站點參數(shù)也進行核查，發(fā)現(xiàn)金陵村二存在同樣問題，修改后也恢復正常。4 .傳輸側(cè)帶寬設(shè)置不合理由于傳輸側(cè)反饋無其他明顯異常，定位至此，有點山窮水盡了。回過頭再次梳理之前的定位過程，從中找些蛛絲馬跡。根據(jù)1.抓包分析，從基站、終端側(cè)抓包看，S1下行存在1/1000的丟包，因此再次安排上站抓包，站點：伊劉村。方法是在基站和PTN設(shè)備之間接入第3方交換機，在連接第三方交換機時發(fā)現(xiàn)，

5、端口速率始終無法達到千兆，而第3方交換機直接和基站傳輸口相連，則可以達到千兆，懷疑傳輸側(cè)配置為100M光口而非1000M,將該問題反饋傳輸核查，經(jīng)傳輸改配后，重新連接PTN和基站，復測速率正常。這種情況有一個特點：在物理設(shè)備-機架-機框-板卡-以太網(wǎng)節(jié)點下，目前正在使用的端口，配置工作模式為自適應，實際工作模式為100M。對全網(wǎng)進行核查發(fā)現(xiàn)還有浦江學院、浦口審計學院試擴、林家凹試擴等站點存在同樣問題。傳輸側(cè)反饋如下，經(jīng)處理幾個站點均恢復正常：站點中興答復伊劉村傳輸側(cè)配置為強制100M浦江學院傳輸側(cè)配置為強制100M浦口審計學院試擴傳輸側(cè)配置為強制100M林家凹試擴基站上PTN設(shè)備安裝為155M

6、光模塊以下是該種情況下，OMCE核查的節(jié)點:5 .上行BLER導致速率持續(xù)偏低針對柳塘村速率持續(xù)偏低的問題，上站抓包：該站沒有明顯丟包，但是從基站可以看到空口有心電圖狀的BLER刺，峰值約10%從拉網(wǎng)速率趨勢看，曾有一小段時間空口無BLER對應的速率可以穩(wěn)定在80M左右，因此可以看出，下載速率高低，與測試點空口BLER有直接關(guān)系，空口BLER會導致下載速率持續(xù)偏低。經(jīng)過外場測試人員尋找，在柳塘村可以找到空口環(huán)境較好的測試點，這些測試點空口無明顯BLER測試速率可在90M,這一現(xiàn)象也能說明，下載速率與BLER的關(guān)系。6 .上行反饋晚點到達服務器和終端丟包通過在柳塘村尋找無線環(huán)境好的測試點，測試速

7、率可在90M以上，但也有偶爾掉坑現(xiàn)象，針對此種情況進行抓包和CDLlk務日志分析，發(fā)現(xiàn)掉坑的時候有突發(fā)重傳，重傳的原因有2中：上行ACK1IJ達服務器時間點晚導致服務器重傳終端側(cè)抓包分析：在500746行收到了SN為904789478的原始包緊接著在500748行對500746行和500747行報文進行確認ACK(ipid:30556),如圖：在501077行，收到SN為904789478的重傳包服務器側(cè)：在939644行對SN:904789478包首次進行發(fā)送在939931對SN:904789478包進行重傳，此時按照TCP協(xié)議，超時重傳會導致速率陡降。然而，在服務器對SN:90478947

8、8重傳后的939936行收到了終端對原始包的確認，說明原始包的ACK（ipid:30556）并沒有丟,只是到服務器時晚了上行ACK晚點到達服務器的原因應該與下述發(fā)現(xiàn)的傳輸時延突發(fā)異常變大有關(guān)。在做業(yè)務過程中，基站對EPC進行長PING操作，會偶爾出現(xiàn)超大時延現(xiàn)象，如圖：終端接收丟包在126424行，抓包看終端已收到SN為3564609387的原始包，然而終端后續(xù)卻一再確認SN為3564609387的包丟失（紅色部分）直到在126917行收到服務器的對SN為3564609387報文的快速重傳才恢復正?？偨Y(jié)上述抓包分析：1）上行TCPACK晚點到達服務器導致重傳；2）業(yè)務過程中PINGEPC存在超

9、大時延是導致ACK晚點的最重要原因；3）重傳為瞬時突發(fā)，絕大部分時間無重傳，且重傳發(fā)生時伴隨速率下降；4）懷疑終端或筆記本性能問題會導致在業(yè)務長時間保持中收到數(shù)據(jù)處理不過來而丟掉；二|上述四點解釋了測試過程中出現(xiàn)的現(xiàn)象：業(yè)務較長時間能夠保持鋒速，偶爾出現(xiàn)掉坑，長時間持續(xù)業(yè)務時速率波動幅度會變大。7 .終端反饋0窗口報文導致速率低針對寶塔街站上站測試抓包，經(jīng)過分析，該站點BLER相對較高，但導致業(yè)務速率低的更重要原因為終端會反饋0窗長報文，一旦出現(xiàn)該問題，當前下載線程則處于停滯狀態(tài)直至終端上報窗長恢復，每次發(fā)生停滯時間120ms-900ms不等，停滯時間內(nèi)速率為0。5線程下載測試，57秒的抓包中

10、，發(fā)生約20次0窗口事件，而且，0窗長發(fā)生時往往伴隨著丟包，如此，必然會導致速率低，如圖，在65419行發(fā)生0窗口事件，直到65466行恢復,停滯時長約800ms。解決措施及結(jié)果：綜上多種情況分析：調(diào)度不滿導致速率低問題，經(jīng)過傳輸整改鏈路、改配端口模式均能有效解決該問題。問題結(jié)論;引起調(diào)度不滿導致速率低問題有以下幾種因素：1 .傳輸問題傳輸明顯丟包；傳輸端口模式配置錯誤;傳輸鏈路不穩(wěn)；2 .參數(shù)設(shè)置問題：上行BO設(shè)置不合理；3 .測試點空口環(huán)境查，BLER高導致速率持續(xù)偏低；4 .傳輸大時延使上行ACK晚點到達服務器，引發(fā)重傳，最終導致下載速率低;5 .終端問題終端性能問題導致業(yè)務長時間保持中

11、收到數(shù)據(jù)處理不過來而丟棄，引發(fā)重傳;終端反饋0窗口報文，導致速率偏低。問題描述：近期，在網(wǎng)格大會戰(zhàn)過程中，LTE網(wǎng)格組發(fā)現(xiàn)多個站點在無線環(huán)境良好的情況下，下載速率無法達到峰值的情況，如下為金陵城二-1小區(qū)測試速率，速率始終只能在50M-60M上下。而該站點的配置在正常情況下應該在80M以上。國共發(fā)現(xiàn)該問題的有：郭家山二搬遷、新生土于港、金陵村二、伊劉村、浦口二、柳塘村、浦江學院、燕江路、寶塔街T、大橋村、浦口審計學院試擴、林家凹試擴等12個站點。問題分析：針對該問題進行了長達1個月的反復抓包、測試定位，分析發(fā)現(xiàn)引發(fā)該問題的原因有多種情況，下面是詳細分析。1.正線側(cè)初步分析排除終端和筆記本、FT

12、P服務器問題：對這幾個站點，進行更換終端、筆記本等方法進行測試，現(xiàn)象一樣，且同樣的筆記本、終端在其他站點上速率正常，可達到峰值。排除這方面的百排除無線環(huán)境因素：測試時對測試位置進行多次選點，在RSRP/SIN將都遠大于極好點的位置進行測試，MC湃級可基本維持在27以上，但是速率表現(xiàn)一樣。同樣的位置進行UDP整包，速率可達到峰值。如下圖，至此可基本排除無線環(huán)境問題。片emfi事7RNKMgLBM_MM#一>w*M«war-rM-GITTITJrTt4-3L“I1HI4”l1111lE-1;JIalwwuM11T:工-.rr1工I3i-mn:as:lw：=s：=rsk.測試組對問題

13、站點的小區(qū)PRB限制為48/24,測試速率基本穩(wěn)定在對應的峰值速率上。也說明問題不在空口上，懷疑進入基站的數(shù)據(jù)不足。在基立的S1口做鏡像抓包，同時在FTP服務器上也做WIRESHAR外包，發(fā)現(xiàn)S1口的下行數(shù)據(jù)存在亂序和丟包的現(xiàn)象，丟包率大約為千分之一，這個有可能導致速率的下降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.，網(wǎng).也4tg"|"，T-d，卜t!I打I11。"IJ1鳥4打2.傳輸鏈路不穩(wěn)及丟包問題根據(jù)以上分析，首先懷疑傳輸側(cè)問題，將存在問題站點提交傳輸分析，傳輸側(cè)反饋郭家山二搬遷、新生土于港鏈路不穩(wěn)，并進行處理；燕江路傳輸側(cè)存在明顯丟包，并對異常進行處理；根

19、據(jù)傳輸側(cè)反饋，項目安排復測：新生土于港和燕江路問題解決，郭家山二搬遷1、2小區(qū)速率恢復正常，3小區(qū)下載速率依然較低；由于同站所有小區(qū)共用傳輸，因此該站3小區(qū)問題非傳輸導致；站點中興答復當前版本郭家山二鏈路不穩(wěn)，已處理3.20.01新生玨港鏈路不穩(wěn)，已處理3.20.01燕江路存在明顯丟包,已處理3.20.013.參數(shù)設(shè)置問題傳輸整改后郭家山二僅3小區(qū)仍存在問題，因此小區(qū)參數(shù)設(shè)置嫌疑較大，將3小區(qū)參數(shù)與1、2小區(qū)進行對比，發(fā)現(xiàn)上行BO參數(shù)設(shè)置不合理，參照1、2小區(qū)進行設(shè)置后，3小區(qū)下載速二率恢復正常，并對其他未解決站點參數(shù)也進行核查，發(fā)現(xiàn)金陵村

20、二存在同樣問題，修改后也恢復正常。4.傳輸側(cè)帶寬設(shè)置不合理由于傳輸側(cè)反饋無其他明顯異常，定位至此，有點山窮水盡了?；剡^頭再次梳理之前的定位過程，從中找些蛛絲馬跡。根據(jù)1.抓包分析，從基站、終端側(cè)抓包看，S1下行存在1/1000的丟包，因此再次安排上站抓包，站點：伊劉村。方法是在基站和PTN設(shè)備之間接入第3方交換機，在連接第三方交換機時發(fā)現(xiàn)，端口速率始終無法達到千兆，而第3方交換機直接和基站傳輸口相連，則可以達到千兆，懷疑傳輸側(cè)配置為100M光口而非1000M,將該問題反饋傳輸核查，經(jīng)傳輸改配后，重新連接PTN和基站，復測速率正常。這種情況有一個特點：在物理設(shè)備-機架-機框-板卡-以太網(wǎng)節(jié)點下，

21、目前正在使用的端口，配置工作模式為自適應，實際工作模式為100M。對全網(wǎng)進行核查發(fā)現(xiàn)還有浦江學院、浦口審計學院試擴、林家凹試擴等站點存在同樣問題。傳輸側(cè)反饋如下，經(jīng)處理幾個站點均恢復正常：站點中興答復伊劉村傳輸側(cè)配置為強制100M浦江學院傳輸側(cè)配置為強制100M浦口審計學院試擴傳輸側(cè)配置為強制100M林家凹試擴基站上PTN設(shè)備安裝為155M光模塊以下是該種情況下，OMCE核查的節(jié)點:5.上行BLER導致速率持續(xù)偏低針對柳塘村速率持續(xù)偏低的問題，上站抓包：該站沒有明顯丟包，但是從基站可以看到空口有心電圖狀的BLER毛刺，峰值約10%從拉網(wǎng)速率趨勢看，曾有一小段時間空口無BLER對應的速率可以穩(wěn)定

22、在80M左右，因此可以看出，下載速率高低，與測試點空口BLER有直接關(guān)系，空口BLER會導致下載速率持續(xù)偏低。經(jīng)過外場測試人員尋找，在柳塘村可以找到空口環(huán)境較好的測試點，這些測試點空口無明顯BLER測試速率可在90M,這一現(xiàn)象也能說明，下載速率與BLER的關(guān)系。6.1行反饋晚點到達服務器和終端丟包通過在柳塘村尋找無線環(huán)境好的測試點，測試速率可在90M以上，但也有偶爾掉坑現(xiàn)象，針（寸此種情況進行抓包和CDL業(yè)務日志分析，發(fā)現(xiàn)掉坑的時候有突發(fā)重傳，重傳的原因有中:上行ACKIU達服務器時間點晚導致服務器重傳終端側(cè)抓包分析：在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尹以喟二二服務器側(cè)：在939644行對SN:904789478包首次進行發(fā)送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協(xié)議，超時重傳會導致速率陡降。"：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”“l(fā)Qh<11J5)JtewnUe*吁L£gqu典curnnber；937g經(jīng)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晚點到達服務器的原因應該與下述發(fā)現(xiàn)的傳輸時延突發(fā)異常變大有關(guān)。在做業(yè)務過程中，基站對EPC進行長PING操作，會偶爾出現(xiàn)超大時延現(xiàn)象，如圖: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的原始包，然而終端后續(xù)卻一再確認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總結(jié)上述抓包分析：1）上行TCPACK晚點到達服務器導致重傳；2）業(yè)務過程