計算機網(wǎng)絡(luò)實驗TCP實驗

1、計算機網(wǎng)絡(luò)實驗報告三TCP實驗1. What is the IP address and TCP port number used by the client computer (source)that is transferring the file to ? To answer this question, itsprobably easiest to select an HTTP message and explore the details of the TCPpacket used to carry this HTTP message, using

2、the “details of the selected packetheader window” (refer to Figure 2 in the “Getting Started with Wireshark” Lab ifyoure uncertain about the Wireshark windows).答：client computer (source)：IP address：02 TCP port number：11612. What is the IP address of ? On what port number

3、is it sendingand receiving TCP segments for this connection?答：IP address：2 port number：803. If you have been able to create your own trace, answer the following question:What is the IP address and TCP port number used by your client computer(source) to transfer the file to gaia.cs.umass

4、.edu?答：My client computer:IP address4. What is the sequence number of the TCP SYN segment that is used to initiate theTCP connection between the client computer and ? What is it in the segment that identifies the segment as a SYN segment?答：sequence number:0 ；syn 被設(shè)置為1說明是syn段。5. What

5、 is the sequence numberto the client computer in reply to the SYN? What is the value of the ACKnowledgement field determine that value? What is it in the segment that identifies the segment as a SYNACK segment?答：The sequence number is:0； SYNACK segment 中 ACKnowledgement 的值為1；ACKnowledgement number的值

6、為SYN消息中sequence number加上1所得；SYN 和Acknowledgement f都置為1說明這是一個SYNACK segment.6. What is the sequence number of the TCP segment containing the HTTP POSTcommand? Note that in order to find the POST command, youll need to dig intothe packet content field at the bottom of the Wireshark window, looking for

7、 asegment with a “POST” within its DATA field.答：第四號報文段是包含 HTTP POST 命令的TCP segment.且報文段的序列號為1. 7. Consider the TCP segment containing the HTTP POST as the first segment in theTCP connection. What are the sequence numbers of the first six segments in theTCP connection (including the segment containin

8、g the HTTP POST)?At what time was each segment sent? When was the ACK for each segment received?Given the difference between when each TCP segment was sent, and when itsacknowledgement was received, what is the RTT value for each of the sixsegments? What is the EstimatedRTT value (see page 249 in te

9、xt) after thereceipt of each ACK? Assume that the value of the EstimatedRTT is equal tothe measured RTT for the first segment, and then is computed using theEstimatedRTT equation on page 249 for all subsequent segments.Note: Wireshark has a nice feature that allows you to plot the RTT foreach of the

10、 TCP segments sent. Select a TCP segment in the “l(fā)isting ofcaptured packets” window that is being sent from the client to server. Then select: Statistics->TCP Stream Graph->Round Trip Time Graph.Segment 1Segment 2Segment 3Segment 4Segment 5Segment 6答：前6個報文段為No.4,5,7,8,10,1

11、1. 對應(yīng)的ACK分別為 No.6,9,12,14,15,16. 前6個報文段截圖如下：報文段的序列號為每個報文段的首字節(jié)加1，所以序列號為：Segment 1 sequence number:1Segment 2 sequence number:566Segment 3 sequence number:2026Segment 4 sequence number:3486Segment 5 sequence number:4946Segment 6 sequence number:6406報文段的發(fā)送時間和相應(yīng)ACK 的到達時間如下表：:Send timeACK received timeRT

12、T secondsSegment 10.0264770.0539370.02746Segment 20.0417370.0772940.035557Segment 30.0540260.1240850.070059Segment 40.0546900.1691180.11443Segment 50.0774050.2172990.13989Segment 60.0781570.2678020.18964EstimatedRTT=0.875* EstimatedRTT+0.125*SampleRTT接受到報文段1之后的EstimatedRTT為：EstimatedRTT=RTT for segm

13、ent 1=0.02746 second接受到報文段2之后的EstimatedRTT為：EstimatedRTT=0.875*0.02764+0.125*0.035557=0.0285 sencond接受到報文段3之后的EstimatedRTT為：EstimatedRTT=0.875*0.0285+0.125*0.070059=0.0337 second接受到報文段4之后的EstimatedRTT為：EstimatedRTT=0.875*0.0337+0.125*0.11443=0.0438 second接受到報文段5之后的EstimatedRTT為：EstimatedRTT=0.875*0.

14、0438+0.125*0.13989= 0.0558 second接受到報文段6之后的EstimatedRTT為：EstimatedRTT=0.875*0.0558+0.125*0.18964= 0.0725 second8. What is the length of each of the first six TCP segments?答：前6個段的長度分別為：565、1460、1460、1460、1460、1460字節(jié)。9. What is the minimum amount of available buffer space advertised at the receivedfor

15、 the entire trace? Does the lack of receiver buffer space ever throttle thesender? 答：接收方通知給發(fā)送方的最低窗口大小為5840字節(jié)，即在服務(wù)器端傳回的第一個ACK中的窗口大小。接收方的窗口大小沒有抑制發(fā)送方的傳輸速率，因為窗口大小從5840逐步增加到62780，窗口大小始終大于發(fā)送方發(fā)送的分組的容量。10. Are there any retransmitted segments in the trace file? What did you check for (inthe trace) in order

16、to answer this question？答：沒有，從TCP報文段的序列號中可以得出以上結(jié)論。從上圖中的時間序號圖可以看出，從源端發(fā)往目的端的序號逐漸遞增，如果這其中有重傳的報文段，則其序號中應(yīng)該有小于其臨近的分組序號的分組，在圖中未看到這樣的分組，所以沒有被重傳的分組。11. How much data does the receiver typically acknowledge in an ACK? Can youidentify cases where the receiver is ACKing every other received segment ？答： 右下圖得，接收方

17、在一個ACK確認的數(shù)據(jù)大小一般為1460字節(jié)。The Acknowledged sequence number and the Acknowledged data:Acknowledged sequence numberAcknowledged dataACK 1566566ACK 220261460ACK 334861460ACK 449461460ACK 564061460ACK 678661460ACK 790131147ACK 8104731460ACK 9119331460ACK 10133931460ACK 11148531460報文段確認數(shù)據(jù)為2920bytes=1460*2 b

18、ytes，即129541-12621=2920.12. What is the throughput (bytes transferred per unit time) for the TCP connection?Explain how you calculated this value.答：TCP 吞吐量計算很大程度上取決于所選內(nèi)容的平均時間。作為一個普通的吞吐量計算，在這問題上，選擇整個連接的時間作為平均時間段。然后，此TCP 連接的平均吞吐量為總的傳輸數(shù)據(jù)與總傳輸時間的比值。傳輸?shù)臄?shù)據(jù)總量為TCP 段第一個序列號（即第4 段的1 字節(jié)）和最后的序列號的ACK （第202 段的16409

19、1個字節(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.222 KByte/sec13. Use the Time-Sequence-Graph(Stevens) plotting tool to view the sequence number versus time plot of segme

20、nts being sent from the client to the server. Can you identify where TCPs slow start phase begins and ends, and where congestion avoidance takes over? Comment on ways in which the measured data differs from the idealized behavior of TCP that weve studied in the text.答:慢啟動階段即從HTTP P

21、OST 報文段發(fā)出時開始，但是無法判斷什么時候慢啟動結(jié)束，擁塞避免階段開始。慢啟動階段和擁塞避免階段的鑒定取決于發(fā)送方擁塞窗口的大小。擁塞窗口的大小并不能從時間序號圖（time-sequence-graph）直接獲得。然而在一個發(fā)送方中未被確認的數(shù)據(jù)量（即in flight 數(shù)據(jù)量）不會超過CongWin（擁塞窗口）和RcvWindow（接收窗口）中的最小值，即LastByteSend-LastByteAcked<=minCongWin,RcvWindow。同時，在第9題中看到，接收方通告給發(fā)送方的窗口大小并沒有遏制發(fā)送速率。因此，未被確認的數(shù)據(jù)量（即in flight 數(shù)據(jù)量），是由擁

22、塞窗口決定的，所以通過發(fā)出而未被確認的數(shù)據(jù)量（即in flight 數(shù)據(jù)量），我們可以估計擁塞窗口大小的下界。下表列出了部分in flight 數(shù)據(jù)量，從表中可以看出擁塞窗口的下界>=8192(因為in flight data 從未超過8192)。 但是，從第10題（即從時間序號圖）得，沒有分組丟失（不管是超時，還是三個冗余ACK），因此無法判斷什么時候慢啟動結(jié)束，擁塞避免階段開始。TypeNo.Seq.ACKed seq.in flight dataData41565Data55662025ACK65661460Data720262920Data834864380ACK92026292

23、0Data1049464380Data1164065840ACK1234864380Data1378665527ACK1440964917ACK1560063007ACK1678661147ACK1790130Data1890131460Data19104732920Data20119334380Data21133935840Data22148537300Data23163138192ACK24104736732ACK25119335272ACK26133933812ACK27148532352ACK2816313892ACK29172050Data30172051460Data3118665

24、2920Data32201254380Data33215855840Data34230457300Data35245058192ACK36186656732ACK37201255272ACK38215853812ACK39230452352ACK4024505892ACK41253970Data42253971460Data43268572920Data44283174380Data45297775840Data46312377300Data47326978192ACK48268576732ACK49283175272ACK50297773812ACK51312371752ACK5233589

25、0Data53335896732Data54350495272Data55365093812Data56379692352Data5739429892Data58408890ACK59350496732ACK60379693812ACK6140889892ACK62417810Data63417811460Data64432412920Data65447014380Data66461615840Data67476217300Data68490818192ACK69447015272ACK70476212352ACK71499730Data72499731460Data73514332920Da

26、ta74528934380Data75543535840Data76558137300Data77572738192ACK78528935272ACK79558132352ACK80581650Data81581651460TCP的發(fā)送方會試探性的發(fā)送數(shù)據(jù)（即慢啟動階段），如果太多的數(shù)據(jù)使網(wǎng)絡(luò)擁塞了，那么發(fā)送方會根據(jù)AIMD算法進行調(diào)整。但是在實際中，TCP的行為主要依賴于應(yīng)用程序怎么設(shè)計。在這次抓包中，在發(fā)送方還可以發(fā)送數(shù)據(jù)的時候，已經(jīng)沒有數(shù)據(jù)可發(fā)了。在web應(yīng)用中，有些web對象比較小，在慢啟動還沒有結(jié)束之前，傳送就結(jié)束啦，因此，傳送小的web對象受到TCP慢啟動階段的影響，導(dǎo)致較長的延遲

27、。14. Answer each of two questions above for the trace that you have gathered when 。答：慢啟動階段即從HTTP POST 報文段發(fā)出時開始，但是無法判斷什么時候慢啟動結(jié)束，擁塞避免階段開始。慢啟動階段和擁塞避免階段的鑒定取決于發(fā)送方擁塞窗口的大小。擁塞窗口的大小并不能從時間序號圖（time-sequence-graph）直接獲得。然而在一個發(fā)送方中未被確認的數(shù)據(jù)量（即in flight 數(shù)據(jù)量）不會超過CongWin（擁塞窗口）和RcvWindow（接收窗口）中的最小值，即LastByteSend-LastByteAcked<=minCongWin,RcvWindow。同時，在第9題中看到，接收方通告給發(fā)送方的窗口大小并沒有遏制發(fā)送速率。因此，未被確認的數(shù)據(jù)量（即in flight 數(shù)據(jù)量），是由擁塞窗口決定的，所以通過發(fā)出而未被確認的數(shù)據(jù)量（即in flight 數(shù)據(jù)量），我們可以估計擁塞窗口大小的下界。下表列出了部分in flight 數(shù)據(jù)量，從表中可以看出擁塞窗口的下界>=9015(因為in flight data 從未超過9015)。 但是，從第10題（即從時間序號圖）得，沒有分組丟失（不管是超時，還是三個冗余ACK），因此無法判斷什么時候慢啟動結(jié)束，擁塞避免階段開始。Ty