Why is TCP termed "reliable"?

The simple answer is that it overcomes the effects of packet loss or receiving packets out of order. Let's elaborate more, shall we?

Packet loss occurs when data fails to reach its destination typically because of data transmission errors (such as wireless network interference) or network congestion.

Network congestion happens when nodes attempt to send more data over a network connection than the connection can handle, causing the nodes to discard the excess packets.

Flow control and retransmission allow TCP to overcome packet loss and facilitate the delivery of data to the recipient.

Working With TCP Sessions

A TCP session allows you to deliver a stream of data from any site to a recipient and receive confirmation that the recipient received the data.

Establishing A Session With The TCP Handshake

A TCP connection uses a 3-way handshake to introduce the client to the server and the server to the client. The handshake creates and establishes a TCP session over which the client and server exchange data

Before it can establish a TCP session, the server must listen for incoming connection (the term server and client is used to refer to the listening node and dialing node. TCP itself doesn't have a concept of a client and server, but an established session between two nodes, whereby one node reaches out to another node to establish the session.

As the first step of the handshake, the client sends a packet with the syn flag to the server. The SYN packet informs the server of the client's capabilities and preferred window setting for the rest of the conversation.

Next, the server responds with its packet, with both the ACK and SYN flags set. The ACK flag tells the client that the server acknowledges receipt of the client's SYN packet. The server's SYN packet tells the client what setting it's agreed to for the duration of the conversion.

Finally, the client replies with an ACK packet to acknowledge the server's SYN packet, which establishes the TCP session.

Each TCP packet contains a seq no, which the receiver uses to acknowledge receipt of each packet and properly order the packets.

An ACK packet users the seq not to tell the sender, "I've received all packets up to and including the packet with this sequence number."

The sender uses the sequence number in the ACK packet to determine whether it needs to retransmit any packets. For example, if a sender transmits a bunch of packets with seq no up through 100 but then receives an ACK from the receiver with seq no. 90, the sender knows it needs to retransmit the packet from sequence no. 91 to 100.

Note: One ACK packet can acknowledge the receipt of one or more packets from the sender.

Receive Buffer and Window Sizes

Since TCP allows a single ACK packet to acknowledge the receipt of more than one incoming packet, the receiver must advertise to the sender how much space it has available in its receive buffer before it sends an acknowledgment.

A receive buffer is a block of memory reserved for incoming data on a network connection. It allows the node to accept a certain amount of data from the network without requiring an application to immediately read the data. Both the client and server maintain their per-connection receive buffer.

ACK packets include a window size, which is the number of bytes the sender can transmit to the receiver without requiring an acknowledgment.

If the client sends an ACK packet to the server with a window size of 24537, the server knows it can send 24537 bytes to the client before expecting the client to send another ACK packet.

A window size of zero indicates that the receiver's buffer is full and can no longer receive additional data. Both the client and the server keep track of each other's window size and do their best to fill each other's receive buffers. This method of receiving the window size in an ACK packet, sending data, receiving an updated window size in the next ACK, and then sending more data is known as a sliding window.

In the diagram above, the client sends an ACK for previously received data. This ACK includes a window size of 3072 bytes. The server now knows that it can send up to 3072 bytes before it requires an ACK from the client. The server sends three packets with 1027 bytes each to fill the client's receive buffer. The client then sends another ACK with an updated window size of 2048 bytes. This means that the application running on the client read 2048 bytes from the receive buffer before the client sent its acknowledgment to the server. The server then sends two more packets of 1024 bytes to fill the client's receive buffer and waits for another ACK.

That wraps it up! Hope you found some useful information. Till next time, keep coding and reading! 😊