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.
HTTP Traffic in Wireshark
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.
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.
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.
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.
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 →