TCP Protocol: The Overview - Part1

One of the most important layers we - as network engineers - hate and avoid in the OSI reference model is the transport layer with its popular and dominant protocol; TCP.

Most of network engineers abandoned diving into TCP protocol because they consider it a host-to-host communication protocol that usually works without a problem. End systems either Windows or Linux gets installed with their own version of TCP stack with some pre-configured values that usually don't break, so why would we bother ourselves learning about one of the most important protocol in the TCP/IP stack!

The irony here is that, System Engineers, Application Developers and Support hold the same issues to the TCP, and it ended up as a protocol that everyone know very few things about.

In the coming weeks, I will offer you a series of posts that are short, intense and detailed about TCP. I know that TCP documents and RFCs are boring and they involve some mathematics that some of us hate, but I guarantee you that these posts will not be one of them. So, let us begin.

TCP is a transport-layer protocol which gets a stream of bytes from an upper layer application on one end-host to be sent reliably, in-ordered fashion, over a pre-established connection with another end-host traversing a network of different physical circuits with different speeds.

This how I usually define TCP to myself, and it really holds a lot of details about TCP. Let's begin with the "stream of bytes" part.

TCP expects a bunch of bytes from the upper-layer applications, because the upper layers do not usually "pile" or "pack" data into fixed shapes or sizes of containers, they usually throw the TCP input buffers with a stream of bytes until the TCP buffers gets filled, and the TCP will flag this to the application layer to hold on until the buffers gets freed.

The second part is "via pre-established connection". TCP is a connection-oriented protocol, which means that an end-to-end virtual connection must be built with some agreed-upon parameters between two endpoints to be used as the transport channel for the stream of bytes.

This gets us to the "reliable and in-ordered fashion" part. One of the parameters that end-hosts synchronize and agree upon when they build the virtual connection is the sequence numbers.

Sequence numbers are just like a "marker" that the sender and receiver will use to determine and keep track of  how much data has been sent and how much data has been received and have to be verified and acknowledged with the sender.

The sequence numbers will be useful in making sure that data sent from one end-host has been delivered completely to the other end-host and that the other end-host can re-assemble these "packages" of data based-upon their sequence number to constitute the original form of the bytes stream in-order.

Being said that, TCP will try so hard not to congest the traversing physical links and induce a delay or drops to the carried data, because when drops increases, TCP will have to specify and spot the dropped "parts" of data and re-transmit them again as fast as it can be, and this is a complicated task.

This is the end of the first post. Again; I don't want to provide a long boring posts, and what have been written above will make perfect sense in the coming posts when every part is discussed in more details.