230 lines
9.1 KiB
HTML
230 lines
9.1 KiB
HTML
<!--startcut ======================================================= -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html>
|
|
<head>
|
|
<META NAME="generator" CONTENT="lgazmail v1.2J.g">
|
|
<TITLE>The Answer Guy 42: SYN, SYN/ACK, ACK, ACK, ACK: TCP Handshaking</TITLE>
|
|
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
|
|
LINK="#3366FF" VLINK="#A000A0">
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
|
|
<P> <hr> <P>
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<center>
|
|
<H1><A NAME="answer">
|
|
<img src="../../gx/dennis/qbubble.gif" alt="(?)"
|
|
border="0" align="middle">
|
|
<font color="#B03060">The Answer Guy</font>
|
|
<img src="../../gx/dennis/bbubble.gif" alt="(!)"
|
|
border="0" align="middle">
|
|
</A></H1>
|
|
<BR>
|
|
<H4>By James T. Dennis,
|
|
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
|
|
LinuxCare,
|
|
<A HREF="http://www.linuxcare.com/">http://www.linuxcare.com/</A>
|
|
</H4>
|
|
</center>
|
|
|
|
<p><hr><p>
|
|
<!-- endcut ======================================================= -->
|
|
<!-- begin 3 -->
|
|
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
|
|
height="50" width="60" alt="(?) " border="0"
|
|
>SYN, SYN/ACK, ACK, ACK, ACK: TCP Handshaking</H3>
|
|
<H4 ALIGN="center">
|
|
"Pleased to meet you!"</H4>
|
|
|
|
|
|
<p><strong>From Kent S on Sun, 02 May 1999
|
|
</strong></p>
|
|
<!-- ::
|
|
SYN, SYN/ACK, ACK, ACK, ACK: TCP Handshaking
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
"Pleased to meet you!"
|
|
:: -->
|
|
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
I need help in finding information regarding how sockets are
|
|
established (not how to code them). In other words, I know that
|
|
there is a standard procedure followed (SYN,SYN/ACK,ACK) in
|
|
getting a device talking with a server.
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
This is referred to as a "three way handshake."
|
|
The "SYN" flags are requests by the TCP stack at one
|
|
end of a socket to synchronize themselves to the sequence
|
|
numbering for this new sessions. The ACK flags
|
|
acknowlege earlier packets in this session. Obviously
|
|
only the initial packet has no ACK flag, since there are
|
|
no previous packets to acknowlege. Only the second
|
|
packet (the first response from a server to a client)
|
|
has both the SYN and the ACK bits set.
|
|
</BLOCKQUOTE>
|
|
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
I am more curious in determining how, where, and who actually
|
|
handles this on the Linux server.
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
The kernel.
|
|
</BLOCKQUOTE>
|
|
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
As an example - I have inetd looking at port 226 for me that will
|
|
start a program that will read from the socket. If this program
|
|
terminates (kill,alarm,etc...) then the device attempts to
|
|
re-establish (sends a SYN). Then one of two things happens
|
|
depending on how the program was stopped. Either the server never
|
|
responds until the device sends a reset or the server sends a
|
|
SYN/ACK and then sends a packets saying that it is finished
|
|
sending data. My questions are on the level of does RESET reset a
|
|
port or a socket, and why would a server send a finish sending
|
|
data flag if the device is requesting a connection. I have been
|
|
unable to find info about the protocols of communications that
|
|
should be taking place. Any help would be appreciated!
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
Kenneth Scott
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
I don't really understand what you're asking or what
|
|
situation you are trying to describe. Giving examples
|
|
of what you see and the specific diagnostic commands
|
|
you're using to gather your data on the problem (ps,
|
|
netstat, lsof, etc) would probably help.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
However, I can take a guess at what you might be seeing.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
There is also a three way handshake at the termination
|
|
of a TCP session. Either side sends a packet with the
|
|
FIN (final) flag set, and waits for the other side to
|
|
acknowlege that with another FIN packet.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
After the local process as attempted to close the
|
|
socket (and the TCP stack has sent the FIN packet to the
|
|
remote system) the process will be listed as being in the
|
|
FIN_WAIT stat when you do a 'netstat' command. Buggy
|
|
TCP clients may just close their end of the connection
|
|
without completing the three way session termination. This
|
|
seems to be mostly from certain MS Windows FTP clients.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
There seems to be no "timeout" for how long a processes
|
|
will sit in FIN_WAIT. When I managed a busy FTP server
|
|
farm for McAfee Associates (a shareware company with lots
|
|
of MS-DOS and Windows products) I used to see alot of zombies
|
|
which were children of FTP daemon processes that were in
|
|
FIN_WAIT. I had a skulker script that would find the
|
|
parents of the zombies, check their age and argument list
|
|
and summarily kill them.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
I don't know the details about the TCP RST (reset) process.
|
|
I've at the extreme edge of my knowlege of TCP in this
|
|
message --- so I can't go into any greater detail on this.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
However, I've heard that the best sources of information
|
|
about TCP protocols are a couple of books. One would be the
|
|
O'Reilly volume by Craig Hunt (the crab book), <em>Understanding
|
|
TCP/IP</em> <em>[ Actually, the "crab book" is
|
|
<a href="http://www.oreilly.com/catalog/tcp2/index.html"
|
|
>TCP/IP Network Administration</a>, now in its 2nd edition.
|
|
-- Heather ]</em>,
|
|
the other would be a three volume set by Comer and
|
|
Stevens <em><a href="http://www.prenhall.com/allbooks/esm_0132169878.html"
|
|
>Internetworking With Tcp/Ip: Principles, Protocols, and Architecture</a></em>.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
As you've suggested these are written more with the
|
|
programmer in mind. However the O'Reilly book seems to be
|
|
more suitable for sysadmins and users (besides being a
|
|
paperback, and therefore much less expensive than the three
|
|
volume hardcover text books from Prentice Hall).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
One of these days I'll get around to reading that one.
|
|
I'd been holding out for one that covered IPv6 in the
|
|
hope that IPv6 would be deployed more widely by the time
|
|
I got around to learning all the gory details. However,
|
|
it looks like we'll still be dealing with IPv4 (the
|
|
current suite of protocols) for the foreseeable future.
|
|
</BLOCKQUOTE>
|
|
<!-- sig -->
|
|
|
|
<!-- end 3 -->
|
|
|
|
<!--startcut ======================================================= -->
|
|
<P> <hr> <P>
|
|
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
|
|
>Copyright ©</a> 1999, James T. Dennis
|
|
<BR>Published in <I>The Linux Gazette</I> Issue 42 June 1999</H5>
|
|
<H6 ALIGN="center">HTML transformation by
|
|
<A HREF="mailto:star@starshine.org">Heather Stern</a> of
|
|
Starshine Techinical Services,
|
|
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A>
|
|
</H6>
|
|
<P> <hr> <P>
|
|
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<TABLE WIDTH="97%"><TR VALIGN="center" ALIGN="center">
|
|
<TD ROWSPAN="4" COLSPAN="1" WIDTH="37%"><A
|
|
HREF="../lg_answer42.html"
|
|
><IMG SRC="../../gx/dennis/answernew.gif"
|
|
ALT="[ Answer Guy Index ]"></A></td>
|
|
<TD WIDTH="10%"><A HREF="1.html">1</A></TD>
|
|
<TD WIDTH="10%"><A HREF="2.html">2</A></TD>
|
|
<TD WIDTH="10%"><A HREF="3.html">3</A></TD>
|
|
<TD WIDTH="10%"><A HREF="4.html">4</A></TD>
|
|
<TD WIDTH="10%"><A HREF="5.html">5</A></TD>
|
|
<TD WIDTH="10%"><A HREF="6.html">6</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="7.html">7</A></TD>
|
|
<TD><A HREF="8.html">8</A></TD>
|
|
<TD><A HREF="9.html">9</A></TD>
|
|
<TD><A HREF="10.html">10</A></TD>
|
|
<TD><A HREF="11.html">11</A></TD>
|
|
<TD><A HREF="12.html">12</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="13.html">13</A></TD>
|
|
<TD><A HREF="14.html">14</A></TD>
|
|
<TD><A HREF="15.html">15</A></TD>
|
|
<TD><A HREF="16.html">16</A></TD>
|
|
<TD><A HREF="17.html">17</A></TD>
|
|
<TD><A HREF="18.html">18</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="19.html">19</A></TD>
|
|
<TD><A HREF="20.html">20</A></TD>
|
|
<TD><A HREF="21.html">21</A></TD>
|
|
<TD><A HREF="22.html">22</A></TD>
|
|
<TD><A HREF="23.html">23</A></TD>
|
|
<TD><A HREF="24.html">24</A></TD>
|
|
</TR></TABLE>
|
|
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<P> <hr> <P>
|
|
<!-- begin lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<A HREF="../../index.html"
|
|
><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
|
|
<A HREF="/index.html"
|
|
><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
|
|
<A HREF="../lg_bytes42.html"
|
|
><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
|
|
<A HREF="../lg_tips42.html"
|
|
><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
|
|
<!-- end lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
</BODY></HTML>
|
|
<!--endcut ========================================================= -->
|