计算机网络实验3TCP实验

计算机网络实验3TCP实验PAGE－PAGE15－计算机网络实验报告三TCP实验1.WhatistheIPaddressandTCPportnumberusedbytheclientcomputer(source)thatistransferringthefileto?Toanswerthisquestion,it’sprobablyeasiesttoselectanHTTPmessageandexplorethedetailsoftheTCPpacketusedtocarrythisHTTPmessage,usingthe“detailsoftheselectedpacketheaderwindow”(refertoFigure2inthe“GettingStartedwithWireshark”Labifyou’reuncertainabouttheWiresharkwindows).答：clientcomputer(source)：IPaddress：02TCPportnumber：1161中sequencenumber加上1所得；SYN和Acknowledgementf都置为1说明这是一个SYNACKsegment.6.WhatisthesequencenumberoftheTCPsegmentcontainingtheHTTPPOSTcommand?NotethatinordertofindthePOSTcommand,you’llneedtodigintothepacketcontentfieldatthebottomoftheWiresharkwindow,lookingforasegmentwitha“POST”withinitsDATAfield.答：第四号报文段是包含HTTPPOST命令的TCPsegment.且报文段的序列号为1.7.ConsidertheTCPsegmentcontainingtheHTTPPOSTasthefirstsegmentintheTCPconnection.WhatarethesequencenumbersofthefirstsixsegmentsintheTCPconnection(includingthesegmentcontainingtheHTTPPOST)?Atwhattimewaseachsegmentsent?WhenwastheACKforeachsegmentreceived?GiventhedifferencebetweenwheneachTCPsegmentwassent,andwhenitsacknowledgementwasreceived,whatistheRTTvalueforeachofthesixsegments?WhatistheEstimatedRTTvalue(seepage249intext)afterthereceiptofeachACK?AssumethatthevalueoftheEstimatedRTTisequaltothemeasuredRTTforthefirstsegment,andtheniscomputedusingtheEstimatedRTTequationonpage249forallsubsequentsegments.Note:WiresharkhasanicefeaturethatallowsyoutoplottheRTTforeachoftheTCPsegmentssent.SelectaTCPsegmentinthe“listingofcapturedpackets”windowthatisbeingsentfromtheclienttoserver.Thenselect:Statistics->TCPStreamGraph->RoundTripTimeGraph.Segment1Segment2Segment3Segment4Segment5Segment6答：前6个报文段为No.4,5,7,8,10,11.对应的ACK分别为No.6,9,12,14,15,16.前6个报文段截图如下：报文段的序列号为每个报文段的首字节加1，所以序列号为：Segment1sequencenumber:1Segment2sequencenumber:566Segment3sequencenumber:2026Segment4sequencenumber:3486Segment5sequencenumber:4946Segment6sequencenumber:6406报文段的发送时间和相应ACK的到达时间如下表：:SendtimeACKreceivedtimeRTTsecondsSegment10.0264770.0539370.02746Segment20.0417370.0772940.035557Segment30.0540260.1240850.070059Segment40.0546900.1691180.11443Segment50.0774050.2172990.13989Segment60.0781570.2678020.18964EstimatedRTT=0.875*EstimatedRTT+0.125*SampleRTT接受到报文段1之后的EstimatedRTT为：EstimatedRTT=RTTforsegment1=0.02746second接受到报文段2之后的EstimatedRTT为：EstimatedRTT=0.875*0.02764+0.125*0.035557=0.0285sencond接受到报文段3之后的EstimatedRTT为：EstimatedRTT=0.875*0.0285+0.125*0.070059=0.0337second接受到报文段4之后的EstimatedRTT为：EstimatedRTT=0.875*0.0337+0.125*0.11443=0.0438second接受到报文段5之后的EstimatedRTT为：EstimatedRTT=0.875*0.0438+0.125*0.13989=0.0558second接受到报文段6之后的EstimatedRTT为：EstimatedRTT=0.875*0.0558+0.125*0.18964=0.0725second8.WhatisthelengthofeachofthefirstsixTCPsegments?答：前6个段的长度分别为：565、1460、1460、1460、1460、1460字节。9.Whatistheminimumamountofavailablebufferspaceadvertisedatthereceivedfortheentiretrace?Doesthelackofreceiverbufferspaceeverthrottlethesender?答：接收方通知给发送方的最低窗口大小为5840字节，即在服务器端传回的第一个ACK中的窗口大小。接收方的窗口大小没有抑制发送方的传输速率，因为窗口大小从5840逐步增加到62780，窗口大小始终大于发送方发送的分组的容量。10.Arethereanyretransmittedsegmentsinthetracefile?Whatdidyoucheckfor(inthetrace)inordertoanswerthisquestion？答：没有，从TCP报文段的序列号中可以得出以上结论。从上图中的时间—序号图可以看出，从源端发往目的端的序号逐渐递增，如果这其中有重传的报文段，则其序号中应该有小于其临近的分组序号的分组，在图中未看到这样的分组，所以没有被重传的分组。11.HowmuchdatadoesthereceivertypicallyacknowledgeinanACK?CanyouidentifycaseswherethereceiverisACKingeveryotherreceivedsegment？答：右下图得，接收方在一个ACK确认的数据大小一般为1460字节。TheAcknowledgedsequencenumberandtheAcknowledgeddata:AcknowledgedsequencenumberAcknowledgeddataACK1566566ACK220261460ACK334861460ACK449461460ACK564061460ACK678661460ACK790131147ACK8104731460ACK9119331460ACK10133931460ACK11148531460报文段确认数据为2920bytes=1460*2bytes，即129541-12621=2920.12.Whatisthethroughput(bytestransferredperunittime)fortheTCPconnection?Explainhowyoucalculatedthisvalue.答：TCP吞吐量计算很大程度上取决于所选内容的平均时间。作为一个普通的吞吐量计算，在这问题上，选择整个连接的时间作为平均时间段。然后，此TCP连接的平均吞吐量为总的传输数据与总传输时间的比值。传输的数据总量为TCP段第一个序列号（即第4段的1字节）和最后的序列号的ACK（第202段的164091个字节）之间的差值。因此，总数据是164091-1=164090字节。整个传输时间是第一个TCP段（即4号段0.026477秒）的时间和最后的ACK（即第202段5.455830秒)时间的差值。因此，总传输时间是5.455830-0.026477=5.4294秒。因此，TCP连接的吞吐量为164090/5.4294=30.222KByte/sec13.UsetheTime-Sequence-Graph(Stevens)plottingtooltoviewthesequencenumberversustimeplotofsegmentsbeingsentfromtheclienttotheserver.CanyouidentifywhereTCP’sslowstartphasebeginsandends,andwherecongestionavoidancetakesover?CommentonwaysinwhichthemeasureddatadiffersfromtheidealizedbehaviorofTCPthatwe’vestudiedinthetext.答:慢启动阶段即从HTTPPOST报文段发出时开始，但是无法判断什么时候慢启动结束，拥塞避免阶段开始。慢启动阶段和拥塞避免阶段的鉴定取决于发送方拥塞窗口的大小。拥塞窗口的大小并不能从时间—序号图（time-sequence-graph）直接获得。然而在一个发送方中未被确认的数据量（即inflight数据量）不会超过CongWin（拥塞窗口）和RcvWindow（接收窗口）中的最小值，即LastByteSend-LastByteAcked<=min{CongWin,RcvWindow}。同时，在第9题中看到，接收方通告给发送方的窗口大小并没有遏制发送速率。因此，未被确认的数据量（即inflight数据量），是由拥塞窗口决定的，所以通过发出而未被确认的数据量（即inflight数据量），我们可以估计拥塞窗口大小的下界。下表列出了部分inflight数据量，从表中可以看出拥塞窗口的下界>=8192(因为inflightdata从未超过8192)。但是，从第10题（即从时间—序号图）得，没有分组丢失（不管是超时，还是三个冗余ACK），因此无法判断什么时候慢启动结束，拥塞避免阶段开始。TypeNo.Seq.ACKedseq.inflightdataData41565Data55662025ACK65661460Data720262920Data834864380ACK920262920Data1049464380Data1164065840ACK1234864380Data1378665527ACK1440964917ACK1560063007ACK1678661147ACK1790130Data1890131460Data19104732920Data20119334380Data21133935840Data22148537300Data23163138192ACK24104736732ACK25119335272ACK26133933812ACK27148532352ACK2816313892ACK29172050Data30172051460Data31186652920Data32201254380Data33215855840Data34230457300Data35245058192ACK36186656732ACK37201255272ACK38215853812ACK39230452352ACK4024505892ACK41253970Data42253971460Data43268572920Data44283174380Data45297775840Data46312377300Data47326978192ACK48268576732ACK49283175272ACK50297773812ACK51312371752ACK52335890Data53335896732Data54350495272Data55365093812Data56379692352Data5739429892Data58408890ACK59350496732ACK60379693812ACK6140889892ACK62417810Data63417811460Data64432412920Data65447014380Data66461615840Data67476217300Data68490818192ACK69447015272ACK70476212352ACK71499730Data72499731460Data73514332920Data74528934380Data75543535840Data76558137300Data77572738192ACK78528935272ACK79558132352ACK80581650Data81581651460TCP的发送方会试探性的发送数据（即慢启动阶段），如果太多的数据使网络拥塞了，那么发送方会根据AIMD算法进行调整。但是在实际中，TCP的行为主要依赖于应用程序怎么设计。在这次抓包中，在发送方还可以发送数据的时候，已经没有数据可发了。在web应用中，有些web对象比较小，在慢启动还没有结束之前，传送就结束啦，因此，传送小的web对象受到TCP慢启动阶段的影响，导致较长的延迟。14.Answereachoftwoquestionsaboveforthetracethatyouhavegatheredwhenyoutransferredafilefromyourcomputerto。答：慢启动阶段即从HTTPPOST报文段发出时开始，但是无法判断什么时候慢启动结束，拥塞避免阶段开始。慢启动阶段和拥塞避免阶段的鉴定取决于发送方拥塞窗口的大小。拥塞窗口的大小并不能从时间—序号图（time-sequence-graph）直接获得。然而在一个发送方中未被确认的数据量（即inflight数据量）不会超过CongWin（拥塞窗口）和RcvWindow（接收窗口）中的最小值，即LastByteSend-LastByteAcked<=min{CongWin,RcvWindow}。同时，在第9题中看到，接收方通告给发送方的窗口大小并没有遏制发送速率。因此，未被确认的数据量（即inflight数据量），是由拥塞窗口决定的，所以通过发出而未被确认的数据量（即inflight数据量），我们可以估计拥塞窗口大小的下界。下表列出了部分inflight数据量，从表中可以看出拥塞窗口的下界>=9015(因为inflightdata从未超过9015)。但是，从第10题（即从时间—序号图）得，没有分组丢失（不管是超时，还是三个冗余ACK），因此无法判断什么时候慢启动结束，拥塞避免阶段开始。TypeNo.Seq.ACKedseq.inflightdataData161823Data178242283ACK198241460Data2022843743Data2137445203ACK2