Link : https://www.zhihu.com/question/33578075/answer/56951771
Source: Zhihu The
copyright belongs to the author, please contact the author for authorization.
When you read these explanations and feel like reading a book from heaven, you probably don't bother to ask any more. But it's fine. This article is to help you understand node.js while avoiding high-end jargon.
The process by which a browser sends a request to a website has not changed much. When a browser makes a request to a website. The server receives the request and starts searching for the requested resource. If necessary, the server will also query the database, and finally send the response back to the browser. However, in traditional web servers (such as Apache), each request causes the server to create a new process to handle the request.
Then there was Ajax. With Ajax, instead of requesting a complete new page each time, we can request only the part of the page information we need each time. This is clearly an improvement. But for example, if you want to build a social networking site like FriendFeed (similar to a website that refreshes friends' news like Renren), your friends will push new status at any time, and then your news will be automatically refreshed in real time. To achieve this requirement, we need to allow the user to maintain an active connection to the server all the time. The easiest way to implement this is to keep long polling between the user and the server.
HTTP requests are not persistent connections, you request once, the server responds once, and you're done. Long rotation is a technique that uses HTTP to simulate persistent connections. Specifically, as soon as the page loads, you send an Ajax request to the server whether or not you need a response from the server. This request is different from the general Ajax request, the server will not return information directly to you, but it has to wait until the server thinks it is time to send you information, it will respond. For example, if your friend posts a news item, the server will send this news item as a response to your browser, and then your browser will refresh the page. After the browser receives the response and refreshes, it sends a new request to the server, but the request will not be responded immediately. So start repeating the above steps. Using this method, you can keep the browser always waiting for a response. Although the above process still only involves non-persistent Http, we simulate a seemingly continuous connection state
Let's look at traditional servers (such as Apache). Every time a new user connects to your website, your server has to open a connection. Each connection needs to occupy a process, and these processes are idle most of the time (for example, waiting for your friend to post something new, and waiting for your friend to send a response message to the user. Or waiting for the database to return query results or something). Although these processes are idle, they still occupy memory. This means that if the number of user connections grows to a certain scale, your server will probably run out of memory and be paralyzed.
How to solve this situation? The solution is just said above: non-blocking and event-driven . These concepts are actually not that difficult to understand in the scenario we are talking about. You think of a non-blocking server as a loop that runs forever. When a new request comes, the loop accepts the request, passes the request to other processes (such as a process that does database queries), and then responds with a callback. When it's done, the loop will continue to run and receive other requests. This way down. The server will not be as stupid as before waiting for the database to return the result.
If the database returns the result, the loop sends the result back to the user's browser and continues to run. In this way, your server's processes don't sit idle. Therefore, in theory, there is no limit to the number of database queries and user requests at the same time. The server only responds when an event occurs on the user's side, which is event-driven.
FriendFeed uses the Python -based non-blocking framework Tornado (Zhihu also uses this framework) to implement the above-mentioned new things function. However, Node.js is better than the former. Node.js applications are developed through javascript and then run directly on Google's perverted V8 engine. With Node.js, you don't have to worry that the client's request will run a block of code in the server. Because javascript itself is an event-driven scripting language. If you recall, when writing javascript for the front end, you are mostly dealing with event handling and callback functions. JavaScript itself is a language tailored for event handling.
Node.js is still in its infancy. If you want to develop a Node.js based application, you should write some very low-level code. But the next generation of browsers will soon adopt WebSocket technology, so long polling will disappear. In web development, technologies like Node.js are only going to become more and more important.