Communication protocols: layers, addressing, transport, and security

1. Rules require more than a message format

Syntax specifies representation and structure: field lengths, encoding, delimiters, and framing. Semantics specifies meaning and actions: what a request means, how a reply changes state, and how errors are handled. Timing includes ordering, rate, deadlines, and timeout behaviour. A protocol may also specify capabilities, negotiation, versioning, and recovery.

State matters. A message valid before authentication may be invalid after closing a connection. A state machine describes legal states and transitions caused by messages, timers, or local actions. Timeouts indicate missing evidence, not proof that the remote operation did not happen.

Interoperability needs compatible interpretation and behaviour. Two implementations can exchange correctly shaped messages yet disagree on units, encoding, or retry semantics. Specifications must cover edge cases, and implementations must validate untrusted input and resource limits.

Worked example

Design a temperature-report message with version, sensor ID, timestamp, unit, numeric value, and sequence number. A value of 32 without its unit is ambiguous. A repeated sequence number may indicate a retry. A timestamp without time-zone or clock assumptions is insufficient for comparing readings. This is protocol design even if the transport already delivers bytes reliably.

2. OSI and Internet-layer models

The OSI reference model has seven layers: physical, data link, network, transport, session, presentation, and application. Physical concerns signals; link concerns local transfer and framing; network concerns delivery across networks; transport concerns endpoint communication. Session, presentation, and application separate dialogue organisation, representation, and application meaning in the model.

The Internet model commonly groups link, Internet, transport, and application responsibilities; a five-layer teaching model separates physical from link. Internet applications often implement representation and session functions within their own libraries and protocols. There is no exact one-to-one mapping that places every real protocol in only one OSI box.

Encapsulation adds control information around higher-layer data. A transport unit may carry application bytes; an IP packet carries transport data; a link frame carries the IP packet on a particular link. Headers change according to the layer and path. Encapsulation is a conceptual organisation, not a requirement to copy every byte separately in software.

3. Link delivery and address resolution

Ethernet provides link-layer frame communication in its supported arrangements. Switching commonly uses destination MAC addresses and VLAN context. A MAC address belongs to the relevant link-delivery namespace; it is not a globally trustworthy identity and can be changed or spoofed.

For IPv4 on a local Ethernet network, ARP maps an on-link protocol address to a link address. To reach an off-link destination, a host usually resolves the next-hop router’s IPv4 address, not the remote server’s MAC address. ARP requests are local broadcasts in the relevant broadcast domain; routers do not normally forward them as ordinary broadcasts between subnets.

IPv6 uses Neighbor Discovery rather than ARP and has different addressing conventions. Do not apply IPv4 broadcast assumptions to IPv6. Link address discovery also does not authenticate that a responder is legitimate; local-network threat models matter.

4. IP addressing, prefixes, and forwarding

IP supplies packet addressing and forwarding across connected networks. It is a best-effort service: loss, duplication, and reordering are possible. IPv4 uses 32-bit addresses; IPv6 uses 128-bit addresses. Neither address length alone determines security, speed, or successful delivery.

A prefix identifies a range used in routing. Forwarding commonly selects the most specific matching prefix: longest-prefix match. The host uses routes to determine whether a destination is on-link or which next hop to use. The default route is a fallback for destinations without a more specific match.

The IP hop-limit or IPv4 TTL field bounds forwarding lifetime; it is not a clock-based end-to-end delivery deadline. Path MTU limits packet size along a route. Oversized traffic may require appropriate endpoint adaptation or fragmentation under the relevant version and conditions. Applications should not assume that one arbitrary large unit crosses every path intact.

Worked example

A route table contains 10.0.0.0/8 through router A, 10.2.0.0/16 through router B, and a default route through C. Destination 10.2.3.4 matches both /8 and /16; the /16 route is more specific, so B is chosen under longest-prefix forwarding. Destination 10.5.1.2 uses A; destination 203.0.113.9 uses C if no other route exists. Documentation addresses in examples do not identify a real service.

5. TCP, UDP, and modern transport choices

TCP supplies an ordered reliable byte stream while a connection is functioning. Sequence information, acknowledgements, retransmission, flow control, and congestion-control behaviour support that service. The byte stream does not preserve application write boundaries: one send may be received in pieces, and several sends may arrive together. Applications need framing, such as length prefixes or delimiters.

TCP connection establishment coordinates endpoint state, commonly described by the SYN, SYN-ACK, ACK three-way exchange. Establishing a connection does not authenticate an application user or encrypt traffic. Closing or resetting has separate semantics. A connection can fail, and application recovery still needs explicit design.

UDP sends datagrams with minimal built-in delivery machinery. It does not itself guarantee delivery, order, or duplicate protection. Applications may implement their own reliability and timing behaviour. UDP is not universally faster, and using it does not excuse a design from congestion-aware behaviour.

QUIC is a secure multiplexed transport built over UDP with its own connection, recovery, and stream machinery. It illustrates why “UDP means unreliable application” is wrong: the service above UDP can add substantial guarantees. Transport choice should follow message, latency, loss, security, and operational requirements.

6. Configuration and naming: DHCP and DNS

DHCPv4 can lease an address and supply configuration such as prefix-related information, default router, and DNS servers. A simplified initial exchange is Discover, Offer, Request, Acknowledge. Leases have lifetimes and renewal behaviour. A DHCP server may be remote with relay support; do not assume every client directly shares its physical segment.

DNS is a hierarchical distributed naming system with different record types. A and AAAA records supply IPv4 and IPv6 addresses; other records support different purposes. A stub resolver commonly asks a recursive resolver, which may answer from cache or consult authoritative information. DNS does not download the webpage and does not assign the host’s own address.

Caching and TTL affect how long a stored answer can be reused. A cached DNS record’s TTL is unrelated to an IP packet’s TTL despite the shared abbreviation. A name can map to multiple addresses, and an address can support multiple services. Naming is not equivalent to trust: secure application identity checks remain necessary.

7. Application protocols and security boundaries

HTTP defines web request/response semantics; HTTPS uses secure transport to protect that communication and support server authentication under the applicable certificate rules. TLS protects confidentiality and integrity in transit within its threat model. It does not make a dishonest server truthful, validate business logic, or secure a compromised endpoint.

SMTP supports email transfer; IMAP and POP serve different mailbox-access roles. SSH provides protected remote access with authentication. Traditional FTP separates control and data mechanisms and does not inherently supply modern confidentiality; secure alternatives have different protocol designs. A port number suggests conventional service use but is not proof of the application or its safety.

Authentication checks identity claims; authorisation determines allowed actions; encryption protects confidentiality; integrity mechanisms detect unauthorised changes under their assumptions. Firewalls apply policy but cannot replace all these functions. State which property is supplied and which trust boundary it covers.

8. A complete transaction and a diagnostic method

For a fresh IPv4 HTTPS request, the client needs interface configuration and routes, resolves the service name when needed, resolves its next-hop link address when needed, establishes the chosen transport and secure session, and sends the application request. Caches and reused connections can omit repeated setup. HTTP/3 uses QUIC, so a TCP-only trace is not universal.

The local frame targets the next-hop interface. Routers forward according to IP information and rebuild link encapsulation as required for each next link. The server interprets the application request and checks access before producing a response. Successful packet delivery is only one part of successful service.

Diagnose from evidence: link status, valid local configuration, route, name resolution, transport reachability, secure-session identity, and application response. A failed ping does not prove every service is unreachable because ICMP may be filtered. A successful ping does not prove HTTP, TLS, authentication, or database availability.

On your own authorised development environment, compare a DNS lookup, a route listing, and an application request. Record the observation and the inference separately. Avoid scanning networks or capturing other users’ traffic as a routine exercise.

Configuration → route decision → name/address resolution as needed
→ transport/security setup → application request → authorised processing → response
Each stage can fail independently; cached state may skip repeated work.