What actually happens when you send "hello" from one computer to another.

Introduction

When you send data over a network, it doesn't simply travel from one computer to another as plain text. The data is formatted, encapsulated, addressed, transmitted, routed, and eventually reconstructed on the receiving side.

A useful way to understand this process is the OSI Model — a conceptual model that divides network communication into seven layers, each responsible for a different part of the communication process.

Understanding these layers helps you reason about networking problems: is this an application issue, a TCP issue, a routing issue, a local-network issue, or a physical-connection issue? That's one of the most useful mental models for debugging as a developer.

Important: The OSI model is primarily a conceptual framework. Modern networks don't literally implement seven independent layers exactly as described below. The real Internet is largely based on the TCP/IP model, where several OSI layers are combined.

The Big Picture

When Computer A sends data to Computer B, the data moves down the networking stack on the sender.

It then travels across the network through devices such as switches and routers.

Finally, it moves up the networking stack on the receiver.

SENDER                              RECEIVER
 
Application  (L7)                   Application  (L7)
Presentation (L6)                   Presentation (L6)
Session      (L5)                   Session      (L5)
Transport    (L4)                   Transport    (L4)
Network      (L3)                   Network      (L3)
Data Link    (L2)                   Data Link    (L2)
Physical     (L1)                   Physical     (L1)
       │                                   ▲
       │  (encapsulation)                  │  (decapsulation)
       ▼                                   │
       └──────────► Switches / Routers ────┘

However, the network devices in between don't process all seven layers.

For example, a typical router primarily works with Layer 3 (Network) information to forward packets.

The 7 Layers at a Glance

A common mnemonic from top to bottom is:

All People Seem To Need Data Processing

Before We Start: One Important Correction

It's tempting to imagine the process like this:

hello
 ↓
binary
 ↓
session
 ↓
TCP
 ↓
IP
 ↓
MAC
 ↓
electrical signal

That's useful as a learning model, but it isn't literally what happens on a modern computer.

For example:

• Applications already work with bytes; there isn't a separate "convert everything to binary" step.
• TCP doesn't take one application message and create one segment for it — it works with a continuous byte stream.
• TLS encryption doesn't map neatly onto OSI Layer 6 in modern implementations.
• Session management usually isn't a distinct Layer 5 protocol.
• MAC addresses matter for local-link delivery, not end-to-end Internet communication — they change at every hop.
• Routers don't simply forward a packet based on its IP address alone; they use their routing table and other information.

We'll unpack each of these as we go. With that in mind, let's follow a realistic example.

Step-by-Step: Sending "hello"

Imagine Computer A wants to send "hello" to a server on another network:

Computer A → Home Router → ISP → Internet → Server

Let's see what happens.

Layer 7: Application

At the top is the Application layer. This is where network-aware applications operate.

Examples include:

• Web browsers
• Chat applications
• Email clients
• API clients
• DNS clients

The application doesn't directly control Ethernet, Wi-Fi, or electrical signals; it hands data to the networking stack via a protocol. For example, an HTTP request might carry:

POST /message HTTP/1.1
Content-Type: application/json
 
{"message":"hello"}

The application gives this data to the networking stack.

Layer 6: Presentation

Conceptually responsible for how data is represented: character encoding, serialization, compression, encryption/decryption. For example, "hello" as UTF-8 bytes is 68 65 6C 6C 6F.

But this doesn't mean "convert text to binary" as a separate networking step — computers already represent data as bytes internally. The important question is: how are those bytes represented and interpreted by the communicating applications.

What about HTTPS? HTTPS is HTTP over TLS, and TLS provides encryption, authentication, and integrity. You can loosely associate TLS with the Presentation layer, but in practice it doesn't fit neatly into one OSI layer. A more accurate statement: the OSI Presentation layer conceptually includes encryption, while real protocols like TLS span multiple OSI layers.

Layer 5: Session

The Session layer conceptually manages communication sessions between applications.

It deals with things such as:

• Establishing communication
• Maintaining a session
• Synchronizing communication
• Ending a session

However, this is one of the biggest differences between the OSI model and real-world networking.

Modern Internet protocols generally don't have a separate Session layer implementation.

For example, when you're using a web application, session behavior may be handled using:

• HTTP cookies
• Authentication tokens
• Application state
• TLS connections
• TCP connections

So don't think of Layer 5 as:

L5 = a special "session protocol"

Instead, think:

Layer 5 is a useful conceptual category for managing communication sessions, but its responsibilities are often handled by protocols at other layers or by the application itself.

Layer 4: Transport

Now we reach one of the most important layers for developers. This layer provides communication between processes running on different machines.

Two of the most important transport protocols are:

• TCP
• UDP

TCP

TCP provides features such as:

• Reliable delivery
• Ordered delivery
• Retransmission
• Flow control
• Congestion control
• Connection-oriented communication

TCP also uses port numbers.

For example:

Source Port:      50000
Destination Port: 443

Port 443 is commonly used for HTTPS.

This allows one computer to run many networked applications simultaneously.

For example:

Computer
│
├── Browser → port 50000
├── SSH     → port 50001
├── Database connection → port 50002
└── Another application → port 50003

The destination server can use the destination port to determine which service should receive the data.

Does TCP split your message into segments?

Conceptually, yes — but there's an important nuance.

Suppose your application gives TCP:

hello

TCP doesn't necessarily create:

Segment 1 = hello

Instead, TCP treats the application data as a byte stream.

It can divide that stream into TCP segments according to factors such as:

• Maximum Segment Size (MSS)
• Available network conditions
• TCP implementation behavior

So if an application sends a large amount of data:

Application data
─────────────────────────────
AAAAAAAAAAAAAAAAAAAAAAAAAAAA
BBBBBBBBBBBBBBBBBBBBBBBBBBBB
CCCCCCCCCCCCCCCCCCCCCCCCCCCC
─────────────────────────────
             ↓
        TCP segments
             ↓
 
Segment 1
Segment 2
Segment 3
...

TCP also assigns sequence numbers so the receiver can reconstruct the byte stream correctly.

UDP

UDP is much simpler.

It provides:

• Port numbers
• Message/datagram boundaries
• A lightweight transport mechanism

But UDP does not provide TCP's built-in guarantees of:

• Reliable delivery
• Ordering
• Retransmission
• Congestion control

That's why applications that use UDP often implement whatever reliability or ordering they need themselves.

UDP is commonly used in things such as:

• DNS
• Real-time communications
• Online games
• Streaming-related protocols

Although modern applications may use different protocols depending on their requirements.

Layer 3: Network

Now we reach the Network layer.

This layer is responsible for moving packets between different networks.

The most important protocol here is:

IP - Internet Protocol

The packet contains information such as:

Source IP:
192.168.1.10
 
Destination IP:
172.217.160.78

The source and destination IP addresses provide logical addressing.

What does a router do?

Imagine your computer has:

IP: 192.168.1.10

and wants to communicate with:

172.217.160.78

That destination isn't on your local network.

Your computer therefore sends the packet toward its default gateway, usually your home router.

The router examines the destination IP and consults its routing table.

Conceptually:

Destination: 172.217.160.78
 
             ↓
        Routing table
             ↓
       Next hop / interface
             ↓
          Forward

The next router performs a similar process.

Eventually:

Computer
   ↓
Router
   ↓
Router
   ↓
Router
   ↓
Destination network

Layer 2: Data Link

Layer 2 is responsible for communication across a local network link.

Examples include:

• Ethernet
• Wi-Fi

This is where MAC addresses are commonly used.

Suppose your computer needs to send an IP packet to its local router.

Your computer may create an Ethernet or Wi-Fi frame containing:

Source MAC:
AA:BB:CC:DD:EE:FF
 
Destination MAC:
11:22:33:44:55:66

The important distinction is:

IP addresses are used for logical, routed communication. MAC addresses are used for local-link delivery.

IP Address vs MAC Address

This distinction is extremely important.

Suppose:

Computer A
IP: 192.168.1.10
MAC: AA:AA:AA
 
Router
IP: 192.168.1.1
MAC: BB:BB:BB

Computer A wants to reach:

8.8.8.8

The destination IP remains:

8.8.8.8

But the Layer 2 destination is initially the router's MAC address:

Destination MAC:
BB:BB:BB

The frame reaches the router. The router removes the old Layer 2 frame and creates a new Layer 2 frame for the next link. So the MAC addresses can change at every hop.

The IP packet, however, is intended to travel end-to-end, subject to normal IP processing such as TTL/hop-limit changes and possible NAT.

Layer 1: Physical

Finally, we reach the Physical layer. At this point, the bits are transmitted using physical signals. Depending on the medium, those signals could be:

Ethernet cable

Electrical signals.

Fiber optic cable

Light pulses.

Wi-Fi

Radio waves.

Conceptually:

Bits
 ↓
Physical encoding
 ↓
Electrical / optical / radio signals
 ↓
Transmission

The Physical layer doesn't understand:

"hello"

It deals with transmitting signals that represent data.

Crossing the Network

Now the data leaves Computer A. A simplified path might look like:

Computer A
     │
     │ Wi-Fi / Ethernet
     ▼
Home Router
     │
     │
     ▼
ISP Router
     │
     │
     ▼
Internet Router
     │
     │
     ▼
More Routers
     │
     ▼
Destination Network
     │
     ▼
Server

But here's something very important:

The entire Layer 2 frame does NOT travel across the Internet unchanged.

At each routed hop, the Layer 2 frame is removed and a new frame is created for the next link.

For example:

Computer A → Router
 
MAC A → MAC Router 1
IP A  → IP Server

Then:

Router 1 → Router 2
 
MAC Router 1 → MAC Router 2
IP A           → IP Server

Then:

Router 2 → Router 3
 
MAC Router 2 → MAC Router 3
IP A           → IP Server

This is a crucial distinction:

MAC addresses are hop-by-hop.

IP addresses are used for routed, end-to-end addressing.

What Does a Router Actually See?

A common misconception is:

"Routers only see Layer 3 and don't care about anything else."

That's a useful beginner simplification, but reality is slightly more complicated. A router must process the Layer 2 frame that arrives on its interface. It then examines the IP packet inside to determine where to forward it. Depending on the technology and configuration, routers can also inspect information from higher layers.

For example, some devices perform:

• NAT
• Firewall filtering
• QoS
• Load balancing
• Application-aware inspection

So a better statement is:

Traditional routing primarily makes forwarding decisions using Layer 3 information, but real network devices can inspect and modify information from other layers as well.

Receiving Side: Decapsulation

The data reaches Computer B and moves back up the stack — this is called decapsulation:

• Physical: the interface receives signals and converts them to bits.
• Data Link: the interface processes the incoming frame (checking structure, destination, integrity) and passes the IP packet upward.
• Network: IP checks source/destination addresses, confirms the packet is meant for this machine, and passes the payload to the transport layer.
• Transport: TCP handles sequence numbers, retransmissions, and reassembly, delivering the application a clean byte stream (or UDP simply delivers a datagram).
• Session/Presentation: as on the sending side, there's usually no dedicated Layer 5/6 protocol here — encoding is interpreted (e.g., UTF-8 bytes → "hello"), and if TLS is in play, records are decrypted as part of that implementation before the application ever sees the data.
• Application: the application finally receives "hello" and can display it, e.g., in a chat window.

The journey is complete.

What Gets Added at Each Layer (Encapsulation)

Application data:        [ "hello" ]
Transport segment:       [ TCP/UDP header | "hello" ]
IP packet:               [ IP header | TCP/UDP header | "hello" ]
Ethernet/Wi-Fi frame:    [ L2 header | IP header | TCP/UDP header | "hello" ]

At the receiver, these headers are stripped off in reverse order — decapsulation.

Not every layer adds a distinct header, though. TCP, UDP, IP, and Ethernet each add real headers (and Ethernet a trailer). TLS adds its own protocol structures. But Layers 5 and 6 don't add a standardized "Session header" or "Presentation header" — which is exactly why it's more useful to think of OSI layers as responsibilities, not seven physical wrappers.

The Full Flow

Here's the conceptual flow from beginning to end:

 
                       "hello"
                          │
                          ▼
                  Application (L7)
                          │
                          ▼
              Data representation / TLS
                     (L6 concept)
                          │
                          ▼
                 Session concepts
                     (L5 concept)
                          │
                          ▼
              TCP / UDP + ports (L4)
                          │
                          ▼
                  IP packet (L3)
                          │
                          ▼
               Ethernet/Wi-Fi frame (L2)
                          │
                          ▼
                Physical signals (L1)
                          │
                          ▼
                     NETWORK
                          │
               ┌──────────┴──────────┐
               │                     │
            Router                Router
               │                     │
               └──────────┬──────────┘
                          │
                          ▼
                    DESTINATION
                          │
                          ▼
                Physical signals (L1)
                          │
                          ▼
               Ethernet/Wi-Fi frame (L2)
                          │
                          ▼
                  IP packet (L3)
                          │
                          ▼
              TCP / UDP + ports (L4)
                          │
                          ▼
                 Session concepts
                     (L5 concept)
                          │
                          ▼
              Data representation / TLS
                     (L6 concept)
                          │
                          ▼
                  Application (L7)
                          │
                          ▼
                       "hello"

The TCP/IP Model

For understanding how the Internet actually works, developers often find the TCP/IP model more useful than the full seven-layer OSI model:

OSI's top three layers collapse into a single "Application" layer in TCP/IP, and the bottom two collapse into "Link." This is closer to how the Internet is actually structured.

One More Important Concept: Data Units

You'll often hear different names for data as it moves through the stack.

For example:

Application
     │
     │ data
     ▼
   TCP
     │
     │ segment
     ▼
    IP
     │
     │ packet
     ▼
 Ethernet
     │
     │ frame
     ▼
Physical
     │
     │ bits/signals
     ▼
   Network

These terms describe how the data is packaged at different stages.

What About NAT?

If your computer is behind a home router, there may be another important operation:

NAT — Network Address Translation.

Your computer might have:

Private IP:
192.168.1.10

But the router has a public IP such as:

203.0.113.50

When traffic leaves your home network, the router can translate the source information so the Internet sees the public address.

Conceptually:

Computer
 
192.168.1.10:50000
       │
       ▼
Home Router
       │
       │ NAT
       ▼
203.0.113.50:62001
       │
       ▼
Internet

This is another reason the simplistic statement:

"The source IP never changes."

isn't universally true.

In a basic routed path without NAT, the source/destination IP addresses generally remain the same across hops, aside from normal IP processing. But NAT devices can modify addresses.

A Real-Life Analogy: Sending a Package

• Application (L7): the actual message you want to send — "Hello!"
• Presentation (L6): how it's formatted or protected — language, encoding, encryption.
• Session (L5): the ongoing conversation context between you and the recipient.
• Transport (L4): how you choose to ship it — tracked and reliable, or fast and untracked.
• Network (L3): the destination's overall address — country, city, street.
• Data Link (L2): The local delivery system figures out how to move the package across the current local link.
• Physical (L1): the actual vehicle — truck, plane, ship.

At each major stage, the local delivery information can change while the overall destination remains the same.

That's similar to how Layer 2 information changes from hop to hop while Layer 3 provides the broader routed destination.

Why This Matters for Developers

You don't need to memorize all seven layers. What matters is using them as a debugging framework.

"My server isn't reachable." Work from the bottom up: is the machine connected (Physical/Data Link)? Can it reach the destination IP (Network)? Is the TCP port open (Transport)? Is the application actually listening (Application)?

"Ping works, but my API doesn't." Ping uses ICMP at the network layer to confirm IP reachability, but that tells you nothing about whether TCP connections to the API's port will succeed, whether TLS will complete, or whether the HTTP application is actually healthy. Instead of assuming the server is down, split the problem into stages: IP connectivity → TCP handshake → TLS handshake (if HTTPS) → HTTP request → application response. That’s a far more actionable framing than “the network is fine.”

"DNS works, but the website doesn't." DNS is an application-layer protocol that resolves names to IPs. If it succeeds but the site still doesn't load, split the problem into stages: DNS resolution → IP connectivity → TCP connection → TLS handshake → HTTP request → application response. That's a far more actionable framing than "the Internet is broken."

Tools by what they help you investigate

You don't have to think of each tool as belonging to exactly one OSI layer.

Instead, ask:

What part of the communication does this tool let me observe?

A Practical Debugging Example

Suppose you run:

curl https://example.com

and it fails.

Instead of immediately changing random configuration, reason through the stack:

1. DNS

Can the hostname resolve?

dig example.com

If not:

DNS problem

2. IP connectivity

Can your machine reach the destination?

ping <IP>

A failed ping isn't conclusive because ICMP may be blocked, but it can provide useful information.

3. TCP

Can you establish a connection to port 443?

nc -vz example.com 443

If this fails:

Possible routing,
firewall,
or TCP connectivity problem.

4. TLS

Can the TLS handshake complete?

curl -v https://example.com

If TCP connects but TLS fails:

Possible TLS/certificate/
protocol configuration problem.

5. HTTP

Does the server return the expected HTTP response?

HTTP/1.1 200 OK

or perhaps:

HTTP/1.1 500 Internal Server Error

Now you're dealing primarily with an application/server problem.

Summary

The OSI model gives us a useful way to reason about network communication:

L7  Application      → What the application wants to communicate
L6  Presentation     → How the data is represented/protected
L5  Session          → Communication/session management concepts
L4  Transport        → Process-to-process delivery
L3  Network          → Delivery between networks
L2  Data Link        → Delivery across a local link
L1  Physical         → Transmission of signals

The key concepts to remember are:

1. The OSI model is a conceptual model, not an exact implementation of the modern Internet.

2. The TCP/IP model more closely reflects how Internet protocols are organized.

3. TCP and UDP operate at the Transport layer.

4. IP operates at the Network layer.

5. Ethernet and Wi-Fi operate primarily at the Data Link and Physical layers.

6. MAC addresses are primarily used for local-link delivery and can change at each routed hop.

7. IP addresses are used for routing between networks, although NAT can modify them.

8. TCP provides a reliable byte stream; it doesn't preserve application message boundaries.

9. TLS, sessions, encoding, and other real-world functionality don't always fit neatly into one OSI layer.

10. Encapsulation happens as data moves down the stack; decapsulation happens as it moves up.

And perhaps the most useful developer takeaway is this:

When something doesn't work, don't just ask "Why is the network broken?" Ask "Which part of the communication path is failing?"

DNS
 ↓
IP connectivity
 ↓
TCP/UDP
 ↓
TLS
 ↓
HTTP
 ↓
Application

Once you start thinking this way, networking problems become much easier to break down.