共计 2320 个字符，预计需要花费 6 分钟才能阅读完成。
第一步——承受客户端连贯
承受一个客户端连贯，或者如果不心愿与这个客户端建设连贯，就将其敞开。
第二步——接管申请报文
从网络中读取一条 HTTP 申请报文
解析报文
1. 解析申请行，查找申请办法、指定的资源标识符（URI）以及版本号，各项之间由一个空格分隔，并以一个回车换行（CRLF）序列作为行的完结；2. 读取以 CRLF 结尾的报文首部；3. 检测到以 CRLF 结尾的、标识首部完结的空行（如果有的话）；4. 如果有的话（长度由 Content-Length 首部指定），读取申请主体。报文的外部表示法
有些 Web 服务器还会用便于进行报文操作的外部数据结构来存储申请报文
连贯的输出 / 输入解决构造
不同的 Web 服务器构造会以不同的形式为申请服务
单线程 Web 服务器
一次只解决一个申请，直到其实现为止。一个事务处理完结之后，才去解决下一条连贯
多过程及多线程 Web 服务器
服务器会为每条连贯调配一个线程 / 过程; 但当服务器同时要解决成百、上千，甚至数以万计的连贯时，须要的过程或线程数量可能会耗费太多的内存或系统资源。因而，很多多线程 Web 服务器都会对线程 / 过程的最大数量进行限度。
复用 I / O 的服务器
Web 服务器都采纳了复用构造。在复用构造中，要同时监督所有连贯上的流动。当连贯的状态发生变化时（比方，有数据可用，或呈现谬误时），就对那条连贯进行大量的解决；解决完结之后，将连贯返回到凋谢连贯列表中，期待下一次状态变动。只有在有事件可做时才会对连贯进行解决；在闲暇连贯上期待的时候并不会绑定线程和过程。
复用的多线程 Web 服务器
有些零碎会将多线程和复用性能联合在一起，以利用计算机平台上的多个 CPU。多个线程（通常是一个物理处理器）中的每一个都在察看关上的连贯（或关上的连贯中的一个子集），并对每条连贯执行大量的工作
第三步——解决申请
对申请报文进行解释，并采取行动，比方 post 可能提交了一些信息，服务器须要来解决这些信息
第四步——对资源的映射及拜访
拜访报文中的指定资源，比方 Get 申请依据地址映射获取服务器上的某个文件。
docroot
通常，Web 服务器的文件系统中会有一个非凡的文件夹专门用于寄存 Web 内容。这个文件夹被称为文档的根目录（document root，或 docroot）。Web 服务器从申请报文中获取 URI，并将其附加在文档根目录的前面。
很多 web 服务器都反对配置 document 在配置文件 httpd.conf 中增加一个 DocumentRoot 行就能够为 Apache Web 服务器设置文档的根目录了：DocumentRoot /usr/local/httpd/files
虚构托管的 docroot
虚构托管的 Web 服务器会在同一台 Web 服务器上提供多个 Web 站点；每个站点在服务器上都有本人独有的文档根目录。虚构托管 Web 服务器会依据 URI 或 Host 首部的 IP 地址或主机名来辨认要应用的正确文档根目录。通过这种形式，即便申请 URI 完全相同，托管在同一 Web 服务器上的两个 Web 站点也能够领有齐全不同的内容了。
解析目录
咱们能够对大多数 Web 服务器进行配置，使其在客户端申请目录 URL 时采取不同的动作。
1. 返回一个谬误。2. 不返回目录，返回一个非凡的默认“索引文件”（Web 服务器可自行配置索引优先级）。3. 扫描目录，返回一个蕴含目录内容的 HTML 页面（主动生成且返回一个展现目录下的所有文件 / 目录的 html 文件）。大多数 Web 服务器都会去查找目录中一个名为 index.html 或 index.htm 的文件来代表此目录。如果用户申请的是一个目录的 URL，而且这个目录中有一个名为 index.html（或 index.htm）的文件，服务器就会返回那个文件的内容。
第五步——构建响应
一旦 Web 服务器辨认出了资源，就执行申请办法中形容的动作，并返回响应报文。
响应实体
如果事务处理产生了响应主体，就将内容放在响应报文中回送过来。
响应报文中通常包含：
1. 形容了响应主体 MIME 类型的 Content-Type 首部；2. 形容了响应主体长度的 Content-Length 首部；3. 理论报文的主体内容。重定向
Web 服务器有时会返回重定向响应而不是胜利的报文。Web 服务器能够将浏览器重定向到其余中央来执行申请。重定向响应由返回码 3XX 阐明。Location 响应首部蕴含了内容的新地址或优选地址的 URI。重定向可用于下列状况。
永恒搬离的资源
资源可能曾经被挪动到了新的地位，或者被重新命名，有了一个新的 URL。态码 301Moved Permanently 就用于此类重定向。
长期搬离的资源
如果资源被长期移走或重命名了，服务器可能心愿将客户端重定向到新的地位下来。状态码 303 See Other 以及状态码 307 Temporary Redirect 就用于此类重定向。
URL 加强
服务器通常用重定向来重写 URL，往往用于嵌入上下文。当申请达到时，服务器会生成一个新的蕴含了嵌入式状态信息的 URL，并将用户重定向到这个新的 URL 下来。[插图] 客户端会追随这个重定向信息，从新发动申请，但这次的申请会蕴含残缺的、通过状态加强的 URL。这是在事务间保护状态的一种无效形式。状态码 303 See Other 和 307 Temporary Redirect 用于此类重定向。
负载平衡
如果一个超载的服务器收到一条申请，服务器能够将客户端重定向到一个负载不太重的服务器下来。状态码 303 See Other 和 307 TemporaryRedirect 可用于此类重定向。
第六步——发送响应
将响应报文返回给客户端
第七步——记录日志
最初，当事务完结时，Web 服务器会在日志文件中增加一个条目，来形容已执行的事务。大多数 Web 服务器都提供了几种日志配置格局。
