Real-time packet flow when we try to access any URL

In order to gain a better understanding of this article, I recommend that you read my DNS article if you are not familiar with the DNS or its functions.

There is a very basic question that people often ask

Often we wonder or are asked how google.com will look when you access it from your laptop. How do you determine the source mac address, the source IP address, the destination mac address and the destination IP address in this case?

There is nothing special about it; it uses the same basic networking principles.

Packet capture or the browser itself are the best ways to verify this.

I'm typing https://google.com in my browser

The browser itself has a very interesting feature that can help you understand HTTP headers in-depth, though I won't go into detail about HTTP headers.

You will find a dotted symbol at the extreme right-hand side of your Google Chrome browser. Click it. Here is what you need to do.

Go to More tools>>Developer tools>> and then choose Network

After this in your browser, type whatever you wish to browse, I am browsing https://google.com here.

On the right side of the above output, we can see Remote Address: 216.58.199.174:443 which represents the IP Address or hostname of the remote computer to which the connection is being made. This is the current state of the connection. I am using HTTPS and therefore the TCP server is listening on port 443.

Let's see what happens when you browse https://google.com by taking the packet capture.

As you can see from the screenshot below, my PC (IP: 10.196.112.78) is sending a DNS query to the DNS server (64.104.128.236).

DNS server sending the response of the DNS query.

We can see four different authoritative Google name servers in the above output: ns1, ns2, ns3, and ns4. A response is being received from ns1.google.com with the IP address 216.58.199.174.

In the case of google.com, the DNS recursor first contacts the root name server. It will be redirected to the .com domain name server by the root name server. It will be redirected to the google.com name server by the .com name server. Here, google.com's name server, ns1.google.com, will find the matching IP address for google.com in its DNS records and return it to your DNS recursor, which will send it back to your browser.

The browser will make a connection with the server that matches the IP address once it receives the correct IP address. Such connections are built using internet protocols by browsers. TCP is the most common protocol for HTTP requests, although other internet protocols can also be used.

A TCP connection is necessary for data packets to be transferred between your computer (client) and the server. TCP/IP three-way handshakes are used to establish this connection. This is a three-step process where the client and the server exchange SYN(synchronize) and ACK(acknowledge) messages to establish a connection.

From the above capture, we can see that the TCP connection has been established with the server 216.58.199.174.

It's time to begin transferring data once the TCP connection has been established! The browser will send a GET request asking for a google.com web page, as we saw at the beginning of this article. Since we are retrieving information, the request method is GET.

If you're entering credentials or submitting a form, you're performing a POST request. It will also contain additional information such as the user agent of the browser (User-Agent header), the types of requests it will accept (Acceptheader), and connection headers to keep the TCP connection alive for additional requests. Additionally, it will pass cookies the browser has stored for this domain.

Conclusion:

It is important to know which packet we are talking about when we talk about source IP, source mac, destination IP, or destination mac, and at which network hop we are being asked. This time, we can see that our Source IP is 10.196.112.78, Destination IP is 64.104.128.236 (DNS server), Source Mac is my PC mac, and Destination Mac is next-hop.

Note:

At each hop, the destination and source mac addresses update according to the incoming and outgoing interfaces, but the destination and source IP addresses do not. Changing the header checksum at each hop demonstrates this.

Let's ping google.com from our PC. I am using a Mac, so Linux is the operating system.

I am just flushing the DNS to clear the cache.

PRIYANKA.KUMARI-M-92EL:~ $ dscacheutil -flushcache

PRIYANKA.KUMARI-M-92EL:~ $ ping google.com

PING google.com (216.58.199.174): 56 data bytes

64 bytes from 216.58.199.174: icmp_seq=0 ttl=49 time=21.103 ms

64 bytes from 216.58.199.174: icmp_seq=1 ttl=49 time=20.530 ms

64 bytes from 216.58.199.174: icmp_seq=2 ttl=49 time=20.683 ms

From the above output, we can see the following details:

Source IP: 10.196.112.78 (My PC IP)

The destination IP is 216.58.199.174 and the destination mac is nothing but my next hop after that.