The introduction

After switching from T to A, my programming language also changed from C++ to Java. T is more server-side development, while A is more business development. Last week, I shared “Server-side High-performance Network Programming” in the group of Company A, and I was surprised that none of the ten people in the group had done development directly based on TCP/IP protocol, and most of them were business development in the Web background. Even Netty, Java’s most powerful network library, has only one user. But it’s not hard to understand — Company A’s middleware platform isolates the business from the bottom layer, allowing programmers to focus on business development.

Which is better? I can’t generalize. I still remember that I was interviewed by N company before I moved to A company. The interviewer asked me about HTTP protocol, RPC framework and other knowledge, but I also had little knowledge. What HTTP protocol, what RPC, we directly TCP/IP. In fact, this is also a manifestation of the insufficient infrastructure of T Company, which was discussed in my other article “My experience in Tencent and Ali”. Those who are interested can move on.

As a Java Web programmer, have you ever wondered how Web servers (Nginx, Tomcat, Jetty, etc.) accept your HTTP requests? Did you know that HTTP is also a text protocol based on TCP/IP? The reason for writing this article is that Java Web programmers have a simple understanding of how some of the server side works and don’t have to ask questions during an interview.

Some of the concepts

Blocking, non-blocking, synchronous, and asynchronous are the four most common words we see when writing server-side networking programs. Their explanations are as follows:

  • Block: A blocked call means that the current thread is suspended until the call returns and only returns when the call returns.
  • Non-blocking: As opposed to blocking, a non-blocking call means that the function does not block the current thread, but returns immediately, until the result is not immediately available.
  • Synchronization: When a function call is made, it does not return until the result is received. Wait until the previous one is done before you can do the next one.
  • Asynchrony: Asynchrony is the opposite of synchronization. When an asynchronous procedure call is made, the caller does not get the result immediately. The part that actually handles the call notifies the caller through status, notifications, and callbacks after completion.

It is common for people to confuse blocking/non-blocking with synchronous/asynchronous. Blocking/non-blocking is more used to describe the attributes of a call (such as whether read() or write() is blocking/non-blocking), so its application scope is narrow; Synchronous/asynchronous is more advanced and usually refers to the relationship between functions/threads (such as whether Thread1 and Thread2 execute synchronously or asynchronously).

Five IO models

Server-side IO is mainly divided into two types: disk IO and network IO. When we talk about server-side high-performance network programming, we talk more about the network IO model. A complete server-side network request processing flow chart is as follows (simplified version, Web server as an example) :

This diagram is relatively simple, but many people will assume that every network read (recvfrom()) or write (sendto()) is between the network card and the user process until they see it, but it is not. As you can see from the figure above, data needs to go through the kernel both from nic to user space and from user space to nic. The same is true for reading and writing data from disk. So there is mMAP technology, interested in their own baidu. Application processes (The Web server is also an application process, so we need to unify the following concepts: User processes, applications, and Web server programs are all application processes relative to the kernel, so they will be called application processes in later articles) and need to read and write data to the kernel through system calls (such as recvfrom/ Sendto), which in turn manipulate the network card.

According to the blocking and non-blocking of application process system call mode, and the difference of synchronous and asynchronous processing mode of operating system when processing application program request, according to UNIX Network Programming Volume I, there are five IO models:

1. Blocking IO model

Advantages: simple programming, suitable for teaching. Many examples in UNIX Network Programming Volume I are based on this pattern. Disadvantages: If there is no data on the socket, the process will always block. Data on other sockets cannot be processed in time. With multithreading, threads exist until connections are closed, and thread creation, maintenance, and destruction are very resource-intensive, so the number of connections that can be made is limited.

2. Nonblocking IO model

Advantages: The code is relatively simple, the process does not block, and all connections can be handled in the same thread.

Disadvantages: Frequent polling, CPU intensive, and spending a lot of time polling on connections without any data when there is a lot of concurrency. So this model only appears in systems that are dedicated to providing a function.

IO multiplexing multiplexing

Advantages: Unified management of connections, not necessarily multi-threaded, and no polling. Just block on SELECT and manage multiple connections at the same time.

Disadvantages: When the number of connections managed by SELECT /poll/epoll is too small, this model will degenerate into a blocking IO model. There is also one more system call: a SELECT /poll/epoll recvFROM.

4. Signal-driven IO

Advantages: Non-blocking

Disadvantages: if the previous notification signal was not processed, the subsequent signal can not be processed. Therefore, when the signal volume is large, it will lead to the following signal can not be timely sensed.

5, Asynchronous IO model

Note: The first four models all have blocking parts, either waiting for data to be ready or copying data from kernel space to user space. In this model, the application process calls AIO_read until the data is copied to user space without any blocking, so this model is called asynchronous IO model. I reserve my opinion on the naming and juxtaposition of these five models, which I feel is easy to confuse readers.

Advantages: No blocking, full use of the system kernel IO operations and computing logic in parallel.

Disadvantages: Complex programming and poor operating system support. Currently, only iocP for Windows implements true AIO. Linux was introduced in version 2.6 and is not perfect at present, so Linux generally adopts the multiplexing model.

Comparison of IO models

The first four models differ primarily from the first stage because the second stage is the same: the process blocks the recvFROM call during the copying of data from the kernel into the buffer of the application process. In contrast, the asynchronous IO model differs from the other four models by having to deal with both phases.

conclusion

Although the JDK’s network programming classes and interfaces are not directly dependent on the operating system like C++, its IO model is dependent on the above five models. After all, this is a model, independent of language or operating system. IO models are just a basic part of high performance network programming. A good IO model is not enough. We also need a good architecture (threading model). The threading model is a core part of high-performance network programming and should be examined in a later article. Remember to pay attention to the public account oh, recording a C++ programmer to Java learning road.