When you hit a URL in a browser, a complex process unfolds across the networking layers of the OSI model (or TCP/IP model). Below, I’ll break down what happens at each layer, starting from the application layer down to the physical layer, and then back up as the response is received. I’ll keep it concise yet detailed, covering the key operations at each layer.
In this part – I will explain from application layer to transport layer. In the second part the other layer will be discussed. This section may be fill you bored 😣Please seat back and read the whole documents. I hope you will get inspired from this to learn more about networking.
1. Application Layer (Layer 7)
What happens
- User Action: You enter a URL (e.g., https://www.example.com) in the browser and press Enter.
- Protocol Handling: The browser parses the URL to identify the protocol (https), domain (www.example.com), and resource path (e.g., /index.html).
- DNS Resolution: The browser initiates a Domain Name System (DNS) query to resolve the domain name to an IP address. This involves:
- Checking the browser’s cache, OS cache, or local hosts file.
- If not found, querying a DNS resolver (e.g., your ISP’s DNS server or public DNS like 8.8.8.8).
- The resolver may query root, top-level domain (TLD), and authoritative name servers to get the IP address (e.g., 93.184.216.34 for example.com).
- HTTP/HTTPS Request: The browser constructs an HTTP (or HTTPS) request (e.g., GET /index.html HTTP/1.1). For HTTPS:
- A TLS handshake is initiated to establish a secure connection.
- The browser verifies the server’s SSL/TLS certificate, negotiates encryption protocols, and exchanges keys.
- Output: The application layer passes the request data (e.g., HTTP GET) to the transport layer, along with the resolved IP address.
2. Presentation Layer (Layer 6)
The Presentation Layer is responsible for data translation, encryption, and compression, ensuring the application data is in a format both sender and receiver understand.
What Happens in the Presentation Layer
- Data Formatting/Translation:
- Converts application data into a standardized format for transmission or from a received format to one that the application can process.
- For HTTPS, this includes formatting the HTTP request (e.g., GET /index.html HTTP/1.1) into a standardized structure the server understands.
- Encryption/Decryption:
- For HTTPS, the TLS protocol operates primarily in the Presentation Layer (though initiated at the Application Layer).
- After the TLS handshake (described earlier), the Presentation Layer encrypts the HTTP request data using the session key (e.g., AES) before sending it to the server.
- On receiving the response, it decrypts the server’s data (e.g., HTML content) for the browser.
- Compression:
- Compresses data to reduce transmission size (e.g., using gzip for HTTP responses).
- Decompress the received data for the application to process.
- Character Encoding:
- Handles character set conversions (e.g., UTF-8, ASCII) to ensure compatibility.
- For example, ensure the browser and server agree on encoding for the HTML content.
- Protocols:
- TLS/SSL is the primary Presentation Layer protocol for HTTPS.
- Other examples (not used here) include JPEG for images or MIME for email.
In URL Context
For https://www.example.com, the Presentation Layer:
- Encrypts the HTTP request (GET /index.html) using TLS before it’s passed to the Session Layer.
- Decrypts the server’s response (e.g., HTML content) after receiving it.
- Ensures the HTTP data is in a format the browser can render (e.g., UTF-8 encoded text).
- If the server sends compressed data (e.g., Content-Encoding: gzip), the Presentation Layer decompresses it.
Interaction with Other Layers
- Receives data from the Application Layer (e.g., raw HTTP request from the browser).
- Formats, encrypts, or compresses it, then passes it to the Session Layer.
- The encrypted data becomes the payload of a TCP segment, which is then encapsulated in an IP packet and Ethernet frame (as described in prior responses).
3. Session Layer (Layer 5)
What Happens in the Session Layer
- Session Establishment:
- When you hit a URL, the browser initiates a session to manage the communication with the server.
- For HTTPS, the Session Layer coordinates the TLS (Transport Layer Security) session, ensuring the secure connection persists for multiple HTTP requests (e.g., fetching HTML, CSS, images).
- Session Management:
- Maintains the state of the connection, such as keeping track of which requests belong to the same browsing session.
- Handles session identifiers (e.g., cookies or TLS session IDs) to resume or maintain sessions without repeating the full TLS handshake.
- Manages multiplexing if multiple data streams (e.g., HTTP/2 streams) are used within the same TCP connection.
- Session Termination:
- Closes the session when the browser or server ends the communication (e.g., when you close the tab or the server sends a FIN in TCP).
- Protocols:
- No standalone Session Layer protocol is typically used for HTTP/HTTPS, but TLS session management and HTTP/2’s stream handling involve Session Layer functions.
- Examples of Session Layer protocols (not directly used here) include NetBIOS or RPC.
In URL Context
- When accessing https://www.example.com, the Session Layer ensures the browser maintains a consistent TLS session with the server.
- For example, after the TCP and TLS handshakes (described earlier), the Session Layer tracks the session ID or ticket to avoid renegotiating TLS for subsequent requests.
- If HTTP/2 is used, the Session Layer manages multiple streams (e.g., for fetching index.html, style.css, etc.) over a single TCP connection.
Interaction with Other Layers
- Receives data from the Presentation Layer (e.g., formatted HTTP requests) and passes it to the Transport Layer (TCP segments).
- Ensures the session persists across multiple TCP segments, IP packets, and Ethernet frames.
4. Transport Layer (Layer 4)
What happens
- Protocol Choice: Typically, TCP is used for HTTP/HTTPS due to its reliability (UDP may be used for DNS or other protocols like QUIC).
- Connection Setup (TCP):
- A TCP three-way handshake occurs: SYN (client), SYN-ACK (server), ACK (client).
- This establishes a reliable connection between your device and the server.
- Port Assignment: The browser assigns a source port (ephemeral, e.g., 49152) and uses the destination port (e.g., 443 for HTTPS, 80 for HTTP).
- Segmentation: The HTTP request data is segmented into smaller chunks (TCP segments), each with headers containing sequence numbers, port numbers, and other metadata.
- Output: TCP segments are passed to the network layer.
Lets discuss about TCP segments structure:
This chart shows the fields of a TCP segment (Transport Layer), with a typical header size of 20 bytes and a sample payload.
Structure of a TCP Segment
- Header (20-60 bytes, typically 20 bytes without options):
- Source Port (2 bytes): Identifies the client’s port (e.g., ephemeral port like 49152).
- Destination Port (2 bytes): Identifies the server’s port (e.g., 443 for HTTPS).
- Sequence Number (4 bytes): Tracks the order of bytes sent, ensuring correct reassembly.
- Acknowledgement Number (4 bytes): Indicates the next byte the receiver expects (used in ACKs).
- Data Offset (4 bits): Specifies the header length (in 32-bit words).
- Flags (9 bits): Control flags like SYN, ACK, FIN, RST for connection management.
- Window Size (2 bytes): Indicates the receiver’s buffer size for flow control.
- Checksum (2 bytes): Ensures data integrity by detecting errors.
- Urgent Pointer (2 bytes): Points to urgent data (rarely used).
- Options (0-40 bytes, optional): Additional settings like Maximum Segment Size (MSS).
- Payload (0-1460 bytes, typically): Contains the application data, such as an HTTP request or TLS-encrypted data. The payload size depends on the Maximum Segment Size (MSS), often 1460 bytes to fit within typical network limits.
Please grab a coffee and try to understand the full flow of networking. No more for today. 👏It’s great if you have successfully read this line.
