Frames, Packets, Segments, and Data Flow

Names for Data at Different Layers

When people say a network "sends data," they compress several steps into one phrase. Each layer packages data differently, and switches, routers, firewalls, operating systems, and analyzers all make decisions on different headers. The CCST exam expects you to use the precise term for each protocol data unit (PDU).

Transport, Network, and Data Link in Detail

At the transport layer, TCP or UDP identifies which application conversation owns the data using port numbers. TCP adds reliability: a three-way handshake (SYN, SYN-ACK, ACK), sequencing, acknowledgments, retransmission, and flow control; its PDU is a segment. UDP skips the handshake and reliability, so its PDU is a datagram. DNS, Voice over IP (VoIP), live video, and many games use UDP because timeliness beats retransmitting every lost piece.

At the network layer, IP wraps the segment into a packet carrying source and destination IP addresses. Routers read the destination IP, compare it to the routing table, and forward toward the next hop. The IP addresses normally stay constant from original sender to final receiver, except where Network Address Translation (NAT) intentionally rewrites them at a boundary.

At the data link layer, Ethernet or Wi-Fi wraps the packet into a frame with source and destination MAC addresses for the local link only. This is the most-tested concept in the section: MAC addresses are local-hop information. When a laptop sends to a server on another network, it builds a frame addressed to the MAC of its default gateway, not the remote server's MAC. The router strips that frame, makes a routing decision on the IP packet, then builds a brand-new frame for the next link. The packet travels end to end; the frame is rebuilt hop by hop.

At the physical layer, the frame becomes bits sent as electrical signals on copper, light on fiber, or radio in the air. Link light, negotiated speed, duplex, signal level, and physical errors live here.

A Worked Web Example

Follow one HTTPS request to tie the terms together:

1. DNS resolves the site name to an IP address.
2. The client opens a TCP connection to destination port 443 on the server.
3. Application data rides inside TCP segments.
4. IP packets carry those segments toward the server.
5. Ethernet or Wi-Fi frames carry each packet across each local link, rebuilt at every router.
6. The physical layer transmits the bits.

Along that path, a switch attends mainly to frame (MAC) information, a router to packet (IP) information, and the host OS to transport ports so it delivers data to the right process.

Reading Captures Without Drowning

Tools such as Wireshark display all layers for one captured frame at once: Ethernet, IP, TCP, and the HTTPS-related fields stacked together. For CCST-level work you do not decode every byte. You should be able to tell whether you are looking at local MAC addressing, IP addressing, TCP/UDP ports, or application behavior. Common trap: confusing a local switching issue (frames not forwarding on one segment) with a routed-path or application issue. Identifying the PDU layer first keeps escalations accurate and lets you save the right capture for the next tier.

How Addresses Behave Across the Path

The single most testable idea in this section is which addresses change and which stay constant as data crosses a routed network. Put the two layers side by side: the IP packet's source and destination addresses stay the same end to end (barring NAT at a boundary), while the frame's source and destination MAC addresses change at every router hop.

A laptop sending to a remote server keeps the server's IP as the destination the whole way but addresses each frame only to the next device on its own segment, first to the default gateway's MAC, then the router re-addresses the frame to the next router, and so on until the final router addresses the last frame to the server's MAC.

Walk a concrete three-segment path to lock this in:

1. Laptop to Router A: destination IP = server, destination MAC = Router A's gateway interface.
2. Router A to Router B: same destination IP = server, destination MAC = Router B's incoming interface; Router A built a brand-new frame.
3. Router B to server: same destination IP = server, destination MAC = the server's NIC; Router B built another new frame.

The Address Resolution Protocol (ARP) is what lets a device learn the MAC that goes with the next-hop IP on its local segment, which is why ARP problems show up as "I have an IP and a gateway but still cannot reach anything." Ports add a third constant: the destination port (for example 443 for HTTPS) identifies the service and normally stays fixed, while the client's source port is a high random number the OS uses to track the reply.

When you read a capture, ask three quick questions in order: Are the MAC addresses local-segment values or do they point at a gateway? Do the IP addresses match the true source and destination I expect? Do the ports match the service? Answering those tells you immediately whether a fault is local switching, routing, or application, and that triage is precisely what CCST capture-interpretation items reward.