The idea
Labs 1 and 2 looked at frames, ARP, ICMP and IP. Lab 3 moves up to the transport and application layers. Phase 1 uploads a 150KB text file to a server and then reads the resulting TCP segments: the handshake, the sequence and acknowledgement numbers that give reliable delivery, the receiver’s advertised window, and the shape of the sender’s window over time.
Phase 2 goes up one more layer and opens HTTP messages directly. You fetch a tiny page, then the same page twice to see caching, then a long page that cannot fit in one segment, then a page with images on other servers, then a password-protected page. Each step changes one thing so you can see its effect in the capture.
Where marks get lost
This page does not contain the answers
Lab 3 is assessed group work. So what follows is what each question is testing, which topic on this site explains the concept, and where in the capture the evidence lives. The values themselves come from the trace you open, and finding them is the exercise.
What you need
- Wireshark, running on a live connection, or the provided trace files
from
wireshark-traces.zip - For Phase 1, the file
alice.txtfrom the lab sheet’s download link, and the upload form page it points to - For Phase 2, only a browser with its cache cleared before each fetch. The sheet gives a separate URL for each section
- The sheet strongly recommends the zip trace
tcp-ethereal-trace-1for Section 1 TCP Q4 to Q15 - The textbook reference is Kurose & Ross, 8th edition: TCP pp. 257 to 285, three-way handshake pp. 279 to 280, PSH p. 261, congestion control pp. 293 to 303, HTTP pp. 125 to 145
- Two shortcuts from the sheet: Statistics, Flow Graph, TCP flow draws the whole exchange as a time diagram, and Follow TCP stream (right click a packet) filters to one connection
Aside
The trace files for the other sections are named on the sheet as
http-ethereal-trace-1 to http-ethereal-trace-5, in the same zip that
Labs 1 and 2 used. Where a section has no trace, the sheet’s own fetch steps
are the only source.
Phase 1, TCP
How it works
Capture a bulk transfer, then read it as TCP
You upload with HTTP POST, not GET, because the lab needs a lot of data going
from your computer to the server. Filter on tcp first. You will see a
three-way handshake, the POST, a run of data segments, and ACKs coming back.
The sheet then tells you to turn off the HTTP protocol under Analyze, Enabled Protocols, so the packet list shows TCP segments instead of HTTP lines. The “HTTP Continuation” or “[TCP segment of a reassembled PDU]” rows are one HTTP message spread over several segments, not an HTTP feature.
The mechanisms behind every question are on TCP Segment and Numbering, TCP Connection Lifecycle, TCP Flow and Error Control and TCP Congestion Control.
Section 2, a first look at the trace
| Q | What it tests | Where to look |
|---|---|---|
| 1 | Identifying the client end of the connection | Select an HTTP segment, expand the Internet Protocol layer for the address and the TCP layer for the port. Ports are covered on Transport Services and Ports |
| 2 | Identifying the server end, including the port it sends and receives on | The same two layers, read on the segments going the other way |
| 3 | Q1 repeated on your own capture. Optional per the sheet | Your own trace, same method as Q1 |
Section 3, TCP basics
| Q | What it tests | Where to look |
|---|---|---|
| 4 | The SYN segment: its sequence number, and what field marks it as a SYN | The TCP layer's flags on the first segment of the connection. See TCP Connection Lifecycle and TCP Segment and Numbering |
| 5 | The SYNACK: its sequence number, its acknowledgement field, how the server arrived at that acknowledgement value, and what marks it as a SYNACK | The second segment of the handshake. The relationship between a sender's sequence number and the reply's acknowledgement number is on TCP Segment and Numbering |
| 6 | Finding the segment that carries the POST command | The sheet says to dig into the packet bytes at the bottom of the Wireshark window and look for the text POST in the data field |
| 7 | Per-segment RTT and a running EstimatedRTT for the first six segments, taking the POST segment as the first | Sent time and the time its ACK arrived, for each of the six. The weighted-average equation is printed on the sheet, and the sheet names Statistics, TCP Stream Graph, Round Trip Time Graph as a cross-check. Background on RTT estimation is on TCP Flow and Error Control |
| 8 | Segment length of those same six segments | The TCP length of each segment. Footnote 4 on the sheet explains why a standard Ethernet link keeps the segment under a limit, and the same MTU idea appears on Fragmentation |
| 9 | The receiver's advertised window, and whether it ever throttled the sender | The window field in the TCP layer across the trace. Flow control is on TCP Flow and Error Control |
| 10 | Whether any segment was retransmitted, and what you checked to decide | Sequence numbers over time. The question asks what you checked, so say what you compared |
| 11 | How much data one ACK typically covers, and whether the receiver ever ACKs every other segment | The acknowledgement number step between consecutive ACKs. The sheet points at Table 3.2 on p. 274 of the textbook for the receiver rules |
| 12 | Throughput of the whole transfer, and how you calculated it | Bytes transferred divided by the time taken, from the first and last data segments. The question asks you to show your method |
Where marks get lost
Q7 is a calculation with a stated starting point
The sheet fixes how EstimatedRTT starts and which equation applies after that. If your numbers drift from your neighbour’s, check which segment you treated as first and whether you used the SampleRTT of the right segment at each step, before suspecting the trace.
Section 4, congestion control in action
| Q | What it tests | Where to look |
|---|---|---|
| 13 | Locating slow start, its end, and where congestion avoidance takes over, then saying where the real trace differs from the textbook picture | The Time-Sequence-Graph (Stevens). Slow start and congestion avoidance are on TCP Congestion Control, which gives the idealised version the question asks you to compare against |
| 14 | Repeating the analysis on your own capture. Optional per the sheet | Your own trace. The sheet words this as "each of two questions above" without saying which two. Q13 is the only analysis question in that section, so treat it as Q13 on your trace |
Aside
The sheet’s supplementary notes say “Section 1 TCP Q4-15”, but the numbered questions end at 14. Nothing is missing from the page; the range is just one too high. Whether a Q15 exists in another version of the sheet is not something this site can confirm.
Phase 2, HTTP
How it works
Same protocol, four things changed one at a time
Filter the capture on http for every section. Each section isolates one
HTTP behaviour: the basic exchange and its headers, a conditional request, a
body too large for one segment, and a page that pulls in other objects. All of
these are covered on HTTP and Web Caching.
The authentication section is a short extension of the same message format.
Ignore any request for favicon.ico in your capture. The sheet explains it is
the browser asking for a small icon and tells you to disregard it.
Section 1, the basic GET and response
| Q | What it tests | Where to look |
|---|---|---|
| 1 | HTTP version used by each side | The request line of the GET and the status line of the response |
| 2 | What the client says it can accept | The request headers sent by the browser |
| 3 | Addresses of the two ends | The IP layer of the same packets, as in Lab 1 and Lab 2 |
| 4 | The status code in the response | The status line. Codes are listed on HTTP and Web Caching |
| 5 | When the object last changed on the server | A response header. Read the sheet's note after Q7 before concluding anything about the value, because this particular file is rewritten on a timer |
| 6 | Size of the returned content | A response header |
| 7 | Whether the raw bytes contain headers the packet list does not show | The packet content pane at the bottom of Wireshark, read against the decoded HTTP lines above it |
Section 2, the conditional GET
Clear the browser cache, load the page, then load it again straight away.
| Q | What it tests | Where to look |
|---|---|---|
| 8 | Whether a first request carries a conditional header | The first GET's request headers |
| 9 | Whether the server sent the object body, and how you can tell | The response to the first GET |
| 10 | Whether the second request carries the conditional header, and what follows it | The second GET's request headers, compared with a header in the first response |
| 11 | The status code and phrase on the second response, and whether a body came back | The second response. Caching and the conditional GET mechanism are on HTTP and Web Caching |
Section 3, a long document
| Q | What it tests | Where to look |
|---|---|---|
| 12 | How many GET requests were sent, and which packet number holds the one for this page | The packet list, filtered on HTTP |
| 13 | Which packet carries the status line and phrase for the response | The packet list |
| 14 | The status code and phrase | The response status line |
| 15 | How many data-carrying TCP segments the single response needed | Count the segments that carry the body. Why one HTTP message splits across several segments is the same MSS idea from Phase 1, on TCP Segment and Numbering |
Section 4, embedded objects
| Q | What it tests | Where to look |
|---|---|---|
| 16 | How many GETs the page triggered, and which addresses they went to | The request lines and the destination address of each. The page references objects on a second server, so expect more than one destination |
| 17 | Whether the two images were fetched one after the other or in parallel, and how you know | The timing and order of the two GETs and their responses. Serial and parallel connections are compared on HTTP and Web Caching |
Section 5, authentication
| Q | What it tests | Where to look |
|---|---|---|
| 18 | How the server answers an unauthenticated request | The first response's status line |
| 19 | The new field the browser adds when it retries | Compare the second GET's headers with the first |
Where marks get lost
Encoded is not encrypted
The sheet shows that the credentials in the second request are only Base64-encoded and that anyone can decode them. The point to take from the exercise is the conclusion the sheet draws: capture from any machine on the path exposes them, so Basic authentication alone does not protect a password. Say that in your own words, with your own capture as the evidence.
What the marker wants
The Lab 3 sheet itself repeats only the report limits. The marking scheme is the one in the unit’s lab admin document, shared by every lab:
| Criterion | Marks | What it covers |
|---|---|---|
| Presentation and format | 1 | Writing clarity, grammar, report structure, template adherence, page limit |
| Experiments (Phase 1 and 2) | 7 | Answer quality, understanding of concepts, completeness of evidence |
Report requirements, from the sheet:
- Maximum 7 pages, title page included
- Follow the Canvas template
- The final report states your overall learning experience and main results
- Answering the numbered questions during the lab is how you learn the material. The sheet says they do not all have to appear in the final report
- For each answer, print the packet or packets you used and annotate them so it is clear where the answer came from. The sheet defines annotate as highlighting the relevant part and adding text beside it
- Print only the minimum packet detail the question needs
In the exam
The rubric rewards linking what you captured to what the lectures taught. For the TCP questions that means saying why a number is what it is, such as how the acknowledgement value follows from the sequence number, not just reading it off. For the congestion control question, the sheet asks you to comment on how the measured trace differs from the idealised behaviour, so a report that only labels two phases and stops has not answered it.