Simple transactions using TCP

Last Update: 20.09.98 (change log)

The definition of a transaction is taken from the book of Stevens. Stevens himself seems to have taken his definition from the TCP for transactions (T/TCP) protocol. A transaction is both, the query sent by a client to a server and the reply of the server.

All diagrams on this page use A for the client and B for the server. The time line moves downwards. A little tweak in the timeline is inserted to indicated a variable amount of time. On the side the timelines are labelled with the TCP state as can be obtained with the netstat -anf inet command. All readers of Stevens will be familiar with the diagrams.


Figure 1: The absolute minimum.		Figure 2: The normal exchange.

If the previously mentioned definition of a transaction is implemented using TCP as transport protocol (like HTTP does), a client and a server usually exchange nine segments. Stevens shows that in early stages of the TCP protocol developement so called christmas tree segments were planned. Such segments have both, the SYN and the FIN indicator set. Those transaction still need to exchange five segments as is shown in figure 1. For this reason and the need of two round trip times the topic was dropped to the best of my knowledge. RFC 1379 reiterates this issue.

The mimimum possible exchange as shown in figure 1 is within the specification of the TCP protocol. To this day there are almost no systems able implementing TCP to this extend. The TCP layer does not support applications to send less than the shown number of segments. The transaction is still accomplished only after two round-trip times (RTT), not one. Most systems are not capable of understanding segments with SYN and FIN bit set. Neither do those systems comprehend that these segments may actually contain data.

For a simple transaction on top of TCP usually the segments shown in figure 2 are exchanged. You get the complete three-way handshake from a TCP open. Afterwards the query data is sent to the server. Up to this point, four segments are exchanged. The FIN is usually transmitted separately from any data. You see in figure 2 a client doing a half close of the connection, indicating that it does not wish to send any further data.


Figure 2: The normal exchange.		Figure 3: The HTTP exchange.

If delayed acknowledgements are supported by the systems, the final FIN could be bundled with the ACK into one segment, but usually data is not bundled with FIN. Finally the result is transmitted by the server. Due to delayed acknowledgements, both data and the ack can be transmitted - if the server is reacting fast enough. The server's FIN is transmitted separately. Finally the connection is terminated.

During a unidirectional data transfer phase, TCP does not need to acknowledge each single segment. Such a phase is either the transmission of a rather longish request or an extensive answer. For TCP it suffices to acknowlegde all data received every window full. For this reason the size of the windows and buffers is very important and a mean to gain more throughput on highspeed links.

Without delayed ACKs the peers have to exchange ten to eleven segments. Most implementation need to exchange only the shown nine segments. You always need a 2 * RTT period for transactions via regular TCP. For simple request and response services the overhead of connection establishment and tearing down is way too large. Worse, the internal TCP mechanisms to avoid network congestion is contraproductive to transactions.

Figure 2 depicts a client which actively closes the connection, thus not using up precious server resources. However, with the HTTP protocol the server closes the connection and leaves the socket for a period of 2MSL in the TIME_WAIT state. Usually nine to ten segments are exchanged as shown in figure 3. Note that the picture just shows the minimum query and reply. Usually, the server reply is much larger, using up many times the multiple of the maximum segment size (MSS) announced during connection establishment.

The red marked part marked "possibly combined" shows the difference between exchanging nine or ten segments. If the time the server needs to answer the request is below tcp_deferred_ack_interval ms (default 50 ms, BSD suggests 200 ms, RFC 1122 forbids values above 500 ms), the ACK can be piggybacked with the answer. In that case the total is only need nine segments. On the other hand a heavily loaded server might not be able to responds this fast. Thus, the server gets the additional load of its TCP stack having to acknowledge the request separately from any kind of reply.

The means to combine data with SYN, FIN and ACK are various and influence the number of exchanged PDUs. Stevens mentions a few possibilities of the combination of the various TCP flags, but common practice is the following:

a SYN is not combined with any data.
a FIN is seldomly combined with data. Usually it is sent separately.
an ACK and the FIN from the side doing the passive close can be combined, but usually are not.
an ACK is usually combined with data, but must be sent separately, if the ACK would outstand for longer than the interval specified in tcp_deferred_ack_interval.

[Back] [Solaris tuning] [TCP transactions] [SYS-V-IPC] [TCP rexmit] [Slow start] [JSV homepage] [RVS homepage]

Please send your suggestions, bugfixes, comments, and ideas for new items to voeckler@rvs.uni-hannover.de
In hope of supplying useful information, Jens-S. Vöckler

Last Modified: Tuesday, 22-Sep-1998 10:20:24 MET DST