Priscilla's explanation is right on the money I have added a
few comments to expand on some areas that were not mentioned.
See below.
> TCP sequences bytes. A lot of people assume that TCP
sequences packets
> or
> segments, but that's not true.
>
> The sequence number in a TCP header is the sequence number of
the first
> byte in the payload. It's not a segment number. The ACK is
the number of
>
> the next byte of payload expected. It's not a segment number.
The
> sliding
> window keeps track of how many bytes have been sent and
acknowledged.
Very correct. The only way to see this is to "count the bytes"
as the go across the wire. To help a little bit, I have
included an ASCII capture summary for a TTCP transfer (watch
wrap):
http://www.west-
point.org/users/usma1983/40768/chesinc/docs/ttcp2.txt
This is not a theoretical capture, rather a real 10 minute
transfer between two windows hosts using a direct connection
with a crossover cable. If you look at the first sequence
number, you will see it is SEQ=20602846 . Look at the window
size and the packet length size (8760 and 1460 respectively).
We should expect to see five more packets cross the wire before
an ACK is sent. You will note that the next sequence number
(SEQ=20604306) reflects an additional 1460 bytes. Finally,
look at the ACK. Note that the ACK is indicating, "Hey, I want
to see the **Next** 1460 bytes, hence the number ACK=20611606.
This is considered a positive or expectational acknowledgement.
The almost full headers are here(watch wrap):
http://www.west-
point.org/users/usma1983/40768/chesinc/docs/ttcp.txt
> The 3-way handshake kind of breaks this rule, which is
probably why
> people
> get confused. They never go past the 3-way handshake. With
the 3-way
> handshake, there are no payload bytes. The recipient's ACK
number is
> nonetheless one more than the other side's SEQ number.
What is equally important is that the ISN (Initial sequence
number) should be a truly random value, so as not to allow
hackers to spoof a connection. There are some pretty well
documented cases where this was not done, most recently with
the CBOS on the 600 series routers.
Also, one point of note is the issue of selective
acknowledgements and negative acknowledgements. Originally,
most Internet hosts did not have a TCP/IP stack that
incorporated SACKs. With the advent of Solaris 8 and Win 98,
SACKs were employed in major operating systems. The effect of
the selective acknowledgment (as opposed to the negative
acknowledgement is as follows.
In the instance where you had the transfer I mentioned above,
consider the situation where I received segments 1 and 2,
missed segment 3, then received segments 4, 5, and 6. Would it
not be a little bit more efficient to tell the server that I at
least got segments 1 and 2? That is the point behind SACKs.
In the case of negative acknowlegements, the intent would be to
say to the server, "okay, big guy, it looks like I got
everything except segment number 2. Whaddya say we resend
segment number 2 just to make things complete?" Negative
acknowledgments are not supported, and likely will not be
supported unless the TCP specification is rewritten. Frankly,
a good sliding window and SACKs seems to be sufficient for
optimization.
I **Strongly** agree with Priscilla's endorsement of TCP/IP
Illustrated, by W. Richard Stevens. Unfortunately, it is
copyrighted September, 1994. It will never be updated by the
original author, since he passed away recently. My
understanding is that his wife is trying to find somebody
suitable to make a next edition (which is long overdue). I
hope a suitable person will be found. The Stevens book is a
*must* read if you want to understand TCP/IP.
v/r,
Paul Werner
________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=6960&t=6899
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
