TechKnowSurge
Cisco CCST Networking 5.2 Cisco CyberOps Associate 4.6 Cisco CyberOps Associate 4.7 Cisco CyberOps Associate 4.8 CompTIA Network+ 1.4 Cisco CCST Networking 1.5
VideoNetworkFree

DEMO: Web Protocols, Wireshark

Wireshark is used to capture and analyze live HTTP traffic, revealing the full request-response cycle between a client and a web server at the packet level. Key elements examined include the TCP three-way handshake, HTTP GET requests, response codes, and raw payload data.

Complete this video to capture a CTF flag worth 1 point.

About this video

Wireshark provides a practical window into how HTTP traffic actually moves across a network, and this content demonstrates that by capturing a live exchange between a client laptop and a locally hosted web server. After starting a capture on the active Ethernet interface and loading a web page, the capture is stopped and filtered using a specific IP address to cut through unrelated network noise — in this case, background Cisco protocol traffic — and focus only on the relevant communication. With the filtered view in place, the TCP three-way handshake is clearly visible, showing SYN, SYN-ACK, and ACK packets establishing connections on ephemeral ports before any HTTP data moves. The HTTP layer then shows a GET request directed at port 80, with the full URI visible in the payload — a detail that surfaces an important point about how web servers handle routing: some rely on the destination IP address and port, while others use the host header or full URI to determine which resource or virtual site to serve. The server's response comes back as a 200 OK, and the payload inspection reveals the actual HTML of the web page being delivered — the title, headers, and body content matching what a browser would render. A follow-up request for a favicon returns a 404 Not Found, demonstrating how HTTP status codes communicate both success and failure at the application layer. The session concludes with the TCP connections closing cleanly, completing the picture of a full HTTP transaction from handshake to teardown.

What you'll learn

What's covered

HTTP Traffic in Wireshark

Aligned to

Cisco CCST Networking
5.2 Perform a packet capture with Wireshark and save it to a file
1.5 Describe common network applications and protocols
Cisco CyberOps Associate
4.6 Extract files from a TCP stream when given a PCAP file and Wireshark
4.7 Identify key elements in an intrusion from a given PCAP file
4.8 Interpret the fields in protocol headers as related to intrusion analysis
CompTIA Network+
1.4 Explain common networking ports, protocols, services, and traffic types

Key terms

Transmission Control Protocol
TCP
A connection-oriented transport protocol that ensures reliable, ordered, and error-checked delivery of data.
Packet
A unit of data formatted for transmission over a network, containing a header, payload, and sometimes a trailer.
Payload
The actual data content of a packet or message, excluding headers and metadata.
Port
A logical endpoint for communication in a network, identified by a number that specifies a particular service or application.
Application Layer
The topmost layer of the OSI model (Layer 7) that provides network services directly to end-user applications.
Hypertext Transfer Protocol
HTTP
An application-layer protocol that defines how web browsers and servers communicate to request and deliver web pages and other content, operating over TCP on port 80. HTTP transmits data in plaintext, which is why it has been largely replaced by HTTPS for sensitive content.
TCP Three-Way Handshake
The process of establishing a TCP connection using three steps: SYN, SYN-ACK, and ACK.
HTTP GET Request
An HTTP method used by a client to request a resource from a web server.
HTTP Response Code
A three-digit status code returned by a server indicating the result of an HTTP request, grouped into categories: 1xx informational, 2xx success, 3xx redirection, 4xx client error, and 5xx server error.

Transcript

Capturing and Filtering the Traffic

In this exercise, what I'm going to do is use Wireshark to monitor the Ethernet connection here. And then with that running — you can see it's collecting some data — I am going to pull up the web page. This is the web page that we've created earlier. So now I have that up. I can minimize that. In fact, what I'll probably do is close out of that, and then I'm going to stop this transfer and look at the data that's been transferred back and forth.

By my capture, I've got a lot of this Cisco traffic that's on here. So the first thing I'm going to do is filter that out. I type in ip.addr equals equals 10.1.0.3. I'm going to hit enter, and then it's going to filter out for just that communication.

The first thing that I notice as I scroll through here is that it sets up that TCP connection. It's that three-way handshake, and it does it actually for two different ports. It establishes an ephemeral port of 58315 and another one for 58316. So it creates a SYN, and then we see the SYN-ACK reply to those, and then we see the acknowledgements from those.

But the one that we're most concerned with is the one that's associated with this HTTP traffic. So if we go down here to the window and open up the layer 4, we'll see that it's using port 58350. In fact, I don't even need to open that up — it says it right there. So 58315. That's the first TCP connection it established.

The GET Request

So let's really look at what the HTTP traffic is doing then. First of all, we notice that this is the GET command, and it's getting HTTP, and it is going to port 80. So that all hopefully is fairly clear.

And then let's look at what we find as far as the payload is concerned. If we scroll down, we see that this is the URI that we entered into the browser. So it's referencing this http://10.1.0.3/, and then if there were a specific page that we're referencing, that would show up here. Or if we used a DNS name, like let's say we type in www.google.com, we would see that in there.

The reason why I bring that up is some browsers will determine what resource you're trying to get to by IP address. So whatever IP address you are trying to get to, then it will have pages associated with that IP address, or a site that's associated with that IP address. While other web servers will look at this for the host that you're trying to reference, or that DNS name, or that full URI that you're trying to reference, and then use that to determine which site you're trying to access. So it's just a little different. It could use either way. It could use the IP address. It could use the port and what port you are trying to reach. Or it could use this host right here, this URI information.

And it's going to use this URI information either way, because it needs to know what specific resource you're accessing. This one's just the main index page, and so we don't need to actually specify the main index page. But if we were to reference another page in here, then it would be listed out right here.

The Reply

All right, so that is the GET request. Next we see is the reply, and we see that there is a 200 OK. So the 200 OK means: okay, I am now delivering this, you have reached a web page and I'm delivering the web page.

So let's look at the payload of this and see what this payload looks like. In fact, this is the line-based text data, and we see it's saying it's using HTML. There is the title, the header, and then we see the information that was part of the web page. And so it's the same thing that we saw when we brought up that web page. So there is the actual delivery of the web page. It's actually delivering it here.

The Favicon Request

So then the next thing that happens is the demo laptop requests this favicon from the demo Pi. And the favicon is that little icon that sits right next to the URI in the top part of the browser. So it is requesting that, and we didn't have one set, so the reply back is 404 Not Found. These are the codes that are being sent back and forth, and it says, "Oh, we don't have a favicon for this site." So you're going to have to do without, is essentially what this is saying. And then we've got some additional information down here of what it's trying to access and that it didn't find it.

So now that gets sent back, and then we see the rest of it is just the TCP connections closing. So it'll close up these TCP connections because it's done communicating. That's how the HTTP traffic traverses across and is sent back and forth between this demo laptop and the demo Pi.

About TechKnowSurge

TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.

Explore free tools and programs →