web服务器_web服务器配置 - CSDN
web服务器 订阅
Web服务器一般指网站服务器,是指驻留于因特网上某种类型计算机的程序,可以处理浏览器等Web客户端的请求并返回相应响应,也可以放置网站文件,让全世界浏览;可以放置数据文件,让全世界下载。目前最主流的三个Web服务器是Apache、 Nginx 、IIS。 展开全文
Web服务器一般指网站服务器,是指驻留于因特网上某种类型计算机的程序,可以处理浏览器等Web客户端的请求并返回相应响应,也可以放置网站文件,让全世界浏览;可以放置数据文件,让全世界下载。目前最主流的三个Web服务器是Apache、 Nginx 、IIS。
信息
中文名
WEB服务器
外文名
Web Server
其他名字
WWW(WORLD WIDE WEB)服务器
WEB服务器词义辨析
什么是网络服务器?网络服务器是网络环境下为客户提供某种服务的专用计算机。WEB服务器也称为WWW(WORLD WIDE WEB)服务器,主要功能是提供网上信息浏览服务。 WWW 是 Internet 的多媒体信息查询工具,是 Internet 上近年才发展起来的服务,也是发展最快和目前用的最广泛的服务。正是因为有了WWW工具,才使得近年来 Internet 迅速发展,且用户数量飞速增长。Web服务器是可以向发出请求的浏览器提供文档的程序。1、服务器是一种被动程序:只有当Internet上运行其他计算机中的浏览器发出的请求时,服务器才会响应 。2 、最常用的Web服务器是Apache和Microsoft的Internet信息服务器(Internet Information Services,IIS)。3、Internet上的服务器也称为Web服务器,是一台在Internet上具有独立IP地址的计算机,可以向Internet上的客户机提供WWW、Email和FTP等各种Internet服务。4、Web服务器是指驻留于因特网上某种类型计算机的程序。当Web浏览器(客户端)连到服务器上并请求文件时,服务器将处理该请求并将文件反馈到该浏览器上,附带的信息会告诉浏览器如何查看该文件(即文件类型)。服务器使用HTTP(超文本传输协议)与客户机浏览器进行信息交流,这就是人们常把它们称为HTTP服务器的原因。Web服务器不仅能够存储信息,还能在用户通过Web浏览器提供的信息的基础上运行脚本和程序。WWW是 World Wide Web (环球信息网)的缩写,也可以简称为 Web,中文名字为“万维网”。它起源于1989年3月,由欧洲量子物理实验室CERN(the European Laboratory for Particle Physics)所发展出来的主从结构分布式超媒体系统。通过万维网,人们只要通过使用简单的方法,就可以很迅速方便地取得丰富的信息资料。由于用户在通过 Web浏览器访问信息资源的过程中,无需再关心一些技术性的细节,而且界面非常友好,因而 Web 在Internet 上一推出就受到了热烈的欢迎,走红全球,并迅速得到了爆炸性的发展。长期以来,人们只是通过传统的媒体(如电视、报纸、杂志和广播等)获得信息。但随着计算机网络的发展,人们想要获取信息,已不再满足于传统媒体那种单方面传输和获取的方式,而希望有一种主观的选择性。网络上提供各种类别的数据库系统,如文献期刊、产业信息、气象信息、论文检索等等。由于计算机网络的发展,信息的获取变得非常及时、迅速和便捷。到了1993年,WWW 的技术有了突破性的进展,它解决了远程信息服务中的文字显示、数据连接以及图像传递的问题,使得 WWW 成为 Internet 上最为流行的信息传播方式。Web 服务器成为 Internet 上最大的计算机群,Web 文档之多、链接的网络之广,令人难以想象。可以说,Web 为 Internet 的普及迈出了开创性的一步,是近年来 Internet 上取得的最激动人心的成就。WWW 采用的是浏览器/服务器结构,其作用是整理和储存各种WWW资源,并响应客户端软件的请求,把客户所需的资源传送到 Windows 95(或Windows98)、Windows NT、UNⅨ 或 Linux 等平台上。使用最多的 web server服务器软件有两个:微软的信息服务器(iis),和Apache。通俗的讲,Web服务器传送(serves)页面使浏览器可以浏览,然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点,你可以说:Web服务器专门处理HTTP请求(request),但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request),会返回一个HTTP响应(response),例如送回一个HTML页面。为了处理一个请求(request),Web服务器可以响应(response)一个静态页面或图片,进行页面跳转(redirect),或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本,JSP(JavaServer Pages)脚本,servlets,ASP(Active Server Pages)脚本,服务器端(server-side)JavaScript,或者一些其它的服务器端(server-side)技术。无论它们(译者注:脚本)的目的如何,这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。要知道,Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时,它只单纯的把请求(request)传递给可以很好的处理请求(request)的程序(译者注:服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境,而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing),数据库连接(database connectivity)和消息(messaging)等功能。虽然Web服务器不支持事务处理或数据库连接池,但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability),例如负载平衡(load balancing),缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。应用程序服务器(The Application Server)根据我们的定义,作为应用程序服务器,它通过各种协议,可以包括HTTP,把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向浏览器发送HTML以供浏览,而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法(或过程语言中的一个函数)一样。应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反,这种信息就是程序逻辑(program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML,所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。在大多数情形下,应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序)的,例如基于J2EE(Java 2 Platform,Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外,应用程序服务器可以管理自己的资源,例如看大门的工作(gate-keeping duties)包括安全(security),事务处理(transaction processing),资源池(resource pooling), 和消息(messaging)。就象Web服务器一样,应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。例如,设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询(query)后,网站会进行查找(lookup)并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。情景1:不带应用程序服务器的Web服务器在此种情景下,一个Web服务器独立提供在线商店的功能。Web服务器获得你的请求(request),然后发送给服务器端(server-side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file,译者注:flat file是指没有特殊格式的非二进制的文件,如properties和XML文件等)中查找定价信息。一旦找到,服务器端(server-side)程序把结果信息表示成(formulate)HTML形式,最后Web服务器把会它发送到你的Web浏览器。简而言之,Web服务器只是简单的通过响应(response)HTML页面来处理HTTP请求(request)。情景2:带应用程序服务器的Web服务器情景2和情景1相同的是Web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注:服务器端(server-side)程序)。然而,你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化,此脚本只是简单的调用应用程序服务器的查找服务(lookup service),而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生HTML响应(response)时就可以使用该服务的返回结果了。在此情景中,应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节,相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时,此服务只是简单的查找并返回结果给客户端。通过从响应产生(response-generating)HTML的代码中分离出来,在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端,例如收款机,也可以调用同样的服务(service)来作为一个店员给客户结帐。相反,在情景1中的定价查找服务是不可重用的因为信息内嵌在HTML页中了。总而言之,在情景2的模型中,在Web服务器通过回应HTML页面来处理HTTP请求(request),而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。警告(Caveats)XML Web Services已经使应用程序服务器和Web服务器的界线混淆了。通过传送一个XML有效载荷(payload)给服务器,Web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。另外,大多数应用程序服务器也包含了Web服务器,这就意味着可以把Web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了Web服务器的功能,但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注:这种功能是指既有应用程序服务器的功能又有Web服务器的功能)。相反,如果需要,他们通常会把Web服务器独立配置,和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的Web请求(request)就不会影响应用程序服务器了),分开配置(专门的Web服务器,集群(clustering)等等),而且给最佳产品的选取留有余地。
收起全文
精华内容
参与话题
  • web 服务器有哪些

    万次阅读 2018-08-27 16:53:49
    什么是web服务器 "网络服务"(Web Service)的本质,就是通过网络调用其他网站的资源。 Web Service架构和云 如果一个软件的主要部分采用了"网络服务",即它把存储或计算环节"外包"...

    <1>什么是web服务器

    "网络服务"(Web Service)的本质,就是通过网络调用其他网站的资源。

    Web Service架构和云

    如果一个软件的主要部分采用了"网络服务",即它把存储或计算环节"外包"给其他网站了,那么我们就说这个软件属于Web Service架构。

    Web Service架构的基本思想,就是尽量把非核心功能交给其他人去做,自己全力开发核心功能。比如,如果你要开发一个相册软件,完全可以使用Flickr的网络服务,把相片都储存到它上面,你只要全力做好相册本身就可以了。总体上看,凡是不属于你核心竞争力的功能,都应该把它"外包"出去。

    最近很红的"云计算"(cloud computing)或者"云服务"(cloud services),实际上就是Web Service的同义词,不过更形象一些罢了。它们不说你把事情交给其他计算机去做,而说你把事情交给"云"去做。

    Web Service的优势

    除了本地服务的缺点以外,Web Service还有以下的优越性:

    * 平台无关。不管你使用什么平台,都可以使用Web service。

    * 编程语言无关。只要遵守相关协议,就可以使用任意编程语言,向其他网站要求Web service。这大大增加了web service的适用性,降低了对程序员的要求。

    * 对于Web service提供者来说,部署、升级和维护Web service都非常单纯,不需要考虑客户端兼容问题,而且一次性就能完成。

    * 对于Web service使用者来说,可以轻易实现多种数据、多种服务的聚合(mashup),因此能够做出一些以前根本无法想像的事情。

    Web service的发展趋势

    根据我的观察,目前Web service有这样几种发展趋势。

    * 在使用方式上,RPC和soap的使用在减少,Restful架构占到了主导地位。

    * 在数据格式上,XML格式的使用在减少,json等轻量级格式的使用在增多。

    * 在设计架构上,越来越多的第三方软件让用户在客户端(即浏览器),直接与云端对话,不再使用第三方的服务器进行中转或处理数据。

    本地服务的缺陷

    "网络服务"是未来软件开发和使用的趋势,本地服务将用得越来越少,主要因为以下三个原因:

    * 本地资源不足。很多数据和资料,本地得不到,只有向其他网站要。

    * 成本因素。本地提供服务,往往是不经济的,使用专业网站的服务更便宜。这里面涉及硬件和人员两部分,即使你买得起硬件,专门找一个人管理系统,也是很麻烦的事。

    * 可移植性差。如果你想把本机的服务,移植到其他机器上,往往很困难,尤其是在跨平台的情况下。

    对本地服务,除非是大型局域网或者说ejb这类局域网协议访问,不然的话没啥意义

    现在市面上有面向过程、方面、模块化编程,当然最多的是应该是面向对象,

    与其说对象编程,不如说是类编程,软件即服务,若软件不能提供功能(接口方法),

    也就失去原本意义,它的灵活性,独立,跨平台、跨语言

    <2>web服务器有哪些

    WEB服务器也可以称为网站服务器,可以用来放置网站文件,供用户浏览。那么常见的WEB服务器有哪些呢?

    web服务器有哪些

    ①Apache

    Apache是世界使用排名的Web服务器软件。它几乎可以运行在所有的计算机平台上。由于Apache是开源免费的,因此有很多人参与到新功能的开发设计,不断对其进行完善。  Apache的特点是简单、速度快、性能稳定,并可做代理服务器来使用。

    ②IIS

    IIS(Internet信息服务)英文Internet Information  Server的缩写。它是微软公司主推的服务器。IIS的特点具有:安全性,强大,灵活。

    ③Nginx

    Nginx不仅是一个小巧且高效的HTTP服务器,也可以做一个高效的负载均衡反向代理,通过它接受用户的请求并分发到多个Mongrel进程可以极大提高Rails应用的并发能力。

    ④Tomcat

    Tomcat是Apache 软件基金会(Apache Software Foundation)的Jakarta  项目中的一个核心项目,由Apache、Sun 和其他一些公司及个人共同开发而成。Tomcat 技术先进、性能稳定,而且免费,因而深受Java  爱好者的喜爱并得到了部分软件开发商的认可,成为目前比较流行的Web 应用服务器。

    ⑤Lighttpd

    Lighttpd是由德国人 Jan Kneschke 领导开发的,基于BSD许可的开源WEB服务器软件,其根本的目的是提供一个专门针对高性能网站,安全、快速、兼容性好并且灵活的web  server环境。具有非常低的内存开销,CPU占用率低,效能好,以及丰富的模块等特点。支持FastCGI, CGI, Auth, 输出压缩(output  compress), URL重写, Alias等重要功能。

    ⑥Zeus

    Zeus是一个运行于Unix下的非常的Web 服务器,据说性能超过Apache,是效率的Web 服务器之一。


    <3>概念

    webserver 基本由这些组成

    • 绑定TCP端口,监听客户端(浏览器)请求
    • 处理客户端(浏览器)请求
    • 响应客户端(浏览器)请求

    Web服务器只负责处理HTTP协议,只能发送静态页面的内容。而JSP,ASP,PHP等动态内容需要通过CGI、FastCGI、ISAPI等接口交给其他程序去处理。这个其他程序就是应用服务器。
    比如Web服务器包括Nginx,Apache,IIS等。而应用服务器包括WebLogic,JBoss等。应用服务器一般也支持HTTP协议,因此界限没这么清晰。但是应用服务器的HTTP协议部分仅仅是支持,一般不会做特别优化,所以很少有见Tomcat直接暴露给外面,而是和Nginx、Apache等配合,只让Tomcat处理JSP和Servlet部分


    <4>web框架和web服务的区别

    web服务器(web server)的主要作用是,接收客户端请求,而web框架(web framework)则是处理web服务器收到的请求,并生成HTML内容,将生成的内容传递给web服务器,再由web服务器返回给客户端。

    服务器和客户端之间的连接靠web服务器来维持,web服务器接收到请求后,将请求以及相关的参数传递给web框架,由框架负责生成内容,并将生成的内容传递给web服务器。所以web服务器的职责是接受并返回请求,web服务器的职责是内容生成。

    对于Django这类的MVC 框架来说,面临的主要挑战是:易开发;对请求对象的完全访问;保持某种状态的能力;最重要的是能有写出业务级逻辑的方式。

    而对于 apache, tomcat, nginx这类web 服务器来说,面临的主要挑战是并行;和数以千计的用户同时保持连接(高并发);能够在一定时间内传送大量数据(吞吐量)。

    虽然Django这类的框架自带有web服务器,但是在面对以上挑战(高并发,吞吐量)时,性能太鸡肋,所以需要专门的web服务器。

     

    <5>原理

    web程序都运行在 TCP/IP 协议上,程序之间使用 socket(套接字) 进行通信,它能够让计算机之间的通信就像写文件和读文件一样简单。 一个 tcp socket 由一个IP地址和端口号组成。

    IP地址是一个32位的二进制数,通常被分割为4个“8位二进制数”,写成10进制的形式就是我们常见的 174.136.14.108。我们通过IP地址来标识所连接的主机。

    端口号是一个范围在0-65535之间的数字,一台主机上可能同时有多个sockets,因此需要端口号进行标识。端口号0-1023 是保留给操作系统使用的,我们可以使用剩下的端口号。

    超文本传输协议(HTTP)描述了一种程序之间交换数据的方法,它非常简单易用,在一个socket连接上,客户端首先发送请求说明它需要什么,然后服务器发送响应,并在响应中包含客户端的数据。响应数据也许是从本地磁盘上复制来的,也许是程序动态生成的。传输过程如图:

    HTTP请求就是一段文本,任何程序都能生成一个http请求,就像生成文本一样简单。这段文本需要包含以下这些部分:

    • HTTP method:HTTP请求方法。最常用的就是 GET(抓取数据)与POST(更新数据或者上传文件)
    • URL:通常是客户端请求的文件的路径,比如 /research/experiments.html, 但是是否响应文件都是由服务器决定的。
    • HTTP version:HTTP版本。通常是 HTTP/1.0 或 HTTP/1.1
    • header field:HTTP头的键值对,做一些基本设置,就像下面这样:
    #客户端接受的数据类型
    Accept: text/html
    #客户端接受的语言
    Accept-Language: en, fr         
    If-Modified-Since: 16-May-2005
    
    • body: 一些与请求有关的负载数据。比如在一个网站登陆的时候提交登陆表单,那负载数据就是你的账号与密码信息。

    HTTP响应的结构类似于请求:

    • status code:状态码。请求成功响应200,请求的文件找不到则响应404。
    • status phrase:对状态码的描述。

    <6>WEB服务器、应用程序服务器、HTTP服务器区别

      WEB服务器、应用程序服务器、HTTP服务器有何区别?IIS、Apache、Tomcat、Weblogic、WebSphere都各属于哪种服务器,这些问题困惑了很久,今天终于梳理清楚了:

        Web服务器的基本功能就是提供Web信息浏览服务。它只需支持HTTP协议、HTML文档格式及URL。与客户端的网络浏览器配合。因为Web服务器主要支持的协议就是HTTP,所以通常情况下HTTP服务器和WEB服务器是相等的(有没有支持除HTTP之外的协议的web服务器,作者没有考证过),说的是一回事。 

      应用程序服务器(简称应用服务器),我们先看一下微软对它的定义:"我们把应用程序服务器定义为“作为服务器执行共享业务应用程序的底层的系统软件”。 就像文件服务器为很多用户提供文件一样,应用程序服务器让多个用户可以同时使用应用程序(通常是客户创建的应用程序)"

      通俗的讲,Web服务器传送(serves)页面使浏览器可以浏览,然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点,你可以说:Web服务器专门处理HTTP请求(request),但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑 (business logic)。

      以Java EE为例,Web服务器主要是处理静态页面处理和作为 Servlet容器,解释和执行servlet/JSP,而应用服务器是运行业务逻辑的,主要是EJB、 JNDI和JMX API等J2EE API方面的,还包含事务处理、数据库连接等功能,所以在企业级应用中,应用服务器提供的功能比WEB服务器强大的多。

      以这样的定义,IIS、Apache、Tomcat都可以属于Web服务器,Weblogic、WebSphere都属于应用服务器。 

      Apache:在Web服务器中,Apache是纯粹的Web服务器,经常与Tomcat配对使用。它对HTML页面具有强大的解释能力,但是不能解释嵌入页面内的服务器端脚本代码(JSP/Servlet)。 

      Tomcat:早期的Tomcat是一个嵌入Apache内的JSP/Servlet解释引擎Apache+Tomcat就相当于IIS+ASP。后来的Tomcat已不再嵌入Apache内,Tomcat进程独立于Apache进程运行。 而且,Tomcat已经是一个独立的Servlet和JSP容器,业务逻辑层代码和界面交互层代码可以分离了。因此,有人把Tomcat叫做轻量级应用服务器。 

      IIS:微软早期的IIS,就是一个纯粹的Web服务器。后来,它嵌入了ASP引擎,可以解释VBScript和JScript服务器端代码了,这时,它就可以兼作应用服务器。当然,它与J2EE应用服务器根本无法相比,但是,从功能上说,从原理上说,它勉强可以称之为应用服务器。确切地说,它是兼有一点应用服务器功能的Web服务器。 

      综上:Apache是纯粹的web服务器,而Tomcat和IIS因为具有了解释执行服务器端代码的能力,可以称作为轻量级应用服务器或带有服务器功能的Web服务器。Weblogic、WebSphere因为能提供强大的J2EE功能,毫无疑问是绝对的应用服务器。对于处于中间位置的Tomcat,它可以配合纯Web服务器Apache一起使用,也可以作为应用服务器的辅助与应用服务器一起部署:

    一、Tomcat与应用服务器

       到目前为止,Tomcat一直被认为是Servlet/JSP API的执行器,也就所谓的Servlet容器。然而,Tomcat并不仅仅如此,它还提供了JNDI和JMX API的实现机制。尽管如此,Tomcat仍然还不能算是应用服务器,因为它不提供大多数J2EE API的支持。

      很有意思的是,目前许多的应用服务器通常把Tomcat作为它们Servlet和JSP API的容器。由于Tomcat允许开发者只需通过加入一行致谢,就可以把Tomcat嵌入到它们的应用中。遗憾的是,许多商业应用服务器并没有遵守此规则。

      对于开发者来说,如果是为了寻找利用Servlet、JSP、JNDI和JMX技术来生成Java Web应用的话,选择Tomcat是一个优秀的解决方案;但是为了寻找支持其他的J2EE API,那么寻找一个应用服务器或者把Tomcat作为应用服务器的辅助,将是一个不错的解决方案;第三种方式是找到独立的J2EE API实现,然后把它们跟Tomcat结合起来使用。虽然整合会带来相关的问题,但是这种方式是最为有效的。。

    二、Tomcat与Web服务器

      Tomcat是提供一个支持Servlet和JSP运行的容器。Servlet和JSP能根据实时需要,产生动态网页内容。而对于Web服务器来说, Apache仅仅支持静态网页,对于支持动态网页就会显得无能为力;Tomcat则既能为动态网页服务,同时也能为静态网页提供支持。尽管它没有通常的Web服务器快、功能也不如Web服务器丰富,但是Tomcat逐渐为支持静态内容不断扩充。大多数的Web服务器都是用底层语言编写如C,利用了相应平台的特征,因此用纯Java编写的Tomcat执行速度不可能与它们相提并论。

      一般来说,大的站点都是将Tomcat与Apache的结合,Apache负责接受所有来自客户端的HTTP请求,然后将Servlets和JSP的请求转发给Tomcat来处理。Tomcat完成处理后,将响应传回给Apache,最后Apache将响应返回给客户端。

      而且为了提高性能,可以一台apache连接多台tomcat实现负载平衡。 

      关于WEB服务器、应用程序服务器的更详细区别可以参考下面这篇文章: 

       通俗的讲,Web服务器传送(serves)页面使浏览器可以浏览,然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点,你可以说:Web服务器专门处理HTTP请求(request),但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑 (business logic)。  

      下面让我们来细细道来:

      Web服务器(Web Server) 

      Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request),会返回一个HTTP响应 (response),例如送回一个HTML页面。为了处理一个请求(request),Web服务器可以响应(response)一个静态页面或图片,进行页面跳转(redirect),或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本,JSP(JavaServer Pages)脚本,servlets,ASP(Active Server Pages)脚本,服务器端(server-side)JavaScript,或者一些其它的服务器端(server-side)技术。无论它们(译者注:脚本)的目的如何,这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。

      要知道,Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时,它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注:服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境,而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing),数据库连接(database connectivity)和消息(messaging)等功能。

      虽然Web服务器不支持事务处理或数据库连接池,但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability),例如负载平衡(load balancing),缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。

      应用程序服务器(The Application Server) 

      根据我们的定义,作为应用程序服务器,它通过各种协议,可以包括HTTP,把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向浏览器发送HTML以供浏览,而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法 (或过程语言中的一个函数)一样。

      应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反,这种信息就是程序逻辑(program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML,所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。

      在大多数情形下,应用程序服务器是通过组件 (component) 的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序)的,例如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外,应用程序服务器可以管理自己的资源,例如看大门的工作(gate-keeping duties)包括安全(security),事务处理(transaction processing),资源池(resource pooling),和消息(messaging)。就象Web服务器一样,应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。

    一个例子 

      例如,设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后,网站会进行查找(lookup)并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器 的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。

    情景1:不带应用程序服务器的Web服务器 

      在此种情景下,一个Web服务器独立提供在线商店的功能。Web服务器获得你的请求(request),然后发送给服务器端(server- side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file,译者注:flat file是指没有特殊格式的非二进制的文件,如properties和XML文件等)中查找定价信息。一旦找到,服务器端(server-side)程序把结果信息表示成(formulate)HTML形式,最后Web服务器把会它发送到你的Web浏览器。

    简而言之,Web服务器只是简单的通过响应(response)HTML页面来处理HTTP请求(request)。

    情景2:带应用程序服务器的Web服务器 

      情景2和情景1相同的是Web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注:服务器端 (server-side)程序)。然而,你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化,此脚本只是简单的调用应用程序服务器的查找服务(lookup service),而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生HTML响应(response)时就可以使用该服务的返回结果了。

      在此情景中,应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节,相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时,此服务只是简单的查找并返回结果给客户端。

      通过从响应产生(response-generating)HTML的代码中分离出来,在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端,例如收款机,也可以调用同样的服务(service)来作为一个店员给客户结帐。相反,在情景1中的定价查找服务是不可重用的因为信息内嵌在 HTML页中了。

      总而言之,在情景2的模型中,在Web服务器通过回应HTML页面来处理HTTP请求(request),而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。

    警告(Caveats)

      现在,XML Web Services已经使应用程序服务器和Web服务器的界线混淆了。通过传送一个XML有效载荷(payload)给服务器,Web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。

      另外,现在大多数应用程序服务器也包含了Web服务器,这就意味着可以把Web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了Web服务器的功能,但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注:这种功能是指既有应用程序服务器的功能又有Web服务器的功能)。相反,如果需要,他们通常会把Web服务器独立配置,和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的Web请求(request)就不会影响应用程序服务器了),分开配置(专门的Web服务器,集群(clustering)等等),而且给最佳产品的选取留有余地。

     

    <7>了解和简单的服务

    server 有两重意思

    1. 有时候 server 表示硬件,也就是一台机器。它还有另一个名字:「主机」。
    2. 更多时候,server 表示软件程序,这种程序主要用来对外提供某些服务,比如邮件服务、FTP 服务、数据库服务、网页服务等。

    作为开发者,我们说 server 的时候,一般指的后者,也就是一个 24 小时运行的软件程序。

    一台主机上面可以运行多个这样的程序。

    什么是 Web Server?

    顾名思义,Web Server 就是提供 Web 服务的 Server。

    比如我们访问 http:// http://baidu.com,其实就是在使用百度的 Server 提供的服务。

    一般来说, Web Server 对外提供的是 HTTP 服务(也可以是其他服务),这就是为什么我们的网址都以「http://」开头。

    如何提供 HTTP 服务?

    下面是有 Node.js 写的一个最简单的 HTTP server

    // 文件名 index.js
    // 使用 node index.js 可运行本程序
    
    var http = require('http')
    
    var server = http.createServer( function (request, response){
        response.end('这是页面内容,你请求的路径是:' + request.url)
    })
    
    server.listen(8080, function(){
        console.log("正在监听 %s 端口", 8080);
    });
    

    你不用看懂这段程序,你只需要知道两件事情:

    1. 这段程序监听了当前机器的 8080 端口。
    2. 一旦外部访问当前机器的 8080 端口,这段程序就会返回一段文字。

     

    这就是一个最简单的 HTTP server。

    分类

    提供 HTTP 服务的 server 分为两类。

    1. 静态文件服务器

    这种服务器简单地根据访问路径,返回对应的文件。

    比如用户访问 http:// 123.123.123.123:8080/a/b/c/d.html,那么这种服务器就会在网站根目录找到 a/b/c/d.html 文件,原样返回给用户。

    2. 动态内容服务器

    这种服务器返回的内容一般不是文件,而是动态生成的字符串(比如从数据库中获取的字符串)。

    比如用户访问 http:// http://weibo.com/home,那么这种 http://weibo.com 的服务器则会返回当前用户最新的微博消息。显然每个用户得到的内容是不一样的

     

    <8>app server和web server的区别

    app服务器和web服务器的区别是什么呢?

    简单来说,web服务器提供页面给浏览器,而app服务器提供客户端可以调用的接口。具体而言,我们可以说:

             Web服务器处理HTTP请求,而app服务器基于多种不同的协议,处理应用程序的逻辑问题。

     

    以下将详细介绍它们之间的区别。

    Web服务器

    web服务器处理HTTP协议。当收到一个HTTP请求之后,web服务器会返回一个HTTP响应,比如一个HTML页面。为了处理请求,它可能响应一个静态的HTML页面、图片、重定向,或者代理(delegate)其他动态响应。这些动态响应可以由其他程序生成,包括CGI脚本,JSPs,servlets,ASPs,服务器端的Javascript,或者其他服务器端技术。而这些服务器端程序响应,大多数时候都表现为HTML页面,供浏览器访问。

    理解一个web服务器的代理模型(delegate model)相对比较简单。当web服务器接收到一个请求,它只是简单的将请求交给处理该请求的最优程序。除了为服务器程序简单的提供一个运行环境(服务器程序可以在其中运行,并且返回生成的响应)之外,web服务器不提供任何功能。服务器程序一般自己处理交换(transaction)、数据库连接、消息分发等。

    虽然web服务器不提供以上的服务,但是它一般会提供诸如容错机制,负载均衡、缓存、集群等的可扩展性。而后者,一般来说不应该部署在web服务器上,而应该在app服务器上!

    App服务器

    根据我们的定义,app服务器可以基于各种不同的协议(可能包含HTTP协议),为客户端程序提供应用逻辑的处理。不同于web服务器主要发送用来展示在浏览器上的HTML页面,app服务器为客户端程序处理应用逻辑方面问题。应用程序使用这些逻辑,就如同调用一个对象的方法(或者面向过程编程中的函数)一样简单。

    这些应用程序可能包含PC机上运行的GUI进程,web服务器,甚至其他的app服务器。app服务器和客户端之间的通信并不局限于简单的显示标记,而是可以由程序逻辑,比如数据表单、方法调用,而非静态的HTML,这样,客户端程序就可以按需去用了!

    在大多数情况下,app服务器通过元件API,比如基于j2ee app服务器的EJB,来提供应用逻辑。而更多的情况下,app服务器自己管理自己的资源。这些责任(gate-keeping)包括安全、进程交互、资源池、消息分发等。同web服务器一样,app服务器也可能需要各种可扩展性和容错机制。

    一个例子

    以一个提供实时价格和相关信息的在线商店为例,它极有可能提供了一个表单,用户可以选择不同的产品并查询。它会查找,并通过HTML网页展示结果。这个网站可能有多种方式来实现这个功能,下面我们将举两个相反的例子,一个不使用app服务器,而另一个使用。通过这两个例子,可以帮助你理解app服务器的功能。

    场景1:web服务器,而非app服务器

    在这个场景里,web服务器独自提供在线商店的功能。它接受用户的请求,交给服务器端程序处理。该服务器端程序通过数据库,或者纯文本,查找到价格信息,然后生成HTML响应,通过web服务器返回给用户的浏览器。

    总结来说,web服务器仅需要接受HTTP请求,并响应HTML网页。

     

    场景2: web服务器 + app服务器

    同场景1一样,web服务器仍然代理脚本生成的响应。但是你可以把业务逻辑部署在app服务器上。这样,脚本就不需要去关注怎样查询和生成响应,而仅需要调用app服务器提供查询服务,从而利用其生成它的HTML响应。

    在这个例子中,app服务器提供了价格查询的业务逻辑。这个逻辑不应该包含怎样去展示,或者强迫客户端使用这些数据。相反的是,客户端和app服务器进行交互,只有当客户端调用了app服务器的价格查询服务的时候,该服务才查找到信息并返回。

    同HTML代码生成分离开后,价格查询逻辑的复用性提高了。另外一个客户端,比如收银机,同样可以调用这个接口。而场景1里,价格查询服务就很难被重用,因为它和HTML页面紧密联系。

    总结来说,第二个场景中,web服务器处理HTTP请求,并返回HTML页面,而app服务器处理业务逻辑。

    注意事项

    近来,XML web服务器模糊了app服务器和web服务器的界限。发送一个XML请求给web服务器,web服务器可以像过去的app服务器一样,处理数据并返回响应。

    另外,很多app服务器包含web服务器,这就意味着你可以把web服务器看做app服务器的一个子集。虽然app服务器包含web服务器的功能,但是开发者还是很少以此身份发布app服务器。如果需要的话,他们通常将web服务器和app服务器分离开。这样的目的是,性能(简单的web请求不会影响到app服务器的性能)、发布配置(专用的web服务器,集群等)、更好的厂商选择。

     

    <9>应用服务器和web服务器

    Web服务器的基本功能就是提供Web信息浏览服务。它只需支持HTTP协议、HTML文档格式及URL。与客户端的网络浏览器配合。因为Web服务器主 要支持的协议就是HTTP,所以通常情况下HTTP服务器和WEB服务器是相等的。

    以这样的定义,IIS、Apache、Tomcat都可以属于Web服务器

           Web服务器(Web Server)可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request),会返回一个HTTP响应 (response),例如送回一个HTML页面。为了处理一个请求(request),Web服务器可以响应(response)一个静态页面或图片, 进行页面跳转(redirect),或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本,JSP(JavaServer Pages)脚本,servlets,ASP(Active Server Pages)脚本,服务器端(server-side)JavaScript,或者一些其它的服务器端(server-side)技术。无论它们(译者 注:脚本)的目的如何,这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。

           要知道,Web服务器的代理模型(delegationmodel)非常简单。当一个请求(request)被送到Web服务器里来时,它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注:服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响 应(response)的环境,而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing),数据库连接(database connectivity)和消息(messaging)等功能。

           虽然Web 服务器不支持事务处理或数据库连接池,但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability),例如负载平衡(load balancing),缓冲(caching)。集群特征(clustering-features)经常被误认为仅仅是应用程序服务器专有的特征。

    应用服务器(The Application Server)

            微软给定义为:我们把应用程序服务器定义为“作为服务器执行共享业务应用程序的底层的系统软件。

    根据定义,作为应用程序服务器,它通过各种协议,可以包括HTTP,把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向 浏览器发送HTML以供浏览,而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就像你调用对象的一个方法(或过程 语言中的一个函数)一样。

           应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至 是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反,这种信息就是程序逻辑(program logic)。 正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML,所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。

           在大多数情形下,应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序)的,例 如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外,应用程序服务器可以管理自己的资源,例如看大门的工作(gate-keepingduties)包括安全(security),事务处理(transaction processing),资源池(resource pooling), 和消息(messaging)。就象Web服务器一样,应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。

      以这样的定义,Weblogic、WebSphere都属于应用服务器。

           Apache:在Web服务器中,Apache是纯粹的Web服务器,经常与Tomcat配对使用。它对HTML页面具有强大的解释能力,但是不能解释嵌入页面内的服务器端脚本代码(JSP/Servlet)。

           Tomcat:早期的Tomcat是一个嵌入Apache内的JSP/Servlet解释引擎Apache+Tomcat就相当于IIS+ASP。后来的 Tomcat已不再嵌入Apache内,Tomcat进程独立于Apache进程运行。 而且,Tomcat已经是一个独立的Servlet和JSP容器,业务逻辑层代码和界面交互层代码可以分离了。因此,有人把Tomcat叫做轻量级应用服务器。

            IIS:微软早期的IIS,就是一个纯粹的Web服务器。后来,它嵌入了ASP引擎,可以解释VBScript和JScript服务器端代码了,这时,它 就可以兼作应用服务器。当然,它与J2EE应用服务器根本无法相比,但是,从功能上说,从原理上说,它勉强可以称之为应用服务器。确切地说,它是兼有一点应用服务器功能的Web服务器。

           综上:Apache是纯粹的web服务器,而Tomcat和IIS因为具有了解释执行服务器端代码的能力,可以称作为轻量级应用服务器或带有服务器功能的Web服务器。 Weblogic、WebSphere因为能提供强大的J2EE功能,毫无疑问是绝对的应用服务器。对于处于中间位置的Tomcat,它可以配合纯Web服务器Apache一起使用,也可以作为应用服务器的辅助与应用服务器一起部署。

     

    常见的web服务器: (其实IIS和Apache同时也支持基础的应用服务器的功能)

      Microsoft IIS

      Microsoft的Web服务器产品为Internet Information Server (IIS), IIS 是允许在公共Intranet或Internet上发布信息的Web服务器。IIS是目前最流行的Web服务器产品之一,很多著名的网站都是建立在IIS 的平台上。IIS提供了一个图形界面的管理工具,称为 Internet服务管理器,可用于监视配置和控制Internet服务。

      IIS是一种Web服务组件,其中包括Web服务器、FTP服务器、NNTP服务器和SMTP服务器, 分别用于网页浏览、文件传输、新闻服务和邮件发送等方面,它使得在网络(包括互联网和局域网)上发布信息成了一件很容易的事。它提供 ISAPI(Intranet Server API)作为扩展Web服务器功能的编程接口;同时,它还提供一个Internet数据库连接器,可以实现对数据库的查询和更新。

           Apache

           Apache 源于NCSAhttpd服务器,经过多次修改,成为世界上最流行的Web服务器软件之一。 Apache是自由软件,所以不断有人来为它开发新的功能、新的特性、修改原来的缺陷。Apache的特点是简单、速度快、性能稳定,并可做代理服务器来 使用。本来它只用于小型或试验Internet网络,后来逐步扩充到各种Unix系统中,尤其对Linux的支持相当完美。

       Apache是以进程为基础的结构,进程要比线程消耗更多的系统开支,不太适合于多处理器环境,因此, 在一个Apache Web站点扩容时,通常是增加服务器或扩充群集节点而不是增加处理器。到目前为止Apache仍然是世界上用的最多的Web服务器,世界上很多著名的网站 都是Apache的产物,它的成功之处主要在于它的源代码开放、有一支开放的开发队伍、支持跨平台的应用(可以运行在几乎所有的Unix、 Windows、Linux系统平台上)以及它的可移植性等方面。

    常见的应用服务器:

      IBM WebSphere

      WebSphere Application Server 是一 种功能完善、开放的Web应用程序服务器,是IBM电子商务计划的核心部分,它是基于 Java 的应用环境,用于建立、部署和管理 Internet 和 Intranet Web 应用程序。 这一整套产品进行了扩展,以适应 Web 应用程序服务器的需要,范围从简单到高级直到企业级。

      WebSphere 针对以 Web 为中心的开发人员,他们都是在基本 HTTP服务器和 CGI 编程技术上成长起来的。IBM 将提供 WebSphere 产品系列,通过提供综合资源、可重复使用的组件、功能强大并易于使用的工具、以及支持 HTTP 和 IIOP 通信的可伸缩运行时环境,来帮助这些用户从简单的 Web 应用程序转移到电子商务世界。

      BEA WebLogic

      BEA WebLogic Server 是一种多功能、基于标准的web应用服务器,为企业构建自己的应用提供了坚实的基础。各种应用开发、部署所有关键性的任务,无论是集成各种系统和数据库,还是提交服务、跨 Internet 协作,起始点都是 BEA WebLogic Server。由于 它具有全面的功能、对开放标准的遵从性、多层架构、支持基于组件的开发,基于 Internet 的企业都选择它来开发、部署最佳的应用。

      BEA WebLogic Server 在使应用服务器成为企业应用架构的基础方面继续处于领先地位。BEA WebLogic Server 为构建集成化的企业级应用提供了稳固的基础,它们以 Internet 的容量和速度,在连网的企业之间共享信息、提交服务,实现协作自动化。BEA WebLogic Server 的遵从 J2EE 、面向服务的架构,以及丰富的工具集支持,便于实现业务逻辑、数据和表达的分离,提供开发和部署各种业务驱动应用所必需的底层核心功能。现在已经归于Oracle所有。

      IPlanet Application

      IPlanet Application Server作为Sun与Netscape联盟产物的iPlanet公司生产的iPlanet Application Server 满足最新J2EE规范的要求。它是一种完整的WEB服务器应用解决方案,它允许企业以便捷的方式,开发、部署和管理关键任务Internet 应用。该解决方案集高性能、高度可伸缩和高度可用性于一体,可以支持大量的具有多种客户机类型与数据源的事务。

      iPlanet Application Server的基本核心服务包括事务监控器、多负载平衡选项、对集群和故障转移全面的支持、集成的XML 解析器和可扩展格式语言转换(XLST)引擎以及对国际化的全面支持。iPlanet ApplicationServer 企业版所提供的全部特性和功能,并得益于J2EE系统构架,拥有更好的商业工作流程管理工具和应用集成功能。

      Oracle IAS

      Oracle iAS的英文全称是Oracle Internet Application Server,即Internet应用服务器,Oracle iAS是基于Java的应用服务器,通过与Oracle数据库等产品的结合,OracleiAS能够满足Internet应用对可靠性、可用性和可伸缩性的要求。

      Oracle iAS最大的优势是其集成性和通用性,它是一个集成的、通用的中间件产品。在集成性方面,Oracle iAS将业界最流行的HTTP服务器Apache集成到系统中,集成了Apache的Oracle iAS通信服务层可以处理多种客户请求,包括来自Web浏览器、胖客户端和手持设备的请求,并且根据请求的具体内容,将它们分发给不同的应用服务进行处 理。在通用性方面,Oracle iAS支持各种业界标准,包括 JavaBeans、CORBA、Servlets以及XML标准等,这种对标准的全面支持使得用户很容易将在其他系统平台上开发的应用移植到 Oracle平台上。

      Tomcat

      Tomcat是一个开放源代码、运行servlet和JSP Web应用软件的基于Java的Web应用软件容器。Tomcat Server是根据servlet和JSP规范进行执行的,因此我们就可以说Tomcat Server也实行了Apache-Jakarta规范且比绝大多数商业应用软件服务器要好。

      Tomcat是Java Servlet2.2和JavaServerPages 1.1技术的标准实现,是基于Apache许可证下开发的自由软件。Tomcat是完全重写的Servlet API 2.2和JSP 1.1兼容的Servlet/JSP容器。Tomcat使用了JServ的一些代码,特别是Apache服务适配器。随着Catalina Servlet引擎的出现,Tomcat第四版号的性能得到提升,使得它成为一个值得考虑的Servlet/JSP容器,因此目前许多WEB服务器都是采用Tomcat。

     

     

     

     

     

     

     

    展开全文
  • 基于HTTP实现的小型web服务器

    千次阅读 2018-09-12 22:26:09
    主要流程为:服务器获得请求–&gt;响应并处理请求–&gt;返回结果。 完整的HTTP过渡到TCP实现客户端与服务器的交互过程 1.当客户端执行网络请求的时候,从url中解析出url的主机名,并将主机地址转换成ip 2....

    主要流程为:服务器获得请求–>响应并处理请求–>返回结果。

    完整的HTTP过渡到TCP实现客户端与服务器的交互过程
    1.当客户端执行网络请求的时候,从url中解析出url的主机名,并将主机地址转换成ip
    2.从url解析出服务器的所用端口号
    3.客户端用TCP连接服务器
    4.连接成功后 获取输出流,将数据以报文的形式传递给服务器
    5.当服务器接收到数据之后,进行判断和解析码,并回应一条响应报文
    6.客户端从输入流中获取报文,然后进行解析
    7.关闭网络连接

    HTTP的特点


    1、支持客户端/服务器的模式
    2、简单快捷 客户向服务器发送请求服务时,只需要传送请求方法和路径,每种方法规定了客户与服务器联系的类型的不同,由于HTTP协议简单,使得HTTP服务器的规模小,因此通信速度很快.
    3、灵活  允许传送各种类型的数据,数据类型用Content-Type标记
    4、无连接:限制每次连接只处理一个请求,服务器处理完客户的请求,收到客户的应答后,随即断开连接,这种方式节省传输时间,请求应答机制会断开
    5、无状态  HTTP协议是无状态的协议,即对事务处理没有记忆功能

    关于URL


    即统一资源定位符,每个网页都对应一个URL地址(俗称网址),具有全球唯一性。它包含的信息指出文件的位置以及浏览器应该怎么处理它。 一个完整的URL包括协议类型、主机类型、路径和文件名。 
    http协议的URL格式: http: //host[:port][abs_path] ,http表示使用http协议来进行资源定位;host是主机域名;port是端口号,一般有默认的;abs_path代表资源的路径。 
    这里我主要介绍项目中涉及的URL的两种格式—URL带参数和不带参数的。

    HTTP的请求与响应格式


    响应报头中的状态码和状态码描述,例如:当请求的资源不存在时,会收到“404 NotFound”的页面,404就是状态码,“NotFound”就是状态码描述,即请求的文件不存在。

    1.实现支持GET和POST方法的小型http服务器
    GET方法:如果GET方法只是简单的请求一份资源,而不传递参数的话则由服务器直接将资源返回即可。如果GET方法的url中带有参数的话,则就要使用CGI模式进行处理。 
    POST方法:POST方法要使用CGI模式进行处理,POST的参数在消息中文中出现。
    使用GET方法使用的是带参数的url,传递的参数会使用?连接在资源后面POST方法使用的是不带参数的url 它的参数是通过http请求正文传递给服务器的,http的请求和响应模式


    响应报头中的状态码和状态码描述,举个例子,当请求的资源不存在的时,会收到"404 NotFound"的页面,404就是状态码,

    "NotFound"就是状态码描述,既请求的文件不存在

    状态码表示响应类型

    1×× 保留

    2×× 表示请求成功地接收

    3×× 为完成请求客户需进一步细化请求

    4×× 客户错误

    5×× 服务器错误 

    响应头的信息包括:服务程序名,通知客户请求的URL需要认证,请求的资源何时能使用

     

    HTTP服务器实现框架


    1.面向链接:http协议是基于TCP通信协议,因此实现web服务器的第一步至少要能实现两个主机不同进程之间的TCP通信,并且需要解决高并发问题所以这里推荐使用多线程服务器来构建,每次创建出来一个新线程出来的时候将线程分离,然后让这个新线程去处理这个请求.
    2.分析出请求行: 当服务器接收到请求后,首先知道的是HTTP服务器版本号,和请求方法。web服务器是要支持cgi模式: 请求的方法不同,cgi可能也不同,我们实现的知识比较简单单的处理GET和POST方法
    3.判断cgi模式
    //    1)当我们判断出来是GET请求时候,并且url中没有参数的话,就用非CGI模式,非CGI模式处理//起来比较简单,首先解析出来请求路径,判断是不是合法资源,如果是就直接返回这个资源。
    //    2)当是CGI模式处理请求的时候,我们要fork一个子进程,对子进程exec替换CGI程序,这个
    //过程中使用pipe进行父子进程之间的通信。所有需要的参数在exec之前,都将这些参数导出为环境变//量,就算exec的话,子进程还是能够通过环境变量获取所需的参数。
    4.响应客户端:此时我们已经知道了方法以及是否为cgi模式,然后开始读取URL,这里有一个细节非cgi模式 请求参数会跟在url当中,如果cgi模式的话,参数在消息正文中,然后我们读取到路径,判断路径当中资源是否存在,如果存在判断这个资源是一个目录,普通文件还是一个可执行程序

    这里分情况分析
        1)如果是cgi模式,直接进入cgi内部运行;只要是POST方法就需要支持cgi,直接进入cgi函数内部运行.
        2)如果是非cgi模式时一定是GET方法并且没有参数,此时进入wwwroot()函数内部即可,该函数会将所请求的资源以html的格式返回给浏览器.

     

    接下来是解释运行cgi模式,首先服务器要从浏览器读取参数,然后创建出来一个子进程去执行cgi部分的可执行资源,父进程通过环境变量的方式传递给子进程,子进程运行完成之后呢,将结果交给父进程,父进程再将数据输出给浏览器. 所以父进程在这个例子当中就向是一个中介,只进行参数和结果的转交实际上并不会执行任何资源,因此将子进程的输入输出文件描述符重定向,就可以让子进程直接与浏览器"联系".



    父进程做的事情

    1. 1.创建两个管道,并关闭相应的文件描述符 
    2. 2.POST方法:继续读取数据,直到读完POST的参数部分GET方法:直接从子进程读取结果
    3. 3.将数据和方法全部交给子进程后等待子进程的结果

    子进程做的事情

    1. 1.关闭管道适当的文件描述符
    2. 2.对标准输入输出进行重定向
    3. 3.通过环境变量传递参数
    4. 4.进行exec程序替换

     

    一次完整的http请求的流程

    项目文件

    目录: 
    python:爬取小说和招聘信息的代码

    sql_connect:存放mysql需要的lib库   连接mysql程序文件
    wwwroot:web服务器工作的根目录,包含各种资源页面(例如默认的index.html页面,差错处理的404页面),以及执行cgi的可执行程序

    文件: 

    makefile:编译整个项目
    httpd.h:服务器的方法声明 
    httpd.c:方法实现 
    main.c:服务器的主逻辑

     

    数据库中的操作
    没有索引的时候会进行整个表的扫描
    添加索引 索引会形成一颗二叉树  利用二分查找的方法。

    遇到的问题:
    1.运行cgi后不能显示在页面上,便尝试着写一个简单的CGI程序看自己的CGI是否真的能跑完,结果CGI没有问题,后来尝试用telnet工具模拟一次http,看看是否真的收到了网页回复,后来分析结果,对比之后发现返回的东西不能显示,之后给html加了一些p标签,便可以显示出来。
    2. 经常会出现类似于:undefined reference to `sql_connecter::~sql_connecter()'的问题,文件编译的路径不对。
    3.调用数据库的数据显示到html文件中出现乱码的问题,最初以为自己编码格式有问题,后来发现是数据库编码格式和浏览器的编码格式不一样,数据库使用utf8编码方式,浏览器是GB2312,后来浏览器使用utf8编码格式,能够正常显示。

    4.代码中会需要int *和 void*的转换,用到C++强制转换形如  int*  data = reinterpret_cast<int*>(arg);

    5.本地环回测试ok,Linux下的浏览器测试也可以,但不能接外部的浏览器访问(没有设置桥接模式) 在外部浏览器测试的话千万别忘记关闭防火墙 

    6.运行程序时会提醒挺行下载页面,因为在响应报头有问题中。而浏览器对于不能识别或解析的实体,都会提醒用户下载。

    展开全文
  • Web服务器工作原理详解(基础篇)

    万次阅读 多人点赞 2018-09-18 16:39:04
    概述:Web服务器概念较为广泛,我们最常说的Web服务器指的是网站服务器,它是建立在Internet之上并且驻留在某种计算机上的程序。Web服务器可以向Web客户端(如浏览器)提供文档或其他服务,只要是遵循HTTP协议而设计的...

    概述:Web服务器概念较为广泛,我们最常说的Web服务器指的是网站服务器,它是建立在Internet之上并且驻留在某种计算机上的程序。Web服务器可以向Web客户端(如浏览器)提供文档或其他服务,只要是遵循HTTP协议而设计的网络应用程序都可以是Web客户端。

    Web服务器和HTTP服务器可以说是同一个东西,当然非得细分的话,HTTP服务器是建立在HTTP协议之上的提供文档浏览的服务器,更多的是提供静态的文件。而Web服务器涵盖了HTTP服务器(这一点可以自行百度百科), Web服务器不仅能够存储信息,还能在用户通过Web浏览器提供的信息的基础上运行脚本和程序。
    Web服务器 约等于 HTTP服务器 + 其他服务

    目前所熟知的Web服务器有很多,其最主流的是 Apache, Nginx, IIS
    各大Web服务器的实现细节都不同,是为了某种情形而设计开发的。但是它们的基础工作原理是相同的,这也是本次基础篇所讲解的内容。

    一、Web服务器工作原理图解

    这里写图片描述
    首先我们暂时不考虑HTTP协议的各种请求方式,我们先跟着**(Web服务器工作原理总体描述01)这张图,将一次Web服务的工作流程过一遍,我们假设以浏览器作为客户端
    (1) 用户做出了一个操作,可以是填写网址敲回车,可以是点击链接,可以是点击按键等,接着浏览器获取了该事件。
    (2) 浏览器与对端服务程序建立TCP连接。
    (3) 浏览器将用户的事件
    按照HTTP协议格式**打包成一个数据包,其实质就是在待发送缓冲区中的一段有着HTTP协议格式的字节流。
    (4) 浏览器确认对端可写,并将该数据包推入Internet,该包经过网络最终递交到对端服务程序。
    (5) 服务端程序拿到该数据包后,同样以HTTP协议格式解包,然后解析客户端的意图。
    (6) 得知客户端意图后,进行分类处理,或是提供某种文件、或是处理数据。
    (7) 将结果装入缓冲区,或是HTML文件、或是一张图片等。
    (8) 按照HTTP协议格式将(7)中的数据打包
    (9) 服务器确认对端可写,并将该数据包推入Internet,该包经过网络最终递交到客户端。
    (10) 浏览器拿到包后,以HTTP协议格式解包,然后解析数据,假设是HTML文件。
    (11) 浏览器将HTML文件展示在页面
    以上为Web服务器工作基本原理。其实不难发现,这仅仅只是一个简单的网络通信。我们应该深信,作为一个服务器,其根本的工作无非有三个

    1. 接收数据 2. 发送数据 3. 数据处理
      而Web服务器的本质就是 接收数据 ⇒ HTTP解析 ⇒ 逻辑处理 ⇒ HTTP封包 ⇒ 发送数据
      高级的服务器无非就是将这三个部分更加细致的设计了。

    二、Web服务器之提供静态文件工作原理图解

    Web服务器最主要的功能是提供静态的文件。日常的上网浏览大多是网页浏览,少数时候才会有一些数据的提交操作。因此,我们结合上一张图示来重点讲解在GET请求下的Web服务器工作原理。
    这里写图片描述
    其他流程基本不变,着重在于红色与蓝色部分。
    (1) 当用户点击一个网页链接或浏览器加载一些资源(css,jpg …)时产生。
    (6) 服务程序解包后,确定其为GET请求,并且是对该服务器上的某一资源的请求。首先服务程序会去确认该路径是否存在,再确定该路径的文件是否可以获取。
    (7-1) 如果请求的路径有误,或者该资源不能被用户获取,则返回错误提示页面。很多服务器的错误页面只有404,更专业的应该是将错误分类并返回对应的错误代码页面。
    (7-2) 如果该路径合法且文件可以被获取,那么服务程序将根据该文件类型进行不同的装载过程,记录其类型作为(8)中HTTP协议中对应的返回类型,并加入响应头。

    假设以点击一个页面链接为例,浏览器首先将HTML文件请求过来,再以同样的流程对HTML文件中包含的资源文件路径进行依次请求。
    这里写图片描述

    三、Web服务器之数据提交工作原理图解

    仅仅只是网页的浏览并不能满足所有人的需求,客户端与服务器应当是有数据交互的。
    即使单方面的资源请求任然是网络的主力军。
    我们应该清楚的知道,数据提交对于用户来说有什么作用。
    (1) 资源上传 (2) 登陆验证 (3) API接口调用 (4) 远程指令等
    数据提交使得用户的操作性有了质的飞跃,它使得HTTP短连接获取静态文件的方式提升到了动态交互的层次上。该性质也催化出各式各样的编程语言、框架。例如PHP,JavaWeb。
    如果你留意目前主流的那些大型服务器,你会发现再高级再牛逼的东西实际是也是最基础的东西建造的。那么我们还可以顺便学习一下最古老的动态技术CGI
    这里写图片描述
    其他流程基本不变,着重在于红色与蓝色部分。
    (1) 用户提交数据,假设用户点击一个按键提交填好的信息。在(3)中将以POST格式写入,并填入提交至服务端的可执行程序的路径。
    (6) 服务端将参数与该CGI绑定,复制进程,用管道传递参数和接收结果
    (7) 子进程执行CGI,接收(6)父进程传来的参数,运算完成返回结果。
    最后父进程将结果装入静态模板文件,放入缓冲区

    四、动态技术

    我们得明白,Web服务器是以短连接为主,并且获取的数据到达浏览器的那一刻一定是静态的不变的。那么所谓动态实际是指两种情况

    1. 服务端产生
      (1) 用户POST提交数据到某个程序,程序根据该数据作为参数运行,得出结果并装入静态的模板页面中,返回该静态页面。但对于用户来说,同一个页面,做了一个操作后数据不一样了。好了,这就是动态页面。(CGI原理)
      (2) PHP的原理是,用户GET请求一个php后缀的文件,服务器先执行该php后缀文件中的PHP代码,将结果填入代码的位置,再返回。当然也可以提交数据参与运算再返回。
    2. 客户端产生
      (1) 用户GET请求一个JavaScript文件,服务端不做任何运算返回该静态文件。浏览器收到该JS文件,在本地执行并更新页面。
      (2) 用户POST提交数据到服务端,服务端根据该提交的数据指令返回静态文件,浏览器收到后执行并更新。
    展开全文
  • HTTP的WEB服务器做了些什么?

    千次阅读 2018-11-10 09:57:37
    Web服务器的实现 Web 服务器实现了 HTTP 和相关的 TCP 连接处理。 负责管理 Web 服务器提供的资 源, 以及对 Web 服务器的配置、 控制及扩展方面的管理。 Web 服务器逻辑实现了 HTTP 协议、 管理着 Web 资源, 并...

    Web服务器的实现

    Web 服务器实现了 HTTP 和相关的 TCP 连接处理。 负责管理 Web 服务器提供的资源, 以及对 Web 服务器的配置、 控制及扩展方面的管理。

    Web 服务器逻辑实现了 HTTP 协议、 管理着 Web 资源, 并负责提供 Web 服务器的管理功能。 Web 服务器逻辑和操作系统共同负责管理 TCP 连接。 底层操作系统负责管理底层计算机系统的硬件细节, 并提供了 TCP/IP 网络支持、 负责装载 Web 资源的文件系统以及控制当前计算活动的进程管理功能。

    Web 服务器有各种不同的形式。

    • 可以在标准的计算机系统上安装并运行通用的软件 Web 服务器。
    • 如果不想那么麻烦地去安装软件, 可以买一台 Web 服务器设备, 通常会是一台安装在时髦机架上的计算机, 里面的软件会预装并配置好。
    • 随着微处理器奇迹般地出现, 有些公司甚至可以在少量计算机芯片上实现嵌入式Web 服务器, 使其成为完美的(便携式) 消费类设备管理控制台。

    Web服务器设备

    Web 服务器设备(Web server appliance) 是预先打包好的软硬件解决方案。 厂商会在他们选择的计算机平台上预先安装好软件服务器, 并将软件配置好。

    下面是一些Web 服务器设备的例子:

    • Sun/Cobalt RaQ Web 设备(http://www.cobalt.com) ;
    • 东芝的 Magnia SG10(http://www.toshiba.com);
    • IBM 的 Whistle Web 服务器设备(http://www.whistle.com)。
      应用解决方案不再需要安装及配置软件, 通常可以极大地简化管理工作。 但是,Web 服务器通常不太灵活, 特性不太丰富, 而且服务器硬件也不太容易重用或升级

    嵌入式Web服务器

    嵌入式服务器(embeded server) 是要嵌入到消费类产品(比如打印机或家用设备)中去的小型 Web 服务器。 嵌入式 Web 服务器允许用户通过便捷的 Web 浏览器接口来管理其消费者设备。 有些嵌入式 Web 服务器甚至可以在小于一平方英寸的空间内实现, 但通常只能提供最小特性功能集。

    下面是两种非常小的嵌入式 Web 服务器实例:

    实际的Web服务器会做些什么

    (1) 建立连接——接受一个客户端连接, 或者如果不希望与这个客户端建立连接, 就
    将其关闭。
    (2) 接收请求——从网络中读取一条 HTTP 请求报文。
    (3) 处理请求——对请求报文进行解释, 并采取行动。
    (4) 访问资源——访问报文中指定的资源。
    (5) 构建响应——创建带有正确首部的 HTTP 响应报文。
    (6) 发送响应——将响应回送给客户端。
    (7) 记录事务处理过程——将与已完成事务有关的内容记录在一个日志文件中。

    image

    第一步——接受客户端连接

    处理新连接

    客户端请求一条到 Web 服务器的 TCP 连接时, Web 服务器会建立连接, 判断连接的另一端是哪个客户端, 从 TCP 连接中将 IP 地址解析出来。一旦新连接建立起来并被接受, 服务器就会将新连接添加到其现存 Web 服务器连接列表中, 做好监视连接上数据传输的准备。

    Web 服务器可以随意拒绝或立即关闭任意一条连接。 有些 Web 服务器会因为客户
    端 IP 地址或主机名是未认证的, 或者因为它是已知的恶意客户端而关闭连接。 Web
    服务器也可以使用其他识别技术。

    客户端主机名识别

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

    可以用配置指令 HostnameLookups 启用 Apache 的主机查找功能。 比如, 例 5-2 中
    的 Apache 配置指令就只打开了 HTML 和 CGI 资源的主机名解析功能。

    配置 Apache, 为 HTML 和 CGI 资源查找主机名

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

    通过ident确定客户端用户

    有些 Web 服务器还支持 IETF 的 ident 协议。 服务器可以通过 ident 协议找到发起
    HTTP 连接的用户名。 这些信息对 Web 服务器的日志记录特别有用——流行的通用
    日志格式(Common Log Format) 的第二个字段中就包含了每条 HTTP 请求的 ident
    用户名

    如果客户端支持 ident 协议, 就在 TCP 端口 113 上监听 ident 请求。 下图说明了ident 协议是如何工作的。 在下图a 中, 客户端打开了一条 HTTP 连接。 然后, 服务器打开自己到客户端 ident 服务器端口(113) 的连接, 发送一条简单的请求, 询问与(由客户端和服务器端口号指定的) 新连接相对应的用户名, 并从客户端解析出包含用户名的响应

    image

    ident 在组织内部可以很好地工作, 但出于多种原因, 在公共因特网上并不能很好地工作, 原因包括:

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

    可以通过 Apache 的 IdentityCheck on 指令告知 Apache Web 服务器使用 ident 查找功能。 如果没有 ident 信息可用, Apache 会用连字符(-) 来填充 ident 日志字段。由于没有 ident 信息可用, 在使用通用日志格式的日志文件中, 第二个字段通常都是连字符

    第二步——接收请求报文

    连接上有数据到达时, Web 服务器会从网络连接中读取数据, 并将请求报文中的内容解析出来

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

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

    image(从连接中读取请求报文)

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

    报文的内部表示法

    有些 Web 服务器还会用便于进行报文操作的内部数据结构来存储请求报文。 比如,数据结构中可能包含有指向请求报文中各个片段的指针及其长度, 这样就可以将这些首部存放在一个快速查询表中, 以便快速访问特定首部的具体值了(参考下图)
    image (将请求报文解析为便捷的内部表示形式)

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

    高性能的 Web 服务器能够同时支持数千条连接。 这些连接使得服务器可以与世界各地的客户端进行通信, 每个客户端都向服务器打开了一条或多条连接。 某些连接可能在快速地向 Web 服务器发送请求, 而其他一些连接则可能在慢慢发送, 或者不经常发送请求, 还有一些可能是空闲的, 安静地等待着将来可能出现的动作。

    因为请求可能会在任意时刻到达, 所以 Web 服务器会不停地观察有无新的 Web 请求。 不同的 Web 服务器结构会以不同的方式为请求服务, 如图所示

    • 单线程 Web 服务器(参见图a)
      单线程的 Web 服务器一次只处理一个请求, 直到其完成为止。 一个事务处理结束之后, 才去处理下一条连接。 这种结构易于实现, 但在处理过程中, 所有其他连接都会被忽略。 这样会造成严重的性能问题, 只适用于低负荷的服务器, 以及type-o-serve 这样的诊断工具

    • 多进程及多线程 Web 服务器(参见图b)
      多进程和多线程 Web 服务器用多个进程,或更高效的线程同时对请求进行处理。可以根据需要创建, 或者预先创建一些线程 / 进程。 6 有些服务器会为每条连接分配一个线程 / 进程, 但当服务器同时要处理成百、 上千, 甚至数以万计的连接时,需要的进程或线程数量可能会消耗太多的内存或系统资源。 因此, 很多多线程 Web 服务器都会对线程 / 进程的最大数量进行限制

    • 复用 I/O 的服务器(参见图c)
      为了支持大量的连接, 很多 Web 服务器都采用了复用结构。 在复用结构中, 要同时监视所有连接上的活动。 当连接的状态发生变化时(比如, 有数据可用, 或出现错误时), 就对那条连接进行少量的处理; 处理结束之后, 将连接返回到开放连接列表中, 等待下一次状态变化。 只有在有事情可做时才会对连接进行处理; 在空闲连接上等待的时候并不会绑定线程和进程

    • 复用的多线程 Web 服务器(参见图d)
      有些系统会将多线程和复用功能结合在一起, 以利用计算机平台上的多个 CPU。多个线程(通常是一个物理处理器) 中的每一个都在观察打开的连接(或打开的连接中的一个子集), 并对每条连接执行少量的任务

    image

    第三步——处理请求

    一旦 Web 服务器收到了请求, 就可以根据方法、 资源、 首部和可选的主体部分来对请求进行处理了。

    有些方法(比如 POST) 要求请求报文中必须带有实体主体部分的数据。 其他一些方法(比如 OPTIONS) 允许有请求的主体部分, 也允许没有。 少数方法(比如GET) 禁止在请求报文中包含实体的主体数据

    第四步——对资源的映射及访问

    Web 服务器是资源服务器。 它们负责发送预先创建好的内容, 比如 HTML 页面或JPEG 图片, 以及运行在服务器上的资源生成程序所产生的动态内容。

    在 Web 服务器将内容传送给客户端之前, 要将请求报文中的 URI 映射为 Web 服务器上适当的内容或内容生成器, 以识别出内容的源头

    docroot文档根目录

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

    在图中, 有一条对 /specials/saw-blade.gif 的请求到达。 这个例子中 Web 服务器的文档根目录为 /usr/local/httpd/files。 Web 服务器会返回文件 /usr/local/httpd/files/specials/saw-blade.gif。

    image (将请求 URI 映射为本地 Web 服务器上的资源)

    在配置文件 httpd.conf 中添加一个 DocumentRoot 行就可以为 Apache Web 服务器设置文档的根目录了:

    DocumentRoot /usr/local/httpd/files
    

    服务器要注意, 不能让相对 URL 退到 docroot 之外, 将文件系统的其余部分暴露出来。 比如, 大多数成熟的 Web 服务器都不允许这样的 URI 看到 Joe 的五金商店文档根目录上一级的文件:

    http://www.joes-hardware.com/../
    

    虚拟托管的docroot

    虚拟托管的 Web 服务器会在同一台 Web 服务器上提供多个 Web 站点, 每个站点在服务器上都有自己独有的文档根目录。 虚拟托管 Web 服务器会根据 URI 或 Host 首部的 IP 地址或主机名来识别要使用的正确文档根目录。 通过这种方式, 即使请求URI 完全相同, 托管在同一 Web 服务器上的两个 Web 站点也可以拥有完全不同的内容了

    图 5-9 中的服务器托管了两个站点: www.joes-hardware.comwww.marys-antiques.com。 服务器可以通过 HTTP 的 Host 首部, 或根据不同的 IP 地址来区分不同的Web 站点

    • 当请求 A 到达时, 服务器会获取文件 /docs/joe/index.html。
    • 当请求 B 到达时, 服务器会获取文件 /docs/mary/index.html。

    image(虚拟托管的请求会使用不同的文档根目录)

    用户的主目录docroot

    Docroot 的另一种常见应用是在 Web 服务器上为人们提供私有的 Web 站点。 通常会把那些以斜杠和波浪号(/~) 开始, 后面跟着用户名的 URI 映射为此用户的私有文档根目录。 私有 docroot 通常都是用户主目录下那个名为 public_html 的目录, 但也可将其配置为其他值(参见图)。

    image (不同用户有不同的 docroot)

    目录列表

    Web 服务器可以接收对目录 URL 的请求, 其路径可以解析为一个目录, 而不是文件。 我们可以对大多数 Web 服务器进行配置, 使其在客户端请求目录 URL 时采取不同的动作。

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

    大多数 Web 服务器都会去查找目录中一个名为 index.html 或 index.htm 的文件来代表此目录。 如果用户请求的是一个目录的 URL, 而且这个目录中有一个名为 index.html(或 index.htm) 的文件, 服务器就会返回那个文件的内容。

    在 Apache Web 服务器上, 可以用配置指令 DirectoryIndex 来配置要作为默认目录文件使用的文件名集合。 指令 DirectoryIndex 会按照优先顺序列出所有可以作为目录索引文件使用的文件名。 下列配置行会使 Apache 在收到一个目录 URL 请求时, 在目录中搜索命令中列出来的任意一个文件:

    DirectoryIndex index.html index.htm home.html home.htm index.cgi
    

    如果用户请求目录 URI 时, 没有提供默认的索引文件, 而且没有禁止使用目录索
    引, 很多 Web 服务器都会自动返回一个 HTML 文件, 此文件中会列出那个目录里的文件名, 以及每个文件的大小和修改日期, 还包括到每个文件的 URI 链接。 使用这个文件列表可能会很方便, 但有些好事者也可以通过它在 Web 服务器上找到一些通常找不到的东西。

    可以通过以下 Apache 指令禁止自动生成目录索引文件:

    Options -Indexes
    

    动态内容资源的映射

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

    Apache 允许用户将 URI 路径名组件映射为可执行文件目录。 服务器收到一条带有可执行路径组件的对 URI 的请求时, 会试着去执行相应服务器目录中的程序。
    例如, 下列 Apache 配置指令就表明所有路径以 /cgi-bin/ 开头的 URI 都应该执行在目录 /usr/local/etc/httpd/cgi-programs/ 中找到的相应文件:

    ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-programs/
    

    Apache 还允许用户用一个特殊的文件扩展名来标识可执行文件。 通过这种方式就可以将可执行脚本放在任意目录中了。 下面的 Apache 配置指令说明要执行所有以 .cgi结尾的 Web 资源:

    AddHandler cgi-script .cgi
    

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

    服务器端包含项

    很多 Web 服务器还提供了对服务器端包含项(SSI) 的支持。 如果某个资源被标识为存在服务器端包含项, 服务器就会在将其发送给客户端之前对资源内容进行处理。

    要对内容进行扫描, 以查找(通常包含在特定 HTML 注释中的) 特定的模板, 这些模板可以是变量名, 也可以是嵌入式脚本。 可以用变量的值或可执行脚本的输出来取代特定的模板。 这是创建动态内容的一种简便方式。

    访问控制

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

    第五步——构建响应

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

    响应实体

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

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

    MIME类型

    Web 服务器要负责确定响应主体的 MIME 类型。 有很多配置服务器的方法可以将MIME 类型与资源关联起来。

    • MIME 类型(mime.types)
      Web 服务器可以用文件的扩展名来说明 MIME 类型。 Web 服务器会为每个资源扫描一个包含了所有扩展名的 MIME 类型的文件, 以确定其 MIME 类型。 这种基于扩展名的类型相关是最常见的, 参见图

    image (Web 服务器用 MIME 类型文件来设置资源输出的 Content-type 首部)

    • 魔法分类(Magic typing)
      Apache Web 服务器可以扫描每个资源的内容, 并将其与一个已知模式表(被称为魔法文件) 进行匹配, 以决定每个文件的 MIME 类型。 这样做可能比较慢,但很方便, 尤其是文件没有标准扩展名的时候。

    • 显式分类(Explicit typing)
      可以对 Web 服务器进行配置, 使其不考虑文件的扩展名或内容, 强制特定文件或目录内容拥有某个 MIME 类型

    • 类型协商
      有些 Web 服务器经过配置, 可以以多种文档格式来存储资源。 在这种情况下,可以配置 Web 服务器, 使其可以通过与用户的协商来决定使用哪种格式(及相关的 MIME 类型)“最好”

    重定向

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

    • 永久搬离的资源
      资源可能已经被移动到了新的位置, 或者被重新命名, 有了一个新的 URL。 Web 服务器可以告诉客户端资源已经被重命名了,这样客户端就可以在从新地址获取资源之前, 更新书签之类的信息了。 状态码 301 Moved Permanently 就用于此类重定向。
    • 临时搬离的资源
      如果资源被临时移走或重命名了, 服务器可能希望将客户端重定向到新的位置上去。 但由于重命名是临时的, 所以服务器希望客户端将来还可以回头去使用老的URL, 不要对书签进行更新。 状态码 303 See Other 以及状态码 307 TemporaryRedirect 就用于此类重定向。
    • URL 增强
      服务器通常用重定向来重写 URL, 往往用于嵌入上下文。 当请求到达时, 服务器会生成一个新的包含了嵌入式状态信息的 URL, 并将用户重定向到这个新的URL 上去。 7 客户端会跟随这个重定向信息, 重新发起请求, 但这次的请求会包含完整的、 经过状态增强的 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 服务器会在日志文件中添加一个条目, 来描述已执行的事务。 大多数 Web 服务器都提供了几种日志配置格式

    展开全文
  • 常见Web服务器简介

    万次阅读 2014-08-11 18:48:21
    常见Web服务器简介   Web服务器也称为WWW (WORLD WIDE WEB)服务器、HTTP服务器,其主要功能是提供网上信息浏览服务。  Unix和Linux平台下的常用Web服务器有Apache,Nginx,Lighttpd,Tomcat,IBM WebSphere、BEA...
  • web服务器的建立(一)

    千次阅读 2019-02-21 11:58:44
    对于服务器,我在网上看了很多的例子,做的都很完善,但是学习价值并不是很高。 所以我做一个具有学习意义的服务器 如上图,网络通信以冯诺依曼体系为基础,通过在应用层运行进程,进而间接性操作操作系统,达到...
  • 一、什么是WEB服务器  Web服务器可以解析HTTP协议。当Web服务器接收到一个HTTP请求,会返回一个HTTP响应,例如送回一个HTML页面。为了处理一个请求Web服务器可以响应一个静态页面或图片,进行页面跳转或者把动态响应...
  • Web服务器理解(通俗易懂)

    千次阅读 2018-01-19 14:09:25
    Web服务器是指驻留于因特网上某种类型计算机的程序。当Web浏览器(客户端)连到服务器上并请求文件时,服务器将处理该请求并将文件发送到该浏览器上,附带的信息会告诉浏览器如何查看该文件(即文件类型)。服务器...
  • 常用的WEB服务器简介

    万次阅读 2018-06-22 10:55:57
    常用的WEB服务器 WEB服务器也称为WWW服务器、HTTP服务器,其主要功能是提供网上信息浏览服务。Unix和Linux平台下常用的服务器有Apache、Nginx、Lighttpd、Tomcat、IBM WebSphere等,其中应用最广泛的是Apache。而...
  • 打开VS2012解决方案资源管理器 -> 点选 Web 项目选择 -> 属性 -> Web -> 选择“使用 Visual Studio 开发服务器” -> 选中“自动分配端口” 。 再次运行Web项目,大功告成! 如图设置
  • 处理【由于 Web 服务器... 由于 Web 服务器上的“ISAPI 和 CGI 限制”列表设置,无法提供您请求的页面. 出现环境:win7 + IIS7.0 解决办法:IIS的根节点->右侧“ISAPI和CGI限制”->把禁止的DotNet版本项设置
  • HBuilder的编写用到了Java、C、Web和Ruby。HBuilder本身主体是由Java编写,它基于Eclipse,所以顺其自然地兼容了Eclipse的插件。快,是HBuilder的最大优势,通过完整的语法提示和代码输入法、代码块等,大幅提升...
  • web服务器和web应用服务器的区别

    千次阅读 2018-06-10 20:22:43
    首先,web服务器和web应用服务器不是同一个概念。起初,我也把两者混为一谈。现在说说自己对这两个的理解,如有不对之处,欢迎指出。 web应用服务器 在java web开发时,最早接触的web服务器是tomcat,其实tomcat是...
  • 一、安装WEB服务器 1.选择添加角色和功能 2.一直下一步到选择web服务器 3.添加功能 4.角色服务可以按需选择,这里直接默认 5.一直下一步,耐心等待安装成功 二、配置IIS 1.安装成功后右键IIS就可以...
  • Web服务器搭建步骤(Win10)

    万次阅读 2019-03-22 13:00:14
    1.在“开始”菜单处打开“控制面板”。 2.点击“程序”。 3.点击“启动或关闭Windows功能”。 4.对“Internet Information Services”下的所有选项打勾✔,点击“确定”。 5.电脑会自动搜索文件下载......
  • 详情请查看: https://blog.csdn.net/dingguanyi/article/details/80894382
  • web服务器和应用服务器的区别与分析

    万次阅读 多人点赞 2019-06-04 16:28:06
    Apache是世界使用排名第一的Web服务器。它可以运行在几乎所有广泛使用的计算机平台上。源于NCSAhttpd服务器,经过多次修改,成为世界上最流行的Web服务器软件之一。Apache取自“a patchy server”的读音,意思是充满...
  • WEB服务器与应用服务器的区别

    万次阅读 多人点赞 2012-06-13 23:59:35
    WEB服务器与应用服务器的区别: 1.WEB服务器: 理解WEB服务器,首先你要理解什么是WEB?WEB你可以简单理解为你所看到的HTML页面就是WEB的数据元素,处理这些数据元素的应用软件就叫WEB服务器,如IIS、apache。 WEB服务器...
  • Java - 常用的Web服务器有哪些?

    万次阅读 2019-03-16 15:55:16
    分享一个大牛的人工智能教程。零基础!通俗易懂!风趣幽默!希望你也加入到人工智能的队伍中来!...选择Web服务器应考虑的因素有:性能、安全性、日志和统计、虚拟主机、代理服务器、缓冲服务和集成应用程序等。下面...
  • Java中最常见的5种Web服务器介绍

    万次阅读 2017-04-29 23:40:55
    Java中最常见的5种Web服务器分别是: Tomcat、Resin、JBoss、WebSphere、WebLogic, Web服务器是运行及发布Web应用的容器,只有将开发的Web项目放置到该容器中,才能使网络中的所有用户通过浏览器进行访问。 ...
1 2 3 4 5 ... 20
收藏数 1,609,916
精华内容 643,966
关键字:

web服务器