Nginx source code analysis (2)-Overview

Source code analysis is a step-by-step process, starting with a rough understanding of the process, a variety of understanding is not too profound, but these real feelings are also recorded, I think it is quite interesting, some understandings may be one-sided or incorrect, but you can continue to correct errors and deepen understanding through a more in-depth and meticulous analysis process. Source code analysis is a process in which experience is gradually accumulated. We hope that words can accurately record this accumulation feeling.

Now let's take a look at the first impression of nginx source code.

After extracting the source code package, the root directory contains several subdirectories and several files. The most important subdirectories are auto and SRC. The most important file is the configure script, which is different from the vast majority of open source code, the configure script of nginx is manually written by the author and is not automatically generated using tools such as Autoconf. The configure script will reference the script file under the auto directory to work. Scripts in the auto directory perform their respective duties based on their purposes, including checking the compiler version, operating system version, standard library version, and module dependency, for installation, initialization, and multi-thread check. As a general driver, configure calls these scripts to generate the version information header file, the declared code of the contained modules by default, and the MAKEFILE file. The version information header file (ngx_auto_config.h, ngx_auto_headers.h) and the declared code (ngx_modules.c) of the default contained module are placed in the newly created objs directory. It should be noted that these generated files are as important as the source code below SRC, and it is an important part to understand the source code.

SRC is the directory where the source code is stored. The objs/src directory created by configure is used to store the generated. o file. Note the difference.

SRC is divided into several parts based on functional features, which correspond to several different subdirectories.

Src/Core stores the main part, basic data structure, and infrastructure source code. The main function is in src/CORE/nginx. C, which is a good starting point for source code analysis.

Src/event stores the source code of the event-driven model and related modules.

Src/HTTP stores the source code of the HTTP server and related modules.

Src/mail stores the source code of the email proxy and related modules.

Src/MISC stores the C ++ compatibility test and the source code of the Google perftools module.

Src/OS stores the source code that relies on the operating system. The most important master and workers creation code During nginx startup is in this directory, which is somewhat surprising.

Nginx has many structs, which are generally named ngx_xxx_t. These structs are scattered in many header files, and almost all header files are collected in src/CORE/ngx_core.h, all the implementation files will contain the ngx_core.h header file, which means that the source code of each part of nginx is tightly coupled. However, in fact, each part of nginx is logically clearly divided, it is a loose structure. Nginx implements some sophisticated basic data structures, such as ngx_string_t, ngx_list_t, ngx_array_t, break, ngx_buf_t, ngx_queue_t, ngx_rbtree_t, and break, as well as some important infrastructure such as log, configure file, time, etc. These data structures and infrastructure are frequently used in many places, which makes people feel that nginx is logically closely linked, but when you are familiar with the implementation code of these basic data structures, you will feel that these data structures are clear and clear, and they are not truly coupled, but there are a few more, however, the "home brewing" code in nginx is also a very obvious highlight.

Nginx is highly modular. You can customize modules based on your own needs, or develop required modules based on certain standards. The modules that have been customized will be declared in objs/ngx_modules.c, this file is generated by configure.

During nginx startup, a very important step is to load and initialize the module, which is completed in ngx_init_cycle. ngx_init_cycle calls the module's hook interface (init_module) to initialize the module, ngx_init_cycle will also call handler to initialize the socket. If it is started in multi-process mode, ngx_master_process_cycle will be called to complete the final startup action. ngx_master_process_cycle will call ngx_start_worker_processes to generate multiple, ngx_start_worker_processes calls ngx_worker_process_cycle to create work content. If the process has multiple sub-threads, the initialization thread and creation thread work content will also be initialized. After the initialization is complete, ngx_worker_process_cycle will enter the processing cycle and call Ss_events_and_timers: This function calls ngx_process_events to listen for events and ships the events to the event queue ngx_posted_events. The events are processed in ngx_event_thread_process_posted.

The event mechanism is a key part of nginx. epool is used in Linux and kqueue is used in FreeBSD to manage events.

The following is a big picture of the source code provided by Joshua. Thank you :)