計算機(jī)網(wǎng)絡(luò)實(shí)驗(yàn)3TCP實(shí)驗(yàn)

計算機(jī)網(wǎng)絡(luò)實(shí)驗(yàn)3TCP實(shí)驗(yàn)PAGE－PAGE15－計算機(jī)網(wǎng)絡(luò)實(shí)驗(yàn)報告三TCP實(shí)驗(yàn)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“l(fā)istingofcapturedpackets”windowthatisbeingsentfromtheclienttoserver.Thenselect:Statistics->TCPStreamGraph->RoundTripTimeGraph.Segment1Segment2Segment3Segment4Segment5Segment6答：前6個報文段為No.4,5,7,8,10,11.對應(yīng)的ACK分別為No.6,9,12,14,15,16.前6個報文段截圖如下：報文段的序列號為每個報文段的首字節(jié)加1，所以序列號為：Segment1sequencenumber:1Segment2sequencenumber:566Segment3sequencenumber:2026Segment4sequencenumber:3486Segment5sequencenumber:4946Segment6sequencenumber:6406報文段的發(fā)送時間和相應(yīng)ACK的到達(dá)時間如下表：: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字節(jié)。9.Whatistheminimumamountofavailablebufferspaceadvertisedatthereceivedfortheentiretrace?Doesthelackofreceiverbufferspaceeverthrottlethesender?答：接收方通知給發(fā)送方的最低窗口大小為5840字節(jié)，即在服務(wù)器端傳回的第一個ACK中的窗口大小。接收方的窗口大小沒有抑制發(fā)送方的傳輸速率，因?yàn)榇翱诖笮?840逐步增加到62780，窗口大小始終大于發(fā)送方發(fā)送的分組的容量。10.Arethereanyretransmittedsegmentsinthetracefile?Whatdidyoucheckfor(inthetrace)inordertoanswerthisquestion？答：沒有，從TCP報文段的序列號中可以得出以上結(jié)論。從上圖中的時間—序號圖可以看出，從源端發(fā)往目的端的序號逐漸遞增，如果這其中有重傳的報文段，則其序號中應(yīng)該有小于其臨近的分組序號的分組，在圖中未看到這樣的分組，所以沒有被重傳的分組。11.HowmuchdatadoesthereceivertypicallyacknowledgeinanACK?CanyouidentifycaseswherethereceiverisACKingeveryotherreceivedsegment？答：右下圖得，接收方在一個ACK確認(rèn)的數(shù)據(jù)大小一般為1460字節(jié)。TheAcknowledgedsequencenumberandtheAcknowledgeddata:AcknowledgedsequencenumberAcknowledgeddataACK1566566ACK220261460ACK334861460ACK449461460ACK564061460ACK678661460ACK790131147ACK8104731460ACK9119331460ACK10133931460ACK11148531460報文段確認(rèn)數(shù)據(jù)為2920bytes=1460*2bytes，即129541-12621=2920.12.Whatisthethroughput(bytestransferredperunittime)fortheTCPconnection?Explainhowyoucalculatedthisvalue.答：TCP吞吐量計算很大程度上取決于所選內(nèi)容的平均時間。作為一個普通的吞吐量計算，在這問題上，選擇整個連接的時間作為平均時間段。然后，此TCP連接的平均吞吐量為總的傳輸數(shù)據(jù)與總傳輸時間的比值。傳輸?shù)臄?shù)據(jù)總量為TCP段第一個序列號（即第4段的1字節(jié)）和最后的序列號的ACK（第202段的164091個字節(jié)）之間的差值。因此，總數(shù)據(jù)是164091-1=164090字節(jié)。整個傳輸時間是第一個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報文段發(fā)出時開始，但是無法判斷什么時候慢啟動結(jié)束，擁塞避免階段開始。慢啟動階段和擁塞避免階段的鑒定取決于發(fā)送方擁塞窗口的大小。擁塞窗口的大小并不能從時間—序號圖（time-sequence-graph）直接獲得。然而在一個發(fā)送方中未被確認(rèn)的數(shù)據(jù)量（即inflight數(shù)據(jù)量）不會超過CongWin（擁塞窗口）和RcvWindow（接收窗口）中的最小值，即LastByteSend-LastByteAcked<=min{CongWin,RcvWindow}。同時，在第9題中看到，接收方通告給發(fā)送方的窗口大小并沒有遏制發(fā)送速率。因此，未被確認(rèn)的數(shù)據(jù)量（即inflight數(shù)據(jù)量），是由擁塞窗口決定的，所以通過發(fā)出而未被確認(rèn)的數(shù)據(jù)量（即inflight數(shù)據(jù)量），我們可以估計擁塞窗口大小的下界。下表列出了部分inflight數(shù)據(jù)量，從表中可以看出擁塞窗口的下界>=8192(因?yàn)閕nflightdata從未超過8192)。但是，從第10題（即從時間—序號圖）得，沒有分組丟失（不管是超時，還是三個冗余ACK），因此無法判斷什么時候慢啟動結(jié)束，擁塞避免階段開始。TypeNo.Seq.ACKedseq.inflightdataData41565Data55662025ACK65661460Data720262920Data834864380ACK920262920Data1049464380Data1164065840ACK1234864380Data1378665527ACK1440964917ACK1560063007ACK1678661147ACK1790130Data1890131460Data19104732920Data20119334380Data21133935840Data22148537300Data23163138192ACK24104736732ACK25119335272ACK26133933812ACK27148532352ACK2816313892ACK29172050Data30172051460Data31186652920Data32201254380Data33215855840Data34230457300Data35245058192ACK36186656732ACK37201255272ACK38215853812ACK39230452352ACK4024505892ACK41253970Data42253971460Data43268572920Data44283174380Data45297775840Data46312377300Data47326978192ACK48268576732ACK49283175272ACK50297773812ACK51312371752ACK52335890Data53335896732Data54350495272Data55365093812Data56379692352Data5739429892Data58408890ACK59350496732ACK60379693812ACK6140889892ACK62417810Data63417811460Data64432412920Data65447014380Data66461615840Data67476217300Data68490818192ACK69447015272ACK70476212352ACK71499730Data72499731460Data73514332920Data74528934380Data75543535840Data76558137300Data77572738192ACK78528935272ACK79558132352ACK80581650Data81581651460TCP的發(fā)送方會試探性的發(fā)送數(shù)據(jù)（即慢啟動階段），如果太多的數(shù)據(jù)使網(wǎng)絡(luò)擁塞了，那么發(fā)送方會根據(jù)AIMD算法進(jìn)行調(diào)整。但是在實(shí)際中，TCP的行為主要依賴于應(yīng)用程序怎么設(shè)計。在這次抓包中，在發(fā)送方還可以發(fā)送數(shù)據(jù)的時候，已經(jīng)沒有數(shù)據(jù)可發(fā)了。在web應(yīng)用中，有些web對象比較小，在慢啟動還沒有結(jié)束之前，傳送就結(jié)束啦，因此，傳送小的web對象受到TCP慢啟動階段的影響，導(dǎo)致較長的延遲。14.Answereachoftwoquestionsaboveforthetracethatyouhavegatheredwhenyoutransferredafilefromyourcomputerto。答：慢啟動階段即從HTTPPOST報文段發(fā)出時開始，但是無法判斷什么時候慢啟動結(jié)束，擁塞避免階段開始。慢啟動階段和擁塞避免階段的鑒定取決于發(fā)送方擁塞窗口的大小。擁塞窗口的大小并不能從時間—序號圖（time-sequence-graph）直接獲得。然而在一個發(fā)送方中未被確認(rèn)的數(shù)據(jù)量（即inflight數(shù)據(jù)量）不會超過CongWin（擁塞窗口）和RcvWindow（接收窗口）中的最小值，即LastByteSend-LastByteAcked<=min{CongWin,RcvWindow}。同時，在第9題中看到，接收方通告給發(fā)送方的窗口大小并沒有遏制發(fā)送速率。因此，未被確認(rèn)的數(shù)據(jù)量（即inflight數(shù)據(jù)量），是由擁塞窗口決定的，所以通過發(fā)出而未被確認(rèn)的數(shù)據(jù)量（即inflight數(shù)據(jù)量），我們可以估計擁塞窗口大小的下界。下表列出了部分inflight數(shù)據(jù)量，從表中可以看出擁塞窗口的下界>=9015(因?yàn)閕nflightdata從未超過9015)。但是，從第10題（即從時間—序號圖）得，沒有分組丟失（不管是超時，還是三個冗余ACK），因此無法判斷什么時候慢啟動結(jié)束，擁塞避免階段開始。TypeNo.Seq.ACKedseq.inflightdataData161823Data178242283ACK198241460Data2022843743Data2137445203ACK2