4.5 Packet Flow

Tracing Packet Flow in the TCP/IP Model

In this chapter you follow what happens to data as it moves through the TCP/IP model, from an application on one device to an application on another, and back again. The goal is not to relearn each layer, but to understand the sequence of events and how the layers cooperate in practice.

Big Picture: From App to Wire and Back

When you send data across a network with the TCP/IP model, information moves:

1. Down the layers on the sender.
2. Across the network.
3. Up the layers on the receiver.

You can think of it as a conversation between matching layers on different devices, with each local stack doing its own work.

In the common 4 layer TCP/IP view, the layers are:

The packet flow is the ordered process that takes data from an application at the source, passes it layer by layer to the network, then reverses that process at the destination.

Step 1: Application Layer Creates Data

The flow begins when an application wants to send something. For example, your browser sends an HTTP request, or a mail client sends an email.

The Application layer:

• Builds a message in an application specific format.
• Hands that message to the Transport layer with information about the remote application, often a port number.

At this point there are no IP addresses or MAC addresses involved. The data is just a structured application message waiting to be delivered.

Step 2: Transport Layer Segments and Adds Ports

The Transport layer (TCP or UDP) takes the application message and prepares it for host to host communication.

Typical actions here:

1. Segmentation or message handling
   If the application data is large, TCP can split it into pieces called segments. UDP may send it as a single datagram or multiple datagrams, depending on size and the application.
2. Port numbers
   The Transport layer attaches:
• A source port, identifying the sending application on the local device.
• A destination port, identifying the receiving application on the remote device.
3. Control fields
   TCP adds sequence numbers, flags, and other fields needed for reliability and ordering. UDP adds a simpler header.

The result is a Transport layer segment (TCP) or datagram (UDP) that wraps the application data.

Step 3: Internet Layer Adds IP Information

The Internet layer takes the segment and prepares it for network wide delivery.

Key actions:

1. Source and destination IP addresses
   The Internet layer attaches:
• Source IP address, the address of the sending host.
• Destination IP address, the address of the target host.
2. Protocol indication
   The IP header includes a field that indicates which Transport protocol is carried above, for example TCP or UDP. This tells the receiver which transport process should handle the payload.
3. Packet size and fragmentation handling
   The Internet layer tracks the total size of the IP packet and may participate in fragmentation if the packet is too large for a link on the path. Detailed MTU behavior is covered elsewhere, but the important idea is that the Internet layer enforces a size that the lower layers can carry.

After this, the object is called an IP packet. It now has all the end to end addressing information needed to travel across multiple networks.

Step 4: Network Access Layer Prepares for Local Delivery

The Network Access layer (sometimes called Link layer in this model) adapts the IP packet to the specific physical network technology, such as Ethernet or Wi Fi.

On a typical Ethernet LAN, the flow is:

1. Determine next hop IP
   The host figures out whether the destination IP is on the same local network or somewhere remote:
• If local, the next hop IP is the destination host itself.
• If remote, the next hop IP is the default gateway router.
2. Resolve next hop MAC address
   The host needs a link layer address to deliver the frame across the local link. For Ethernet this is a MAC address. If the host does not already know the MAC address for the next hop IP, it uses an address resolution mechanism such as ARP, which has its own chapter.
3. Frame construction
   The Network Access layer builds a frame that includes:
• Destination MAC address, the MAC of the next hop device.
• Source MAC address, the MAC of the sender.
• A type or protocol field that indicates the payload is an IP packet.
• The IP packet itself as the payload.

The result is a frame that can be sent over the physical medium.

Step 5: Physical Transmission Across the Link

Once the frame is ready, it goes through the physical hardware.

Typical actions:

1. The Network Interface Card (NIC) encodes the frame into signals, such as electrical pulses in copper, light in fiber, or radio waves in Wi Fi.
2. The signals travel across the medium to the next device, usually a switch or a router.

Here, the TCP/IP layers are not aware of the specific physical encoding. They simply pass frames to the Network Access and Physical components, which carry them across the link.

Step 6: Switches Forward Frames Within a Network

If the device that receives the frame is a switch on an Ethernet LAN, the switch uses the frame’s destination MAC address to forward it toward the correct port.

In the context of packet flow:

• The switch does not change IP addresses.
• The switch does not look inside the IP packet beyond what is needed for basic functions such as VLAN handling.
• The switch keeps the frame intact and makes sure it arrives at the correct next hop on the same Layer 2 network.

So between two hosts on the same LAN, or between a host and its default gateway, multiple switches may forward the same frame until it reaches the next IP hop.

Step 7: Router Receives the Frame and Processes the Packet

When the frame reaches a router interface, the router participates in packet flow at more layers than a switch.

The router receives the frame as follows:

1. Network Access handling on the router
   The router’s interface card recognizes a frame addressed to its own MAC address and passes the payload to the higher layer.
2. Internet layer inspection
   Inside the frame is the IP packet. The router reads the destination IP address and looks it up in the routing table.
3. Routing decision
   Based on the routing table, the router chooses the outgoing interface and possibly a next hop IP address.

At this point, the router has logically consumed the original frame but not the IP packet. The frame does not cross routers. The IP packet may be forwarded and may be modified only in specific fields such as hop count (for IPv4, TTL).

Step 8: Router Forwards the Packet to the Next Hop

Once the router decides where the packet should go, it must rebuild a frame suitable for the next outgoing link.

The steps mirror what a host does:

1. Determine link layer destination
   The router determines the next hop IP address for forwarding. It then resolves that IP address to a link layer address suitable to the outgoing interface, for example a MAC address on Ethernet.
2. Rebuild the frame
   The router constructs a new frame:
• New source MAC address, the router’s outgoing interface MAC.
• New destination MAC address, the MAC of the next hop (which might be another router or the final host).
• The IP packet as payload, with the same source and destination IP as before, except for fields like TTL that are updated.
3. Send on the physical medium
   The router sends the new frame out of the selected interface across the next link.

This process repeats on each router along the path. The IP packet is carried inside a different frame on each link, but the IP source and destination remain constant from sender to final receiver.

Step 9: Arrival at the Destination Host

Eventually, the frame reaches the destination host’s local network and is delivered to the host’s NIC.

The steps on the destination host are:

1. Network Access layer checks
   The NIC sees a frame with its own MAC address as destination, accepts it from the wire, and passes it to the system’s Network Access logic. Basic integrity checks (such as frame checksums) are verified here.
2. Extract the IP packet
   The frame header and trailer are stripped off. What remains is the IP packet.
3. Internet layer verification
   The host examines the IP header:
• Verifies that the destination IP address matches one of its own addresses.
• Checks for errors and validity.

If the destination IP does not match, the packet is usually discarded.

Step 10: Internet Layer Hands Packet to Transport Layer

Once the Internet layer has validated the packet, it forwards the payload to the appropriate Transport layer protocol.

Key aspects:

• The IP header contains a protocol field that indicates whether the payload is a TCP or UDP segment (or some other protocol).
• The IP layer hands the payload to the matching transport handler, such as TCP or UDP in the operating system.

The IP header is removed at this point, so the Transport layer receives the original segment or datagram.

Step 11: Transport Layer Delivers to the Right Application

The Transport layer completes the delivery to the correct process on the destination host.

Typical actions:

1. Port based demultiplexing
   The segment carries:
• Destination port, which the OS uses to determine which application is supposed to receive the data.
• Source port, which helps identify which remote application instance is sending the data.

The combination of source IP, source port, destination IP, and destination port identifies a particular communication flow in TCP.

2. TCP reliability handling (if TCP is used)
   TCP performs:
• Sequence number checks.
• Reordering of out of sequence segments.
• Acknowledgement of received data back to the sender.
• Detection and handling of data loss, with retransmission if needed.
3. UDP handling (if UDP is used)
   UDP does minimal processing and passes the data quickly to the waiting application. Error handling and ordering are usually the application’s responsibility.

The Transport layer then gives the application data to the target process.

Step 12: Application Layer Consumes the Data

Finally, the application on the destination host receives the reassembled data stream or message.

Examples:

• A web server receives an HTTP request and generates an HTTP response.
• A mail server receives an SMTP message and stores or forwards it.
• A streaming application receives media chunks and plays them.

The application does not see IP, MAC, or physical signaling. It simply receives data in the form the application protocol defines.

From the user’s point of view, a page loads, a video plays, or a message appears. The complex layered journey remains hidden.

Bidirectional Nature of Packet Flow

Communication is normally two way. For each direction, the same sequence applies but with the roles reversed:

1. Application on host A sends to application on host B.
2. Data flows down A’s stack, across the network, and up B’s stack.
3. Application on host B replies, and data flows down B’s stack, across the network, and up A’s stack.

Each direction has its own IP packets and frames. In TCP, both ends maintain state for the connection and exchange control segments as well as data segments.

What Changes and What Stays the Same

It is helpful to remember which fields change on each hop and which do not.

Understanding this distinction is central to understanding packet flow in real networks.

Putting It All Together

Packet flow in the TCP/IP model can be summarized as:

• Application data moves down the stack, gaining headers at each layer.
• The resulting frame travels over one link, is forwarded by switches, and is processed and re framed by each router.
• At the destination, headers are removed as data moves up the stack.
• Each layer only cares about its own header and passes the payload to the next layer.

Once you understand this path, tools like packet captures become much easier to interpret, because you can see each layer’s headers in order and relate them to where the packet is in its journey.