the question is why the second handshake cannot be done
1. The information sent from the client to the server is delayed for a long time in the network. After receiving the message, the server returns a confirmation message, but at this time the connection of the client is nearly closed, but the server still waits all the time, which will cause a waste of server resources
this kind of understanding
2. The information transmitted from the client to the server is delayed for a long time in the network. after receiving the message, the server returns the confirmation message, but the client has abandoned the first connection and sent the request for the second connection. when the client receives the request, it will think that this is the confirmation of the second request, so as to establish the connection.
OK, that"s the problem. When sending a connection request and confirming a connection request, we will send the sequence number and the confirmation number. Assuming that the sequence number of the first request sent by the client is x, then the confirmation number in the packet in which the server returns the confirmation information should be xreply 1, and the sequence number of the second connection request sent by the client will obviously not be x, assuming y. Then when the client receives the confirmation number xroom1 in the confirmation message returned by the server, it should not establish a connection, because he needs to wait for a confirmation number of yroom1.
then this second problem should not exist.
my understanding of tcp is only conceptual, and I have not actually done any research on tcp, so there may be some problems in understanding. I hope you can point out.
I think the possible answer:
1. The client does not confirm the confirmation number, but why?
2. Both requests have the same sequence number (should not be possible, randomly generated)
3. This problem does not exist
/ / 2019.9.16 still not clear about the second case
still not clear