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

1、計(jì)算機(jī)網(wǎng)絡(luò)實(shí)驗(yàn)報(bào)告三TCP實(shí)驗(yàn)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說明這是一個(gè)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.答：第四號(hào)報(bào)文段是包含 HTTP POST 命令的TCP segment.且報(bào)文段的序列號(hào)為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個(gè)報(bào)文段為No.4,5,7,8,10,1

11、1. 對(duì)應(yīng)的ACK分別為 No.6,9,12,14,15,16. 前6個(gè)報(bào)文段截圖如下：報(bào)文段的序列號(hào)為每個(gè)報(bào)文段的首字節(jié)加1，所以序列號(hào)為：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報(bào)文段的發(fā)送時(shí)間和相應(yīng)ACK 的到達(dá)時(shí)間如下表：: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接受到報(bào)文段1之后的EstimatedRTT為：EstimatedRTT=RTT for segm

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

14、0438+0.125*0.13989= 0.0558 second接受到報(bào)文段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個(gè)段的長度分別為：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ù)器端傳回的第一個(gè)ACK中的窗口大小。接收方的窗口大小沒有抑制發(fā)送方的傳輸速率，因?yàn)榇翱诖笮?840逐步增加到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報(bào)文段的序列號(hào)中可以得出以上結(jié)論。從上圖中的時(shí)間序號(hào)圖可以看出，從源端發(fā)往目的端的序號(hào)逐漸遞增，如果這其中有重傳的報(bào)文段，則其序號(hào)中應(yīng)該有小于其臨近的分組序號(hào)的分組，在圖中未看到這樣的分組，所以沒有被重傳的分組。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、在一個(gè)ACK確認(rèn)的數(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報(bào)文段確認(rèn)數(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 吞吐量計(jì)算很大程度上取決于所選內(nèi)容的平均時(shí)間。作為一個(gè)普通的吞吐量計(jì)算，在這問題上，選擇整個(gè)連接的時(shí)間作為平均時(shí)間段。然后，此TCP 連接的平均吞吐量為總的傳輸數(shù)據(jù)與總傳輸時(shí)間的比值。傳輸?shù)臄?shù)據(jù)總量為TCP 段第一個(gè)序列號(hào)（即第4 段的1 字節(jié)）和最后的序列號(hào)的ACK （第202 段的16409

19、1個(gè)字節(jié)）之間的差值。因此，總數(shù)據(jù)是 164091-1 = 164090 字節(jié)。整個(gè)傳輸時(shí)間是第一個(gè) TCP 段（即4號(hào)段0.026477 秒）的時(shí)間和最后的 ACK（即第202 段5.455830秒) 時(shí)間的差值。因此，總傳輸時(shí)間是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.答:慢啟動(dòng)階段即從HTTP P

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

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

23、0Data1049464380Data1164065840ACK1234864380Data1378665527ACK1440964917ACK1560063007ACK1678661147ACK1790130Data1890131460Data19104732920Data20119334380Data21133935840Data22148537300Data23163138192ACK24104736732ACK25119335272ACK26133933812ACK27148532352ACK2816313892ACK29172050Data30172051460Data3118665

24、2920Data32201254380Data33215855840Data34230457300Data35245058192ACK36186656732ACK37201255272ACK38215853812ACK39230452352ACK4024505892ACK41253970Data42253971460Data43268572920Data44283174380Data45297775840Data46312377300Data47326978192ACK48268576732ACK49283175272ACK50297773812ACK51312371752ACK5233589

25、0Data53335896732Data54350495272Data55365093812Data56379692352Data5739429892Data58408890ACK59350496732ACK60379693812ACK6140889892ACK62417810Data63417811460Data64432412920Data65447014380Data66461615840Data67476217300Data68490818192ACK69447015272ACK70476212352ACK71499730Data72499731460Data73514332920Da

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

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