4 ms·

Thanks for the link with the correct explanation: Particularly, the two-way handshake presents potential problems when the ACK message from the server delays t

by f1shy 2y ago

Thanks for the link with the correct explanation: Particularly, the two-way handshake presents potential problems when the ACK message from the server delays too much. Thus, if a connection timeout occurs, the client sends another SYN message with a new sequence number (Z, for example) to the server. However, if the server previously sent an ACK (which is delayed), it’ll discard this new SYN message. The client, in turn, receives the delayed ACK and assumes that it refers to the last sent SYN message. Here’s where the error happens: the client will send messages with the sequence number Z, while the server expects messages following the sequence number X.

deleted 2y ago
[deleted]
zokier 2y ago
That is possibly even more wrong explanation. Hosts do not blindly assume what is getting acknowledged by ACKs
dcuthbertson 2y ago
Thanks for explaining the why. I'm glad it falls somewhere between the X and the Z.
tsimionescu 2y ago
This is a bogus explanation, one that has nothing to do with TCP. In TCP every segment has a SEQ number and an ACK number, regardless of it being a handshake segment or a data segment. This completely negates the described problem: the server's first response to a SYN includes "SEQ=Y, ACK=X". If the client which just sent "SYN seq=Z" receives the ACK for SEQ=X, it will drop this ACK and wait for a new one. Also, a server which receives a new SYN has no reason to drop it, it will send a new ACK instead.