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
netstat -anf inet command. All readers of Stevens will be
familiar with the diagrams.
|Figure 1: The absolute minimum.||Figure 2: The normal exchange.|
FINindicator 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
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
|Figure 2: The normal exchange.||Figure 3: The HTTP exchange.|
FINcould be bundled with the
ACKinto 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
FINis 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
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
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
(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
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:
SYNis not combined with any data.
FINis seldomly combined with data. Usually it is sent separately.
FINfrom the side doing the passive close can be combined, but usually are not.
ACKis usually combined with data, but must be sent separately, if the
ACKwould outstand for longer than the interval specified in tcp_deferred_ack_interval.
Last Modified: Tuesday, 22-Sep-1998 10:20:24 MET DST