TCP/IP Handshake Explained: Transport-Layer Functions and TTL

Posted on 2026-07-03 by Sam Snider

In a TCP/IP handshake, the transport layer opens a connection with a three-step exchange of SYN, SYN-ACK, and ACK segments. That exchange sets up ports, sequence numbers, acknowledgment numbers, and connection state before application data moves. The outer IP header carries a separate TTL network limit that controls how far each packet can travel; it is not part of the TCP header and it does not count handshake steps.

Reading a packet trace becomes much easier when those layers are separated. TCP handles delivery reliability and session state, while IP TTL only limits packet lifetime hop by hop.

Transport-layer functions in a TCP session

Ports and endpoints

The transport layer identifies communication endpoints with ports. A TCP session is defined by the combination of source IP, source port, destination IP, and destination port. For example, a browser might open a connection from client port 52314 to server port 443. The port number tells the server process which application should receive the data, while the IP address tells the network where to send it.

This four-part endpoint is why multiple connections can share the same server address without mixing their data. One client may connect to port 443 for HTTPS, another to port 22 for SSH, and both can remain active at the same time.

Sequence and acknowledgment numbers

TCP uses sequence numbers to label bytes in the stream and acknowledgment numbers to confirm what has been received. During connection setup, each side chooses an initial sequence number. The first ACK from the peer confirms the next expected byte, which is usually one more than the SYN sequence number because the SYN consumes one sequence number.

These fields are the basis of reliability. If a segment is lost, the sender can retransmit it because the byte range is known. If data arrives out of order, the receiver can still place it correctly in the stream using the sequence numbers.

Flags, reliability, flow control, and connection state

TCP flags describe the purpose of each segment. In the handshake, SYN requests a new session, SYN-ACK accepts and responds, and ACK confirms receipt and moves the session forward. Other flags such as FIN and RST close or reset a connection, but they are separate from the three-way setup.

Reliability comes from acknowledgments, retransmissions, and timers. If an ACK does not arrive, TCP assumes loss and sends the segment again after a timeout or on duplicate acknowledgments. Flow control protects the receiver by advertising a receive window, which tells the sender how much data can be accepted without overflow. The connection also has state, moving through LISTEN, SYN-SENT, SYN-RECEIVED, and ESTABLISHED as the handshake completes.

TCP/IP handshake step by step

SYN: start the session

The handshake begins when the client sends a SYN segment to the server. This segment includes the client’s initial sequence number, the destination port, and a set of TCP options such as window scaling or selective acknowledgments if both sides support them. The SYN does not carry application data in a normal setup; its job is to request a connection and advertise the client’s starting state.

At this point, the client is usually in SYN-SENT. If the packet reaches a listening server port, the server can allocate resources for the new connection. If no service is listening, the network may return a refusal later in the process.

SYN-ACK: confirm and reply

The server responds with SYN-ACK. This segment confirms receipt of the client’s SYN with an acknowledgment number and also sends the server’s own initial sequence number. The server is now in SYN-RECEIVED, which means it has recognized the request but is waiting for the final confirmation before it treats the connection as open.

In practice, the SYN-ACK proves two things: the server heard the client, and the server is ready to establish a two-way stateful exchange. If the SYN-ACK never reaches the client, the client will usually retransmit the SYN after a timeout.

ACK: move to established state

The client completes the handshake with an ACK that acknowledges the server’s sequence number. After this segment arrives, both ends move to ESTABLISHED. From here, application data can flow in both directions, with each segment still carrying sequence and acknowledgment numbers so either side can verify delivery.

The key point is that the third message does not open the session by itself. It completes the state transition after both sides have exchanged enough information to trust the connection parameters. That is why the TCP/IP handshake is often described as a coordinated setup of transport state rather than a single packet event.

How network TTL limits packet lifetime

TTL in the IP header

TTL, or time to live, belongs to the IP header, not the TCP header. It is a hop limit that prevents packets from circulating forever if routing loops occur. The value is set by the sender when the packet is created, and it applies to each IP packet independently, including each SYN, SYN-ACK, and ACK.

TTL does not track connection state, and it does not determine whether the handshake succeeds by itself. A packet can have a normal TCP sequence number and still fail if its TTL expires before it reaches the destination.

How routers decrement TTL

Every router that forwards the packet subtracts one from TTL. If a packet starts with TTL 64, then after one hop it becomes 63, after two hops 62, and so on. When the value reaches zero, the router discards the packet instead of forwarding it farther.

In many networks, the router also sends an ICMP Time Exceeded message back to the sender, which helps reveal where the packet stopped. This mechanism is often visible in diagnostic tools and traceroute-style behavior, but it is separate from TCP itself.

When TTL expires before the packet arrives

If TTL expires before the SYN reaches the server, the handshake never starts. If it expires on the return SYN-ACK, the client never sees the server’s reply and will usually retransmit the original SYN. If it expires on the final ACK, the server may have half-open state for a short time and then time out waiting for completion.

These failures can look similar at the application layer, but the packet trace shows a different cause. A TTL problem produces disappearing packets at a predictable hop count, while a TCP problem usually shows retries, resets, or long waits with no route change pattern.

How to read a complete connection trace

Normal handshake trace

A clean trace often looks like this:

Client to server: SYN, seq=1000, dst port 443
Server to client: SYN-ACK, seq=5000, ack=1001
Client to server: ACK, ack=5001

That pattern shows that the ports match the application, the sequence numbers advance correctly, and the connection has moved into the established state. The IP TTL value may differ on each packet, but it does not change the meaning of the handshake.

Retransmission, refusal, and timeout

If the client sends a SYN and does not receive a SYN-ACK, a retransmission usually appears after a timer expires. That is a transport-layer reliability event, not a TTL field. The repeated SYN has the same purpose and sequence relationship as the first one, because TCP is trying again to establish the same connection.

A refusal looks different. If the destination port is closed, the server may return a RST instead of a SYN-ACK. That tells the client the host reached the packet, but no listening process accepted the connection. A timeout happens when neither a reply nor a reset arrives, so the client keeps retrying until it gives up. In traces, refusal is immediate feedback, while timeout is silence followed by retransmission.

Path-expiry example caused by TTL

Consider a SYN sent with a TTL that is too low for the route. The packet may reach several routers and then expire before the server ever sees it. The client observes only retries, but the trace reveals a fixed hop where packets stop and possibly an ICMP Time Exceeded response. If the client then raises TTL or the route changes, the handshake may succeed without changing any TCP settings.

That distinction matters when troubleshooting. TCP sequence numbers, ACKs, flags, and state explain whether the session logic is working. IP TTL explains whether the packet can survive long enough to reach the next hop and complete the exchange.