Network IO
Foreword:
As a server-side development, in order to improve the overall service efficiency, network programming is our indispensable knowledge. This article will start from the process of receiving data from the network card, string up knowledge of cpu interrupts, operating systems, thread scheduling, etc., and further analyze the evolution process from select to epoll.
1. The network card receives data
Below is a typical computer structure diagram. The computer is composed of CPU, memory (memory) and network interface. In order to understand network IO, we must first look at how the computer receives network data from a hardware perspective.
The following figure shows the process of receiving data by the network card:
- In the ① stage, the network card receives the data from the network cable;
- After the transmission of the hardware circuit of stage ②;
- In the final stage ③, the data is written to an address in the memory.
This process involves DMA transmission, IO channel selection and other hardware-related knowledge, but we only need to know: the network card will write the received data into the memory .
Through hardware transmission, the data received by the network card is stored in the memory, and the operating system can read them.
2. If you know that you have received the data?
After the data received by the network card is put into the memory, how does the Sokcet created in the operating system perceive that there is data sent? To understand this problem, you need to understand a concept-interrupt.
When the computer executes the program, there will be priority requirements. For example, when the computer receives a power-off signal, it should immediately save the data. The program that saves the data has a higher priority (the capacitor can save a small amount of power for the CPU to run for a short period of time).
Generally speaking, the signal generated by the hardware requires the CPU to respond immediately, otherwise the data may be lost, so its priority is very high. The CPU should interrupt the program being executed to respond; when the CPU completes the response to the hardware, it re-executes the user program. The interruption process is as shown in the figure below. It is similar to a function call, except that the function call is at a predetermined location, and the interrupt location is determined by the "signal".
Take the network card as an example: when the network card writes data into the memory, the network card sends an interrupt signal to the CPU, and the operating system can learn that new data is coming, and then process the data through the network card interrupt program. Network card interrupt program: According to the specified IP and port, write the received data into the input buffer of the corresponding socket. (Socket: the four-tuple ID is unique)
3. BIO model
In order to support multitasking, the operating system implements the function of process scheduling and divides the process into several states such as "running" and "waiting". The running state can get the CPU execution right and participate in the CPU time slicing; the waiting state is the blocking state, the process enters the waiting queue, and will not get the CPU execution right, and enters the running state when awakened. The operating system executes processes in each running state in a time-sharing manner. Because of its fast speed, it looks like it is executing multiple tasks at the same time.
The accept and recv methods of the BIO model enter the waiting state if there is no data.
The computer in the figure below is running three processes, A, B, and C. Process A executes the basic network program of the BIO model. At the beginning, these three processes are all referenced by the operating system's work queue and are in a running state. Time-sharing execution.
3.1 Create Socket
When process A executes the statement to create Socket, the operating system will create a Socket object managed by the file system (as shown in the figure below). This socket object contains member variables such as sending buffer, receiving buffer, and waiting queue. The wait queue variable is very important, it points to all processes that need to wait for the socket event.
3.2 recv blocking
When the program executes to accept and recv, if there is no data in the receiving buffer, park will be called to suspend thread A and join the waiting queue. Since there are only processes B and C left in the work queue, according to process scheduling, the CPU will execute the programs of these two processes in turn, and will not execute the programs of process A. Therefore, process A is blocked, does not execute code down, and does not occupy CPU resources.
When there is data in the socket receiving buffer area, unpark will be called to wake up process A. The process changes from the waiting state to the running state, continues to execute the code of process A, and reads the data in the receive buffer area.
3.3 Wake up the process
In this step, through the knowledge of network card, interrupt and process scheduling, it describes the whole process of the kernel receiving data under the blocking recv.
As shown in the following figure: during the recv blocking period, the computer receives the data transmitted by the opposite end (step 1), the data is transmitted to the memory via the network card (step 2), and then the network card informs the CPU that the data is large through the interrupt signal, and the CPU executes the network card Interrupt the program (step 3).
Network card interrupt program:
- First write the network data into the receiving buffer of the corresponding socket (step 5)
- Call unpark to wake up process A, and process A re-enters the work queue
After writing data and waking up the thread:
The above is the BIO model, the whole process of the kernel receiving data, here we may think about a question:
-
How does the operating system know which socket the network data corresponds to?
Answer: socket: socket is a four-tuple of (IP + port: IP + port), and the network data packet contains IP and port information, the kernel can find the corresponding socket through the port number
4. NIO model
The biggest difference between the NIO model and the BIO model implemented by the operating system is that the accpet and recv methods are not blocking. Even if the process is executing the recv method of the NIO model, it will continue to execute the code even if it does not obtain data.
When the network card receives data, the flowchart is as follows:
When the application layer implements BIO network programming, a user thread usually corresponds to a socket. The thread model of the current mainstream commercial Java virtual machine is implemented based on the native thread model of the operating system, that is, the thread model of 1:1 is adopted, and the number of threads has been set. More, it will cause frequent context switching and waste performance, so the BIO model is not suitable for scenarios with a large number of network connections.
As for the NIO network model, one user thread can manage multiple sockets, but the user thread does not know which socket has data coming in. The user program has to traverse all sockets to read data. When reading data, it will switch from user mode to kernel mode ( System call), call the kernel recv method to read data.
5. Multiplexing select
NIO user threads are not good at managing multiple sockets uniformly, and the operating system provides a multiplexer to manage multiple sockets.
Let's start with the less efficient select, and finally analyze the efficient epoll.
// ALL