Imagine why you didn't let multiple processes/threads listen on the same IP address and port, which is simple, because the TCP/IP model uses a port as a unique identifier for a four-layer multiplexed reuse, which is a four-tier address, just as the IP address belongs to a host (a NIC?). ), a ip/port pair belongs to a specific process on a host, and it is only a static identity that guarantees uniqueness. The world's different hosts can not have the same IP address, a host binding a specific IP address of the different processes can not have the same port, or you do not know what a stream should be handed to which process!
Imagine why Reuseport can make it possible for things that were impossible before. Very simple, in addition to static factors added a dynamic factor, that is, the source IP and source port to initiate the connection is also taken into account, the four-tuple to do a simple hash calculation, the results of the listener number of models, to obtain which listener to serve this connection.
In fact, we find that it is not a listener that needs to be uniquely identified, but rather a connection itself. The TCP server is meaningful when there is a client attempting to establish a connection. So what makes a socket bound to the same ip/port can only be listen once such a limitation existed for so long? I think the answer has two aspects, on the one hand because of the UNIX process model, on the other hand, this limitation in the single-core CPU is good enough to avoid many problems.
OK, now I will listener and process completely separated, I do not agree with binding the same IP address/port socket can only listen once, and do not agree with the Reuseport scheme, I temporarily ignore which process/thread is listening, assuming there is no process/thread listening concept, I only ask for a connection request, you can successfully complete three handshake, create a customer socket, and this is very simple, the newly created customer socket is put into a pool, the listen task is completed, before the handshake is completed, and any process/thread is not associated, then the process/ Threads take into account that they come to accept, that is, to get a client socket from a pool to handle. In fact, I was separated listen and accept, the kernel stack is only responsible for listen, and the process/thread is only responsible for accept, the problem is solved.
When things get tangled together, it introduces a lot of complexity, and the way to avoid these complexities is to peel away things that are intertwined. Colleague for me this optimization took a very good name, called Xsocket, here X can be understood as two meaning, one is "Ox x" in the X, one is "plug"!!
Today feel particularly tired, but very happy, last night to have a dream, feel today will be pleasantly surprised, but wait for a day or not, I no longer believe fate, but eventually I still change the idea, fate did not do, God let my surprise came from elsewhere, although it is not my dream of that. Ah, amen ...
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
The idea behind Linux TCP implementation optimizations
