关于http:图解HTTP权威指南三-Web服务器对HTTP请求的处理和响应

作者简介

李先生（Lemon），高级运维工程师（自称），SRE 专家（指标），幻想在 35 岁买一辆保时捷。喜爱钻研底层技术，认为底层根底才是王道。所有新技术都离不开操作系统（CPU、内存、磁盘）、网络等。保持输入输出，记录本人学习的点滴，在平庸中保持前行，总有一天会遇见不一样的本人。公众号：运维汪（ID：Leeeee_Li）。

一、问题

解释 Web 服务器是如何解决 HTTP 事务的

二、Web 服务器

Web 服务器会对 HTTP 申请进行解决并提供响应。Web 服务器申请的七大步骤：

1）承受客户端连贯

2）接管申请报文

3）解决申请

4）资源映射及拜访

5）构建响应

6）发送响应

7）记录日志

1、承受客户端连贯

1）解决新连贯

客户端申请一条到 Web 服务器的 TCP 连贯时，Web 服务器会建设连贯，判断连贯的另一端是哪个客户端，从 TCP 连贯中将 IP 地址解析进去。一旦新连贯建设起来并承受，服务器就会将新连贯增加到其现存 Web 服务器连贯列表中，做好监督连贯上数据传输的筹备。Web 服务器能够随便回绝或立刻敞开任意一条连贯。有些 Web 服务器会因为客户端 IP 地址或主机名是未认证的，或者因为它是已知的歹意客户端而敞开连贯。Web 服务器也能够应用其余技术辨认。

2）客户端主机名辨认

能够用”反向 DNS“对大部分 Web 服务器进行配置，以便将客户端 IP 地址转换成客户端主机名。Web 服务器能够将客户端主机名用于具体的访问控制和日志记录。须要留神的是，主机名查找可能会破费很长的工夫，这样会升高 Web 事务处理的速度。很多大容量的 Web 服务器会禁止主机名解析，或者只容许对特定内容进行解析。

能够用配置指令 Hostnamelookups 启用 Apache 的主机查找性能。如只关上 HTML 和 CGI 资源的主机名解析性能。

HostnameLookups off
<Files ~ "\.(html|htm|cgi)$">
   HostnameLookups on 
</Files>

3）通过 ident 确定客户端用户

服务器能够通过 ident 协定找到发动 HTTP 连贯的用户名。这些信息对 Web 服务器的日志记录特地有用，风行的通用日志格局的第二个字段就蕴含了每条 HTTP 申请的 ident 用户名。

1）客户端关上一条 HTTP 连贯

2）服务器关上本人到客户端 ident 服务 113 端口的连贯

3）服务器发送一条简略的申请，询问与新连贯绝对应的用户名，把那个从客户端解析出蕴含用户名的响应

Apache 的 IdentityCheck on 指令告知 Apache Web 服务器应用 ident 查找性能，如果没有 ident 信息可用，Apache 会用连字符（-）来填充 ident 日志字段。如果没有 ident 信息可用，在应用通用日志格局的日志文件中，第二个字段通常都是连字符。

2、接管申请报文

当连贯上有数据达到时，Web 服务器会从网络连接中读取数据，并将申请报文中的内容解析进去。

1）解析申请报文时，Web 服务器的工作

1、解析申请行，查找申请办法、指定的资源标识符（URI）以及版本号，各项之间有一个空格隔开，并以一个回车换行（CRLF）序列作为行的完结；

2、读取以 CRLF 结尾的报文首部；

3、检测到以 CRLF 结尾的、标识首部完结的空行；

4、读取申请主体

2）报文的外部表示法

3、连贯的输出 / 输入解决构造

高性能的 Web 服务器可能同时反对数千条连贯，每个客户端都向服务器关上了一条或多条连贯。不同的 Web 服务器会以不同的形式为申请服务。

单线程 Web 服务器：单线程的 Web 服务器一次只解决一个申请，直到其实现为止。一个事务处理完结之后，才去解决下一条连贯。

多过程及多线程 Web 服务器：多过程和多线程 Web 服务器用多个过程，或更高效的线程同时对申请进行解决。

复用 I / O 的服务器：在复用构造中，要同时监督所有连贯上的流动。当连贯的状态发生变化时，就对那条连贯进行解决，解决完结后，将连贯返回到凋谢的连贯列表中，期待下一次的状态变动。只有在有事件能够做时才会对连贯进行解决，在闲暇连贯上期待的时候并不会绑定线程和过程。

复用的多线程 Web 服务器：将多线程和复用性能联合在一起，利用计算机的多个 CPU。多个线程中（通常是一个物理处理器）的每一个都在察看关上的连贯，并对每条连贯（或关上连贯中的一个子集）执行工作。

3、解决申请

当 Web 服务器接管到申请后，依据办法、资源、首部和可选的主体局部来对申请进行解决。

4、对资源的映射及拜访

1）docroot（文档的根目录）

Web 服务器的文件系统中有一个专门寄存 Web 内容的目录，称为文档的根目录（document root，或 docroot）。当一个 Web 服务器的根目录为 /usr/local/httpd/files，并且有一条 /special/s.gif 的申请达到时，他的拜访如图

在 Apache 中，对配置文件 httpd.conf 增加一行 DocumentRoot 行就可设置文档的根目录

DocumentRoot /usr/local/httpd/files

2）虚构托管的 docroot

虚构托管的 Web 服务器会在同一台 Web 服务器上提供多个 Web 站点，每个站点在服务器上都有本人都有的文档根目录。虚构托管 Web 服务器会依据 URI 或 Host 首部的 IP 或主机名来辨认要应用的正确的文档根目录。通过这种形式，及时申请的 URI 雷同，托管在同一 Web 服务器上的两个 Web 站点也能够领有齐全不同的内存。

A 申请进来时，获取服务器的 /doc/aaa/index.html

B 申请进来时，获取服务器的 /doc/bbb/index.html

3）用户的主目录 docroot

Docroot 提供公有的 Web 站点时，通常会以斜杠和波浪号（/~）开始，如

A 申请进来时，获取服务器的 /home/mary/index.html

B 申请进来时，获取服务器的 /home/ken/index.html

在 Apache 的配置如下：

<VirtualHost www.aaa.com> 
    ServerName www.aaa.com 
    DocumentRoot /doc/aaa
    TransferLog /logs/aaa.access_log 
    ErrorLog /1ogs/aaa.error_log
</VirtualHost>

<VirtualHost www.bbb.com> 
    ServerName www.bbb.com 
    DocumentRoot /doc/bbb
    TransferLog /logs/bbb.access_log 
    ErrorLog /1ogs/bbb.error_log
</VirtualHost>

5、构建响应

一旦 Web 服务器辨认出了资源、就执行申请办法中的形容的动作，并返回响应报文。响应报文中蕴含有状态码、响应首部、如果生成了响应主体的话，还包含响应主体。

1）响应主体

如果事务处理产生了响应主体，就将内容放在响应报文中回送过来。如果有响应主体的话，响应报文中通常包含：

a）形容了响应主体 MIME 类型的 Content-Type 首部；

b）形容了响应主体长度的 Content-Length 首部；

c）理论报文的主题内容

2）MIME 类型

Web 服务器要负责确定响应主体的 MIME 类型。

a）依据扩展名确定 MIME 类型

Web 服务器能够用文件的扩展名来阐明 MIME 类型。Web 服务器会为每个资源扫描一个蕴含了所有扩展名的 MIME 类型的文件，以确定 MIME 类型。Web 服务器用 MIME 类型文件来设置资源输入的 Content-type 首部。

b）魔法分类

Apache Web 服务器扫描每个资源的内容，并与一个已知模式表（魔法文件）进行匹配，决定每个文件的 MIME 类型。

c）显示分类

对 Web 服务器进行配置，使其不思考文件的扩展名和内容，强制特定文件或目录内容领有某个 MIME 类型。

d）类型协商

通过配置 Web 服务器，使其能够通过与用户的协商来决定应用哪种格局以及相干的 MIME 类型。

3）重定向

Web 服务器有时会返回重定向响应而不是胜利的报文。Web 服务器能够将浏览器重定向到其余中央来执行申请。重定向响应码为 3XX 系列。Location 响应首部蕴含了内容的新地址或优选地址的 URL。

a）永恒删除的资源

资源可能曾经被挪动到了新的地位，或者被重新命名，有了一个新的 URL。Web 服务器能够通知客户端资源曾经被重新命名了，这样客户端就能够在从新地址获取资源之前，更新书签之类的信息了。状态码 301 Moved Permanently 用于此类重定向。

b）长期删除的资源

资源被长期移走了或重命名了。服务器可能心愿将客户端重定向到新的地位下来。但因为重命名是长期的，所以服务器心愿客户端未来还能够回头应用老的 URL，不要对书签进行更新。状态吗 303 See Other 以及状态码 307 Temporary Redirect 用于此类重定向。

c）URL 加强

服务器通常用重定向来重写 URL，往往用于嵌入上下文。当申请达到时，服务器会生成一个新的蕴含了嵌入式状态信息的 URL，并将用户重定向到这个新的 URL 上。客户端会追随这个重定向信息，从新发动申请，但这次的申请会蕴含残缺的、通过状态加强的 URL。状态吗 303 See Other 以及状态码 307 Temporary Redirect 用于此类重定向。

d）负载平衡

一个超载的服务器收到一条申请，服务器能够将客户端重定向到一个负载不太重的服务器下来。状态吗 303 See Other 以及状态码 307 Temporary Redirect 用于此类重定向。

e）服务器关联

Web 服务器上可能会有某些用户的本地信息，服务器能够将客户端重定向到蕴含了那个客户端信息的服务器下来。状态吗 303 See Other 以及状态码 307 Temporary Redirect 用于此类重定向。

f）标准目录名称

客户端申请的 URL 是一个不带尾部斜线的目录名时，大多数 Web 服务器都会将客户端重定向到一个加了斜线的 URL 上，这样绝对链接就能够失常工作了。

6、发送响应

Web 服务器通过连贯发送数据，发送数据与接收数据一样可能有多条到客户端的连贯，有些是闲暇的，有些在向服务器发送数据，还有一些在向客户端回送响应数据。服务器要记录连贯的状态，还须要特地留神长久连贯的解决。对于非长久连贯，服务器应该在发送了整条报文之后，敞开本人这一端的连贯。

7、记录日志

当事务完结时，Web 服务器会在日志文件中增加一个条目，来形容已执行的事务。