Httpd Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(73 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Internal=
=Internal=


* [[httpd#Concepts]]
* [[httpd#Subjects|httpd]]


=Multi-Processing Module (MPM)=
=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=


https://home.feodorov.com:9443/wiki/Wiki.jsp?page=HttpdMultiProcessingModules
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,


=Forward Proxy=
=Multi-Processing Module (MPM)=


An ordinary forward proxy is an intermediate server that sits between the client and the origin server. In order to get content from the origin server, the client sends a request to the proxy naming the origin server as the target and the proxy then requests the content from the origin server and returns it to the client. The client must be specially configured to use the forward proxy to access other sites.
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Httpd Multi-Processing Module Concepts|Multi-Processing Module (MPM) Concepts]]
</blockquote>


=Reverse Proxy (Gateway)=
=Proxying Concepts=


A reverse proxy (or gateway), by contrast, appears to the client just like an ordinary web server. No special configuration on the client is necessary. The client makes ordinary requests for content in the name-space of the reverse proxy. The reverse proxy then decides where to send those requests, and returns the content as if it was itself the origin.
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Httpd mod proxy Concepts|mod_proxy Concepts]]
</blockquote>


A typical usage of a reverse proxy is to provide Internet users access to a server that is behind a firewall. Reverse proxies can also be used to balance load among several back-end servers, or to provide caching for a slower back-end server. In addition, reverse proxies can be used simply to bring several servers into the same URL space.
=Context=


=Worker=
* Server Configuration (httpd.conf)
<font color=red>
* [[#Virtual_Host|Virtual Host]]
TODO
* Directory
</font>


=Virtual Host=
=Virtual Host=
Line 26: Line 89:
* External Apache 2.4 Documentation - Virtual Hosts http://httpd.apache.org/docs/2.4/vhosts/
* External Apache 2.4 Documentation - Virtual Hosts http://httpd.apache.org/docs/2.4/vhosts/


==Overview===
==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=


A virtual host is a container within a httpd instance serving a single logical web site. Multiple, separate web sites can be served off the same httpd instance without that being apparent to the client.
<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:

https://httpd.apache.org/docs/current/stopping.html#term

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:

https://httpd.apache.org/docs/current/stopping.html#gracefulstop

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:

https://httpd.apache.org/docs/current/stopping.html#hup

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:

https://httpd.apache.org/docs/current/stopping.html#graceful

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)

Multi-Processing Module (MPM) Concepts

Proxying Concepts

mod_proxy Concepts

Context

Virtual Host

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:

httpd 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:

httpd SSL Configuration

Module

httpd Modules