Free lesson · Computer Networking

Protocols The Rules Of Communication

Easy10 min readnetworkingcomputer-networkstcp-ip

What Is a Protocol?

A protocol is a set of rules that governs how two parties communicate. That definition applies far beyond networking - languages, diplomatic customs, and social conventions are all protocols in the general sense. In networking, a protocol specifies the exact format of messages, the order in which messages are exchanged, and the actions each party must take when sending, receiving, or encountering errors.

Consider a simple human protocol: ordering coffee. You walk up to the counter. The barista says "what can I get you?" You state your order. The barista confirms the order and states the price. You pay. The barista prepares the drink. The barista calls your name. You pick up the coffee. Both parties follow a predictable sequence, and both know what to expect at each step.

Network protocols work identically but with precise, unambiguous rules. When your browser connects to a web server using HTTP, both sides know the exact format of requests and responses, the exact meaning of status codes (200 means success, 404 means not found), and the exact sequence of operations (the client sends a request, the server sends a response). There is no room for interpretation or improvisation - unlike human conversation, a network protocol must be followed to the byte.

Tip: The word "protocol" comes from the Greek protokollon, meaning "first sheet" - the first page of a document that specified how the rest should be interpreted. Network protocols serve the same function: they are the rules that tell each side how to interpret the messages the other side sends.

Protocols Live at Layers

Every protocol operates at a specific layer of the network model. This is not an organizational convenience - it reflects a real constraint. A protocol can only use the services provided by the layer below it and can only provide services to the layer above it.

A protocol at one layer does not need to know the details of protocols at other layers. HTTP does not know whether the underlying transport is TCP or QUIC. TCP does not know whether the underlying network is IPv4 or IPv6. IP does not know whether the underlying link is Ethernet or Wi-Fi. This independence is what makes the layered architecture powerful - you can change the protocol at one layer without affecting any other layer. It also means you can learn protocols one at a time, in any order, without needing to understand the entire stack first.

graph TD
    subgraph AppLayer["Application Layer Protocols"]
        HTTP["HTTP/HTTPS"]
        DNS["DNS"]
        SMTP["SMTP"]
        SSH["SSH"]
    end

    subgraph TransLayer["Transport Layer Protocols"]
        TCP["TCP"]
        UDP["UDP"]
    end

    subgraph NetLayer["Network Layer Protocol"]
        IP["IP (v4/v6)"]
    end

    subgraph LinkLayer["Data Link Layer Protocols"]
        ETH["Ethernet"]
        WIFI["Wi-Fi"]
    end

    HTTP --> TCP
    DNS --> UDP
    DNS -.->|"Zone transfers"| TCP
    SMTP --> TCP
    SSH --> TCP

    TCP --> IP
    UDP --> IP

    IP --> ETH
    IP --> WIFI

    style HTTP fill:#4f46e5,stroke:#4338ca,color:#fff
    style DNS fill:#4f46e5,stroke:#4338ca,color:#fff
    style SMTP fill:#4f46e5,stroke:#4338ca,color:#fff
    style SSH fill:#4f46e5,stroke:#4338ca,color:#fff
    style TCP fill:#7c3aed,stroke:#6d28d9,color:#fff
    style UDP fill:#7c3aed,stroke:#6d28d9,color:#fff
    style IP fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style ETH fill:#a78bfa,stroke:#8b5cf6,color:#fff
    style WIFI fill:#a78bfa,stroke:#8b5cf6,color:#fff

This diagram shows how protocols at different layers depend on each other. At the Application Layer, HTTP, SMTP, and SSH all use TCP at the Transport Layer. DNS primarily uses UDP but also uses TCP for zone transfers. At the Transport Layer, both TCP and UDP use IP at the Network Layer. IP can run over either Ethernet or Wi-Fi at the Data Link Layer. The diagram shows that protocols at each layer are independent of each other - HTTP does not know or care whether Ethernet or Wi-Fi is being used below.

The Protocol Stack - How Protocols Work Together

When you hear the phrase "protocol stack," it refers to the combination of protocols from different layers that work together to accomplish a complete communication task. Every network interaction involves a stack - a set of cooperating protocols, one per layer.

For example, when you load a web page over a wired connection:

• Application layer: HTTP (formats the request for the web page)
• Transport layer: TCP (ensures reliable delivery of the request and response)
• Network layer: IP (routes packets from your machine to the web server)
• Data Link layer: Ethernet (delivers frames between your machine and your router)
• Physical layer: Electrical signals over copper cable

This stack is not theoretical - it is literally the set of headers you would see if you captured the traffic in Wireshark. Each protocol adds its own header during encapsulation, and each header follows that protocol's exact specification for format, meaning, and sequencing.

Change one element - switch from wired to Wi-Fi - and only the lower layers change:

• Application layer: HTTP (unchanged)
• Transport layer: TCP (unchanged)
• Network layer: IP (unchanged)
• Data Link layer: Wi-Fi (replaced Ethernet)
• Physical layer: Radio waves (replaced copper cable)

The application-layer protocol did not change. The transport-layer protocol did not change. The network-layer protocol did not change. Only the bottom two layers swapped, and the upper layers did not notice. This is the protocol stack in action - independent layers, each pluggable without disturbing the rest.

Protocol Stack Combinations in Practice

Different applications use different stacks depending on their requirements:

Important: Notice that the "right" transport protocol depends entirely on the application's requirements. There is no universally better protocol - TCP and UDP serve different needs. The protocol stack is designed so you can pick the right tool at each layer independently.

How a Protocol Is Defined

Every protocol specifies three things:

1. Message Format (Syntax)

The protocol defines the exact structure of each message - which fields exist, how many bytes each field occupies, what values are valid, and in what order the fields appear. An IP packet header, for example, has the version field in the first 4 bits, the header length in the next 4 bits, and so on in a precisely defined sequence. There is zero ambiguity.

IP Header (simplified):
┌───────────┬───────────┬───────────────────────┐
│ Version   │ Header    │ Total Length           │
│ (4 bits)  │ Length    │ (16 bits)              │
│           │ (4 bits)  │                        │
├───────────┴───────────┼───────────────────────┤
│ Time to Live (8 bits) │ Protocol (8 bits)      │
├───────────────────────┼───────────────────────┤
│ Source IP Address (32 bits)                    │
├───────────────────────────────────────────────┤
│ Destination IP Address (32 bits)              │
└───────────────────────────────────────────────┘

2. Message Meaning (Semantics)

The protocol defines what each field means and how it should be interpreted. In TCP, a packet with the SYN flag set means "I want to start a new connection." A packet with the ACK flag set means "I acknowledge receiving your data." A packet with the FIN flag set means "I want to close the connection." These meanings are fixed and universal - every TCP implementation in the world interprets these flags the same way.

3. Message Ordering (Timing)

The protocol defines the sequence in which messages should be exchanged. TCP's three-way handshake is a strict sequence: the client sends SYN, the server responds with SYN-ACK, the client sends ACK. Only after this three-message sequence is the connection established. Sending data before the handshake completes violates the protocol and the data will be rejected.

Protocol timing also covers timeouts and retransmission. If a TCP sender transmits a segment and does not receive an acknowledgment within a specified time window, it retransmits the segment. The timeout duration, the retransmission strategy, and the maximum number of retries are all defined by the protocol. This is what makes TCP "reliable" - the protocol itself specifies how to recover from lost data without the application needing to implement retry logic.

Some protocols are conversational (request-response patterns like HTTP), some are streaming (continuous data flow like RTP for video), and some are event-driven (notifications triggered by state changes like BGP routing updates). The timing rules differ dramatically between these patterns, but every protocol defines its timing rules explicitly.

sequenceDiagram
    participant C as Client
    participant S as Server
    
    Note over C,S: TCP Three-Way Handshake<br/>(Protocol defines this exact sequence)
    C->>S: SYN (seq=100)
    Note right of S: Server receives connection request
    S->>C: SYN-ACK (seq=300, ack=101)
    Note left of C: Client receives acknowledgment
    C->>S: ACK (ack=301)
    Note over C,S: Connection Established ✓
    
    C->>S: HTTP GET /index.html
    S->>C: HTTP 200 OK + page content
    
    Note over C,S: TCP Connection Teardown
    C->>S: FIN
    S->>C: ACK
    S->>C: FIN
    C->>S: ACK
    Note over C,S: Connection Closed ✓

This sequence diagram shows the TCP three-way handshake and subsequent communication. The client sends a SYN message to the server with sequence number 100. The server responds with a SYN-ACK containing its own sequence number 300 and acknowledging the client's sequence as 101. The client sends an ACK acknowledging 301, and the connection is established. The client then sends an HTTP GET request, the server responds with an HTTP 200 OK. To close the connection, the client sends FIN, the server sends ACK then its own FIN, and the client sends a final ACK.

The "Language" Analogy - And Where It Breaks Down

Protocols are often compared to human languages, and the analogy is useful up to a point. HTTP is like English - a set of vocabulary ("GET," "POST," "200 OK") and grammar rules (request line, then headers, then body) that both sides must understand. TCP is like the postal rules - how to ensure the letter arrives and in what order to read pages if the letter was split across multiple envelopes.

But the analogy breaks down in one important way: human languages tolerate ambiguity and improvisation. If you misspell a word or use unconventional grammar, the other person usually understands. Network protocols have zero tolerance for ambiguity. A single misplaced byte, a wrong flag, or an unexpected message sequence causes the communication to fail. This is why protocol specifications (documented in RFCs) are exhaustively detailed - they must leave no room for different implementations to interpret the same message differently.

The practical implication is that when you read protocol documentation (RFCs, standards documents), the precision is intentional. Every "MUST," "SHOULD," and "MAY" has a specific meaning defined by RFC 2119, and implementations are expected to follow these directives exactly. "MUST" means the behavior is an absolute requirement. "SHOULD" means there may be valid reasons to deviate, but the consequences must be understood. "MAY" means the behavior is truly optional. This graduated language allows protocol specifications to distinguish between core requirements and optional features without ambiguity.

This strictness is what makes it possible for a web server written in Go to communicate perfectly with a browser written in C++, running on different operating systems, built by different companies, on different continents. Both implementations follow the same RFC, interpret the same fields the same way, and produce the same responses to the same inputs. The protocol specification is the shared contract that makes interoperability possible without bilateral coordination between every pair of implementations.

It is worth noting that protocol specifications also define what should happen when things go wrong - when a message arrives with an unexpected field, when a timeout occurs, when a connection is interrupted. Robust error handling is as much a part of a protocol as the happy-path behavior. Many of the most subtle networking bugs come not from incorrect normal behavior, but from different implementations handling edge cases and error conditions differently despite following the same specification.

Interview: Protocols are often the hidden layer behind System Design interview questions. When an interviewer asks "how should services communicate in your design?", they want to know which protocol you would choose and why. REST over HTTP? gRPC over HTTP/2? Message queues using AMQP? WebSockets for real-time updates?

Each of these is a protocol choice at the application layer, and each comes with trade-offs:

• REST/HTTP: Simple, widely supported, human-readable, but verbose and synchronous
• gRPC: Efficient binary encoding (Protocol Buffers), supports streaming, but requires code generation and is less browser-friendly
• WebSockets: Full-duplex communication, great for real-time features, but more complex connection management
• Message queues (Kafka, RabbitMQ): Asynchronous, decoupled, durable, but add operational complexity

Understanding that these are all application-layer protocols - and that the choice between them is a protocol-level design decision - demonstrates the kind of layered thinking interviewers value.

What Comes Next

The final topic in this module puts everything together in a hands-on exercise. You will install Wireshark, capture real network traffic, and see layers, encapsulation, protocols, and PDUs in action - not as abstract concepts, but as visible bytes in a packet capture. The theory becomes tangible when you can point to the TCP header in a real packet and say "that is the transport layer."

Exercise: Starter: Pick three applications you use daily (your browser, a messaging app, a music streaming service). For each one, identify the application-layer protocol it uses and the transport-layer protocol beneath it. Which ones use TCP? Do any use UDP? Why?

Intermediate: Read the first page of RFC 9110 (the HTTP/1.1 specification) or RFC 793 (the TCP specification). Both are freely available online. Note how the document defines message format, semantics, and timing. How does the level of precision compare to documentation you have written or read for software APIs?

Advanced: Research the concept of "protocol ossification" - the phenomenon where widely deployed protocols become effectively impossible to change because so many devices and middleboxes depend on specific protocol behaviors. How did protocol ossification affect TCP and motivate the design of QUIC? Why did Google build QUIC on top of UDP rather than creating a new transport protocol from scratch?

Back to Computer Networking