Hosted by |wbenton.tripod.com/
This forum was created June 21, 2000 and discusses all kinds of things related to network and security. Some of the things discussed are recent [Computer Security Alerts]; various [General] news about security related things; various news about recently [Publicized Hacks/Theft]; various things about [SPAM] including problems and recent legislation/news to try and reduce SPAM; and then just various odds & ends including some of the [Security Basics] which most people should know or at least strive to learn to be able to protect themselves from the evil lurking on the internet.
So now, let's break down each parameter of the [SYN] packet into separate posts.
Starting with the sequence number parameter [Seq=0]. This is one of the simpler ones to explain.
Note: It's usually a client whom initiates a session with a server.
The client creates a random sequence number  in the example below and increments that number by 1 for every byte sent. WireShark, for the sense of easy human recognition re-assigns that long and hard to remember (for humans) number of 43956742 to a relative sequence number of  the one in parenthesis below.
The server also creates it's own random sequence number  in the example below and increments that number by 1 for every byte sent. WireShark, for the sense of easy human recognition re-assigns that long and hard to remember (for humans) number of 9369305 to a relative sequence number of  the one in parenthesis below.
So now you have two sets of sequence numbers... one for bytes sent from the client and one for bytes sent from the server.
The client's request is usually short, simple and sweet (or small). Sort of like give me this picture or give me that page or give me some other thing.
The server's response however is usually much larger than the request. Depending upon what was requested, it could be a 6KByte .GIF file, it could be a 17KByte HTML page, it could be a 4MByte .PDF file, it could be a 25Mbyte FTP file... or it could be a 700MByte or larger videoclip.
Therefore, the server's response counter will usually increase much more rapidly than the clients request counter.
But regardless, that counters are used to confirm whether a byte went missing or not.
So the server sees that it received relative sequence numbers 1, 2, 3, 4, 5 and 7. That means that 6 is missing. The client says it received relative sequence numbers 1 ~ 7280 and 7283 ~ 137495. That means 7281 and 7282 are missing.
When either side discovers a missing sequence number or two or more... they ask for those sequences to be re-transmitted again. But re-transmissions are discussed later.
Just remember that the sequence numbers sent on both sides is different and both are used to keep track of the packets received by the receiving party.