When writing a TCP program, for the service side, accept successfully return, it must mean that a client has successfully established a TCP connection? For clients, does the successful return of connect necessarily mean that they have successfully connected to the server? It's far from it!
Accept/connect These two socket calls are completely based on the TCP three-time handshake state machine, that is, as long as the local TCP state machine enters the establish state, it will return successfully. And we know that the three handshake of TCP itself is the result of a trade-off. Why not shake it four times? Why not five times? ... Questions can always be asked.
In fact, the client can completely after receiving Syn-ack, send the last Ack after the leave, the server can also be received after the SYN, send Syn-ack, and never ask the world, for the end, Accept/connect obviously will successfully return, Because the on-end state machine has been converted to establish, they are unaware that they have been tricked. For TCP, it acts as a connection-based end-to-end protocol, and our work is very similar, when entering the job, to sign a contract, leaving the time, to handle the separation process, for those who leave, you can do most can only be ridiculed. However, for TCP, you can use the above-mentioned leave to improve their "new connections per second" to deceive the relatively low-level testing tools, or ridicule those who know the reason why the candidate (as an effective touchstone, sometimes really ask the candidates some of these questions, They are better than letting the candidate write a handshake, write a socket program, explain the parameters of the socket function to be more effective).
For the above, it is easier to spoof the client than to spoof the server, because for the server, there is a socket option called tcp_defer_accept, which suppresses the return of the ACCEPT before it receives the first data from the client, of course, It is only valid for application-layer protocols (such as HTTP protocol) that the client first sends the first data.
If I was looking at the candidate's understanding of TCP programming, I would ask them to write one or understand a whole-of-a-kind deception program and convert the TCP connection ACK mechanism into challenge/Response mode:
Spoof client: Write a spoofed server, Execute and execute only the following logic: 1. Whenever a SYN is received, an initial sequence number is computed, and the syn-ack;2 is constructed and replied to. As long as the data received, the TCP header information based on this data is constructed to respond to the pure ACK packet; 3. If you receive fin, you will get the ACK out and then send a fin;4. from any data.
Spoofing Service side: This is not difficult ...
As for how to get the TCP data instead of getting it into the protocol stack, this is important in implementation and can be used to examine how familiar the candidate is with the system. Why can't we get into the protocol stack? Because entering the protocol stack will enter the standard of the correct processing process, will generally be rst ... So how do we get the data? There are too many options, including but not limited to: 1. Use packet sockets; 2. Use pf_ring;3. Use the Tun/tap card, 4. Use the NetFilter queue mechanism; 5. Directly change the kernel ...
Do the above work really make sense? In general, there is no point, and even if you make your server extremely high concurrency in this way, once discovered, it is not just a matter of technical scope. In fact, the significance of doing the above is that you will now understand what is "a TCP connection", specifically, a TCP connection consists of two unmistakable state machines, and not just one, a TCP connection conceptually and the network does not have any relationship, is considered "end-to-end protocol", for the above behavior, Obviously there is no error maintaining an unmistakable state machine at the end of a no-go or challenge answer, so it is not a complete, error-free TCP connection, such as a new TCP connection-based performance test, such as a newly created number of connections. So, this test must include the transmission of the challenge/response data in the business category, that is, once again: you can telnet to a certain port of an IP, and that does not mean there must be a service open for you. In other words, as long as you can get the packet, how to deal with it is their own business, if you look like a normal stack in the end, you can deceive them, in the two sides of the two end as a whole lack of a collective introspection mechanism ...
Lack of self-examination mechanism is inevitable, because once the self-reflection mechanism, then the network really become intelligent organisms ... The computer has the ability to handle any complex data, and unfortunately, it does not know that it has this ability. Thinking deeply about this question is interesting, I know my surname Zhao, but I know "I I know my surname Zhao" this matter? "I am most afraid of the dark" and "I confess that I am most afraid of the dark" is completely different.
TCP socket Accept/connect successfully returned but left without saying goodbye
