TCP provides a reliable stream abstraction on top of the underlying IP layer. Although an application interacts with TCP as if it were a stream of individual bytes, a TCP implementation packages a sequence of bytes together into what is known as a TCP segment. A segment has a TCP header, for the protocol to operate, and data, from the driving application. Like those Russian dolls, TCP segments are then used as the data of an IP packet, so that segments can be routed from the source to destination.

RFC 793 provides a diagram of the TCP segment format, which I’ve reproduced below:

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TCP Header Format

          Note that one tick mark represents one bit position.

                               Figure 3.

To better understand what TCP offers, let’s contrast it with UDP, a much simpler protocol. RFC 768 provides an analogous diagram for the UDP header:

                  0      7 8     15 16    23 24    31  
                 +--------+--------+--------+--------+ 
                 |     Source      |   Destination   | 
                 |      Port       |      Port       | 
                 +--------+--------+--------+--------+ 
                 |                 |                 | 
                 |     Length      |    Checksum     | 
                 +--------+--------+--------+--------+ 
                 |                                     
                 |          data octets ...            
                 +---------------- ...                 

                      User Datagram Header Format

There are a few features common to both:

• Ports are used for multiplexing. This lets applications address specific processes rather than just hosts.
• Checksums are used to detect corruption of individual segments/datagrams.

That’s about it! Let’s look at a few of the differences:

• The TCP header has a variable length, depending on whether options are used. Because of this, it needs a Data Offset field to indicate where the data actually starts.
• Unlike TCP, UDP explicitly includes a Length field to indicate the total size of the datagram. TCP does not require this field because the length can be inferred from the enclosing IP packet’s size. One possible reason for UDP’s design choice is that it comes from a time when alternatives to IP were still being considered. Additionally, including Length ensures that the UDP header has 4-byte alignment.
• TCP provides a reliable byte stream by explicitly communicating the position in this stream for data being sent (the Sequence Number). Since TCP is bi-directional, a segment also indicates the next byte expected by it sender (the Acknowledgement Number). The sequence number increases as data is sent, and the acknowledgement number increases as data is successfully received. If sent data is not acknowledged, TCP can re-send this data.
• To prevent scenarios where a sender is overwhelming a receiver with more data than it can keep up with, TCP provides a notion of flow control. This relies on the protocol managing an interval of sequence numbers, known as a “sliding window”. The window defines what sequence numbers the sender is allowed to send, and this window advances as earlier sequence numbers get acknowledged. Instead of using a fixed window size, the TCP specification allows for the receiver to set the size with the Window field of the header.
• The TCP header has various flags that can be used for things like establishing or closing a connection.
• The Urgent Pointer. In principle, when the Urgent flag is set, this field indicates an offset into the TCP segment’s data where the bytes are considered “urgent”. It’s not obvious from the RFC how this is used in practice.

This comparison offers an additional perspective on TCP that complements my previous discussion about the TCP state machine and sequence diagrams. While the state machine and sequence diagrams define TCP’s semantics, the segment format defines TCP’s syntax. To fully understand TCP, you need both.