top of page
Search

Wireshark Network Investigation: What Really Happens When You Open a Website?

fabztechtips
Aug 24
9 min read

Introduction

Opening a website normally feels like one simple action.

I type a URL into my browser, press Enter, and a few seconds later the page appears.

But underneath that simple action, the computer can generate hundreds or thousands of packets involving DNS servers, remote web servers, encryption protocols, background applications and network services.

For this project, I wanted to see exactly what was happening on my own Windows laptop.

Rather than using a traditional home broadband connection, I connected the laptop to a TP-Link mobile hotspot and captured the traffic using Wireshark.

The objective was to investigate the network activity generated during normal browsing and understand how DNS, TCP, TLS, HTTP and other protocols appear in a real packet capture.

Lab Environment

The test environment was deliberately simple.

I used:

  • Windows laptop

  • TP-Link mobile hotspot

  • Wi-Fi connection

  • Mobile broadband

  • Wireshark 4.6.7

  • Web browser

  • Windows networking tools

The laptop was connected to the TP-Link hotspot using Wi-Fi.

Network topology

                 Mobile Network
                       |
                       |
                TP-Link Hotspot
                  192.168.0.1
                       |
                     Wi-Fi
                       |
                       |
              Windows Laptop
                192.168.0.112
                       |
                    Wireshark
                       |
                    Internet



Establishing the Laptop's Network Configuration

Before beginning the packet capture, I checked the laptop's network configuration using:

ipconfig

The Wi-Fi adapter had the following configuration:

IPv4 Address:     192.168.0.112
Subnet Mask:      255.255.255.0
Default Gateway:  192.168.0.1

The 192.168.0.1 address was therefore being used as the local gateway for the TP-Link hotspot.

This immediately gave me a useful baseline for identifying my laptop's traffic inside Wireshark.



Clearing the DNS Cache

Before starting the investigation, I flushed the Windows DNS resolver cache:

ipconfig /flushdns

The command completed successfully.

This was useful because it reduced the possibility of an existing cached DNS entry being reused without generating a new DNS request.



Starting the Wireshark Capture

I opened Wireshark and selected the active Wi-Fi interface.

The interface showed live packet activity, confirming that Wireshark was monitoring the network adapter connected to the TP-Link hotspot.



I then started the capture and allowed the laptop to generate normal network traffic.

This is where the investigation became more interesting.

Instead of seeing only the traffic generated by the website I was investigating, the capture contained background network activity from the operating system and installed applications.

This is actually representative of what happens on a real workstation.

A user may think they are performing one network action, while Windows and other applications are simultaneously communicating with remote services.

DNS Investigation

I started the investigation by filtering the capture using:

dns

The capture contained numerous DNS requests between the laptop and the TP-Link gateway.

The laptop was:

192.168.0.112

and the DNS server visible in the capture was:

192.168.0.1

The DNS traffic wasn't limited to the website itself.

Several requests related to background services appeared, including domains associated with Opera and Microsoft.

Examples visible in the capture included:

ab-merchandise.opera-api.com
merchandise.opera-api.com
sd-images.operacdn.com
weather.opera-api2.com
settings-win.data.microsoft.com
sitecheck.opera.com
msedge.api.cdp.microsoft.com



This was one of the first important findings from the project.

A packet capture taken while browsing is not necessarily a clean representation of one website.

The computer itself is constantly communicating with other services.

DNS Responses and CNAME Resolution

The DNS responses also contained CNAME chains.

For example, the Microsoft settings-win.data.microsoft.com lookup returned a chain involving Microsoft's traffic-management infrastructure.

Similarly, Opera-related domains resolved through additional CNAME records.



This demonstrates why DNS analysis can be useful during network troubleshooting.

A hostname entered by an application does not necessarily map directly to a single obvious server.

CDNs, geographic routing and traffic-management systems can introduce several layers between the original hostname and the final destination.

Investigating TCP

The next stage was examining TCP traffic.

I filtered the capture for TCP and inspected the individual connections.

One of the captured connections used:

Source Port:      55918
Destination Port: 443

The destination port of 443 immediately indicated an HTTPS connection.



The TCP packet showed:

Flags: SYN

This represents the first stage of the TCP three-way handshake.

The server responded with a SYN/ACK.



The response contained:

Flags: SYN, ACK

The client could then acknowledge the server's response.

The basic process was:

Laptop → Server     SYN

Laptop ← Server     SYN/ACK

Laptop → Server     ACK

At this point, the TCP connection had been established.



This is a good example of why Wireshark is useful for troubleshooting.

Instead of simply seeing "the website is loading", I can see the underlying connection being established packet by packet.

TLS Encryption

Once TCP connectivity had been established, the capture contained TLS traffic.

I filtered the capture using:

tls

The capture contained both TLS 1.2 and TLS 1.3 traffic.

This was particularly interesting because it demonstrates that a modern Windows workstation can have multiple TLS sessions using different versions at the same time, depending on the applications and services involved.

Inspecting a TLS Client Hello

One of the captured TLS handshakes contained a TLS 1.2 Client Hello.

The packet showed:

TLS Version: TLS 1.2

and, importantly, contained the Server Name Indication:



The Client Hello also contained information about supported cipher suites and TLS extensions.

Among the extensions was:

server_name

along with:

supported_groups
signature_algorithms
session_ticket
application_layer_protocol_negotiation

This demonstrates that although HTTPS encrypts application data, the TLS handshake can still expose useful metadata.

TLS Application Data

After the handshake, the capture contained encrypted application data.



The important distinction is that I could see the encrypted traffic but not simply read the underlying application content.

The capture therefore demonstrates an important security principle:

HTTPS does not make the network traffic invisible.

Instead, it encrypts the application contents while leaving certain network metadata observable.

HTTP Traffic in the Capture

One of the more unexpected findings was that the capture also contained HTTP traffic.

Filtering for:

http

revealed requests involving:

146.75.90.172

The capture showed requests such as:

GET /filestreamingservice/.../pieceshash

and responses including:

HTTP/1.1 200 OK

and:

HTTP/1.1 206 Partial Content



The 206 Partial Content responses are particularly interesting because they indicate that only portions of a resource were being transferred.

This is commonly associated with applications retrieving data in chunks rather than downloading an entire resource in one request.

This also reinforced one of the lessons from the project:

A real workstation capture can contain traffic generated by many different applications and services at the same time.

HTTPS Traffic on TCP/443

I then applied:

tcp.port == 443

This produced a large number of HTTPS-related TCP connections.



77.111.246.40

as well as other remote addresses.

There were numerous different client-side source ports connecting to TCP/443.

This is normal behaviour for a modern operating system and browser environment.

A single webpage can result in multiple connections to different services, while background applications may also be generating their own HTTPS sessions.

TCP Retransmissions

The most interesting network-performance finding in the capture was the presence of TCP retransmissions.

I applied the filter:

tcp.analysis.retransmission

Wireshark returned multiple packets.



Examples included retransmissions involving:

77.111.246.40
48.209.133.15
95.100.100.106

Some packets contained application data, while others were retransmitted FIN/ACK packets used during connection termination.

This is particularly relevant because the laptop was connected through a mobile network.

Mobile connections can experience:

  • Variable latency

  • Packet loss

  • Changing radio conditions

  • Network congestion

  • Variable throughput

  • Connection instability

Therefore, seeing retransmissions in this environment is useful evidence when investigating network performance.

However, retransmissions alone do not prove that the mobile network is faulty.

Wireshark can identify that retransmission occurred, but additional investigation is required to determine the underlying cause.

Following a TCP Stream

I also examined an individual TCP stream.

One of the streams used:

Source Port: 55918
Destination Port: 443



The stream contained binary-looking data rather than readable website content.

This was expected because the connection was protected by encryption.

Interestingly, the raw stream also contained a visible reference to:

This is another reminder that packet captures can contain traffic belonging to services other than the website being investigated.

It is therefore important not to assume that every visible hostname or endpoint belongs to the website that the user believes they opened.

Connection Termination

I then investigated TCP FIN packets using:

tcp.flags.fin == 1

The capture showed numerous connections being closed with FIN/ACK packets.



Several FIN/ACK packets were also identified by Wireshark as retransmissions.

For example, connections involving 77.111.246.40 and 48.209.133.15 contained retransmitted FIN/ACK packets.

This suggests that some connection termination packets were not acknowledged immediately and had to be retransmitted.

Again, on a mobile connection, this is an interesting network-performance observation.

Conversation Analysis

Wireshark's Conversations window provided another useful view of the capture.



The capture contained multiple TCP conversations rather than one single persistent connection.

The visible conversations included connections between the laptop and several remote HTTPS endpoints.

For example:

192.168.0.112 → 77.111.246.40:443
192.168.0.112 → 48.209.133.15:443
192.168.0.112 → 48.192.143.121:443
192.168.0.112 → 20.184.175.3:443

This provides a useful visual demonstration of the number of network relationships a modern workstation can establish during ordinary use.

Endpoint Analysis

Finally, I examined the IPv4 endpoint statistics.



The laptop appeared as:

192.168.0.112

The remote endpoints included several public IP addresses, with 77.111.246.40 generating a significant portion of the observed HTTPS traffic.

The endpoint statistics also showed that the capture contained considerably more than one simple client/server conversation.

What Did This Investigation Actually Show?

The original question was:

What happens when I open a website?

The packet capture showed that the answer is considerably more complicated than:

Laptop → Website

Instead, a real Windows workstation can produce something closer to:

                         Internet
                            |
          +-----------------+------------------+
          |                 |                  |
       DNS/Services      HTTPS             Other Apps
          |                 |                  |
          |                 |                  |
      192.168.0.1      Multiple IPs       Opera/Microsoft
          |                 |
          +--------+--------+
                   |
             TP-Link Hotspot
                   |
                   |
             192.168.0.112
                Laptop

The laptop was simultaneously performing DNS lookups, establishing HTTPS connections, transferring data, communicating with background services and closing previous connections.

Key Findings

The investigation produced several useful findings.

1. The laptop's local address

192.168.0.112

2. The TP-Link gateway

192.168.0.1

3. DNS was visible

The laptop was sending DNS queries to the hotspot gateway.

4. Multiple applications generated traffic

The DNS capture contained Opera and Microsoft-related domains.

5. HTTPS was heavily used

A significant portion of the traffic involved TCP port 443.

6. TLS 1.2 and TLS 1.3 were observed

The capture contained both TLS versions.

7. TLS metadata was visible

The TLS Client Hello exposed information such as the SNI hostname:

8. Application data remained encrypted

The HTTPS payload could not simply be read from the TCP stream.

9. HTTP traffic was also present

The capture contained HTTP requests and 206 Partial Content responses.

10. TCP retransmissions occurred

Wireshark identified multiple retransmitted TCP packets.

11. Some connection termination packets were retransmitted

FIN/ACK packets were repeatedly retransmitted on several connections.

12. The capture contained multiple simultaneous conversations

The workstation was communicating with numerous remote endpoints.

What I Learned

The biggest lesson from this project was that network troubleshooting is rarely as simple as looking for one IP address or one connection.

A user might say:

"The website is slow."

But the packet capture raises several possible questions:

  • Is DNS slow?

  • Is the TCP handshake slow?

  • Is TLS negotiation slow?

  • Is the remote server slow?

  • Is there packet loss?

  • Are TCP segments being retransmitted?

  • Is the mobile network introducing latency?

  • Is another application consuming bandwidth?

  • Are background Windows services generating traffic?

  • Is the browser opening multiple connections?

Wireshark gives me the evidence needed to start answering those questions.

Why the Mobile Hotspot Made This Interesting

Using a TP-Link mobile hotspot made the investigation more representative of a less predictable network environment.

Unlike a controlled lab network, mobile broadband can introduce changing latency and packet loss.

The retransmissions observed in this capture therefore became particularly interesting.

However, I would not automatically conclude that the mobile provider was responsible.

A proper investigation would require comparison against:

  • A second capture at another time

  • A different network

  • Ping/latency measurements

  • Throughput testing

  • TCP statistics

  • Potentially additional captures during periods of poor performance

This is an important distinction between identifying an anomaly and proving its root cause.

Security Perspective

The capture also demonstrates why encryption matters.

Without encryption, packet captures can potentially expose application content directly.

With HTTPS, the situation is different.

A network observer can still potentially see metadata such as:

  • Source IP

  • Destination IP

  • Port

  • Packet size

  • Timing

  • TLS information

  • Some hostname information

But the actual application data is protected by encryption.

This means Wireshark remains extremely useful for troubleshooting encrypted connections without necessarily allowing an observer to read the contents of those connections.

Final Conclusion

This project started with a simple question:

What actually happens when I open a website?

The answer turned out to involve far more than a single connection.

The capture showed DNS resolution, TCP connections, TLS negotiation, encrypted application traffic, HTTP transfers, background application traffic, multiple remote endpoints and TCP retransmissions.

It also demonstrated an important principle of network troubleshooting:

The packet capture tells the story, but you have to know how to read it.

For me, the most valuable part of the investigation wasn't simply identifying TCP or TLS packets. It was learning to separate normal background workstation traffic from the connection I was actually investigating and then looking for evidence of network performance problems.

The project also reinforced how useful Wireshark can be for real-world IT support and troubleshooting, particularly when investigating reports such as slow websites, intermittent connectivity or suspected packet loss.

Technologies and Skills Demonstrated

Networking

  • TCP/IP

  • DNS

  • IPv4

  • TCP 3-way handshake

  • TCP connection termination

  • TCP retransmissions

  • Ports and sockets

  • Network latency

Security

  • TLS 1.2

  • TLS 1.3

  • HTTPS

  • Encrypted traffic analysis

  • Network metadata analysis

Tools

  • Wireshark

  • Windows ipconfig

  • Windows DNS troubleshooting

  • PCAPNG analysis

Infrastructure

  • Windows workstation

  • Wi-Fi

  • TP-Link mobile hotspot

  • Mobile broadband

Wireshark Filters Used

dns
tcp
tcp.port == 443
tls
tcp.analysis.retransmission
tcp.flags.fin == 1

These filters provided the foundation for moving from a large packet capture to specific areas of investigation.

Project Takeaway

This was more than a Wireshark demonstration.

It was a practical investigation of a real Windows workstation communicating over a mobile network, using packet-level evidence to understand what was happening underneath normal web activity.

The most important takeaway was simple:

When a network problem occurs, don't guess. Capture the traffic, filter the evidence, follow the conversation and build the story from the packets.

 
 
 

Comments

bottom of page