Shulou(Shulou.com)06/01 Report--

When writing a TCP program, for the server, when accept returns successfully, does it necessarily mean that a client has successfully established a TCP connection? For the client, does the successful return of connect necessarily mean that you have successfully connected to the server? Far from it!

The two socket calls to accept/connect are based entirely on the TCP three-way handshake state machine, that is, as long as the local TCP state machine enters the ESTABLISH state, it will be returned successfully. We know that TCP's three-way handshake is itself the result of a trade-off. Why not shake hands four times? Why not five times? ... You can keep asking questions like this.

In fact, the client can leave without saying goodbye after receiving the syn-ack and sending the last ack, or the server can leave without saying goodbye after receiving the syn and sending the syn-ack, and never ask about the world again. For the peer, the accept/connect will obviously return successfully, because the state machine of the peer has been switched to ESTABLISH, and they do not realize that they have been tricked. For TCP, as a connection-based end-to-end agreement, it is very similar to our job. When you enter a job, you have to sign a contract, when you leave, you have to leave. For those who leave without saying goodbye, most of what you can do is ridicule. But for TCP, the above-mentioned "new connections per second" means can be used to improve their "new connections per second" to deceive relatively low-level testing tools, or to ridicule candidates who do not know why (as an effective touchstone, sometimes they really have to ask those candidates some of these questions, they are better than asking candidates to write a handshake process and a socket program. It is much more efficient to explain the parameters of the socket function.

For the above leaving without saying goodbye, it is easier to deceive the client than to deceive the server, because for the server, there is a socket option called TCP_DEFER_ACCEPT, which suppresses the return of accept before receiving the first data from the client. Of course, it is only valid for the application layer protocol (such as HTTP protocol) in which the client sends the first data first.

If I were to examine candidates' understanding of TCP programming, I would ask them to write or understand a full spoofing program that converts TCP's connection ack mechanism into a challenge / response mode:

Cheat client: write a spoofing server that continues to execute and only executes the following logic: 1. As soon as the syn is received, an initial sequence number is calculated, and the syn-ack;2 is constructed and replied. As long as the data is received, a pure ack packet response is constructed based on the TCP header information of the data. 3. As soon as you receive a fin, you will ack it and send a fin;4. Never initiate any data on your own initiative.

Deceiving the server: this is not difficult.

As for how to get TCP data instead of getting it into the protocol stack, this is important in implementation to examine the candidate's familiarity with the system. Why can't you enter the protocol stack? Because entering the protocol stack will enter the standard and correct processing flow, which will generally be RST... So how do you get the data? There are too many ways, including but not limited to: 1. Use PACKET sockets; 2. Use PF_RING;3. Use TUN/TAP network card; 4. Use Netfilter queue mechanism; 5. Directly change the kernel.

Does all of the above work really make sense? Generally speaking, it doesn't make any sense, even if you make your server achieve extremely high concurrency in this way, once discovered, it's probably not just a technical problem. In fact, the significance of doing the above is that at this point you will understand what "a TCP connection" is. To be exact, a TCP connection consists of two error-free state machines, not just one. A TCP connection has nothing to do with the network conceptually as an "end-to-end protocol." for the above behavior, there is obviously no maintenance of an error-free state machine at the end of the goodbye or challenge response. So it is not a complete TCP connection, and performance tests based on TCP connections, such as the number of new TCP connections, must be able to detect this. So, this test must include the transmission of challenge / response data in the business area, that is, to reiterate: just because you can telnet a port in an IP does not mean that a service is open for you. In other words, as long as you can get the packet, how to deal with it is your own business. If you look like a normal protocol stack to the opposite end, you can deceive them. The two sides of the two places as a whole lack a collective introspection mechanism.

The lack of introspection mechanism is inevitable, because once there is an introspection mechanism, then the network will really become an intelligent creature. The computer has the ability to deal with arbitrarily complex data, but unfortunately, it does not know that it has this ability. It is interesting to think about this question in depth. I know my surname is Zhao, but do I know that my surname is Zhao? "I am most afraid of dark" and "I admit that I am most afraid of dark" are completely different.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.