Httpd Concepts: Difference between revisions
No edit summary |
|||
(76 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
=Internal= | =Internal= | ||
* [[httpd# | * [[httpd#Subjects|httpd]] | ||
= | =Server Lifecycle= | ||
* https://httpd.apache.org/docs/current/stopping.html | |||
The httpd server, which may consist in several OS processes, can be stopped and restarted by sending Unix signals into the ''[[Httpd_Concepts#The_Parent_Process|parent process]]''. Under normal circumstances, you should never have to interact with the child processes. There are four types of lifecycle events httpd can go through, and they correspond to four different Unix signals, described below. The signals can be sent into the parent process using the httpd process directly, using the -k command line options or (recommended) the <tt>apachectl</tt>control script. For more details on how to operationally control the lifecycle see "[[Controlling httpd Lifecycle#Overview|Controlling httpd Lifecycle]]" article. | |||
==Stop Now== | |||
When the httpd server is "stopped now", the parent immediately attempts to kill all of its children. Then the parent itself exits. Any requests in progress are terminated, and no further requests are processed. "Stop now" is achieved by sending the [[Linux_Signals#SIGTERM_.2815.29|SIGTERM]] signal or "stop" command into the parent. | |||
= | More details: | ||
< | |||
<blockquote style="background-color: AliceBlue; border: solid thin LightSteelBlue;"> | |||
</ | :https://httpd.apache.org/docs/current/stopping.html#term<br> | ||
</blockquote> | |||
==Graceful Stop== | |||
When the httpd server is "gracefully stopped", the parent advises the children to exit after serving the current request - or exit immediately if they are not serving anything. Then the parent will remove its [[httpd PidFile|PidFile][ and cease listening on any ports. The parent will continue to run and monitor the children which are still handling requests. Once all children have finished handling requests and exited, or the [[httpd GracefulShutdownTimeout|GracefulShutdownTimeout]] has passed, the parent will also exit. If the timeout is reached while the children are still handling requests, they will be forced to exit. | |||
"Graceful Stop" is achieved by sending the [[Linux_Signals#SIGWINCH_.2828.29|SIGWINCH]] signal or "graceful-stop" command into the parent. | |||
More details: | |||
<blockquote style="background-color: AliceBlue; border: solid thin LightSteelBlue;"> | |||
:https://httpd.apache.org/docs/current/stopping.html#gracefulstop<br> | |||
</blockquote> | |||
==Restart Now== | |||
When the httpd server is "restarted now", the parent first verifies the configuration file syntax, and if errors are encountered, the server logs an error and refuses to restart. This is to avoid the situation where the server halts and then cannot be restarted due to syntax errors. However, this does not guarantees that the server will restart correctly if semantic errors are present. | |||
Then the parent kills all of its children as in "[[#Stop_Now|stop now]]" but the parent does not exit. It re-reads the configuration files, re-opens the log files and then it creates a new set of children and continue serving requests. When reading the configuration file, a syntax check is performed and the configuration file has errors, the restart will not be attempted. [[httpd mod_status|mod_status]] server statistics will be set to zero. | |||
"Restart Now" is achieved by sending the [[Linux_Signals#SIGHUP_.281.29|SIGHUP]] signal or "restart" command into the parent. | |||
More details: | |||
<blockquote style="background-color: AliceBlue; border: solid thin LightSteelBlue;"> | |||
:https://httpd.apache.org/docs/current/stopping.html#hup<br> | |||
</blockquote> | |||
==Graceful Restart== | |||
When the httpd server is "gracefully restarted", the parent first verifies the configuration file syntax, and if errors are encountered, the server logs an error and refuses to restart. This is to avoid the situation where the server halts and then cannot be restarted due to syntax errors. However, this does not guarantees that the server will restart correctly if semantic errors are present. | |||
If the syntax check is successful, the parent ''advises'' all its children to exit after they finish processing the current requests, or to exit immediately if they are not serving anything. Then the parent re-reads the configuration file and re-opens the log files. As each child exits, the parent replaces it with a child from the ''new generation of the configuration'', which begins serving new requests immediately. | |||
The graceful restart always respects the process control directives, so the number of processes and threads available to serve clients is respected during the restart process. | |||
If [[httpd mod_status|mod_status]] is used, the server statistics will ''not'' be reset. The status module will use a G to indicate those children which are still serving requests, started before the graceful restart command. | |||
"Graceful Restart" is achieved by sending the [[Linux_Signals#SIGUSR1_.2810.29|SIGUSR1]] signal or "graceful" command into the parent. | |||
More details: | |||
<blockquote style="background-color: AliceBlue; border: solid thin LightSteelBlue;"> | |||
:https://httpd.apache.org/docs/current/stopping.html#graceful<br> | |||
</blockquote> | |||
=The Parent Process= | |||
The httpd parent process is the process whose PID is written in [[httpd PidFile#Overview|PidFile]]. Under normal circumstances, the [[#Server_Lifecycle|lifecycle]] of the entire server, consisting in a parent process and several children, can be controlled by sending signals into the parent process only, | |||
=Multi-Processing Module (MPM)= | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[Httpd Multi-Processing Module Concepts|Multi-Processing Module (MPM) Concepts]] | |||
</blockquote> | |||
=Proxying Concepts= | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[Httpd mod proxy Concepts|mod_proxy Concepts]] | |||
</blockquote> | |||
=Context= | |||
* Server Configuration (httpd.conf) | |||
* [[#Virtual_Host|Virtual Host]] | |||
* Directory | |||
=Virtual Host= | =Virtual Host= | ||
* External Apache 2.4 Documentation - Virtual Hosts http://httpd.apache.org/docs/2.4/vhosts/ | |||
==Overview== | |||
A virtual host is a container within a httpd instance serving a single logical web site. Multiple, separate web sites, even belonging to different domains, can be served off the same httpd instance without that being apparent to the client. The virtual hosts can be ''name-based'' or ''ip-address based''. | |||
==Name-Based Virtual Host== | |||
The server relies on the client sending a "Host" HTTP header. It uses the value to locate the correct logical host. This technique allows many different virtual hosts to share the same IP address. The web browser must cooperate by sending the correct "Host" header, as part of each request. | |||
Name-based virtual hosting is the preferred technique, unless you're using equipment that explicitly demands IP-based hosting. | |||
==IP Address-Based Virtual Host== | |||
IP-based virtual hosts use the IP address of the connection to determine the correct virtual host to serve. Therefore you need to have a separate IP address for each host. | |||
==Virtual Host Configuration== | |||
A virtual host is declared in the httpd configuration using the <tt><VirtualHost></tt> configuration element. More details on virtual host configuration: | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[httpd Virtual Host Configuration]] | |||
</blockquote> | |||
=SSL Support= | |||
httpd provides SSL/TLS encryption support via the mod_ssl module, which is an interface to OpenSSL library. More details about SSL configuration are available here: | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[httpd SSL Configuration]] | |||
</blockquote> | |||
=Module= | |||
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;"> | |||
:[[httpd Modules]] | |||
</blockquote> |
Latest revision as of 15:43, 10 January 2017
Internal
Server Lifecycle
The httpd server, which may consist in several OS processes, can be stopped and restarted by sending Unix signals into the parent process. Under normal circumstances, you should never have to interact with the child processes. There are four types of lifecycle events httpd can go through, and they correspond to four different Unix signals, described below. The signals can be sent into the parent process using the httpd process directly, using the -k command line options or (recommended) the apachectlcontrol script. For more details on how to operationally control the lifecycle see "Controlling httpd Lifecycle" article.
Stop Now
When the httpd server is "stopped now", the parent immediately attempts to kill all of its children. Then the parent itself exits. Any requests in progress are terminated, and no further requests are processed. "Stop now" is achieved by sending the SIGTERM signal or "stop" command into the parent.
More details:
Graceful Stop
When the httpd server is "gracefully stopped", the parent advises the children to exit after serving the current request - or exit immediately if they are not serving anything. Then the parent will remove its [[httpd PidFile|PidFile][ and cease listening on any ports. The parent will continue to run and monitor the children which are still handling requests. Once all children have finished handling requests and exited, or the GracefulShutdownTimeout has passed, the parent will also exit. If the timeout is reached while the children are still handling requests, they will be forced to exit.
"Graceful Stop" is achieved by sending the SIGWINCH signal or "graceful-stop" command into the parent.
More details:
Restart Now
When the httpd server is "restarted now", the parent first verifies the configuration file syntax, and if errors are encountered, the server logs an error and refuses to restart. This is to avoid the situation where the server halts and then cannot be restarted due to syntax errors. However, this does not guarantees that the server will restart correctly if semantic errors are present.
Then the parent kills all of its children as in "stop now" but the parent does not exit. It re-reads the configuration files, re-opens the log files and then it creates a new set of children and continue serving requests. When reading the configuration file, a syntax check is performed and the configuration file has errors, the restart will not be attempted. mod_status server statistics will be set to zero.
"Restart Now" is achieved by sending the SIGHUP signal or "restart" command into the parent.
More details:
Graceful Restart
When the httpd server is "gracefully restarted", the parent first verifies the configuration file syntax, and if errors are encountered, the server logs an error and refuses to restart. This is to avoid the situation where the server halts and then cannot be restarted due to syntax errors. However, this does not guarantees that the server will restart correctly if semantic errors are present.
If the syntax check is successful, the parent advises all its children to exit after they finish processing the current requests, or to exit immediately if they are not serving anything. Then the parent re-reads the configuration file and re-opens the log files. As each child exits, the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.
The graceful restart always respects the process control directives, so the number of processes and threads available to serve clients is respected during the restart process.
If mod_status is used, the server statistics will not be reset. The status module will use a G to indicate those children which are still serving requests, started before the graceful restart command.
"Graceful Restart" is achieved by sending the SIGUSR1 signal or "graceful" command into the parent.
More details:
The Parent Process
The httpd parent process is the process whose PID is written in PidFile. Under normal circumstances, the lifecycle of the entire server, consisting in a parent process and several children, can be controlled by sending signals into the parent process only,
Multi-Processing Module (MPM)
Proxying Concepts
Context
- Server Configuration (httpd.conf)
- Virtual Host
- Directory
Virtual Host
- External Apache 2.4 Documentation - Virtual Hosts http://httpd.apache.org/docs/2.4/vhosts/
Overview
A virtual host is a container within a httpd instance serving a single logical web site. Multiple, separate web sites, even belonging to different domains, can be served off the same httpd instance without that being apparent to the client. The virtual hosts can be name-based or ip-address based.
Name-Based Virtual Host
The server relies on the client sending a "Host" HTTP header. It uses the value to locate the correct logical host. This technique allows many different virtual hosts to share the same IP address. The web browser must cooperate by sending the correct "Host" header, as part of each request.
Name-based virtual hosting is the preferred technique, unless you're using equipment that explicitly demands IP-based hosting.
IP Address-Based Virtual Host
IP-based virtual hosts use the IP address of the connection to determine the correct virtual host to serve. Therefore you need to have a separate IP address for each host.
Virtual Host Configuration
A virtual host is declared in the httpd configuration using the <VirtualHost> configuration element. More details on virtual host configuration:
SSL Support
httpd provides SSL/TLS encryption support via the mod_ssl module, which is an interface to OpenSSL library. More details about SSL configuration are available here: