Wireshark抓包常见问题解析

Wireshark抓包常见问题解析QQTCPWireshark抓包抓包分析抓包工具网络过滤抓包作者小憩闲人/分类网络安全/发布于2012-05-0808:501.tcpout-of-order（tcp有问题）解答：1）、应该有很多原因。但是多半是网络拥塞，导致顺序包抵达时间不同，延时太长，或者包丢失，需要重新组合数据单元因为他们可能是通过不同的路径到达你电脑上面的。2）、CRMIT同仁上礼拜来跟我反应一个问题，由他们客服系统藉由邮件主机要寄送给客户的信件，常常会有寄送失败的问题，查看了一下Log，发现正常的信件在主机接收DATA完成后会记录收到的邮件大小，然后开始进行后续寄送出去的处理，但这些有问题的寄送，都会发生DATA没有传送完，Server就记录已读取到EOF，然后结束连线，也因此这封信就不算顺利的送到Server上来。初步看了一下排除是Timeout问题，因为连线断的时间都还未达设定的连线Timeout时间，由于CRM系统是外面厂商写的，为了厘清问题我只好抓封包来看是不是用户端送出来结束传送的指令的。抓了一下结果如下：整封邮件的传送过程，包含了大量的TCPRetransmission或是SegmentLost，到后来还有跑出TCPOut-Of-Order，看起来是网路的问题，网路上对于TCPOut-Of-Order的建议是说，有些Packet可能Lost，所以重新传送造成，另一个可能是因为Client到Server间有两条网路路径，像是LoadBalance之类的架构，因此若两个封包走不同路径，晚送的封包却比早送的到达，就会发生Out-Of-Order。因此在断定有可能是网路造成，加上CRM系统上的网卡同事是把两张做成一张Virtual，再请他拿掉Bonding只用单一张跑以后，问题就不存在了，观察流量还跑的比原本两张合起来的Virtual单张跑的高，所以M$在Bonding网卡上是不是还有什么需要调整的就不得而之了，至少找出造成大量寄送失败的原因就好。2.tcpsegmentofareassembledPDU解答：1）在连个连接建立的时候，SYN包里面会把彼此TCP最大的报文段长度，在局域网内一般都是1460.如果发送的包比最大的报文段长度长的话就要分片了，被分片出来的包，就会被标记了“TCPsegmentofareassembledPDU”，可以参考下图，看一下，被标记了的包的SEQ和ACK都和原来的包一致：2）上周在公司里遇到一个问题，用wireshark抓系统给网管上报的数据发现里面有好多报文被标识为“TCPsegmentofareassembledPDU”，并且每一段报文都是180Byte，当时看到这样的标识，觉得是IP报文分片，以为系统的接口MTU值为设置小了，通过命令查询发现是1500，没有被重设过，当时有点想不通。回来查了一下，发现自己的理解是错的，“TCPsegmentofareassembledPDU”指的不是IP层的分片，IP分片在wireshark里用“FragmentedIPprotocol”来标识。详细查了一下，发现“TCPsegmentofareassembledPDU”指TCP层收到上层大块报文后分解成段后发出去。于是有个疑问，TCP层完全可以把大段报文丢给IP层，让IP层完成分段，为什么要在TCP层分呢？其实这个是由TCP的MSS(MaximumSegmentSize，最大报文段长度)决定的，TCP在发起连接的第一个报文的TCP头里通过MSS这个可选项告知对方本端能够接收的最大报文（当然，这个大小是TCP净荷的大小），以太网上这个值一般设置成1460，因为1460Byte净荷+20ByteTCP头+20ByteIP头＝1500字节，正好符合链路层最大报文的要求。至于收到一个报文后如何确定它是一个”TCPsegment”？如果有几个报文的ACK序号都一样，并且这些报文的SequenceNumber都不一样，并且后一个SequenceNumber为前一个SequenceNumber加上前一个报文大小再加上1的话，肯定是TCPsegment了，对于没有ACK标志时，则无法判断。既然收到的TCP报文都是180Byte的segment，那么应该是协商的时候PC端告知了MSS为180Byte，至于为什么这样，只能等抓包后确认是MSS的问题再排查了。另外，有一种情况也可能导致这个问题：被测系统因为MTU为220Byte而设置MSS为180Byte，但是这种情况现在可以排除，因为前面讲过，已经查询过MTU值为1500。3.Tcpprevioussegmentlost（tcp先前的分片丢失）解答：（1）、“TCPPrevioussegmentlost”errorsarenot“fatal”errors.Theysimplyindicatethatthesequencenumberinthearrivingpacketishigherthanthenext-expectedsequencenumber,indicatingthatatleastonesegmentwasdropped/lost.ThereceivingstationremediesthissituationbysendingduplicateACKsforeachadditionalpacketitreceivesuntilthesenderretransmitsthemissingpacket(s).TCPisdesignedtorecoverfromthissituation,whichiswhytheimageisdownloadedcorrectlydespitehavinga(briefly)missingpacket.Ifyouaregettingalargenumberoflostpackets,thenthereislikelyacommunicationproblembetweenthesenderandreceiver.Acommoncauseofthisisun-matchedduplexsettingsbetweenthePCandtheswitch.We(ourlab)recentlyupgradedtoEthereal0.10.14withWinPCap3.1.IfIremembercorrectly,wehadpreviouslybeenusing0.10.2withWinPCap3.0.However,sincetheupgradewehavebeennoticingseveralissues.Thefirstissueiswith“TCPPrevioussegmentlost”and“TCPCHECKSUMINCORRECT”messagesappearinginthePacketListingwindow.WedonotrememberseeingtheseinthepreviousversionofEthereal,oratleastnotnearlyasmanyasweareseeingnow.Forexample,onetaskforthestudentinstructionalpartofthelabinvolvesvisitingawebsitecontainingtwoimagesandobservingthenetworkactivity.AfterthetwoGETrequestsaresentfortheimages,itisnotuncommonforoneimagetobereturnedwithatypical200OKresponsepacket,buttheresponsepacketfortheotherimagewillbedisplayedas“TCPPrevioussegmentlost.”However,bothimagesaredownloadedanddisplayedperfectlyfineinthebrowser.Iwouldthinkthatthesegmentlosterrorwouldmeantheobjectwasn’treturnedcorrectlyandshouldn’tbeabletobedisplayed,butapparentlythatisnotthecase.(Thecachehadbeenclearedwhenthiswasperformed,soitwasnotdefaultingtoalocalcopyoftheimage.)Anotherproblemwe’vebeennoticingisthatsomepacketssimplyaren’tdisplayedinthePacketListingwindow,evenwhentheyareobviouslyreceived.Usingthesameexampleasabove,afterthetwoGETrequestsaresentfortheimages,itisnotuncommonforoneimagetobereturnedwithatypical200OKresponse,buttheotherresponsewillnotappear.Yetbothimagesaresuccessfullydisplayedinthebrowser.IsthisaproblemwithEtherealnotdetectingthepackets?I’mnotsurehowtypicalthisis,butweseemtobeexperiencingtheseissuesoftenwith0.10.14whileweneverdidwith0.10.2.CoulditalsobeanissuewithWinPCap,andnotnecessarilyEthereal?I’mjusttryingtofindsomeanswersastowhyweareseeingasuddenabundanceofTCPrelatederrorsanduncapturedpackets.Thanks.（2）、IhaveanetworkclientapplicationthatrunsfinewhileIamdebugging(noTCPerrors),butwhenIrunthereleaseversion,itrunsincrediblyslow.Itrunsasaseriesoftransactions,whereeachtransactionisaseparateconnectiontotheserver.Wiresharkanalysishasdeterminedthatabout50%ofalltransactionsinvolvetheseries:TCPPreviousSegmentLostTCPDupACKRSTTheRSTconsumes3secondspertransaction,whichisaBigDeal.Sotopreventit,Imustpreventtheinitial“TCPPreviousSegmentLost”(whichseems,onthesurface,tomerelybeatime-outonaparticularsegment).Inthefollowingclip,theSYNpacketsuffersfromthe“TCPPreviousSegmentLost”condition.0.000640secondsseemsliketooshortofatimetodeclarethiscondition,asmanyprevioussuccessfultransactionstookmuchlongertobesuccessfullySYN-ACK’ed.Cansomebodyexplain“TCPPreviousSegment