What happen when you enter google.com in your browser using osi models

Network Layers Breakdown

A Comprehensive Walk-Through of Network Layers using OSI Models


Google.com Request breakdown

Introduction

When you type ”google.com” in your browser’s address bar and press enter, within 1-2 seconds, you receive a response with a web page. However, under the hood, a complex sequence of events occurs across seven layers of the OSI model. Each layer plays an important role in ensuring accurate and efficient data flow from your device to Google servers. Let's break down these events:

  • The browser checks whether the URL IP is known or needs to be looked up.
  • If the IP is known, the browser prepares a request to Google.
  • TCP connection is established with Google to ensure reliable data transfer.
  • The request is broken into packets, put into frames, and transmitted as electrical signals over networks.
  • Google receives and processes the request, then sends back a response.
  • The response travels back through the same layers, and the browser renders the web page by loading HTML, CSS, JS, and image files.

Let’s dive deep and break down each event across all OSI model layers:

1. User Input and URL Parsing

When we type ”google.com” and press enter, the browser checks whether it is a URL or search term. In this case, it is a URL, not a search term. Secondly, the browser checks its preloaded HSTS (HTTP Strict Transport Security) list, which is a list of websites that must be contacted via HTTPS only. If the website is in the list, the browser sends an HTTPS request instead of HTTP.

Example of URL Breakdown:

  • Protocol: "https"
  • Host: "www.google.com"
  • Path: "/"

2. Application Layer

The Application Layer is closest to end users and is responsible for network services like file transfers, email, and other network software services.

2.1 DNS Query

Initial Check: The browser first checks its local cache to know the IP address for ”www.google.com”.

If Cached: The cached IP address is used.

If Not Cached: The browser generates a DNS query to find the IP address of the domain.

  • DNS Resolver: Sends the DNS query to the DNS server (ISP caching DNS server).
  • If Not Found: DNS resolver sends the query to root DNS servers, TLD (top-level domain) servers, and authoritative nameservers for the domain to get the IP address.
  • Received IP Address: Once DNS resolution is complete, the IP address is obtained, e.g., ”www.google.com” (172.217.12.206).
  • Cache IP Address: The resolved IP address is now cached for future use.

2.2 HTTP Request

The browser prepares an HTTP request to access ”google.com”.

  • Constructing Request: The browser specifies the method (GET, POST, etc.), path ("/", "/homepage", etc.), and HTTP version (HTTP/1.1).
  • Headers: Includes metadata like Host: "www.google.com", User-Agent, Accept, Connection, etc.
  • Send Request: The HTTP request is sent to the IP address obtained from DNS resolution.

3. Transport Layer

After the IP address is obtained, the browser establishes a connection using TCP/IP.

3.1 TCP Connection Establishment

3.1.1 Three-Way Handshake

1

SYN: Client sends a SYN packet to the server to start the connection, which contains the initial sequence number.

2

SYN-ACK: Server responds with a SYN-ACK packet, which contains acknowledgment of the client SYN and server sequence number.

3

ACK: Client sends an ACK packet, which acknowledges the server SYN-ACK.

3.1.2 SSL/TLS Handshake (for HTTPS)

1

Client Hello: Client sends a SYN packet to the server to start the connection, which contains the initial sequence number.

2

Server Hello: Server responds with a SYN-ACK packet, which contains acknowledgment of the client SYN and server sequence number.

3

Certificate Verification: Client sends an ACK packet, which acknowledges the server SYN-ACK.

4

Session Key Exchange: Both parties exchange keys to establish a secure session.

3.2 Data Transfer

3.2.1 Segmentation:

HTTP data is broken into smaller TCP segments, each with its sequence number.

3.2.2 Reliability:

  • Acknowledgments: Each segment sent must be acknowledged by the receiver.
  • Retransmission: Lost segments are retransmitted.
  • Flow Control: TCP uses flow control to prevent overwhelming the receiver.

3.2.3 Reassembly:

Segments are reassembled into the original HTTP request on the server.

4. Session Layer (Client)

The Session Layer is responsible for establishing, maintaining, and terminating sessions between applications. It manages the communication session between the client and server, ensuring that data is exchanged reliably.

In many modern implementations, session management is handled by the transport layer or higher-level application protocols, so it may not always be distinctly handled. In practical implementations, session management often occurs at the application layer or is integrated within the transport layer secure connection. For HTTPS, the session management is often handled as part of the TLS/SSL protocol.

5. Network Layer

5.1 Packet Creation

At the Network Layer, the HTTP request (which is segmented into TCP segments from the Transport Layer) is encapsulated in an IP packet. This encapsulation involves adding a header to each TCP segment. The IP packet includes crucial information for routing and delivery.

  • IP Header: The IP packet header contains fields essential for routing and addressing
    • Source IP Address: The IP address of the client device initiating the request.
    • Destination IP Address: The IP address obtained from the DNS resolution, which corresponds to “www.google.com.”
    • Version: Indicates the version of IP being used (IPv4 or IPv6).
    • Header Length: Specifies the length of the IP header.
    • Total Length: The total length of the IP packet (header plus data).
    • TTL (Time to live): A field that limits the lifespan of the packet to prevent it from circulating indefinitely in case of routing loops.
    • Protocol: Indicates the protocol used in the data portion of the packet (TCP in this case).
    • Checksum: Used for error-checking the header.

5.2 IP Packet Transmission (Client)

Once the IP packet is created, it is transmitted over the network. This involves sending the packet to the next-hop router or directly to the destination server if it is on the same network.

  • Transmission Medium: The packet travels through various physical mediums like Ethernet cables, Wi-Fi, or fiber optics.
  • Routing: Routers along the path use the destination IP address to determine the next hop for the packet. The packet may pass through several routers and networks before reaching the destination server.
  • Forwarding: Routers forward the packet based on the routing table, which is a list of routes to various network destinations.
  • Fragmentation: If the packet size exceeds the Maximum Transmission Unit (MTU) of the network, it may be fragmented into smaller packets.

5.3 IP Packet Reception (Server)

The server receives the IP packet from the network. Upon arrival, the IP packet is extracted from the data frame provided by the Data Link Layer and forwarded to the appropriate TCP segment.

  • Data Frame: The IP packet is carried within a data frame (e.g., Ethernet frame) which includes additional headers specific to the Data Link Layer.
  • Decapsulation: At the server’s Network Layer, the IP packet is decapsulated from the data frame, and its header information is read.
  • Address Check: The server checks if the destination IP address in the packet matches its own IP address. If so, the packet is accepted; otherwise, it is discarded.

5.4 IP Packet Processing (Server)

After receiving the IP packet, the server processes it to extract the TCP segment. This segment is then passed to the Transport Layer for further processing.

  • Header Analysis: The server reads the IP header to extract information necessary for handling the packet, such as source and destination IP addresses and protocol type.
  • TCP Segment Extraction: The payload of the IP packet contains the TCP segment. The Network Layer extracts this segment and forwards it to the Transport Layer.
  • Checksum Verification: The server verifies the IP packet’s checksum to ensure data integrity and detect any errors that may have occurred during transmission.

7 Physical Layer

The Physical Layer is responsible for the actual transmission of raw data bits over the physical medium. It deals with the hardware aspects of network communication.

7.1 Signal Transmission (Client)

The data frame is converted into electrical, optical, or radio signals for transmission over the physical network medium.

  • Data Encoding: The data in the frame is encoded into signals that can be transmitted. Manchester encoding and NRZ (Non-Return-to-Zero) encoding are commonly used.
  • Transmission Medium: Ethernet cables, fibre optics, and wireless medium are used for transmission.

7.2 Signal Reception (Server)

The server’s NIC receives the signals from the physical medium. These signals are converted back into a data frame for further processing at the Data Link Layer.

  • Signal Decoding: The received signals are decoded to retrieve the raw data bits. This involves reversing the encoding process used during transmission.
  • Signal Processing: Includes amplification and filtering to ensure the signal quality before decoding.
  • Synchronization: Ensures that the timing of the received signals matches the expected timing to accurately interpret the data bits.

8 Application Layer (Server)

The Application Layer is responsible for handling high-level protocols and services that provide end-user services directly. When a server receives an HTTP request, it processes it to generate an appropriate response. Let’s break down the events in this layer in detail.

8.1 HTTP Response Handling

After receiving and processing the HTTP request from the client, the server generates an HTTP response. This response includes a status line, headers, and a body.

8.1.1 Request Processing

The server parses the HTTP request to extract the request line (method, path, and HTTP version), headers, and body (if present).

  • Request Line: GET /index.html HTTP/1.1
  • Headers: Host: www.google.com, User-Agent: Mozilla/5.0
  • Body: May be empty or some form data in POST request

After it, the server uses the request path (e.g., "/index.html") to determine which resource or handler should process the request.

8.1.2 Response Construction

It constructs the valid HTTP response that will be sent back to the client.

  • Status Line:
    • Format: HTTP/1.1 <Status Code> <Reason Phrase>
    • Example: HTTP/1.1 200 OK
  • Headers: It provides metadata about the response, such as content type, length, and server information.
    • Content-Type: Specifies the media type of the response body (e.g., Content-Type: text/html).
    • Content-Length: Indicates the size of the response body in bytes (e.g., Content-Length: 1024).
    • Cache-Control: Directives for caching mechanisms (e.g., Cache-Control: no-cache).
  • Body: It carries the actual content of the response.
    • HTML
    • JSON
    • Files

In case of google.com request, we get HTML, CSS, JS files, and logo.png (Google Logo).

8.1.3 Response Formatting

It ensures the response adheres to the HTTP standard and is correctly formatted for transmission. Line breaks and encoding response body is used for it.

8.2 HTTP Response Transmission

Server sends the constructed HTTP response back to the client over the established TCP connection.

8.2.1 TCP Data Transfer

It transmits the HTTP response over a reliable connection.

  • Segmentation
  • Transmission
  • Acknowledgment

8.2.2 Response Delivery

It delivers the complete HTTP response to the client.

  • Receiving Packets: The client receives TCP packets containing the response.
  • Reassembly: TCP segments are reassembled into the complete HTTP response.
  • Error Handling: Any lost packets are retransmitted, and errors are handled according to TCP protocols.

9 Transport Layer (Client)

The client browser reassembles the HTTP response received from Google’s server, which is sent over multiple TCP segments. This ensures that the complete and correct data (the HTML page and other resources) is reconstructed from the segments.

9.1 Receiving TCP Segments

After sending an HTTP request to Google’s server, the client receives TCP segments containing parts of the HTTP response.

  • The server responds with these segments in potentially fragmented parts, which are managed by the TCP protocol.
  • Sequence Numbers: Each segment from Google’s server has a sequence number that helps the client browser determine the order of the segments.
  • Out-of-Order Segments: Sometimes, segments may arrive out of sequence due to network conditions. TCP handles this by reordering the segments based on their sequence numbers.

9.2 Segmentation and Reassembly

Google’s server breaks down the large HTTP response (e.g., the HTML content of the Google homepage, images, CSS files) into smaller TCP segments. Each segment is given a header with sequence information. For instance, a large HTML file might be split into several TCP segments for easier transmission.

It reconstructs the complete HTTP response from received TCP segments.

9.3 Data Assembly and Error Handling

It combines all TCP segments into the complete HTTP response that the browser can use.

  • Reconstruction: After all segments are received and verified, the browser reconstructs the complete HTML page and other resources by concatenating the segments based on their sequence numbers.
  • Error Handling: If segments are lost or corrupted, TCP retransmits them. For instance, if the segment containing critical parts of the HTML is lost, TCP will request its retransmission. For example, if the segment with a portion of CSS for displaying google.com page is lost, then the server will resend it.

9.4 Passing Data to Higher Layers

Once the HTTP response is fully reassembled, including the HTML content and any additional resources (like images and scripts), it is handed over to the browser’s Application Layer. After it, the Application Layer processes the HTTP response to render the web page for the user.

10 Presentation Layer (Client)

After receiving the complete HTTP response, the browser’s Presentation Layer decodes the data to convert it into a format that can be interpreted and rendered. This includes decoding any encoded data in the HTTP response such as compressed content or character encodings.

10.1 HTTP Response Structure

Google’s server responds with an HTTP response that includes an HTML document, which is the main content of the page, as well as links to CSS files, JavaScript files, and image resources.

10.2 Decoding Compressed Content

Content-Encoding Header: Google uses gzip compression for the HTML content to reduce the amount of data sent. The HTTP response header includes Content-Encoding: gzip. So the browser decompresses the gzip-encoded HTML to load HTML.

10.3 Character Encoding

The response is generally "Content-Type: text/html; charset=UTF-8" and the browser interprets this and decodes to display text characters.

10.4 HTTP Response Rendering

The browser renders the HTML content, applying CSS styles and executing JavaScript to present the Google homepage to users. This is basically done by:

10.4.1 Parsing HTML

DOM Construction: The browser parses the HTML and constructs a DOM tree. For Google’s homepage, this includes elements like <div>, <input>, and <button>.

10.4.2 Applying CSS

The browser fetches and parses styles.css from Google’s server. The styles are applied to the DOM.

10.4.3 Executing JavaScript

The browser fetches and executes scripts.js.

10.4.4 Rendering the Page

  • Layout Calculation: The browser calculates the layout of all elements based on the DOM structure and CSS styles. For Google, this means placing the search box and button in the center of the page.
  • Painting: The browser paints the content onto the screen. It renders the search box, button, and any text or images, translating the DOM and CSS into visible pixels on the screen.
  • Reflows and Repaints: If JavaScript modifies the DOM or CSS, the browser might need to adjust the layout (reflow) and update the visual display (repaint).

Comments

If u have any doubts ,let-me-know

Translate

search blog monthly

Contact Form

Send