My Networking Learning Journey 5: Communication Principles, Protocols and TCP/IP and OSI Models

Communication Principles

Communication plays a crucial role in our lives and can take many different forms. We adjust our expectations and adapt our communication styles depending on the context—whether we are chatting with a friend on WhatsApp, attending a job interview, or speaking with a child. Each of these scenarios demands distinct behaviors and communication methods.

Before any exchange can take place, a few key agreements must be made to ensure the conversation can occur smoothly:

• Method: Two people want to communicate. One of them is mute and suggests using sign language. The other doesn't know sign language, so they agree to write messages on paper instead.

  

  Before communication can begin, participants must agree on the method used.

• Language: One person speaks Polish and English, the other Japanese and English. They choose to communicate in English, the shared language.

  

  Before communication can begin, participants must agree on the language used.

• Confirmation: "I'd like small fries and a cheeseburger." – "Sure, small fries and a cheeseburger for you?" – "Yes, that's right.”

  

  Communication is successful when the intended message has been received and confirmed.

Protocols and rules must be followed to ensure the message is successfully delivered and understood. In human communication, examples of such protocols might include:

• A defined sender and receiver

• An agreed method of communication (in person, by phone, letter, or messenger app)

• A shared language

• Agreed timing and message delivery expectations

• Acknowledgment of receipt

These communication techniques apply to both human interactions and computer networking.

---

The Role of Protocols

Computers also rely on protocols and rules to communicate with one another. These protocols are essential because they ensure that devices on a network can understand each other. Within a local area network (LAN), all computers must "speak" the same protocol in order to successfully exchange data.

Drawing a parallel with human communication: imagine a group of people where everyone speaks a different language that no one else understands—productive conversation becomes impossible. The same applies to computers or hosts: without a common protocol, they cannot communicate.

Networking protocols define many aspects of digital communication, including:

• Message format: Messages must have a well-defined structure and format, which depend on the type of message and the transmission channel.

• Message size: Strict rules often define how large a message can be. Frequently, messages must be divided into smaller chunks to be transmitted successfully.

• Timing: Many network communication functions rely on timing. This includes the speed at which bits are transmitted and sometimes when data can be sent or received.

• Encoding: Data in a network is encoded—individual bits are translated into electrical signals, radio waves, or light pulses. The receiving host must decode these signals back into data.

• Encapsulation: Every message sent over a network includes a header with metadata such as source and destination addresses. Encapsulation is the process of adding this information to the message, essentially "wrapping" it with a header. Additional standard information may also be included.

• Message pattern: Some messages require acknowledgment of receipt. This acknowledgment pattern is common in networking, although other types of messages may be streamed without requiring a confirmation.

---

Devices in a Bubble

There is a difference between how we humans visualize a network and how individual devices perceive it.

As humans, we tend to see a network (at least in part) as a collection of interconnected devices—hosts, switches, routers, DNS servers, etc.—some of which we may know by their IP addresses, MAC addresses, or domain names.

Devices, on the other hand, operate within their own isolated "bubble." A network device only knows about itself and its own address. It has no inherent knowledge of the broader network.

So how does a device know things like:

• What is my IP address?

• What network am I part of?

• Is the destination host in my network or an external one?

• Where should I send a message if the target host is outside my network?

• Has the destination host received my message?

The answer lies in protocols.

Messages are broken into smaller units called packets, and different protocols are responsible for ensuring those packets are reliably delivered and correctly interpreted at the destination.

---

Key Networking Protocols

• Ethernet (Layer 2 – Data Link Layer): Responsible for delivering data across a local network.

• IP (Internet Protocol) (Layer 3 – Network Layer): Handles addressing and routing to ensure data is delivered from sender to receiver, even across multiple networks.

• TCP (Transmission Control Protocol) (Layer 4 – Transport Layer): Ensures reliable end-to-end connections and guarantees that out-of-order packets are reassembled correctly.

• HTTP (HyperText Transfer Protocol) (Layer 7 – Application Layer): Used for data exchange in the World Wide Web.

When a user types a website address into the browser, the request must pass through all these protocols to be delivered and understood correctly.

---

Protocol Stack – TCP/IP Model

• Application Layer:
  Responsible for representing data to the user and managing encoding, dialog control, and application-specific protocols. It uses protocols like HTTP to govern the transfer and exchange of data such as HTML content.

• Transport Layer:
  Ensures reliable delivery of messages between devices across a network. It uses protocols like TCP to support error checking, data flow control, and session management between endpoints.

• Internet Layer:
  Determines the most efficient route for data to travel from the source to the destination across networks. It uses the IP protocol to route packets and define logical addressing, ensuring that packets find the best available path through the network.

• Network Access Layer:
  Handles the physical transmission of data over the network hardware. It manages protocols like Ethernet and is responsible for interfacing with network interface cards (NICs), as well as controlling how data is encoded onto the physical medium (cables, radio waves, etc.).

---

Example: What Happens When You Enter Web Page Address in the Browser?

1. Application Layer
   The browser prepares an HTTP request (e.g., GET /).
   It first resolves the domain name by querying a DNS server to retrieve the IP address for www.example.com.

2. Transport Layer
   A TCP connection is established between the browser and the web server (typically using port 80 or 443).
   This involves a three-way TCP handshake: SYN → SYN-ACK → ACK.

3. Internet Layer
   The HTTP request is encapsulated within a TCP segment, which is then encapsulated in an IP packet.
   IP defines the path to the destination IP address of the server.

4. Network Access Layer
   The IP packet is further encapsulated in an Ethernet frame (or other link-layer protocol).
   It is transmitted from your device to your router, then forwarded by your ISP across the Internet to the destination server.

At the server:
The server decapsulates the message through all layers, processes the HTTP request, and sends back an HTTP response (e.g., an HTML page).

In the browser:
The browser receives the HTTP response, parses the HTML, and renders the website.

---

The Power of Layered Models in Networking

Layered network models help us visualize and understand how protocols operate, identify which layer they belong to, and explain their responsibilities and interactions. Some of the main advantages of layered models include:

• Protocol design simplification: Each protocol operates within a defined layer and interfaces with adjacent layers, which clarifies responsibilities and facilitates modular protocol development.

• Vendor interoperability: Devices and software from different vendors can interoperate, thanks to clearly defined interfaces.

• Technology independence: Changes in one layer can be implemented without affecting others.

• Common terminology: The model provides a standardized language for describing networking functionality.

The first layered model for network communication, developed in the early 1970s, is known as the Internet Model. It identifies four broad functional categories required for successful communication. The TCP/IP protocol suite, which powers the internet, aligns with this model. Hence, the Internet Model is often referred to as the TCP/IP Model.

Protocol Models vs. Reference Models

When discussing network communication, we often use two types of models:

• Protocol Models define how protocols work together within a given stack. The TCP/IP model is an example, as it directly maps to the protocol suite it represents.

• Reference Models outline the required functionality in each layer, without specifying how that functionality should be implemented. The goal is to clarify the processes involved in communication.

The most well-known reference model is the OSI (Open Systems Interconnection) Model, developed by the ISO (International Organization for Standardization). It's widely used for network design, operations specifications, and troubleshooting.

The OSI Model Layers

1. Physical: Describes the mechanical, electrical, and procedural aspects of physical data transmission. Examples: Ethernet cables, fiber optics.

2. Data Link: Defines protocols for frame exchange across a physical medium, including MAC addressing and error detection.

3. Network: Handles routing and addressing via IP, ensuring packets reach the correct destination.

4. Transport: Manages reliable data transmission, segmentation, and reassembly. Example: TCP.

5. Session: Establishes, maintains, and terminates sessions between applications.

6. Presentation: Standardizes data formats, encryption, and compression.

7. Application: Interfaces directly with user applications and handles services such as HTTP, DNS, SMTP.

Request Flow: Client to Server

And here, I think the best way to illustrate this is a detailed, step-by-step insight into what happens on each layer after entering an address in the browser.

HTTP Request Flow (Browser → Server)

1. Application Layer

   • User enters http://example.com in a browser.

   • Browser generates an HTTP GET request.

   • DNS resolves example.com to an IP address.

2. Presentation Layer

   • Data may be encoded, compressed, or encrypted (e.g., SSL/TLS in HTTPS).

3. Session Layer

   • Establishes communication context (e.g., persistent connection, cookies).

4. Transport Layer

   • TCP is used to ensure reliable delivery.

   • Initiates a three-way handshake: SYN → SYN-ACK → ACK.

   • Data is segmented and includes source/destination ports (e.g., 80).

5. Network Layer

   • Segments are encapsulated in IP packets with source/destination IP addresses.

6. Data Link Layer

   • IP packets are wrapped in Ethernet frames with MAC addresses.

   • ARP may resolve MAC of the default gateway.

7. Physical Layer

   • Frames are transmitted as electrical, optical, or wireless signals.

   • Bits travel through cables, switches, and routers to the server.

HTTP Response Flow (Server → Client)

1. Physical Layer: Bits travel back to the client.

2. Data Link Layer: Ethernet frame includes the client MAC address.

3. Network Layer: Packet carries the client IP as the destination.

4. Transport Layer: TCP ensures the data (e.g., HTTP response) is reliable and ordered.

5. Session Layer: Session context is used or closed.

6. Presentation Layer: Decryption and decoding (e.g., UTF-8, TLS).

7. Application Layer: Response is parsed by the browser and rendered as a webpage.

OSI vs. TCP/IP: A Comparative View

So, if TCP/IP is the set of protocols we use, why do we need the OSI model?

The TCP/IP model describes how its specific protocol suite functions and how the protocols interact. It does not fully describe the physical or data link procedures (e.g., signal encoding, media access) – these are better handled by the lower layers of the OSI model.

Summary:

• The Transport and Network layers have strong parallels.

• The Application layer in TCP/IP covers OSI’s Application, Presentation, and Session layers.

• The Network Access layer in TCP/IP combines the responsibilities of OSI’s Physical and Data Link layers.

The OSI model is better suited for theoretical understanding, while TCP/IP is more practical and implementation-oriented.

Encapsulation in the OSI and TCP/IP Models

Each layer adds its own "envelope" of control information (headers), much like a Russian nesting doll — the data is wrapped layer by layer.

---

Example: HTTP Transmission in the TCP/IP Model (Mapped to OSI Layers)

When you request a webpage, here's a step-by-step breakdown of how your HTTP request transforms as it moves through the network stack, with each layer adding its own "envelope" of information, making the "packet" progressively larger. Think of it like putting a letter into an envelope, then putting that envelope into a bigger package, and so on.

1. Application Layer (OSI Layer 7 – Application) This is where your request originates. For example, a simple GET request for a webpage looks like this:

    GET /index.html HTTP/1.1
    Host: example.com
   

   At this stage, this is pure application-layer data (e.g., HTTP, SMTP, FTP). No network headers have been added yet; it's just the raw message, your "letter."

   Packet Structure at Layer 7:

    ┌───────────────────────────────┐
    │ HTTP Request (Your Data)      │
    └───────────────────────────────┘
   

   (Illustrative Size: HTTP Request Size)

2. Transport Layer (OSI Layer 4 – Transport) Next, the Transport Layer kicks in, typically using TCP for reliable connections. It takes your raw HTTP request and adds a TCP header to it. This header contains crucial information for managing the connection, such as:

    Source Port: 49152 (a random, ephemeral port on your machine)
    Destination Port: 80 (the standard HTTP port on the server)
    Sequence Number: 1000 (for tracking data order)
    ACK Number: 0 (if this is the initial SYN packet)
    Flags: SYN, ACK, etc. (for connection establishment and control)
    Window Size, Checksum, etc.
   

   The original HTTP request now becomes the payload within this new TCP segment. The "packet" has grown, as the TCP header is now prepended to your HTTP data, like putting your letter into an envelope labeled "TCP":

   Packet Structure at Layer 4 (TCP Segment):

    ┌───────────────────────────────┐
    │ TCP Header                    │  <-- New header added here
    ├───────────────────────────────┤
    │ HTTP Request (Payload)        │  <-- Previous layer's data, now encapsulated
    └───────────────────────────────┘
   

   (Illustrative Size: ~20 bytes TCP Header + HTTP Request Size)

3. Internet Layer (OSI Layer 3 – Network) Moving down, the Internet Layer takes over, primarily using the IP (Internet Protocol). It's responsible for logical addressing and routing across different networks. This layer receives the entire TCP segment (TCP header + HTTP data) and adds an IP header to it. The IP header includes:

    Version: IPv4 (or IPv6)
    Source IP: 192.168.0.5 (your local IP address)
    Destination IP: 93.184.216.34 (the server's IP address for example.com)
    TTL (Time To Live): 64 (to prevent packets from looping endlessly)
    Protocol: TCP (06) (indicating the payload is a TCP segment)
    Header Checksum, etc.
   

   The entire TCP segment (which already contains the HTTP request) now becomes the payload of this new IP packet. The "packet" grows again, as the IP header is now prepended to the TCP segment. It's like putting the "TCP envelope" into another, larger envelope labeled "IP":

   Packet Structure at Layer 3 (IP Packet):

    ┌───────────────────────────────┐
    │ IP Header                     │  <-- New header added here
    ├───────────────────────────────┤
    │ TCP Header                    │  <-- Previous layer's header
    ├───────────────────────────────┤
    │ HTTP Request (Payload)        │  <-- Original data, now deeply encapsulated
    └───────────────────────────────┘
   

   (Illustrative Size: ~20 bytes IP Header + ~20 bytes TCP Header + HTTP Request Size)

4. Network Access Layer (OSI Layers 2 – Data Link + 1 – Physical) Finally, at the Network Access Layer, the IP packet is prepared for transmission over the local physical network. If you're on a typical wired LAN, this involves Ethernet. An Ethernet header is prepended to the full IP packet. This header contains physical addressing information:

    Destination MAC: 00:16:3e:12:34:56 (the MAC address of the next hop, e.g., your router)
    Source MAC: 00:1a:2b:3c:4d:5e (your device's MAC address)
    Type: IPv4 (0x0800) (indicating the payload is an IPv4 packet)
   

   The full IP packet (IP header + TCP segment + HTTP data) is now the payload within this final Ethernet frame. This completed Ethernet frame is then converted into electrical signals (or light, or radio waves) and sent across the physical medium. This is the largest "package" your data will be in before it's sent:

   Packet Structure at Layer 2 (Ethernet Frame):

    ┌───────────────────────────────┐
    │ Ethernet Header               │  <-- New header added here
    ├───────────────────────────────┤
    │ IP Header                     │  <-- Previous layer's header
    ├───────────────────────────────┤
    │ TCP Header                    │  <-- Previous layer's header
    ├───────────────────────────────┤
    │ HTTP Request (Payload)        │  <-- Original data, now fully encapsulated
    └───────────────────────────────┘
   

   (Illustrative Size: ~14 bytes Ethernet Header + ~20 bytes IP Header + ~20 bytes TCP Header + HTTP Request Size)

---

This entire process, known as encapsulation, ensures that each layer adds its necessary control information before passing the data down, creating a structured, multi-layered packet ready for its journey across the network.

---

The Fully Encapsulated Packet (Ethernet Frame Ready for Transmission):

Here's how all those layers stack up, forming the complete Ethernet frame that gets sent over the wire. Each header is like a distinct envelope, protecting and guiding the data nested within it:

┌─────────────────────────────────────────────────────────────┐
│ ETHERNET HEADER                                             │  <-- For local network delivery (MAC addresses)
│   Destination MAC: 00:16:3e:12:34:56                        │
│   Source MAC: 00:1a:2b:3c:4d:5e                             │
│   Type: IPv4 (0x0800)                                       │
├─────────────────────────────────────────────────────────────┤
│ IP HEADER                                                   │  <-- For end-to-end routing (IP addresses)
│   Version: IPv4                                             │
│   Source IP: 192.168.0.5                                    │
│   Destination IP: 93.184.216.34                             │
│   TTL: 64                                                   │
│   Protocol: TCP (06)                                        │
│   ... (other IP header fields)                              │
├─────────────────────────────────────────────────────────────┤
│ TCP HEADER                                                  │  <-- For reliable connection management (ports, sequence)
│   Source Port: 49152                                        │
│   Destination Port: 80                                      │
│   Sequence Number: 1000                                     │
│   ACK Number: 0                                             │
│   Flags: SYN                                                │
│   ... (other TCP header fields)                             │
├─────────────────────────────────────────────────────────────┤
│ HTTP REQUEST                                                │  <-- Your original application data
│   GET /index.html HTTP/1.1                                  │
│   Host: example.com                                         │
│   ... (any other HTTP headers/body)                         │
└─────────────────────────────────────────────────────────────┘

This journey of encapsulation is reversed on the receiving end, with each layer stripping off its respective header until the original application-layer data is delivered to its destination.

---

Additional: Three-Way TCP Handshake

The SYN, ACK, and SYN-ACK flags have appeared multiple times in previous examples. I decided to explain what they are at the end because I was wondering about them myself initially, and I think shedding a little light on the matter wouldn't hurt. And since it's easiest to understand with an example, I have one prepared.

TCP is a connection-oriented protocol, meaning a logical connection must be established before data is exchanged. This is done via the three-way handshake:

1. SYN (synchronize)

   • Client sends a TCP segment with the SYN flag.

   • Includes the Initial Sequence Number (ISN).

   • Client state: SYN_SENT

2. SYN-ACK (synchronize-acknowledge)

   • Server replies with SYN + ACK flags.

   • Acknowledges client's ISN with ACK = ISN + 1.

   • Server state: SYN_RECEIVED

3. ACK (acknowledge)

   • Client responds with ACK.

   • Acknowledges server’s ISN.

   • Both client and server state: ESTABLISHED

Sequence Example:

Why it matters:

• Reliability: Ensures both sides are ready.

• Synchronization: Establishes sequence numbers.

• Security: Basic protection against attacks like SYN flooding.

Summary

This was a fairly long article, packed with a good amount of information. It took me the longest to write so far, mainly because I really wanted to understand the subject well. I went through the lesson on Cisco Academy and read it at least a few times, just to be sure I knew exactly what was going on. I think this topic is crucial for a few reasons—it's hard to move forward in your networking journey without knowing it, and these concepts also frequently come up in the daily work of both programmers and DevOps engineers. I remember often encountering, for example, the mentioned layer numbers in the OSI model in articles, tutorials, or conversations and wondering what they meant. I hope this article clarifies the issue to some extent, or at least provides a reference point before exploring the topic on your own from other sources.