HTTP Server
Back to our previous "Hello World" example, it only takes a few lines of code.
Because Node.js has encapsulated many details in the source code, the main code is in the files lib/http*.js. Now let's follow the above code and see what Node.js has done for us at the source code level from the arrival of an HTTP request to the response.
Server
In Node.js, to receive an HTTP request, you first need to create an instance of the http.Server class and then listen for its request event. Since the HTTP protocol belongs to the application layer, the lower transport layer usually uses the TCP protocol, so the net.Server class is the parent class of the http.Server class.
The requestListener
callback function acts as an observer and listens for the request
event, with a default timeout of 2 minutes.
When the connection is established, the observer connectionListener
handles the connection
event.
At this point, an HTTP parser is needed to parse the data transmitted through TCP:
HTTP Parser
It is worth mentioning that the parser is obtained from a "pool", which uses a data structure called freelist. In order to reuse the parser as much as possible and avoid the cost of constantly calling the constructor, and there is a limit on the number (1000 in the http module).
The implementation of HTTPParser is currently implemented by C++ binding. For details, see the deps/http_parser directory. But here I will expand a bit:
There has been a debate in the community about the performance of the http_parser implementation, and the JS implementation of performance surpasses the C implementation.
The reasons are many:
Removed the C++ binding layer.
JS implementation avoids switching between C stack and JS stack and parameter copying.
V8 JIT optimizes hot functions.
Even with these advantages, the community has not yet merged and is in a pending state. Combining personal and community views:
Concurrent requests will cause frequent garbage collection and trigger GC pauses.
Can exist as a third-party module.
pull request: https://github.com/nodejs/node/pull/1457/
The parser here is also event-based, which is in line with Node.js's core ideas.
So a complete HTTP request from receiving to complete parsing will go through the event listeners on the parser one by one:
parserOnHeaders: Continuously parse the incoming request header data.
parserOnHeadersComplete: The request header is parsed, the header object is constructed, and the http.IncomingMessage instance is created for the request body.
parserOnBody: Continuously parse the incoming request body data.
parserOnExecute: After the request body is parsed, check whether the parsing reports an error. If an error is reported, the clientError event is triggered directly. If the request is a CONNECT method or has an Upgrade header, the connect or upgrade event is triggered directly.
parserOnIncoming: Handle the specific parsed request.
Where is the request
event triggered? Let's go back to the source code.
We notice two queues, incoming
and outgoing
, which are used to buffer IncomingMessage instances and their corresponding ServerResponse instances. By constructing the corresponding ServerResponse
instance through the IncomingMessage
instance, and binding the triple <req, res, socket>
through res.assignSocket(socket);
.
Finally, the request
event is sent with req
and res
as parameters. In the "Hello World" example, the listener receives req
and res
, writes the HTTP header and content to the response stream, and sends it out.
Summary
Object pools are a derivative of memory pools and require a trade-off between memory and performance.
The above only outlines a main line, and other aspects such as exception handling and security will be analyzed in subsequent chapters.
Reference
https://docs.google.com/document/d/1A3cxhZg2aktJeSGt0P-8KrA4WyG1c8LlPomQflaQs8s/edit
Last updated