- Posts: 1
- Thank you received: 0
TCP Sequence & Acknowledgment numbers
- stacketpacket
- Topic Author
- Offline
- New Member
Less
More
10 years 8 months ago - 10 years 8 months ago #38525
by stacketpacket
TCP Sequence & Acknowledgment numbers was created by stacketpacket
I have just been reading
this
explanation of TCP sequence & acknowledgment numbers. About half-way down there is this diagram:
Near the end of the page, the explanation of the final step, step 4, includes this text:
I am currently struggling to understand this:
I am seeking general clarification on this.
Near the end of the page, the explanation of the final step, step 4, includes this text:
Note that the sequence number of the segment in line 4 is the same as in line 3 because the ACK does not occupy sequence number space.
So keep in mind that any packets generated, which are simply acknowledgments (in other words, have only the ACK flag set and contain no data) to previously received packets, never increment the sequence number.
I am currently struggling to understand this:
- I can clearly see that the sequence number in the packet sent in step 4 has the same sequence number as the packet sent in step 3.
- It is also clear to see that the acknowledgement number is also the same in these steps
- Basically, the author seems to be saying that the step 4 packet is identical to the step 3 packet, except that the step 4 packet contains data/payload.
With regards to my first two points, is this correct?
With regards to my third point, is this correct?
And finally, assuming the answer to the first two questions is basically 'yes', then is the reason that these numbers are the same in both packets because there hasn't been any intervening packet received from the
I am seeking general clarification on this.
Last edit: 10 years 8 months ago by stacketpacket.
10 years 8 months ago #38527
by Chris
Chris Partsenidis.
Founder & Editor-in-Chief
www.Firewall.cx
Replied by Chris on topic TCP Sequence & Acknowledgment numbers
Hi stacketpacket and welcome to Firewall.cx.
Both of your points are correct. What we need to keep in mind here is that the 3rd packet completes the 3-way handshake and the 4th packet can be considered as an 'extension' to the 3rd packet, which simply requests data from the HTTP server.
Now keep in mind that some implementations of TCP stack might slightly alter the presented theory and we've seen this happen in the past.
While we do provide diagrams and screenshots to help make things as clear as possible, the recommended practice is to download a packet sniffer e.g Wireshark and give it a try to see what you get. It will greatly help you understand a lot of the theory covered here.
Hope I've helped answer your question.
Thanks.
Chris.
Both of your points are correct. What we need to keep in mind here is that the 3rd packet completes the 3-way handshake and the 4th packet can be considered as an 'extension' to the 3rd packet, which simply requests data from the HTTP server.
Now keep in mind that some implementations of TCP stack might slightly alter the presented theory and we've seen this happen in the past.
While we do provide diagrams and screenshots to help make things as clear as possible, the recommended practice is to download a packet sniffer e.g Wireshark and give it a try to see what you get. It will greatly help you understand a lot of the theory covered here.
Hope I've helped answer your question.
Thanks.
Chris.
Chris Partsenidis.
Founder & Editor-in-Chief
www.Firewall.cx
Time to create page: 0.116 seconds