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 acknowledgments 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 acknowledgments, 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:
SYN is not combined with any data.
FIN is seldomly combined with data. Usually it is
sent separately.
ACK and the FIN from the side doing the
passive close can be combined, but usually are not.
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.
Sun, Sun Microsystems, the Sun Logo and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Please send your suggestions, bugfixes, comments, and ideas for new items to
soltune at sean dot de
Last Modified: Thursday, 22-Sep-2005 16:15:50 MEST