TCP socket accept/connect returns a successful result, but the peer end does not leave, and the accept does not leave.

TCP socket accept/connect returns a successful result, but the peer end does not leave, and the accept does not leave.
When writing a TCP program, when accept returns a successful result to the server, does it mean that a client has successfully established a TCP connection? For the client, will the successful return of connect necessarily mean that you have successfully connected to the server? Far from me!
The two socket calls of accept/connect are completely based on the TCP three-way handshake state machine, that is, as long as the local TCP state machine enters the ESTABLISH state, it will return a success. We know that TCP's three-way handshake is a trade-off result. Why not four handshakes? Why not ?... You can keep asking this question.
In fact, the client can send the last ack after receiving the syn-ack, and the server can also quit after the syn is received and send the syn-ack, for the peer, accept/connect will obviously return a successful result, because the peer state machine has been converted to ESTABLISH, and they cannot realize that they are being played. TCP serves as a connection-based end-to-end protocol, which is similar to our work. When we start a job, we need to sign a contract. When we leave the job, we have to go through the exit procedures, most of what you can do is ridicule. However, for TCP, you can use this alternative method to increase your "Number of new connections per second" to cheat relatively low-level test tools, or make a joke about the candidates who do not know where they are. (as an effective touchstone, they sometimes really want to ask these candidates some questions. They are better than asking them to write a handshake, write a socket program to explain how many parameters of the socket function should be valid ).
It is easier to spoof the client than to spoof the server, because there is a socket option for the server, called TCP_DEFER_ACCEPT. before receiving the first data from the client, it only applies to the application layer protocol (such as HTTP) that the client sends the first data.
If I was investigating the applications' understanding of TCP programming, I would ask them to write or understand a full-process spoofing program and convert the TCP connection ack mechanism into a challenge/response mode:
Spoof client: Write a spoof server that continuously executes and only executes the following logic: 1. as long as the syn is received, an initial serial number is calculated to construct and reply to syn-ack; 2. once the data is received, a pure ack packet response is constructed based on the TCP Header of the data. 3. as long as you receive the fin, You Can ack it and then send a fin; 4. never initiate any data.
Spoof server: This is not hard...
As for how to obtain TCP data rather than putting it into the protocol stack, this is important in implementation and can be used to measure the degree of familiarity with the system. Why cannot I access the protocol stack? As the protocol stack enters the standard and correct processing process, the data is usually obtained by RST... how can this problem be solved? There are too many methods, including but not limited to: 1. use PACKET socket; 2. use PF_RING; 3. use the TUN/TAP Nic; 4. use the Netfilter queue mechanism; 5. directly change the kernel...
Are those jobs really meaningful? Generally speaking, it doesn't make any sense. Even if you use this method to bring your server into ultra-high concurrency, once discovered, it is estimated that it is not just a technical issue. In fact, the purpose of doing this is to understand what a TCP connection is. Specifically, a TCP connection includes two error-free state machines, not just one, a TCP connection has nothing to do with the network in terms of concept. It is an "end-to-end protocol". For the above behavior, it is clear that no error state machine is maintained at the end of leaving or challenging the response, therefore, it is not a complete and correct TCP connection. performance tests based on TCP connections, such as new TCP connections, must be able to detect this situation. Therefore, this test must include the challenges of business/the transmission of response data, that is, reiterate that you can telnet to a port of an IP address, it does not mean that a service must be enabled for you. In other words, as long as you can get data packets, how to handle them is your own business. If you look like a normal protocol stack to the peer end, you can cheat them, the two ends in two locations lack a collective introspection mechanism as a whole...
The lack of introspection mechanisms is inevitable, because once there is an introspection mechanism, the network will actually become a smart creature... A computer can process any complex data. Unfortunately, it does not know it. It is interesting to think deeply about this problem. I know my name is Zhao, but I know that I know "I know my name is Zhao? "I am most afraid of dark" and "I admit that I am most afraid of dark" are completely different.