Packet analysis lab 8 of 12
Application performance: server delay against network delay
Three slow applications cross the same 100 ms link, each slow for a different reason. You measure the network's round trip, then show that one page waits on the server, one waits on dozens of round trips, and one is held back by a small receive window, using http.time, iRTT, the I/O graph and the tcptrace graph.
Run this lab
It needs Lite: its 3 nodes are set to 3 vCPU and 2,560 MB in total. That fits the free demo too.
In your workspace: Shared, then Packet analysis with Wireshark and tcpdump guided labs, then 08 - Application performance - server delay against network delay
- Level
- Advanced
- Time
- About 70 minutes
- Nodes need
- 3 vCPU, 2,560 MB
- Smallest plan
- Lite
The scenario
The Kendal shop says three things are "slow": the daily sales report page, the online catalogue on the kiosk, and the stock-sync tool that downloads the stock file. They all use the head-office application server SRV across a link with about 100 ms of round-trip time (WAN). There's no packet loss on this link, so "the network is slow" can only mean the round trip. Your job is to show, with packets, what each one is waiting for.
| Device | Interface | Address | Role |
|---|---|---|---|
| WS | eth0 | 10.90.0.10/24 | your workstation; runs curl, catalogue and stock-sync |
| WAN | eth0 ↔ eth1 | bridge, no address | adds 50 ms in each direction |
| SRV | eth0 | 10.90.0.20/24 | the shop's web application |
Your workstation, WS. Open WS's console (a remote desktop, root / eve), start Wireshark from Applications > Internet > Wireshark, and open a terminal. Write answers in /root/answers.txt (pluma /root/answers.txt &).
What you’ll practise
- Separate server response time from network round-trip time in a capture
- Show how round-trip time multiplies in chatty request and response applications
- Explain window-limited throughput (window divided by round-trip time) and spot it in a stream graph
- Use http.time, tcp.analysis.initial_rtt, tcp.analysis.ack_rtt and bytes in flight as columns and filters
- Turn the evidence into a clear statement of who must fix what
The tasks
- Recreate the link
- Capture the three complaints
- Server delay or network delay?
- Death by round trips
- The window that holds back stock-sync
The Lab Tasks pane has the scenario, these tasks, the checks to run, hints and the full solution.
Topology and devices
The network as it opens in EVE-NG, drawn from the lab’s own canvas, and the image each node runs.
Every link, as text
- WS
eth0to WANeth0 - WAN
eth1to SRVeth0
| Node | Device | Image in Add Node | Set to |
|---|---|---|---|
| WS | EVE-NG GUI server (Docker) | eve-gui-server:latest | 1 vCPU, 1,024 MB |
| WAN | Alpine WAN emulator | clbalpinewanem-alpine-wanem-3-20-3 | 1 vCPU, 512 MB |
| SRV | EVE-NG GUI server (Docker) | eve-gui-server:latest | 1 vCPU, 1,024 MB |
How to open this lab
Sign in to your workspace at
lab.cloudlabbox.com.In File Manager, open Shared, then the folder
Packet analysis with Wireshark and tcpdump guided labs.Open
08 - Application performance - server delay against network delayand start its nodes, then open Lab Tasks for the scenario and the steps.
The lab is read-only. You can start the nodes and configure the devices, but changes to the topology can’t be saved. To change it, rebuild it in your own folder.
More Packet analysis labs
Related labs in other courses
CloudLabBox is independent of the Wireshark Foundation, CompTIA and Cisco. The lab follows exam topics and isn’t vendor training material; vendor names identify the exams and the images in the workspace.