记录 ---- Web服务器

Web服务器

Web服务器的实现

Web服务器会对HTTP请求进行处理并提供响应。术语"Web服务器"能够用来表示Web服务器的软件,也能够用来表示提供Web页面的特定设备或计算机。
html

Web服务器实现了HTTP和相关的TCP链接处理。负责管理Web服务器提供的资源,以及对Web服务器的配置、控制及扩展方面的管理。Web服务器逻辑实现了HTTP协议、管理着Web 资源,并负责提供We 服务器的管理功能。Web服务器逻辑和操做系统共同负责管理TCP链接。底层操做系统负责管理底层计算机系统的硬件细节,并提供了TCP/IP网络支持、负责装载Web资源的文件系统以及控制当前计算活动的进程管理功能。
后端

Web 服务器有各类不一样的形式。
浏览器

  • 能够在标准的计算机系统上安装并运行通用软件Web服务器:通用的软件Web服务器都运行在标准的、有网络功能的计算机系统上。能够选择开源软件(好比Apache)或者商业软件(好比微软的IIS)。基本上全部的计算机和操做系统中都有可用的Web服务器软件。
  • 若是不想那么麻烦地去安装软件,能够买一台Web服务器设备:一般会是一台安装在时髦机架上的计算机,里面的软件会预装并配置好,是预先打包好的软硬件解决方案。厂商会在他们选择的计算机平台上预先安装好软件服务器,并将软件配置好。应用解决方案再也不须要安装及配置软件,一般能够极大地简化管理工做。可是,Web服务器一般不太灵活,特性不太丰富,并且服务器硬件也不太容易重用或升级。
  • 随着微处理器奇迹般地出现,有些公司甚至能够在少许计算机芯片上实现嵌入式Web服务器,使其成为完美的(便携式)消费类设备管理控制台:嵌入式服务器是要嵌入到消费类产品(好比打印机或家用设备)中去的小型Web服务器。嵌入式Web服务器容许用户经过便捷的Web浏览器接口来管理其消费者设备。有些嵌入式Web服务器甚至能够在小于一平方英寸的空间内实现,但一般只能提供最小特性功能集。

Web服务器会作些什么

  • 创建链接:接受一个客户端链接,或者若是不但愿与这个客户端创建链接,就将其关闭。
  • 接收请求:从网络中读取一条HTTP请求报文。
  • 处理请求:对请求报文进行解释,并采起行动。
  • 访问资源:访问报文中指定的资源。
  • 构建响应:建立带有正确首部的HTTP响应报文。
  • 发送响应:将响应回送给客户端。
  • 记录日志:将与已完成事务有关的内容记录在一个日志文件中。

接受客户端连接

若是客户端已经打开了一条到服务器的持久链接,可使用那条链接来发送它的请求。不然,客户端须要打开一条新的到服务器的链接。
安全

处理新链接

客户端请求一条到Web服务器的TCP链接时,Web服务器会创建链接,判断链接的另外一端是哪一个客户端,从TCP链接中将IP地址解析出来。一旦新链接创建起来并被接受,服务器就会将新链接添加到其现存Web服务器链接列表中,作好监视链接上数据传输的准备。Web服务器能够随意拒绝或当即关闭任意一条链接。有些Web服务器会由于客户端IP地址或主机名是未认证的,或者由于它是已知的恶意客户端而关闭链接。Web服务器也可使用其余识别技术。
服务器

客户端主机名识别

能够用"反向域名解析"对大部分Web服务器进行配置,以便将客户端IP地址转换成客户端主机名。Web服务器能够将客户端主机名用于详细的访问控制和日志记录。但要注意的是,主机名查找可能会花费很长时间,这样会下降Web事务处理的速度。不少大容量Web服务器要么会禁止主机名解析,要么只容许对特定内容进行解析。
网络

肯定客户端用户

有些Web服务器还支持IETF的ident协议。服务器能够经过ident协议找到发起HTTP链接的用户名。这些信息对Web服务器的日志记录特别有用——流行的通用日志格式(Common Log Format)的第二个字段中就包含了每条HTTP请求的ident用户名。若是客户端支持ident协议,就在TCP端口113上监听ident请求。
数据结构

ident在组织内部能够很好地工做,但出于多种缘由,在公共因特网上并不能很好地工做,缘由包括:
多线程

  • 不少客户端PC没有运行ident识别协议守护进程软件;
  • ident协议会使HTTP事务处理产生严重的时延;
  • 不少防火墙不容许ident流量进入;
  • ident协议不安全,容易被伪造;
  • ident协议也不支持虚拟IP地址;
  • 暴露客户端的用户名还涉及隐私问题。

接收请求报文

链接上有数据到达时,Web服务器会从网络链接中读取数据,并将请求报文中的内容解析出来。解析请求报文时,Web服务器会不按期地从网络上接收输入数据。网络链接可能随时都会出现延迟。Web服务器须要从网络中读取数据,将部分报文数据临时存储在内存中,直到收到足以进行解析的数据并理解其意义为止。
负载均衡

解析请求报文时,Web服务器会:
ide

  • 解析请求行,查找请求方法、指定的URI以及版本号,各项之 间由一个空格分隔,并以一个CRLF序列做为行的结束;
  • 检测到以CRLF结尾的、标识首部结束的空行(若是有的话);
  • 若是有的话(长度由Content-Length首部指定),读取请求主体。

报文的内部表示法

有些Web服务器还会用便于进行报文操做的内部数据结构来存储请求报文。好比,数据结构中可能包含有指向请求报文中各个片断的指针及其长度,这样就能够将这些首部存放在一个快速查询表中,以便快速访问特定首部的具体值了

链接的输入/输出处理结构

高性能的Web服务器可以同时支持数千条链接。这些链接使得服务器能够与世界各地的客户端进行通讯,每一个客户端都向服务器打开了一条或多条链接。某些链接可能在快速地向Web服务器发送请求,而其余一些链接则可能在慢慢发送,或者不常常发送请求,还有一些多是空闲的,安静地等待着未来可能出现的动做。由于请求可能会在任意时刻到达,因此Web服务器会不停地观察有无新的Web请求。不一样的Web服务器结构会以不一样的方式为请求服务。

  • 单线程Web服务器:单线程的Web服务器一次只处理一个请求,直到其完成为止。一个事务处理结束以后,才去处理下一条链接。这种结构易于实现,但在处理过程当中,全部其余链接都会被忽略。这样会形成严重的性能问题,只适用于低负荷的服务器,以及诊断工具。
  • 多进程及多线程Web服务器:多进程和多线程Web服务器用多个进程,或更高效的线程同时对请求进行处理。能够根据须要建立,或者预先建立一些线程/进程。有些服务器会为每条链接 分配一个线程/进程,但当服务器同时要处理成百、上千,甚至数以万计的链接 时,须要的进程或线程数量可能会消耗太多的内存或系统资源。所以,不少多线 程Web服务器都会对线程/进程的最大数量进行限制。
  • 复用I/O的服务器:为了支持大量的链接,不少Web服务器都采用了复用结构。在复用结构中,要同时监视全部链接上的活动。当链接的状态发生变化时(好比,有数据可用,或出现错误时),就对那条链接进行少许的处理;处理结束以后,将链接返回到开放链接列表中,等待下一次状态变化。只有在有事情可作时才会对链接进行处理;在空闲链接上等待的时候并不会绑定线程和进程。
  • 复用的多线程Web服务器:有些系统会将多线程和复用功能结合在一块儿,以利用计算机平台上的多个CPU。多个线程(一般是一个物理处理器)中的每个都在观察打开的链接(或打开的链接中的一个子集),并对每条链接执行少许的任务。

处理请求

一旦Web服务器收到了请求,就能够根据方法、资源、首部和可选的主体部分来对请求进行处理了。有些方法(好比POST)要求请求报文中必须带有实体主体部分的数据。其余一些方法(好比OPTIONS)容许有请求的主体部分,也容许没有。少数方法(好比GET)禁止在请求报文中包含实体的主体数据。

对资源的映射及访问

Web服务器是资源服务器。它们负责发送预先建立好的内容(好比HTML页面或JPEG图片),以及运行在服务器上的资源生成程序所产生的动态内容。在Web服务器将内容传送给客户端以前,要将请求报文中的URI映射为Web服务 器上适当的内容或内容生成器,以识别出内容的源头。

文档的根目录

Web服务器支持各类不一样类型的资源映射,但最简单的资源映射形式就是用请求URI做为名字来访问Web服务器文件系统中的文件。一般,Web服务器的文件系统中会有一个特殊的文件夹专门用于存放Web内容。这个文件夹被称为文档的根目录(document root)。Web服务器从请求报文中获取URI,并将其附加在文档根目录的后面。

目录列表

Web服务器能够接收对目录URL的请求,其路径能够解析为一个目录,而不是文件。咱们能够对大多数Web服务器进行配置,使其在客户端请求目录URL时采起不一样的动做。大多数Web服务器都会去查找目录中一个名为"index.html"或"index.htm"的文件来表明此目录。若是用户请求的是一个目录的URL,并且这个目录中有一个名为"index.html"或"index.htm"的文件,服务器就会返回那个文件的内容。

  • 返回一个错误。
  • 不返回目录,返回一个特殊的默认"索引文件"。
  • 扫描目录,返回一个包含目录内容的HTML页面。

动态内容资源的映射

Web服务器还能够将URI映射为动态资源——也就是说,映射到按需动态生成内容的程序上去。实际上,有一大类名为应用程序服务器的Web服务器会将Web服务器链接到复杂的后端应用程序上去。Web服务器要可以分辨出资源何时是动态的,动态内容生成程序位于何处,以及如何运行那个程序。大多数Web服务器都提供了一些基本的机制以识别和映射动态资源。

CGI是早期出现的一种简单、流行的服务端应用程序执行接口。现代的应用程序服务器都有更强大更有效的服务端动态内容支持机制,包括ASP(Active Server Page)和Java servlet。

服务器端包含项

不少Web服务器还提供了对服务器端包含项(SSI)的支持。若是某个资源被标识为存在服务器端包含项,服务器就会在将其发送给客户端以前对资源内容进行处理。要对内容进行扫描,以查找(一般包含在特定HTML注释中的)特定的模板,这些模板能够是变量名,也能够是嵌入式脚本。能够用变量的值或可执行脚本的输出来取代特定的模板。这是建立动态内容的一种简便方式。

访问控制

Web服务器还能够为特定资源进行访问控制。有请求到达,要访问受控资源时,Web服务器能够根据客户端的IP地址进行访问控制,也能够要求输入密码来访问资源。

构建响应

一旦Web服务器识别出了资源,就执行请求方法中描述的动做,并返回响应报文。响应报文中包含有响应状态码、响应首部,若是生成了响应主体的话,还包括响应主体。

响应实体

若是事务处理产生了响应主体,就将内容放在响应报文中回送过去。

若是有响应主体的话,响应报文中一般包括:

  • 描述了响应主体MIME类型的Content-Type首部;
  • 描述了响应主体长度的Content-Length首部;
  • 实际报文的主体内容。

MIME类型

Web服务器要负责肯定响应主体的MIME类型。有不少配置服务器的方法能够将MIME类型与资源关联起来。Web服务器能够用文件的扩展名来讲明MIME类型。Web服务器会为每一个资源扫描一个包含了全部扩展名的MIME类型的文件,以肯定其MIME类型。还能够经过配置Web服务器,将特定的文件与MIME类型相关联。

  • 魔法分类:Web服务器能够扫描每一个资源的内容,并将其与一个已知模式表(被称为魔法文件)进行匹配,以决定每一个文件的MIME类型。这样作可能比较慢,但很方便,尤为是文件没有标准扩展名的时候。
  • 显式分类:能够对Web服务器进行配置,使其不考虑文件的扩展名或内容,强制特定文件或目录内容拥有某个MIME类型。
  • 类型协商:有些Web服务器通过配置,能够以多种文档格式来存储资源。在这种状况下,能够配置Web服务器,使其能够经过与用户的协商来决定使用哪一种格式(及相关的 MIME 类型)"最好"。

重定向

Web服务器有时会返回重定向响应而不是成功的报文。Web服务器能够将浏览器重定向到其余地方来执行请求。重定向响应由返回码3XX说明。Location响应首部包含了内容的新地址或优选地址的URI。

重定向可用于下列状况。

  • 永久搬离的资源:资源可能已经被移动到了新的位置,或者被从新命名,有了一个新的URL。Web服务器能够告诉客户端资源已经被重命名了,这样客户端就能够在重新地址获取资源以前,更新书签之类的信息了。状态码"301 Moved Permanently"就用于此类重定向。
  • 临时搬离的资源:若是资源被临时移走或重命名了,服务器可能但愿将客户端重定向到新的位置上去。但因为重命名是临时的,因此服务器但愿客户端未来还能够回头去使用老的URL,不要对书签进行更新。状态码"303 See Other"以及状态码"307 Temporary Redirect"就用于此类重定向。
  • URL 加强:服务器一般用重定向来重写URL,每每用于嵌入上下文。当请求到达时,服务器会生成一个新的包含了嵌入式状态信息的URL,并将用户重定向到这个新的URL上去。客户端会跟随这个重定向信息,从新发起请求,但此次的请求会包含完整的、通过状态加强的URL。这是在事务间维护状态的一种有效方式。状态码"303 See Other"和"307 Temporary Redirect"用于此类重定向。
  • 负载均衡:若是一个超载的服务器收到一条请求,服务器能够将客户端重定向到一个负载不过重的服务器上去。状态码"303 See Other"和"307 Temporary Redirect"可用于此类重定向。
  • 服务器关联:Web服务器上可能会有某些用户的本地信息;服务器能够将客户端重定向到包含了那个客户端信息的服务器上去。状态码"303 See Other"和"307 Temporary Redirect"可用于此类重定向。
  • 规范目录名称:客户端请求的URI是一个不带尾部斜线的目录名时,大多数Web服务器都会将客户端重定向到一个加了斜线的URI上,这样相对连接就能够正常工做了。

发送响应

Web服务器经过链接发送数据时也会面临与接收数据同样的问题。服务器可能有不少条到各个客户端的链接,有些是空闲的,有些在向服务器发送数据,还有一些在向客户端回送响应数据。服务器要记录链接的状态,还要特别注意对持久链接的处理。对非持久链接而言,服务器应该在发送了整条报文以后,关闭本身这一端的链接。对持久链接来讲,链接可能仍保持打开状态,在这种状况下,服务器要特别当心,要正确地计算Content-Length首部,否则客户端就没法知道响应何时结束了。

记录事务处理过程

最后,当事务结束时,Web服务器会在日志文件中添加一个条目,来描述已执行的事务。

相关文章
相关标签/搜索