Skip to content
Skip to main content

About this free course

Download this course

Share this free course

Protocols in multi-service networks
Protocols in multi-service networks

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

3.4 Transmission control protocol (TCP)

As I outlined in the previous section, peer entities in clients and servers exchange HTTP protocol data units when they wish to transfer a resource over the web. I gave very little detail about this because I wanted to focus on the general features of protocols in the application layer of the TCP/IP model. The HTTP protocol data units are transferred from the sender host to the receiver host by calling on the services of the transport layer. In the case we are considering, the transport layer provides the services through the transmission control protocol (TCP).

A host may have several applications active simultaneously and it is necessary to separate the messages arriving from the transport layer. In the TCP/IP model this is achieved through port numbers. Port numbers are stored as 16-bit numbers, so have the range 0 to 65535 (65535 = 216 − 1). Those in the range 0 to 1023 are reserved for standard services and are called well-known port numbers. Those in the range 1024 to 49151 refer to ports registered to provide services to unknown callers. The remainder, 49152 to 65535, refer to dynamic or private ports and may be used as required. Well-known port numbers are embedded in the software, so for standard services a host does not have to take any special actions to find out which port number to specify.


Which of the layer functions mentioned in Section 2 is accomplished through port numbers in the TCP protocol?


Multiplexing and demultiplexing. Port numbers allow several applications to establish separate virtual connections to different applications.

The receiver host has the port number 80 reserved for receiving HTTP messages, but for certain other applications the sender host can select any port number it wishes in the range 1024 to 65535.

Before I describe the primitives issued to support HTTP, we need to look at TCP to understand some of its functions. The main objective of TCP is to provide a reliable end-to-end byte stream over an internetwork. The TCP entity receives a byte stream from an application entity and divides the data into units not exceeding 65535 bytes. In practice the size is about 1500 bytes because of the maximum transfer unit supported by the underlying physical networks. These protocol data units are then passed down to the internetwork layer for delivery to the destination host. The transport layer at the destination re-assembles the data units into a byte stream for delivery to the application layer in that system.

Some insight into the operation of TCP can be obtained by examining the format of the protocol data units, which are called segments in TCP terminology, as shown in Figure 17.

Figure 17
Figure 17 TCP segment format

Figure 17 identifies the following fields in a TCP segment:

  • source port (16 bits) – identifies the port number of the source;

  • destination port (16 bits) – identifies the port number of the destination;

  • sequence number (32 bits) – gives the number of the first data byte in this segment, unless the synchronise flag is set, in which case the first data byte is this number plus 1;

  • acknowledgement number (32 bits) – if the acknowledgement flag is set, this is the sequence number of the next data byte that the sender of this segment expects to receive;

  • data offset (4 bits) – gives the number of 32-bit words in the header and therefore indicates where the data begins in the segment;

  • reserved field (6 bits) – these bits have no defined purpose;

  • URG (1 bit) – the urgent flag indicates that the urgent pointer field is significant;

  • ACK (1 bit) – the acknowledgement flag indicates that the acknowledgement number field is significant;

  • PSH (1 bit) – the push flag indicates that the receiver is to deliver all data to the application rather than wait for a buffer to fill;

  • RST (1 bit) – the reset flag indicates that the connection is to be reset because some problem has arisen;

  • SYN (1 bit) – the synchronise flag indicates that the initial sequence number of the data bytes is to be the value of the sequence number field plus 1; in effect it indicates a request to establish a new connection;

  • FIN (1 bit) – the finish flag indicates that there is no more data from the sender and also indicates a request to clear the connection;

  • window size (16 bits) – identifies the number of data bytes that the sender of this segment is willing to accept without acknowledgements;

  • checksum (16 bits) – this is a simple check sequence of all the 16-bit words in the header and user data fields;

  • urgent pointer (16 bits) – if the urgent flag is set, this is the offset in the data field of the first data byte that follows the urgent data, i.e. in effect it gives the position of the end of the urgent data;

  • options (0 or more 32-bit words) – a list of option parameters, e.g. the maximum segment size;

  • user data (optional) – user data to be transferred transparently between application entities.

Notice that the network address of the host is not included in any field of a TCP segment. This is because the network address is important to the internetwork layer rather than the transport layer and, as you will see later, appears in the IP protocol data unit.


Why is data optional in TCP segments?


As you will see in the next section, some TCP segments do not transfer data from higher layers but perform functions such as setting up a virtual connection.