What happen when you enter google.com in your browser using osi models
A Comprehensive Walk-Through of Network Layers using OSI Models
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 likeHost:
"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
SYN: Client sends a SYN packet to the server to start the connection, which contains the initial sequence number.
SYN-ACK: Server responds with a SYN-ACK packet, which contains acknowledgment of the client SYN and server sequence number.
ACK: Client sends an ACK packet, which acknowledges the server SYN-ACK.
3.1.2 SSL/TLS Handshake (for HTTPS)
Client Hello: Client sends a SYN packet to the server to start the connection, which contains the initial sequence number.
Server Hello: Server responds with a SYN-ACK packet, which contains acknowledgment of the client SYN and server sequence number.
Certificate Verification: Client sends an ACK packet, which acknowledges the server SYN-ACK.
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.
6 Data Link Layer
The Data Link Layer is responsible for node-to-node data transfer and error detection and correction on the local network segment. It frames the data packets from the Network Layer and handles their delivery over the physical medium.
6.1 Frame Creation
The IP packet, which contains the encapsulated TCP segment, is further encapsulated into a data frame at the Data Link Layer. This frame is prepared for transmission over the physical network medium. The process of encapsulation at the Data Link Layer involves adding a header and a trailer around the IP packet. This forms the data frame.
- Frame Header:
- Source MAC Address: The Media Access Control (MAC) address of the sender’s network interface card (NIC).
- Destination MAC Address: The MAC address of the intended recipient’s NIC. If the destination is a remote host, this will be the MAC address of the next-hop router.
- Type/Length Field: Indicates the protocol of the encapsulated data (e.g., IPv4 or IPv6).
- Priority Field: May indicate the priority of the frame in network traffic (e.g., Quality of Service).
- Frame Trailer:
- Frame Check Sequence (FCS): A checksum used for error detection. It allows the receiving device to verify if the frame has been transmitted correctly.
6.2 Frame Transmission (Client)
The frame, now containing the IP packet, is transmitted over the network to the next-hop device (e.g., router) or directly to the destination if on the same network.
- Transmission Medium: The frame is sent over the physical medium such as an Ethernet cable, Wi-Fi, or fiber optic link.
- MAC Addressing: The Data Link Layer uses MAC addresses to deliver the frame to the correct hardware address on the local network.
- Access Methods: Various methods (e.g., CSMA/CD for Ethernet, CSMA/CA for Wi-Fi) determine how the network medium is accessed and how collisions are handled.
6.3 Frame Reception (Server)
The server receives the data frame from the network. The frame is extracted, and the IP packet within it is processed.
- Decapsulation: The server’s NIC removes the frame header and trailer, revealing the encapsulated IP packet.
- MAC Address Check: The server checks the destination MAC address to ensure it matches its own address or that of a router for further forwarding.
- Error Checking: The FCS field is checked for errors. If errors are detected, the frame is discarded or a retransmission request may be issued.
6.4 Frame Processing (Server)
After the frame is processed, the IP packet is passed up to the Network Layer for further handling.
- Frame Removal: The Data Link Layer removes the frame’s header and trailer before passing the remaining IP packet to the Network Layer.
- Packet Forwarding: The IP packet is then handed over to the Network Layer, where further processing is carried out to handle the encapsulated TCP segment.
- Address Validation: The MAC address in the frame header is validated to ensure that the frame is intended for the server or router.
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