OSI model purpose

The Open Systems Interconnection (OSI) model organizes communication functions into seven conceptual layers. Each layer serves the layer above it and relies on the layer below it, which helps separate concerns for protocol design, interoperability, and troubleshooting.

Purpose and structure

The OSI model standardizes networking functions into seven distinct layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application. It is a reference framework that helps describe how networking responsibilities can be separated.

The TCP/IP model is based on the Internet protocol suite and is commonly represented as four layers: Link (or Network Access), Internet, Transport, and Application. Some presentations use five layers by separating physical and data-link functions.

Protocols and practical use

The OSI model is not tied to one particular protocol suite; it provides a general way to classify networking functions. The TCP/IP model is closely associated with the protocols used for Internet communication.

For example, HTTP and DNS are application-layer protocols, TCP and UDP are transport-layer protocols, and IP operates at the Internet layer. In practice, engineers often use both models: TCP/IP to describe deployed protocol behavior and OSI terminology to isolate responsibilities during design and troubleshooting.

Concept

Encapsulation enables layered communication. A protocol layer adds information needed for its own function without requiring higher layers to manage lower-layer details. This information can include addresses, protocol identifiers, sequencing information, and integrity-checking fields.

De-encapsulation uses that information at the receiving system to identify, validate where applicable, and deliver the data to the next higher layer.

De-encapsulation at the receiver

The receiving system processes the data in the opposite direction. The data-link layer accepts the frame and processes link-layer information. The IP layer processes the IP header and, if the packet is for the host, passes its payload upward. The transport layer uses the transport header, including the destination port, to deliver data to the appropriate application or service.

At each stage, a layer generally removes or does not forward the control information intended for that layer. The application ultimately receives the original application-layer data.

Protocol data units

The exact names vary by protocol and teaching model, but a common transmission sequence is: application data, transport segment or datagram, IP packet or datagram, data-link frame, and physical-layer bits or signals. The receiver processes these units in the reverse order.

Traffic scope and broadcast domains

A hub and a switch do not route traffic between IP networks. A hub repeats traffic across its connected ports, while a switch limits known unicast traffic to the required port. A switch creates separate broadcast domains when ports are placed in different VLANs.

Routers separate broadcast domains and route packets between IP networks. Traffic intended for another IP network is sent to a router, which determines where to forward it next.

What changes at routers

A router receives a Layer 2 frame, removes its link-layer encapsulation, examines the IP packet, and chooses the next hop using the destination IP address. It then sends the packet on its outgoing link inside a newly created Layer 2 frame.

Therefore, the Layer 2 source and destination MAC addresses are local to each routed link and generally change at routers. The original IP source and destination usually remain end-to-end, although mechanisms such as network address translation can modify IP addresses.

Why both are needed

IP addresses answer where the packet is ultimately intended to go across interconnected networks. MAC addresses answer which local interface should receive the frame for the next step. IP routing alone does not provide local frame delivery, and a MAC address alone does not provide routing across separate IP networks.

MAC address learning

When a frame arrives, the switch reads its source MAC address and associates that address with the port on which the frame was received. The association is maintained in the switch's MAC address table, also called a forwarding table or CAM table.

MAC learning is VLAN-specific: the same MAC address is associated with a port within a particular VLAN. If the switch later receives a frame with the same source MAC on a different port, it updates the table to reflect the new location.

Table aging and adaptation

Dynamically learned MAC address entries are normally removed after an inactivity period. Aging prevents stale entries from remaining indefinitely and helps the switch adapt when a device is disconnected or moved to another port.

This learning, forwarding, flooding, and aging process lets a switch build its forwarding information automatically without requiring a manually configured entry for every attached device.

Purpose of ARP

ARP, the Address Resolution Protocol, maps an IPv4 address to a link-layer address such as an Ethernet MAC address. It is used to deliver an Ethernet frame to the appropriate local next hop.

Before using ARP, the sender determines whether the IP destination is on the local network. For a local destination, the next hop is the destination host. For a remote destination, the next hop is usually the default gateway.

Local-link scope

ARP requests are limited to the local broadcast domain because routers do not forward ordinary Layer 2 broadcasts between routed networks. Therefore, ARP does not obtain the MAC address of a host on a remote network.

For remote traffic, the IP packet still carries the remote destination IP address, but the Ethernet frame is addressed to the MAC address of the local router or other configured next hop.

IPv6 equivalent

IPv6 does not use ARP. It uses Neighbor Discovery, based on ICMPv6, for address resolution and related local-link functions.

Definition

A SPOF exists when one failure can interrupt a required function. It may be a physical device, a network connection, a power source, or a supporting service that the network depends on.

Operational reliability

Redundancy is useful only if failover works when a failure occurs. Health detection, correct configuration, and regular failover testing help ensure that the remaining component or path can assume the workload.

Addressing and representation

IPv4 addresses are 32 bits long and are usually written in dotted-decimal notation, such as 192.168.1.10. Its address space contains about 4.3 billion possible addresses.

IPv6 addresses are 128 bits long and are written as hexadecimal groups separated by colons, such as 2001:db8::10. The much larger address space reduces the need to conserve addresses through NAT.

Packet header and fragmentation

An IPv4 header has a variable length of 20 to 60 bytes because options are included in the header. IPv6 has a fixed 40-byte base header; optional functionality is carried in extension headers.

IPv4 routers may fragment packets when required by a link's maximum transmission unit. IPv6 routers do not fragment packets; instead, the sending host uses path MTU discovery and may fragment packets using an IPv6 Fragment extension header when necessary.

Address resolution and traffic delivery

IPv4 typically uses ARP to map a local IPv4 address to a link-layer address. IPv6 uses Neighbor Discovery, which operates through ICMPv6, for address resolution and related local-link functions.

IPv4 supports broadcast traffic. IPv6 has no broadcast; multicast is used where group delivery is needed. IPv6 also supports anycast addressing, in which packets are delivered to one member of an anycast group.

Configuration, NAT, and transition

IPv4 hosts are commonly configured manually or through DHCP. IPv6 supports Stateless Address Autoconfiguration (SLAAC) and DHCPv6; the choice depends on the network's addressing and configuration requirements.

NAT is widespread in IPv4 networks because public IPv4 addresses are limited. IPv6 does not normally require NAT for address conservation, although firewalls are still used for traffic control. Because IPv4 and IPv6 are separate protocols, many networks operate both in dual-stack mode during migration.

NAT and private addressing

Private IP addresses are not globally routable on the public Internet. A NAT gateway at the network edge translates addresses in packets crossing between a private network and the Internet.

Translation table and return traffic

The NAT gateway maintains a translation table for active flows. The entry associates the internal endpoint with the public address and translated port used externally.

When a reply arrives at the public IP address and translated port, the gateway finds the matching entry, changes the destination back to the internal IP address and port, updates packet checksums as required, and forwards the packet to the intended device. This keeps traffic for different private devices and connections separate.

What NAT does and does not provide

PAT conserves public IPv4 addresses and prevents private addressing details from being directly visible in outbound packets. NAT is not, by itself, a replacement for a firewall: firewalling requires explicit traffic-control policy and may include additional inspection capabilities.

Subnet range

The block size in the last octet is 256

192 = 64. Therefore, the /26 subnets in this octet span 0–63, 64–127, 128–191, and 192–255.

Since 192.168.10.70 falls within the 64–127 range, it belongs to the 192.168.10.64/26 subnet.

Purpose

DHCP provides a client with network settings such as an IPv4 address, subnet mask, default gateway, DNS server information, and a lease duration. DORA describes the initial address-allocation exchange between a DHCP client and server.

1. Discover

A client that does not yet know the DHCP server sends a DHCPDISCOVER message to locate available servers. This message is typically broadcast on the local network because the client may not yet have a usable IP address or know the server address.

2. Offer

Each DHCP server able to serve the client may respond with a DHCPOFFER. The offer proposes an IP address and can include configuration options and the lease time for that address.

3. Request

The client sends a DHCPREQUEST to select one offer. During the initial exchange, this request is commonly broadcast, allowing the selected server to identify itself and other servers to withdraw any addresses they offered.

4. Acknowledge and lease

The selected server sends a DHCPACK to confirm the lease and configuration. The client then configures the assigned address and can use the network. The address is leased for a limited period, and the client normally attempts renewal before the lease expires.

DHCP for IPv4 uses UDP: servers listen on port 67 and clients use port 68.

Route lookup determines the path

The host does not decide solely by comparing its address with the destination address. It performs a routing-table lookup for the destination IP address. In the usual routing model, the route with the longest matching prefix is selected; route preference or metrics can break ties between equally specific routes.

The selected route indicates whether the destination is reachable directly on a local link or whether a router must be used as the next hop. A host can have multiple interfaces and multiple directly connected networks, so this decision is made for the selected route and outgoing interface.

When the destination is directly reachable

If the selected route is an on-link route, the host sends the packet directly on that interface. It resolves the destination host’s link-layer address and places that address in the frame destination field.

For example, IPv4 commonly uses ARP for link-layer address resolution, while IPv6 uses Neighbor Discovery. The IP packet still has the destination host’s IP address.

When a router is required

If the selected route names a next-hop router, the host resolves the router’s link-layer address and sends the frame to that router on the local link. It does not try to resolve the link-layer address of the remote destination host.

The router then forwards the packet toward its IP destination. On the first link, the frame destination is the router, but the IP destination remains the final remote host.

Role of the default gateway

A default gateway is the next-hop router configured for the default route, commonly represented by a route with prefix length zero. That route is used only when the routing table has no more-specific matching route for the destination.

Thus, traffic to another network does not always use the default gateway: a more-specific route may select a different router or another directly reachable interface.

TTL and Hop Limit mechanism

IPv4 TTL and IPv6 Hop Limit prevent packets from circulating indefinitely. A router reduces the value as it forwards a packet. If the value expires at that router, the router discards the packet and normally sends an ICMP Time Exceeded response to the source.

Traceroute deliberately uses this behavior to make probes expire at progressively more distant routers.

Reaching the destination and probe types

The destination is considered reached when it returns a response appropriate to the probe type. Traditional UDP-based traceroute commonly elicits an ICMP Port Unreachable response from the destination, while ICMP Echo probes can elicit an Echo Reply. TCP-based probes may receive a TCP response from the destination.

Probe formats vary by traceroute implementation and configuration. Common choices are UDP, ICMP Echo Request, and TCP probes; this choice can affect how networks and firewalls handle the probes.

Missing replies and limitations

A timeout, often displayed as an asterisk, means that no expected response was received before the timeout. It does not prove that the router or path has failed: a router may rate-limit or suppress ICMP Time Exceeded messages, or a firewall may filter the probe or reply.

Traceroute shows routers that respond to its probes, not necessarily every forwarding device. Also, the reverse path taken by ICMP replies may differ from the forward path followed by the probes.

MTU and oversized packets

The Maximum Transmission Unit (MTU) is the largest IP packet a particular link can carry without fragmentation. Because links along a path can have different MTUs, a packet that fits one link may be too large for a later link.

When a router receives a packet larger than the MTU of its outgoing link, it must fragment it when permitted or discard it and notify the source when possible.

IPv6 behavior

IPv6 routers do not fragment transit packets. If a packet exceeds the outgoing-link MTU, the router discards it and sends an ICMPv6 Packet Too Big message to the source.

The source must send smaller packets. IPv6 allows fragmentation only by the source, using an IPv6 Fragment extension header; the destination performs any required reassembly.

Path MTU Discovery and TCP

Path MTU Discovery (PMTUD) helps a sender determine the largest packet size that can traverse the complete path without fragmentation, using information such as ICMP or ICMPv6 too-big messages.

TCP normally selects a Maximum Segment Size (MSS) intended to keep TCP segments within the expected IP path MTU, reducing the need for fragmentation.

TCP

TCP establishes a connection before transferring application data. It presents data to applications as a continuous byte stream rather than as separate messages.

TCP uses acknowledgements and retransmission to recover from detected loss, delivers received bytes to the application in order, applies flow control so a sender does not overwhelm a receiver, and uses congestion control to adapt its sending behavior to network congestion.

UDP

UDP does not establish a transport connection and preserves application data as individual datagrams. Each datagram is handled independently.

UDP does not inherently guarantee that a datagram will arrive, arrive only once, or arrive in order. It has no built-in retransmission, flow control, or congestion control. An application or a protocol built above UDP must provide any of these features if required.

Overhead and error detection

UDP has a fixed 8-byte header. TCP has a larger, variable-length header, with a minimum size of 20 bytes. TCP’s additional mechanisms generally add protocol overhead and can introduce delay when it waits for missing data to preserve ordered delivery.

Both TCP and UDP use checksums for error detection. UDP checksum requirements differ by IP version: it is optional in IPv4 and required in IPv6.

Choosing between them

TCP is appropriate when complete, ordered data is important, such as for file transfer, remote login, email transport, and many web applications. UDP is appropriate when independent messages and timely delivery are more important than automatic recovery from loss, such as in some DNS exchanges, voice/video traffic, and online gaming.

UDP does not automatically make an application lower latency; its benefit is that it avoids TCP’s connection setup and built-in retransmission and in-order delivery behavior. Actual latency depends on the network and application design.

What TCP must establish

TCP is a stateful, full-duplex byte-stream protocol. Before data transfer, each endpoint needs to create connection state and learn the peer’s initial sequence number so that bytes can be numbered, acknowledged, and reliably delivered.

The endpoints do not use the same initial sequence number. Each side chooses its own initial sequence number, and the handshake lets the other side acknowledge it.

Why two messages are insufficient

After sending a SYN-ACK, the server knows that the client initiated a connection and that the client’s initial sequence number was received. However, it does not yet know whether the client received the server’s SYN and initial sequence number.

The third message provides that confirmation. It allows the server to enter the established state only after the client has acknowledged the server’s SYN, avoiding premature allocation of a fully established connection for a request that may not have reached the client.

Protection against stale connection requests

The handshake also helps TCP distinguish a current connection attempt from delayed or duplicate segments from an earlier attempt. A stale SYN alone cannot complete a new connection, because the peer’s SYN must be acknowledged by the original initiator before the server regards the connection as established.

Sequence numbers and ordered byte streams

TCP assigns sequence numbers to bytes in the stream. These numbers let the receiver determine the position of each received byte, identify missing ranges, and recognize duplicate data.

The receiving TCP implementation delivers data to the application only in sequence order. Data that arrives beyond a gap may be buffered until the missing bytes are received.

Acknowledgments and retransmission

The receiver sends acknowledgments indicating the next byte it expects, which cumulatively confirms receipt of all preceding bytes. When supported by both endpoints, Selective Acknowledgment (SACK) can additionally report received noncontiguous ranges.

TCP does not receive an explicit loss notification from IP. Instead, the sender infers loss when an acknowledgment is not received before a retransmission timeout or from patterns of duplicate acknowledgments, then retransmits the missing or unacknowledged data.

Corruption and duplicate handling

Each TCP segment includes a checksum. A segment that fails checksum validation is discarded and is not delivered to the application; the absence of an acknowledgment can cause the sender to retransmit it.

Sequence numbers also allow the receiver to recognize retransmitted or duplicated data and avoid delivering the same bytes more than once to the application.

Flow and congestion control

Flow control uses the receiver-advertised window to limit the amount of unacknowledged data the sender may have in flight, helping prevent the receiver's buffer from being overrun.

Congestion control adjusts the sender's transmission behavior in response to perceived network congestion. It supports efficient network use, but the core reliability mechanisms are acknowledgments, checksums, sequencing, buffering, and retransmission.

IP address, port, and protocol

The IP address routes a packet to the correct host or interface. After the packet reaches that host, the transport protocol and destination port identify the local service that should receive it. For example, TCP port 443 and UDP port 443 are distinct endpoints because TCP and UDP are different transport protocols.

Multiple simultaneous connections

For TCP, a connection is normally identified by the transport protocol, source IP address, source port, destination IP address, and destination port. This five-tuple lets a server accept many simultaneous connections to the same local IP address and port. Each accepted connection has separate communication state even though all clients reach the same listening service.

A socket is commonly described as the operating-system abstraction representing a communication endpoint. A server has a listening TCP socket, while each accepted TCP connection is represented by a separate connected socket.

Client query and caching

When an application needs an address for a name such as example.com, it sends a DNS query to a configured recursive resolver. The application, operating system, or resolver may already have a usable cached answer, in which case no external DNS lookup is needed.

The recursive resolver is commonly supplied by an organization, ISP, router, or public DNS provider. It performs the lookup on the client's behalf when it does not have a cached answer.

Aliases, responses, and caching

An A record contains an IPv4 address, while an AAAA record contains an IPv6 address. If the queried name has a CNAME record, the resolver follows the alias to its target name and resolves that target as needed.

The resolver returns the resulting DNS response to the client. It normally caches cacheable data for the TTL specified in the DNS records, allowing later queries to be answered more quickly until the cached entry expires.

Transport

Traditional DNS queries commonly use UDP port 53. TCP port 53 is used when needed, including for zone transfers and for responses that cannot be handled over UDP.

HTTPS and TLS

HTTPS is HTTP carried over Transport Layer Security (TLS). TLS creates a protected communication channel between the browser and the server before normal HTTP messages are exchanged. It provides confidentiality, integrity, and authentication of the server in the usual HTTPS deployment.

Connection setup and certificate validation

The browser first establishes the underlying transport connection. This is usually TCP for HTTP/1.1 and HTTP/2; HTTP/3 uses QUIC, which runs over UDP and incorporates TLS handshake functionality.

During the TLS handshake, the server presents a certificate containing its public key and identity information. The browser checks that the certificate chains to a trusted certificate authority, is valid for the requested hostname, and is within its validity period. The server also proves possession of the corresponding private key as part of the handshake.

Key agreement and protected data transfer

The browser and server negotiate TLS parameters and perform key agreement, commonly using ephemeral key exchange. They derive shared session keys without sending those final keys directly over the network. Ephemeral key exchange can provide forward secrecy, meaning that compromise of a server’s long-term private key does not normally reveal past sessions.

After the handshake, HTTP requests and responses are protected using symmetric cryptography. TLS encryption prevents network observers from reading the application data, while authenticated encryption or equivalent integrity mechanisms allow the recipient to detect altered, injected, or forged records.

Security boundaries

HTTPS protects data while it travels between the browser and the authenticated server endpoint. It does not prove that a website operator is honest, that the site is free from vulnerabilities, or that data remains protected after the server receives it. Client authentication is possible with TLS certificates, but it is not normally used for standard web browsing.

1. URL parsing and local checks

The browser separates the URL into components such as the scheme, hostname, port if specified, path, query, and fragment. The fragment is normally handled locally by the browser and is not sent in the HTTP request.

Before making network requests, the browser may use cached HTTP responses, cached DNS records, service-worker-controlled responses, or an existing reusable connection. Cache rules and browser policies determine whether a cached response can be used or must be revalidated.

4. Response processing and rendering

The request may be handled by a CDN, reverse proxy, load balancer, application server, cache, or database, depending on the service architecture. The responding component returns an HTTP status code, headers, and a response body, which may be HTML or another type of content.

When HTML is received, the browser parses it and discovers referenced resources such as stylesheets, scripts, images, and fonts. It requests those resources as needed, applies CSS, executes JavaScript where required, calculates layout, paints the result, and displays the page. Resource loading and rendering can overlap, and JavaScript or later network responses can update the page after the initial display.

Defense strategy and attack layers

DDoS attacks may exhaust Internet bandwidth, network-device or server connection state, or application resources. Effective protection is therefore layered rather than dependent on a single firewall or appliance.

Volumetric attacks must be mitigated before they saturate the organization’s Internet connection. Once the link is full, local systems may remain reachable internally but external users cannot reach them.