Five-Tuple

When people in packet captures say “see whether the five-tuple changed,” they are not using another name for a TCP connection. The five-tuple is the smallest practical identifier for a network flow. NAT, firewalls, load balancers, and connection tracking all depend on it.

Looking at only one IP address is not enough. Two hosts can have many simultaneous connections, even to the same service. Looking at only one port is not enough either, because the same port numbers repeat across different hosts. The network and the kernel need a combination that is small enough to operate on and stable enough to answer questions like: is this the same flow, is this a return packet, and should this state table entry be reused?

The five-tuple does not try to describe the packet more completely. It gives a network flow the smallest usable unique identity: source IP, destination IP, transport protocol, source port, and destination port

What Problem It Solves

If you only use destination address and destination port to think about communication, the model breaks quickly.

For example, one client host may simultaneously:

• Open two browser tabs to the same HTTPS site
• Talk to the same database address from one process
• Download a file while also calling an API, both on 443

These flows may share the same destination IP and destination port, but they are clearly not the same flow. If the network device or OS cannot tell them apart, problems appear immediately:

• Which local socket gets the reply
• Whether a firewall should treat the packet as established return traffic
• Which internal host a NAT mapping should restore the packet to
• Which backend a load balancer should keep using for the current flow

The five-tuple is the smallest answer to that class of problems. It lets kernels and network devices match a flow to a real set of conditions.

The Main Model

The standard five-tuple includes:

• Source IP address
• Destination IP address
• Transport protocol such as TCP or UDP
• Source port
• Destination port

The core model is:

Packet arrives
  -> Check transport protocol
  -> Check the source / destination address and port combination
  -> Decide whether it belongs to an existing flow or a new one

The important boundary is this:

• It describes a transport-layer flow
• It is not the application session itself
• It is not the same thing as “a service”

If you do not keep that boundary clear, it becomes very easy to mix up five-tuples, sockets, connections, business sessions, and login state.

A Typical Path

Here is a normal TCP HTTPS request as it appears to a host or an intermediate device:

The device does not say “this is HTTPS” and stop there. It uses the five-tuple, plus the reverse direction, to identify the flow.

That is why the same pair of hosts can have many simultaneous TCP 443 connections and still be separated correctly. The source ports differ, so the five-tuples differ.

Why It Naturally Belongs to Flows

The five-tuple is best at describing a transport-layer flow, not an abstract business object.

For TCP, it often maps closely to a connection boundary. Once the connection is established, most subsequent packets sit in that tuple and its reverse.

For UDP, the protocol itself has no connection setup, but many systems still treat a sequence of packets with the same five-tuple as one flow or one session window so they can do:

• State timeout
• Reply matching
• Connection tracking
• Load-balancing stickiness

So the five-tuple is not a TCP-only idea. It is the shared base for transport-layer flow identification. TCP just adds stronger connection semantics on top of it.

Why Four-Tuple or Port-Only Views Are Not Enough

Every field in the five-tuple matters.

Source and destination addresses alone are not enough because the same two hosts can carry many protocols, services, and ports at the same time.

Even address plus port is still not enough, because:

• TCP 53 and UDP 53 are different semantics
• The same addresses and ports mean different things under different transport protocols

That is why the transport protocol must stay as its own dimension. It is not an extra convenience field. It is required for correct matching.

Five-Tuple, Socket, Connection, and Session

These words are easy to mix up, but they are not equivalent.

• The five-tuple describes the matching condition for a transport-layer flow
• A socket is an operating-system endpoint object
• A connection is the transport-layer state relationship, especially for TCP
• A session is an application-layer business relationship

Sometimes these line up closely. Sometimes one socket carries multiple application streams, or one session spans several transport flows. The safer model is:

• Five-tuple answers “is this the same transport flow”
• Socket answers “which kernel object receives this traffic”
• Connection answers “has the transport state been established”
• Session answers “is this the same business interaction”

Why NAT Depends on It

NAT is not just address rewriting. It maintains mappings between internal and external flow identities. Many internal hosts may share one public address, so address rewriting alone cannot disambiguate the return path.

NAT devices usually need to consider:

• Internal source address and source port
• External destination address and destination port
• Transport protocol

In other words, they live directly on the five-tuple.

Once NAT rewrites an address or port, the packet’s five-tuple changes too. That is why NAT debugging usually requires both the pre-translation tuple and the post-translation tuple.

Why Stateful Firewalls Depend on It Too

Stateful firewalls do not usually parse full business meaning. They more often decide:

• If the first packet is allowed
• If it is allowed, create state for the flow
• Use the five-tuple and its reverse direction to match later packets

That is how they separate:

• Return traffic for an already established flow
• A new inbound connection that has not been allowed

Cloud security groups, host connection tracking, and boundary firewalls all rely on this kind of matching.

Why Load Balancers Care About It

Load balancers also use the five-tuple heavily.

Why? Because once a flow is assigned to one backend, later packets from the same flow usually need to keep going to the same backend. Otherwise the state breaks.

Common patterns include:

• Hash the five-tuple to select a backend for the first packet
• Keep the same result for later packets in the same flow
• Add higher-layer stickiness if needed

So the value of the five-tuple is not only identification. It also helps keep the traffic path consistent.

Why “The Five-Tuple Changed” Often Means “A Bug Started Here”

Many strange network failures are really cases where the five-tuple changed when it should have stayed stable, or failed to stay stable when it needed to.

Common examples:

• NAT rewrites the source port and the peer sees a new flow
• A retry picks a different local ephemeral port
• Connection migration, proxying, or multi-exit paths change the source address
• A load balancer hashes differently and sends later packets to another backend

So when a packet reaches the destination but the state does not line up, the first thing to check is often whether the five-tuple remained consistent.

What to Look At First in Packet Capture and Debugging

The easiest way to get lost is to stare at TCP flags or application fields before you know whether this is still the same flow. A better order is:

First, write down the forward and reverse tuples

Confirm:

• Source and destination addresses and ports
• Transport protocol
• Whether the reply forms the reverse tuple exactly

Then ask whether a middlebox changed it

Check whether:

• NAT rewrote the source address or port
• A proxy terminated and recreated the flow
• A firewall or load balancer tracks the flow state separately

Finally, map the tuple to the real layer

The five-tuple is not the application itself. It is the operating key that lets the network keep one flow separate from another.

Takeaways

• Do not think of the five-tuple as a packet-capture term. It is the common base used by kernels and network devices to identify flows
• Do not mix the five-tuple with an application session. It only identifies a transport-layer flow
• Do not forget the protocol dimension. TCP and UDP with the same addresses and ports are not the same flow
• Do not underestimate changes to the five-tuple. Many NAT, load-balancing, and stateful-firewall failures start there
• Do not only memorize the definition. In troubleshooting, first ask whether you are still looking at the same five-tuple before and after the problem

Further Reading

• Port - what the source and destination ports in the five-tuple really mean on a host
• TCP - why the five-tuple is often used to identify a TCP connection
• UDP - why connectionless protocols are still often tracked by five-tuple on network devices
• NAT - why address and port rewriting directly changes the five-tuple
• Firewall - why stateful firewalls depend on the five-tuple and the reverse flow to make connection decisions

References