> For the complete documentation index, see [llms.txt](https://naz.gitbook.io/my-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://naz.gitbook.io/my-docs/basic-networking/tcp_ip_model_ccna_day3.md).

# TCP/IP Model

## Protocols and Standards

A protocol is a set of rules defining how data should be communicated between devices over a network. Protocols are the languages computers use to speak to each other. Just as someone who only speaks Chinese cannot talk with someone who only speaks English, computers that speak different protocols cannot exchange data.

In the early days, protocols were often developed by a specific vendor, like IBM, to be used with their own products. This proprietary approach made communication between different vendors difficult. For example, an Apple iMac using its own protocols would not be understood by an IBM server using different ones.

Today, networks use standard, vendor-neutral protocols. A standard is an agreed-upon specification describing how a protocol or technology should work. When devices follow the same standard, they can communicate regardless of who made them.

* An Apple MacBook can access a website hosted on a Linux server
* A Windows PC can send an email that can be read on an Android smartphone

```mermaid
flowchart TB
    Apple["Apple iMac<br/>(proprietary protocols)"] -->|X| IBM["IBM Server<br/>(proprietary protocols)"]
    Mac["Apple MacBook<br/>(vendor-neutral)"] -->|check| Linux["Linux Server<br/>(vendor-neutral)"]
    PC["Windows PC<br/>(vendor-neutral)"] -->|check| Android["Android Phone<br/>(vendor-neutral)"]
```

## A Bit of History

Early work on computer networks began in the 1960s, mainly in the US. The Department of Defense's ARPA (Advanced Research Projects Agency) funded ARPANET, which came online in 1969 to connect mainframes at universities and labs around the country.

ARPANET originally used a protocol called NCP (Network Control Program). There was no TCP/IP in the early days.

In 1974, Vint Cerf and Bob Kahn began developing TCP (Transmission Control Program) as an internetworking protocol. TCP went through several revisions and was later split into two protocols still used today:

* **TCP** — Transmission Control Protocol (note: "Program" became "Protocol")
* **IP** — Internet Protocol

Together, these two form the foundation of the protocol suite known as TCP/IP. ARPANET fully switched to use TCP/IP on January 1st, 1983.

TCP/IP became dominant over other vendor-proprietary solutions because it was published as open standards that any vendor could implement, and it could run over many different types of networks.

```mermaid
flowchart LR
    ARPANET["ARPANET<br/>(1969)"] -->|"used"| NCP["NCP"]
    NCP -->|"replaced by"| TCP_IP["TCP/IP<br/>(1974-1983)"]
    TCP_IP -->|"open standard"| Internet["Modern Internet"]
```

## Who Defines the Standards?

Most networking standards are created by independent organizations, not by a single vendor. Engineers from many companies participate in the process.

### IEEE — Institute of Electrical and Electronics Engineers

The IEEE develops technologies used on local area networks:

* **Ethernet** — defined in the 802.3 standards
* **Wi-Fi** — defined in the 802.11 standards

These standards include physical specifications like cable types and radio frequencies, plus how to format messages for sending data over the medium.

### IETF — Internet Engineering Task Force

The IETF is an open community that defines many Internet protocols:

* TCP, IP, UDP, HTTP, DNS

The IETF publishes standards in documents called **RFCs** (Requests for Comments), all freely available online.

```mermaid
flowchart TB
    IEEE["IEEE"] -->|"802.3"| Ethernet["Ethernet"]
    IEEE -->|"802.11"| WiFi["Wi-Fi"]
    IETF -->|"RFCs"| TCP["TCP"]
    IETF -->|"RFCs"| IP["IP"]
    IETF -->|"RFCs"| UDP["UDP"]
    IETF -->|"RFCs"| HTTP["HTTP"]
    IETF -->|"RFCs"| DNS["DNS"]
```

## Layered Models

Networks perform many jobs when moving data from one computer to another:

* Physical transmission of signals
* Local delivery of messages on a LAN
* Routing traffic between networks
* Maintaining end-to-end conversations
* The applications themselves

A model groups related jobs into layers. Each layer has a specific role, uses the services of the layer below, and provides services to the layer above. Protocols live mostly at one layer, and together they form a **network stack**.

RFC 791, published in 1981 and still current today, defines a protocol stack with these layers:

* **Application layer**: Telnet, FTP, TFTP
* **Transport layer**: TCP, UDP
* **Internet layer**: IP (versions 4 and 6)
* **Link layer**: Ethernet, Wi-Fi

The TCP/IP model is a description, not a law. Different textbooks use slightly different models — some with 4 layers, some with 5, some with more.

```mermaid
flowchart TB
    subgraph TCP_IP["TCP/IP Protocol Stack"]
        direction TB
        APP["5 Application Layer<br/>Telnet, FTP, TFTP"]
        TRANS["4 Transport Layer<br/>TCP, UDP"]
        INTERNET["3 Internet Layer<br/>IP v4, IP v6"]
        LOCALNET["2 Local Network Layer<br/>Ethernet, Wi-Fi"]
        PHYSICAL["1 Physical Layer<br/>Cables, signals"]
    end

    APP --> TRANS --> INTERNET --> LOCALNET --> PHYSICAL
```

## Analogy: Sending a Letter

Consider sending a letter to a friend via the post. You write a letter addressed to Bob, put it in an envelope addressed to Bob's house, and deliver it to post office A.

Notice the three different destinations:

* Your car goes to post office A
* The envelope goes to Bob's house
* The letter goes to Bob himself

Post office A moves the envelope to a truck and delivers it to post office B. The truck's destination is post office B, but the envelope and letter inside keep their original destinations. Post office B then moves the envelope to a new truck and delivers it to Bob's house, where the envelope is opened and the letter is read.

Different parts care about different things: the message itself, who should read it, which house it goes to, and how it moves along the route.

```mermaid
flowchart LR
    You["You<br/>write letter"] -->|car| POA["Post Office A"]
    POA -->|truck| POB["Post Office B"]
    POB -->|truck| BobHouse["Bob's House"]
    BobHouse -->|read| Bob["Bob"]
```

## Building the Model from the Analogy

The mail system maps to a layered model:

| Mail System Layer    | TCP/IP Layer        | What It Focuses On                        |
| -------------------- | ------------------- | ----------------------------------------- |
| Content layer        | Application layer   | The actual text of the letter             |
| Recipient layer      | Transport layer     | Who inside the house should read it (Bob) |
| Address layer        | Internet layer      | Which house the letter goes to            |
| Local delivery layer | Local Network layer | Moving the envelope to the next stop      |
| Infrastructure layer | Physical layer      | Roads and paths the vehicles travel on    |

The bottom two layers always work together. If traveling over ground, local delivery uses a car or truck. If traveling by air, it uses an airplane. If by water, a ship. You can think of these as one combined delivery layer or split into two — this is why some networking models use 4 layers and some use 5.

```mermaid
flowchart TB
    Content["Content Layer<br/>(what to say)"] --> Recipient["Recipient Layer<br/>(who reads it)"]
    Recipient --> Address["Address Layer<br/>(which house)"]
    Address --> Local["Local Delivery Layer<br/>(car/truck)"]
    Local --> Infra["Infrastructure Layer<br/>(roads)"]
```

## Separation of Layers

Each layer has its own job. The Content layer focuses on the actual contents of the letter, which doesn't change throughout the journey. The Recipient layer focuses on who should receive it. The Address layer focuses on the house address. The Local Delivery layer focuses on getting the letter to the next stop. The Infrastructure layer is the roads and trucks.

What happens inside one layer doesn't change the job of other layers:

* Changing the content doesn't change the delivery steps
* Changing the delivery path doesn't affect the letter itself

When writing the letter, you don't have to think about how the postal service will deliver it. But the layers aren't entirely independent — if you address the letter overseas, that influences how it's delivered. That's just not your concern as you write the letter.

## The TCP/IP Model

The five layers of the mail system map directly to the TCP/IP model:

* Content layer = **Application layer**
* Recipient layer = **Transport layer**
* Address layer = **Internet layer**
* Local delivery layer = **Local Network layer**
* Infrastructure layer = **Physical layer**

To see how these work in a real network, consider PC1 (a client running Chrome) wanting to access a web page hosted on SRV1 (a server running a web server and a file server). Between them are two routers (R1, R2) and two switches (SW1, SW2).

```mermaid
flowchart LR
    PC1["PC1<br/>Chrome<br/>(client)"] <-->|Ethernet| SW1["SW1<br/>(switch)"]
    SW1 <-->|Ethernet| R1["R1<br/>(router)"]
    R1 <-->|link| R2["R2<br/>(router)"]
    R2 <-->|Ethernet| SW2["SW2<br/>(switch)"]
    SW2 <-->|Ethernet| SRV1["SRV1<br/>Web Server<br/>File Server"]
```

## Layer 5: Application Layer

The Application layer includes protocols for communication between application processes. It's responsible for creating and interpreting the data.

When Chrome on PC1 sends a request to the web server on SRV1, it uses an Application-layer protocol like HTTP to format and send the message. The same protocol tells the web server how to interpret what it receives.

Protocols at this layer define message formats and rules for specific tasks:

* **HTTP / HTTPS** — browsing web pages
* **FTP, TFTP** — file transfers
* Email uses its own protocols too

Network infrastructure devices like routers and switches don't care about Application-layer details. They just move messages across the network. Only the communicating hosts (PC1 and SRV1) look at and interpret the Application-layer data.

```mermaid
sequenceDiagram
    participant Chrome as Chrome (PC1)
    participant WebSvr as Web Server (SRV1)
    participant FileSvr as File Server (SRV1)

    Chrome->>WebSvr: HTTP GET /index.html
    WebSvr-->>Chrome: HTTP Response (HTML)
    Note over Chrome,WebSvr: Only these two processes care about HTTP

    Note right of FileSvr: File server ignores this traffic
```

## Layer 4: Transport Layer

SRV1 runs multiple services — a web server and a file server. When it receives a message, it needs to know which service should handle it. The Transport layer solves this by providing end-to-end communication between application processes using **port numbers**.

* Port **80** for the web server
* Port **21** for the file server

Don't be confused by the name "port" — these aren't physical ports like Ethernet jacks. A port is just a number used to identify a process running on a host.

When Chrome on PC1 wants to reach the web server on SRV1, it addresses the message to port 80. If it wanted the file server instead, it would use port 21. This is why the Transport layer is also called "process-to-process" or "service-to-service" communication.

Layer 4 runs mainly on the communicating hosts (PC1 and SRV1). Routers normally operate based on IP (Layer 3), not Transport-layer information.

The two most prominent protocols:

* **UDP** — User Datagram Protocol
* **TCP** — Transmission Control Protocol

They offer different features, covered later in the course.

```mermaid
sequenceDiagram
    participant PC1 as Chrome (PC1)
    participant SRV1 as SRV1

    PC1->>SRV1: HTTP request -> port 80
    Note right of SRV1: Web server handles this
    PC1->>SRV1: FTP request -> port 21
    Note right of SRV1: File server handles this

    Note over PC1,SRV1: Port numbers decide which process gets the data
```

## Layer 3: Internet Layer

Even if the message is addressed to the correct port on SRV1, it still has to reach SRV1 in the first place. SRV1 has an **IP address** for that purpose (e.g., `10.1.1.1`).

By addressing its message to SRV1's IP address, PC1 tells the routers in the path which host the message should be delivered to. The Internet layer provides end-to-end delivery between hosts across multiple networks. "Internet" means "internetwork" — multiple networks connected together.

**Routers** operate mainly at this layer. They use the destination IP address to forward the message toward its final destination host.

Protocols at this layer:

* **IP** (both version 4 and version 6)
* **ICMP** — Internet Control Message Protocol

```mermaid
sequenceDiagram
    participant PC1 as PC1 (10.1.1.2)
    participant R1 as R1
    participant R2 as R2
    participant SRV1 as SRV1 (10.1.1.1)

    Note over PC1,SRV1: All care about destination IP 10.1.1.1
    PC1->>R1: packet -> dest 10.1.1.1
    R1->>R2: packet -> dest 10.1.1.1
    R2->>SRV1: packet -> dest 10.1.1.1

    Note over PC1,SRV1: IP addresses guide the journey end-to-end
```

## Layer 2: Local Network Layer

There are several devices between PC1 and SRV1. The Local Network layer provides **hop-to-hop** delivery within a local network using **MAC addresses** and switches.

A hop is one step along the path from one router or host to the next:

* Hop 1: PC1 to R1
* Hop 2: R1 to R2
* Hop 3: R2 to SRV1

Three hops total. Switches don't count as hops — a switch just extends the local network.

Each device on a LAN has a unique MAC address for each interface. PC1 sends the message to the MAC address of R1's G1 interface. R1 sends it to the MAC address of R2's G1 interface. R2 sends it to the MAC address of SRV1's interface.

Key protocols at this layer:

* **Ethernet**
* **Wi-Fi**

By far the most commonly used Layer 2 protocols.

```mermaid
flowchart LR
    PC1["PC1"] -->|frame| SW1["SW1"]
    SW1 -->|frame| R1_G1["R1<br/>G1 interface"]
    R1_G1 -->|frame| R2_G1["R2<br/>G1 interface"]
    R2_G1 -->|frame| SW2["SW2"]
    SW2 -->|frame| SRV1["SRV1"]
```

## Layer 1: Physical Layer

All the cables connecting devices, and the transceivers that transmit and receive signals. The Physical layer sends **bits** as electrical, optical, or radio signals over the physical medium.

* Electrical signals over copper UTP cables
* Optical signals over fiber-optic cables
* Radio signals over wireless Wi-Fi connections

It defines cables, connectors, signal levels, and link speeds — all the physical aspects of communication.

Examples:

* Copper UTP ports and cables
* Fiber-optic cables
* Network interface cards (NICs)

The physical aspects of transmitting data are very complex, involving electrical and optical engineering. Fortunately, network engineers typically don't need the low-level details of how it all works.

```mermaid
flowchart TB
    NIC["Network Interface Card<br/>(NIC)"] -->|"electrical signals"| UTP["Copper UTP Cable"]
    NIC -->|"optical signals"| Fiber["Fiber-Optic Cable"]
    NIC -->|"radio signals"| WiFi["Wi-Fi Radio"]
```

## Encapsulation

To show how encapsulation works, simplify the network to a direct connection between PC1 and SRV1. The Application layer prepares the data (e.g., an HTTP request). As the message moves down the stack, each layer adds a header with its own information:

1. **Layer 4** adds a header with source and destination port numbers
2. **Layer 3** adds a header with source and destination IP addresses
3. **Layer 2** adds both a header and a trailer (the trailer checks for transmission errors)
4. **Layer 1** transmits the bits as signals over the physical medium

The Layer 2 header is transmitted first, the Layer 2 trailer is transmitted last.

```mermaid
flowchart TB
    APP["Application Data<br/>(HTTP request)"] -->|"add L4 header"| L4["Segment/Datagram<br/>+ ports"]
    L4 -->|"add L3 header"| L3["Packet<br/>+ IPs"]
    L3 -->|"add L2 header + trailer"| L2["Frame<br/>+ MACs"]
    L2 -->|"transmit bits"| L1["Physical Signal<br/>electrical/optical/radio"]
```

## Decapsulation

The receiving device receives the message as a stream of bits at Layer 1. Layer 1 passes those bits up to the next layer. The device then:

1. Examines the **Layer 2** header and trailer, then removes them
2. Layer 3 examines and removes the **Layer 3** header
3. Layer 4 examines and removes the **Layer 4** header
4. The data is delivered to the **Application** layer

The application processes the data and, if needed, generates a response that goes back down the stack, transmitted back to PC1.

Each device has its own network stack. A message from PC1 goes down its stack, crosses the wire, and then goes up SRV1's stack where the Application layer processes it. The response does the same in the opposite direction.

```mermaid
flowchart BT
    L1["Physical Signal<br/>bits on wire"] -->|"strip L2 header/trailer"| L2["Frame decoded"]
    L2 -->|"strip L3 header"| L3["Packet extracted"]
    L3 -->|"strip L4 header"| L4["Segment/Datagram"]
    L4 -->|"deliver to app"| APP["Application Data<br/>(processed)"]
```

## Protocol Data Units (PDUs)

At each stage in the encapsulation process, there is a name for the message:

* **Layer 4 PDU (L4PDU)**: segment (TCP) or datagram (UDP)
* **Layer 3 PDU (L3PDU)**: packet
* **Layer 2 PDU (L2PDU)**: frame

TCP creates segments, UDP creates datagrams. This difference relates to how TCP and UDP treat the data.

The frame is what is actually sent over the wire. You'll never see a packet, segment, or datagram on the wire itself — they are always sent inside a frame.

**Payload** is everything encapsulated by that layer's header and trailer:

| Layer   | PDU                | Payload                                |
| ------- | ------------------ | -------------------------------------- |
| Layer 4 | Segment / Datagram | Application data                       |
| Layer 3 | Packet             | Segment or datagram (L4 header + data) |
| Layer 2 | Frame              | Packet (L3 header + L4 header + data)  |

```mermaid
flowchart LR
    APP["App Data"] -->|"L4 encapsulates"| SEG["Segment<br/>(TCP) or<br/>Datagram<br/>(UDP)"]
    SEG -->|"L3 encapsulates"| PKT["Packet"]
    PKT -->|"L2 encapsulates"| FRM["Frame"]
    FRM -->|"on wire"| WIRE["Bits on wire"]
```

## Adjacent-Layer and Same-Layer Interaction

**Adjacent-layer interaction**: each layer provides a service to the layer above and is serviced by the layer below.

* Layer 4 to Layer 5: delivers data to the correct application using port numbers
* Layer 3 to Layer 4: delivers segments/datagrams to the correct host using IP addresses
* Layer 2 to Layer 3: delivers packets to the next hop using MAC addresses
* Layer 1 to Layer 2: sends and receives bits as signals over the medium

**Same-layer interaction**: each layer communicates with the same layer on other devices.

* Application layer on PC1 sends data to Application layer on SRV1
* Segment/datagram is addressed to the correct port on SRV1
* Packet is addressed to SRV1's IP address
* Frame is addressed to the next hop's MAC address
* Signals from a physical port are received by a physical port on the connected device

```mermaid
sequenceDiagram
    participant PC1 as PC1 (all layers)
    participant SRV1 as SRV1 (all layers)

    Note over PC1: L5 sends to L5 on SRV1
    PC1->>SRV1: L5 data to L5
    Note over PC1: L4 sends to L4 on SRV1
    PC1->>SRV1: L4 segment to L4
    Note over PC1: L3 sends to L3 on SRV1
    PC1->>SRV1: L3 packet to L3
    Note over PC1: L2 sends to L2 on next hop
    PC1->>SRV1: L2 frame to L2
    Note over PC1: L1 sends bits on wire
    PC1->>SRV1: L1 bits to L1

    Note over PC1,SRV1: Same-layer = peer talks to peer
    Note over PC1,SRV1: Adjacent-layer = each layer uses the one below
```

## Separation of Layers

Because the layers are modular, we can swap protocols at one layer without changing the others.

* Instead of HTTP and TCP, it could be TFTP over UDP
* The lower layers (IP and Ethernet) don't worry about upper layer details
* If wired Ethernet changes to wireless Wi-Fi, Layers 1 and 2 change but upper layers stay the same

As long as each layer keeps its "contract" with the layers above and below, we can improve or replace protocols at different layers without redesigning everything. That flexibility is one of the main benefits of a layered model.

```mermaid
flowchart TB
    subgraph Upper["Upper Layers (unchanged)"]
        APP["Application: HTTP"]
        TRANS["Transport: TCP"]
    end
    subgraph Lower["Lower Layers (swappable)"]
        INT3["Internet: IP"]
        L2_ETHERNET["Link: Ethernet"]
        L2_WIFI["Link: Wi-Fi"]
        L1_CABLE["Physical: Cable"]
        L1_RADIO["Physical: Radio"]
    end

    APP --> TRANS --> INT3
    INT3 --> L2_ETHERNET --> L1_CABLE
    INT3 --> L2_WIFI --> L1_RADIO
```

## The OSI Model

In the late 1970s and 1980s, the ISO designed a 7-layer model called OSI (Open Systems Interconnection). The goal was to create international, vendor-neutral networking standards that could unify proprietary stacks and potentially replace TCP/IP.

Seven layers:

1. Application
2. Presentation
3. Session
4. Transport
5. Network
6. Data Link
7. Physical

Governments promoted OSI as the preferred stack for new deployments. Many thought OSI was the future. But OSI protocols were developed too late and were too complex. They never gained the same deployment as TCP/IP.

TCP/IP used a more bottom-up approach, while OSI was very top-down — committees designed protocols in detail, and vendors were expected to implement them exactly as specified. TCP/IP won in the real world.

OSI survived as a reference and teaching model and as a common way to talk about layers.

```mermaid
flowchart TB
    subgraph OSI["OSI Model (7 layers)"]
        direction TB
        O7["7. Application"]
        O6["6. Presentation"]
        O5["5. Session"]
        O4["4. Transport"]
        O3["3. Network"]
        O2["2. Data Link"]
        O1["1. Physical"]
    end
    subgraph TCPIP["TCP/IP Model (5 layers)"]
        direction TB
        T5["5. Application"]
        T4["4. Transport"]
        T3["3. Internet"]
        T2["2. Local Network"]
        T1["1. Physical"]
    end

    O7 --> T5
    O6 --> T5
    O5 --> T5
    O4 --> T4
    O3 --> T3
    O2 --> T2
    O1 --> T1
```

Today, most networking resources use a 5-layer model with names borrowed from OSI:

| TCP/IP Layer  | OSI Layer | Common Name       |
| ------------- | --------- | ----------------- |
| Application   | Layer 7   | "Layer 7"         |
| Transport     | Layer 4   | "Layer 4"         |
| Internet      | Layer 3   | "Network layer"   |
| Local Network | Layer 2   | "Data Link layer" |
| Physical      | Layer 1   | "Physical layer"  |

In practice, people usually just say "Layer 2" or "Layer 3" rather than the full names.

## Review

The TCP/IP model has five layers. Know the general purpose of each and the common OSI-borrowed names.

Encapsulation: the sending host adds headers (and a trailer) to data to prepare it for transmission. Decapsulation: the receiving host removes them layer by layer until reaching the data.

PDUs: Layer 4 PDU is a segment (TCP) or datagram (UDP). Layer 3 PDU is a packet. Layer 2 PDU is a frame. The frame is what travels on the wire.

Adjacent-layer interaction: each layer provides a service to the layer above and is serviced by the layer below. Same-layer interaction: each layer communicates with the same layer on other devices.

The model is a tool, not a law. Real protocols don't always fit neatly into a single layer, and that's okay.

```mermaid
flowchart TB
    subgraph ReviewStack["TCP/IP Layers"]
        direction TB
        R5["L5 Application<br/>Protocols between apps"]
        R4["L4 Transport<br/>Port-based process delivery"]
        R3["L3 Internet<br/>IP-based host delivery"]
        R2["L2 Local Network<br/>MAC-based hop delivery"]
        R1["L1 Physical<br/>Bits on wire"]
    end
```

***

## See also

* [TCP and UDP](/my-docs/basic-networking/tcp_and_udp_ccna_day30.md) — the Layer 4 protocols that sit on top of the TCP/IP model

***

## Resource

* [How the TCP/IP Model Actually Works | CCNA Day 3 — Jeremy's IT Lab](https://www.youtube.com/watch?v=yM-XNq9ADlI)