Computer communication EDA343/DIT420 Lab 1

Transcription

1 Computer communication EDA343/DIT420 Lab 1 Packet and Traffic Analysis Using Network Sniffing Software 1. There are three assignments in this course. First two assignments are in form of programming or network software experiment labs whereas the third assignment is in form of a written report. For each assignment there will be a fixed deadline as mentioned in the submission system. This is the PM of the first lab. 2. You may work in groups of max 2 students per group and computer. 3. Completed lab work must be reported with answers of the questions embedded in the lab tasks. The report must be posted to pingpong before the deadline. Please read through this PM before attending the lab session and make sure that you are prepared to use Wireshark. This lab is including adopted and selected parts from the Wireshark Labs which can be downloaded from the course book home page: ( Student resources / Wireshark labs ). Wireshark is popular network protocol analyzer and it is available to download using under the GNU General Public License. Purpose: To learn how to listen to network traffic and analyze different protocols as well as learning to use some useful system utilities. Background reading: Read related sections in Chapter 2 (Application) and Chapter 3 (Transport), please see below the outlined sections of the course book. Preparation: Either at home using your own installation of the software or at campus using the computers of the lab rooms J232 (Gnistan) and J234 (Bryggan), floor 2 in Jupiter building; prepare by yourself the first part of the exercises (Getting Started with Wireshark) to be familiar with the program and its usage; please refer to the Wireshark Lab at the end of Chapter 1 in the course book. The following lab parts are the ones that should be performed fully during the lab sessions. 1. Getting Started with Wireshark (prepared before the lab session) 2. HTTP (section 2.2) 3. DNS (section 2.5) 4. TCP (sections 3.5 and 3.7) For those who wish and who have some time, you may also perform by yourself the following optional labs at home: Page 1

2 Useful and practical information You will be working in the Windows environment but the instructions include as well the Linux environment. To facilitate the work, a small list of things to think about and practical information is found next on this page. Time estimation: Estimate about little bit more than one hour for each part of lab (they are three HTTP lab, DNS lab and TCP lab). Try to understand all topics before continuing with the next part! Bring the book: You will most likely have to consult the book about various topics, so make sure each group has at least one book available! Using Wireshark on computers in lab room: You are going to use the Chalmers studat-computers located in Jup232 (Gnistan) and Jup234 (Bryggan). When coming to the lab, you must log into the machine in front of you using operating system Windows. Use your Chalmers student account to log in. You are going to get some root privileges on these computers that allow you to perform the lab tasks using Wireshark. Ordinary studat-users are not allowed to capture network traffic. Note: In any other Studat-computer rooms Wireshark must run with administrator (root) privileges. If you just start Wireshark, you will get an error message permission denied when trying to capture packets. Using traces: The book resources include traces files for the Wireshark labs. You may use these prerecorded trace files at home but not during the lab session. Please note; do not use any trace file during the lab exercises, since you are able to run Wireshark on a live network connection in the lab room. You should use your own outworked trace. Manuals and on-line help: If you need help about a command, you can ask the system in Linux by giving the command man command in a terminal window. In Windows use the help parameter /? To get help, for example enter C:\> ipconfig /?. Web browser: When using web browser you may need to clean the cache as outlined in the text of the instructions depending on which browser is in use. DNS: In addition to the nslookup command, you can experiment with the host command. Also, note that the Linux ifconfig has different arguments than Windows ipconfig. In order to flush DNS-cache use the command sudo /etc/init.d/nscd restart as it is outlined in the text of the instructions. Page 2

3 HTTP (March 2012) Adopted from Wireshark Labs 2009 J.F. Kurose, K.W. Ross. All Rights Reserved Computer Networking: A Top down Approach, 5th edition. In this lab, you ll explore several aspects of the HTTP protocol; the basic GET/response interaction, HTTP message format, retrieving large HTML files, retrieving HTML files with embedded objects, and optional HTTP authentication and security. Before beginning these labs, you might want to review section 2.2 of the book. 1. The Basic HTTP GET/response interaction Let s begin the exploration of HTTP by downloading a very simple HTML file; one that is very short, and contains no embedded objects. Do the following: Start up your web browser. Start up the Wireshark packet capture, as described in the introductory lab (but don t yet begin packet capture). Enter the string http in the Filter-field (or in the display-filterspecification window), then press the button Apply so that only captured HTTP messages will be displayed later in the packet-listing window. (We are only interested in the HTTP protocol here, and don t want to see the clutter of all captured packets). Start Wireshark packet capture. Enter the following to your browser: Your browser should display the very simple, one-line HTML file. Stop Wireshark packet capture. Wireshark will show in the packet-listing window that two HTTP messages are captured; the GET message (from your browser to the gaia.cs.umass.edu web server) and the response message from the server to your browser. The packet-contents window shows details of the selected message (in this case the HTTP GET message, when you highlight it in the packet-listing window). Recall that since the HTTP message was carried inside a TCP segment, which was carried inside an IP datagram, which was carried within an Ethernet frame, Wireshark displays the Frame, Ethernet, IP, and TCP header information as well. We want to minimize the amount of non-http data displayed (We are interested in HTTP here, and you will be investigating these other protocols in later labs), so make sure that the boxes at the far left of the Frame, Ethernet, IP and TCP information have a plus sign (which means there is hidden, not displayed information), and the HTTP line has a minus sign (which means that all information about the HTTP message is displayed). N o t e : You should ignore any HTTP GET and response for favicon.ico. There is no reference to this file in the html-page; it is your browser automatically asking the server if it (the server) has a small icon file that should be displayed next to the displayed URL in your browser. Just ignore the GET/response messages of this file. Page 3

4 By looking at the information in the HTTP GET and response messages, answer the following questions. When answering, you should inspect the fields of the GET and response messages to indicate where in the message you ve found the information about answers. 1. What is the IP address of your computer? 2. What HTTP version is your browser running? What version is the server running? 3. What languages (if any) does your browser indicate to the server that it can accept? 4. What is the status code returned from the server to your browser? 5. When was the HTML-file that you are retrieving last-modified at the server? 6. How many bytes of content are being returned to your browser? 7. By inspecting the raw decoded data in the packet-contents window, compare the header lines with those that are displayed in the protocol-contents window, are they the same? N o t e : In your answer to question 5 above, you might have been surprised to find that the document you just retrieved was last modified within a minute before you downloaded the document. That s because (for this particular file), the gaia.cs.umass.edu server is setting the file s last-modified time to be the current time, and is doing so once per minute. Thus, if you wait a minute between accesses, the file will appear to have been recently modified, and hence your browser will download a new copy of the document. 2. The HTTP CONDITIONAL GET/response interaction Recall from Sections of the book, that most web browsers perform object caching and thus perform a conditional GET when retrieving an HTTP object. Before performing the steps below, make sure your browser s cache is empty. (To do this under Firefox, select Tools Clear Recent History, or for Internet Explorer, select Tools Internet Options General Tab Clear History; these actions will remove cached files from your browser s cache.) Now do the following: Start up your web browser, and make sure your browser s cache is cleared, as explained above. Start up the Wireshark packet capture, and enter http in the Filter-field as before. Enter the following URL into your browser Your browser should display a very simple five-line HTML file. Quickly enter the same URL into your browser again (or simply select the refresh button on your browser). Stop Wireshark packet capture. Answer the following questions: 8. Inspect the contents of the first HTTP GET request from your browser to the server. Is the request indicating conditional GET? 9. Inspect the contents of the server response. Does the server explicitly return the contents of the file? How can you tell? 10. Now inspect the contents of the second HTTP GET request from your browser to the server. Which HTTP header line does the request indicate conditional GET? 11. What is the HTTP status code and phrase returned from the server in response to this second HTTP GET? Does the server explicitly return the contents of the file? Explain. Page 4

5 3. Retrieving Long Documents In our examples thus far, the documents retrieved have been simple and short HTML files. Let s next see what happens when you download a large HTML file. Do the following: Start up your web browser, and make sure your browser s cache is cleared, as discussed above. Start up the Wireshark packet capture, and enter http in the Filter-field as before. Enter the following URL into your browser Your browser should display the rather lengthy US Bill of Rights. Stop Wireshark packet capture. In the packet-listing window, you should see the HTTP GET message, followed by a multiplepacket response to your HTTP GET request. This multiple-packet response deserves a bit of explanation. Recall from Section 2.2 (see Figure 2.9 in the book) that the HTTP response message consists of a status line, followed by header lines, followed by a blank line, followed by the entity body. The entity body in the response is the entire requested HTML file. In our case here, the HTML file is rather long, and at 4500 bytes is too large to fit in one single TCP segment or one IP packet. The single HTTP response message is thus broken into several pieces by TCP, with each piece being contained within a separate TCP segment. (Each TCP segment may be recorded as a separate packet by Wireshark or a number of segments are reassembled and the former will also be indicated by the Continuation phrase displayed by Wireshark. It should be clear here that there is no Continuation message in HTTP!). Please check Wireshark Preferences Protocols HTTP to see what options to choose in order to suppress reassembly of segments. Answer the following questions: 12. How many HTTP GET request messages are sent by your browser? 13. How many data-containing TCP segments are needed to carry the single HTTP response? 14. What is the status code and phrase associated with the response to the HTTP GET request? 15. Are there any HTTP status-lines in the transmitted data associated with a TCP-induced Continuation? 4. HTML Documents with Embedded Objects Now that you ve seen how Wireshark displays the captured packet traffic for large HTML files, you can look at what happens when your browser downloads a file with embedded objects, i.e., a file that includes other objects (in the example below, image files) that are stored on other servers. Do the following: Start up your web browser, and make sure your browser s cache is cleared. Start up the Wireshark packet capture and enter http in the Filter-field as before. Enter the following URL into your browser Stop Wireshark packet capture. Your browser should display a short HTML file with two images. These two images are referenced in the base HTML file. That is, the images themselves are not contained in the HTML; instead the URLs for the images are contained in the downloaded base HTML file. As discussed in the book, your browser will have to retrieve these logos from the indicated web sites. The publisher s logo is retrieved from the web site. The image of the course book s cover is stored at the server. Page 5

6 Answer the following questions: 16. How many HTTP GET request messages are sent by your browser? To which Internet addresses are these GET requests sent? 17. Can you tell whether your browser downloaded the two images serially, or whether they are downloaded from the two web sites in parallel? Explain. 5. HTTP Authentication (Optional) Finally, let s try visiting a web site that is password-protected and examine the sequence of HTTP messages exchanged for such a site. So let s access this secure password-protected site. Do the following: Start up your browser and make sure that the browser s cache is cleared, as before. Start up the Wireshark packet capture. Enter the following URL into your browser This URL is password protected. The username is wireshark-students and the password is network. Type the requested user name and password into the pop up box. Stop Wireshark packet capture, and enter http in the display-filter-specification window, so that only captured HTTP messages will be displayed later in the packet-listing window. Now let s examine the Wireshark output. You might want to first read up on HTTP authentication by reviewing the easy-to-read material on HTTP Access Authentication Framework at Answer the following questions: 18. What is the server s response (status code and phrase) in response to the initial HTTP GET message from your browser? 19. When your browser s sends the HTTP GET message for the second time, what new field is included in the HTTP GET message? The username (wireshark-students) and password (network) that you entered are encoded in the string of characters (d2lyzxnoyxjrlxn0dwrlbnrzom5ldhdvcms=) following the Authorization: Basic header in the client s HTTP GET message. While it may appear that your username and password are encrypted, they are simply encoded in a format known as Base64 format. The username and password are not encrypted! To see this, go to decoder web page Enter the base64- encoded string d2lyzxnoyxjrlxn0dwrlbnrz and press decode. Voila! You have translated from Base64 encoding to ASCII encoding, and thus should see your username! To view the password, enter the remainder of the string Om5ldHdvcms= and press decode. Since anyone can download a tool like Wireshark and sniff packets (not just their own) passing by their network adapter, and anyone can translate from Base64 to ASCII (you just did it!), it should be clear to you that simple passwords on WWW sites are not secure unless additional measures are taken. Fear not! As you will see in Chapter 7, there are ways to make WWW access more secure. However, you ll clearly need something that goes beyond the basic HTTP authentication framework! Page 6

7 DNS (March 2012) Adopted from Wireshark Labs 2009 J.F. Kurose, K.W. Ross. All Rights Reserved Computer Networking: A Top down Approach, 5th edition. As described in section 2.5 of the book, the Domain Name System (DNS) mainly translates hostnames to IP addresses, fulfilling a critical role in the Internet infrastructure. In this lab, you ll take a closer look at the client side of DNS. Recall that the client s role in the DNS is relatively simple; a client sends a query to its local (cache-only) DNS server, and receives a response back. As shown in Figures 2.21 and 2.22 in the book, much can go on under the covers invisible to the DNS clients, as the hierarchical DNS servers communicate with each other to either recursively or/and iteratively resolve the client s DNS query. From the DNS client s standpoint, however, the protocol is quite simple; a query is formulated to the local DNS server and a response is received from that server. Before beginning this lab, you ll probably want to review DNS by reading Section 2.5 of the book. In particular, you may want to review the material on local DNS servers, DNS caching, Resource Records and DNS message format. 1. nslookup In this lab, you ll make extensive use of the nslookup tool, which is available in most Linux/Unix and Microsoft platforms today. To run nslookup in Linux/Unix, you open a terminal window and just enter the nslookup command on the command line. To run it in Windows, open the Command Prompt and run nslookup on the command line. The general syntax of nslookup command is: nslookup option1 option2 host-to-find dns-server In general, nslookup can be run with zero, one, two or more options. And as you will see in the following examples, the dns-server is optional as well; if it is not supplied, the query is sent to the default local DNS server. In its most basic operation, nslookup tool allows the host to query any specified DNS server for a DNS record. The queried DNS server can be a root DNS server, a Top-Level- Domain DNS server, an authoritative DNS server, or an intermediate DNS server (see the book for definitions of these terms). To accomplish this task, nslookup sends a DNS query to the specified DNS server, receives a DNS reply from that same DNS server, and displays the result. Consider first the results by entering the command: nslookup In words, this command is saying please send me the IP address for the host When running nslookup, if no DNS server is specified, then nslookup sends the query to the default DNS server. The response from this server provides two pieces of information: (1) the name and IP address of the DNS server that provides the answer; and (2) the answer itself, which is the host Page 7

8 name and IP address of Although the response will come from the local DNS server at the Chalmers University (probably res1.chalmers.se), it is quite possible that this local DNS server iteratively contacted several other DNS servers to get the answer, as described in Section 2.5 of the book. Now consider the results by entering a second command: nslookup -type=ns mit.edu In this example, you provide the option -type=ns and the domain mit.edu. This causes nslookup to send a query for a type NS record to the default local DNS server. In words, the query is saying, please send me the host names of the authoritative DNS for mit.edu. (When the -type option is not used, nslookup uses the default, which is to query for type A records.) The answer will first indicate the DNS server that is providing the answer (which is the default local DNS server) along with three MIT name servers. Each of these servers is indeed an authoritative DNS server for the hosts on the MIT campus. However, nslookup also indicates that the answer is nonauthoritative, meaning that this answer came from the cache of the local server rather than directly from an authoritative MIT DNS server. Finally, the answer also includes the IP addresses of the authoritative DNS servers at MIT. (Even though the type-ns query generated by nslookup did not explicitly ask for the IP addresses, the local DNS server returned these for free and nslookup displays the result.). Finally consider a third command: nslookup bitsy.mit.edu In this example, you indicate that you want the query to be sent to the DNS server bitsy.mit.edu rather than to the default local DNS server. Thus, the query and reply transaction takes place directly between your querying host and bitsy.mit.edu. In this example, the DNS server bitsy.mit.edu recursively provides the IP address of the host which is a web server at the Advanced Institute of Information Technology (in Korea). Do the following (and write down your commands and the results): 1. Run nslookup to obtain the IP address of a Web server in Asia. 2. Run nslookup to determine the authoritative DNS servers for a university in Europe. 3. Run nslookup to determine the mail servers for Yahoo! 2. ipconfig/ifconfig The commands ipconfig (for Windows) and ifconfig (for Linux/Unix) are among the most useful little utilities in your host, especially for debugging network issues. ipconfig or ifconfig can be used to show host current TCP/IP information, including IP address, adapter type and so on. For example, if you want all this information about your host, just enter: C:\> ipconfig /all into the Command Prompt, in Windows $ /sbin/ifconfig into a terminal, in Linux In Section 2.5 you learned that a host can cache DNS records it recently obtained. To clear the cache, enter: C:\> ipconfig /flushdns into the Command Prompt, in Windows $ sudo /etc/init.d/nscd restart into a terminal, in Linux. Flushing or restarting the DNS cache clears all entries and reloads the entries from the hosts file. Page 8

9 3. Tracing DNS with Wireshark Now that you are familiar with nslookup and ipconfig/ifconfig, you re ready to get down to some serious business. Let s first capture the DNS packets that are generated by ordinary Web surfing activity. Use the appropriate command to empty the DNS cache in your host. Open your browser and empty the browser cache. Start Wireshark and enter ip.addr = = your_ip_address into the Filter-field, where you find out your_ip_address using ipconfig/ifconfig. This filter removes all packets that neither originate nor are destined to your host. Start packet capture in Wireshark. With your browser, visit the Web page: Stop packet capture. Answer the following questions: 4. Locate the DNS query and response messages. Are they sent over UDP or TCP? 5. What are the source and the destination ports used for the DNS query and response messages? 6. To what IP address is the DNS query message sent? Is this the IP address of your local DNS server? Use ipconfig /all in Windows, or enter the command cat /etc/resolv.conf in Linux to determine the IP address of your local DNS server. 7. Examine the DNS query message. What Type of DNS query is it? Which information fields sections are there in the query message? 8. Examine the DNS response message. How many sections are provided? What does each of these fields contain? 9. Consider the subsequent TCP SYN packet sent by your host. Does the destination IP address of the SYN packet correspond to any of the IP addresses provided in the DNS response message? 10. This web page contains images. In order to retrieve each image a GET message is sent with the host name does your host issue new DNS queries to resolve it? Why? Now let s examine DNS messages using nslookup. Start packet capture. Type and execute the command: nslookup bitsy.mit.edu Stop packet capture. You should now get a packet trace where nslookup actually sent three DNS queries and received three DNS responses. For the purpose of this assignment, in answering the following questions, you should focus on the desired query and response messages to translate the hostname. Please ignore any other sets of queries/responses, as they are specific to the DNS configuration of the host and are not normally generated by standard Internet applications. Answer the following questions: 11. To what IP address is the DNS query message sent? Is this the IP address of your default local DNS server? If not, what does the IP address correspond to? 12. Examine the DNS query message. What Type of DNS query is it? Does the query message contain any sections? 13. Examine the DNS response message. How many answers are provided? What does each of these answers contain? Page 9

10 TCP (March 2012) Adopted from Wireshark Labs 2009 J.F. Kurose, K.W. Ross. All Rights Reserved Computer Networking: A Top down Approach, 5th edition. In this lab, you ll investigate the behaviour of TCP in detail. You ll do so by analyzing a trace of the TCP segments sent and received when transferring a 150 Kbyte file (containing the text of Lewis Carroll s Alice s Adventures in Wonderland) from your computer to a remote server. Before beginning this lab, you ll probably want to review sections 3.5 and 3.7 in the book. You are going to: Study TCP s use of sequence and acknowledgement numbers for providing reliable data transfer, Consider briefly TCP connection setup Look at TCP s receiver-advertised flow control mechanism. Investigate the performance (throughput and round-trip time) of the TCP connection between your computer and the server. See TCP s congestion control algorithm; slow start and congestion avoidance in action, 1. Capturing a bulk TCP transfer from your computer to a remote server Before beginning the exploration of TCP, you ll need to use Wireshark to obtain a packet trace of the TCP transfer of a file from your computer to a remote server. You ll do so by accessing a Web page that will allow you to enter the name of a file stored on your computer (which contains the ASCII text of Alice Adventures in Wonderland), and then transfer the file to the Web server using the HTTP POST method (see section in the book). You re using the POST method this time rather than the GET method because you d like to transfer a large amount of data from your computer to a Web server. Of course, you ll be running Wireshark during this time to obtain the trace of the TCP segments sent and received from your computer. Do the following: Start up your web browser. Go the and retrieve an ASCII copy of Alice Adventure in Wonderland. Store this file somewhere on your computer. Next go to You should see a screen that looks like: Page 10

11 Use the Browse button in this form to enter the name of the file (full path name) on your computer containing Alice Adventure in Wonderland (or do so manually). Don t yet press the Upload alice.txt file button. Now start up Wireshark and begin packet capture. Returning to your browser, press the Upload alice.txt file button to upload the file to the gaia.cs.umass.edu server. Once the file has been uploaded, a short congratulations message will be displayed in your browser. Stop Wireshark packet capture. 2. A first look at the captured trace Before analyzing the behaviour of the TCP connection in detail, let s take a high level view of the trace. Since this lab is about TCP rather than HTTP, let s change Wireshark s listing of captured packets window so that it shows information about the TCP segments containing the HTTP messages, rather than about the HTTP messages. To do so; filter the packets displayed in the Wireshark window by entering tcp in the Filter field and then press the button Apply. You should now see a series of TCP segments sent between your computer and gaia.cs.umass.edu. You will use this packet trace that you have captured to study TCP behaviour in the rest of this lab. You should see the initial three-way handshake containing SYN/ACK messages. Then you should see an HTTP POST message and a series of HTTP Continuation segments being sent from your computer to gaia.cs.umass.edu. Recall from a previous discussion in the earlier HTTP Wireshark lab, that there is no such thing as an HTTP Continuation message. This is Wireshark s way of indicating that there are multiple TCP segments being used to carry a single HTTP message. You should also see TCP ACK segments being returned from gaia.cs.umass.edu to your computer. Whenever possible, you should indicate which packet(s) within the trace that you used to answer the question and explain your answer. Answer the following questions: 1. What is the IP address and TCP port number used by your computer (source)? 2. What is the IP address of gaia.cs.umass.edu? On what port number is it sending and receiving TCP segments for this connection? Page 11

12 3. TCP Basics Answer the following questions for the TCP segments: 3. Identify the TCP segments that are used to initiate the TCP connection between your computer and gaia.cs.umass.edu. What are the initial sequence numbers being used? For each one, what is in the segment that identifies it as an initial connection segment? 4. What is the value of the ACKnowledgement field in each of these initial segments? How does each side determine that value? What is; in the segment, that identifies it as a ACK segment? 5. What is the sequence number of the TCP segment containing the HTTP POST method? Consider the first TCP segment containing HTTP in this connection. Note that in order to find the POST command; you ll need to dig into the packet content field at the bottom of the Wireshark window, looking for a segment with a POST within its data field. 6. What are the sequence numbers of the first six segments in the TCP connection (following the segment containing the HTTP POST)? At what time is each segment sent? When is the ACK for each segment received? Make a table of these values. 7. Given the difference between when each TCP segment is sent, and when its acknowledgement is received, what is the RTT value for each of the six segments? What is the Estimated RTT value after the receipt of each ACK? Assume that the value of the Estimated RTT is equal to the measured RTT for the first (POST) segment, and then the Estimated RTT is computed using the Estimated RTT equation (given in Section in the book) for all subsequent segments. Complete the table in your answer for Q.6. N o t e : Wireshark has a nice feature that allows you to plot the RTT for each of the TCP segments sent. Select a TCP segment that is being sent from your computer to the gaia.cs.umass.edu server in the listing of captured packets window. Then select: Statistics TCP Stream Graph Round Trip Time Graph. 8. What is the length of data in each of these six TCP segments? 9. What is the minimum amount of available buffer space advertised by the receiver for the entire trace? Does the lack of receiver buffer space ever throttle the sender? 10. Are there any retransmitted segments in the trace file? What do you check for (in the trace) in order to answer this question? 11. How much data does the receiver typically acknowledge in an ACK? Can you identify cases where the receiver is ACKing every other received segment (see Table 3.2 in the book). 12. What is the overall throughput (in kbps) for the whole TCP connection? Explain how you have calculated this value. N o t e : The TCP segments are all equal or less than 1460 bytes. This is because the computer has an Ethernet card that limits the length of the maximum IP packet (MTU) up to 1500 bytes (40 bytes of TCP/IP header data and 1460 bytes of TCP payload). This 1500-byte value is the standard maximum length allowed by Ethernet. 13. In order to see the TCP flow graphically; select a TCP segment in the listing of captured packets window and then select the menu Statistics Flow Graph. Choose flow type TCP flow. Now by using this TCP flow graph you may verify your answers of the above questions Q Page 12

13 4. TCP Congestion Control Let s now examine the amount of data sent per unit time from your computer to the server. Rather than (tediously!) calculating this from the raw data in the Wireshark window, you ll use one of Wireshark s TCP graphing utilities; Time-Sequence Graph (Stevens) to plot out data. Select a TCP segment in the Wireshark s listing of captured-packets window. Then select the menu Statistics TCP Stream Graph Time-Sequence Graph (Stevens). You should see a plot of the segments sent per time. In this graph; each dot represents a TCP segment sent, and the utility is plotting the sequence number of the segment versus the time at which it was sent. Note that a set of dots stacked above each other represents a series of packets that are sent backto-back by the sender. Answer the following questions: 14. Using sequence-time plot of the segments being sent from your computer to the gaia.cs.umass.edu server; can you identify where TCP s slow start phase begins and ends, and where congestion avoidance takes over? Include a copy of your plot and explain your answer with values from it. 15. Comment on ways in which the measured data differs from the idealized behaviour of TCP that you ve studied in the book. Page 13