我们配置Web服务器，就是在服务器上建立网站，并设置好相关的参数，至于网站中的网页应该由网站的维护人员制作并上传到服务器中，下面小编就来介绍下如何配置服务器。
 
IIS的安装
 
一般在安装操作系统时不默认安装IIS，所以在第一次配置Web服务器时需要安装IIS。安装方法为：
 
1、打开“控制面板”，打开“添加/删除程序”，弹出“添加/删除程序”窗口。
 
2、单击窗口中的“添加/删除Windows组件”图标，弹出“Windows组件向导”对话框。
 添加/删除程序
 
 
3、选中“向导”中的“应用程序服务器”复选框。单击“详细信息”按钮，弹出“应用程序服务器”对话框。
 添加/删除Windows组件
 
 
4、选择需要的组件，其中“Internet信息服务(IIS)”和“应用程序服务器控制台”是必须选中的。选中“Internet信息服务(IIS)”后，再单击“详细信息”按钮，弹出“Internet信息服务(IIS)”对话框。
 
 
5、选中“Internet信息服务管理器”和“万维网服务”。并且选中“万维网服务”后，再单击“详细信息”按钮，弹出“万维网服务”对话框。
 
 
6、其中的“万维网服务”必须选中。如果想要服务器支持ASP，还应该选中“ActiveServerPages”。逐个单击“确定”按钮，关闭各对话框，直到返回图1的“Windows组件向导”对话框。
 
7、单击“下一步”按钮，系统开始IIS的安装，这期间可能要求插入WindowsServer2003安装盘，系统会自动进行安装工作。
 
8、安装完成后，弹出提示安装成功的对话框，单击“确定”按钮就完成了IIS的安装。
 
友情提示：如果想要同时装入FTP服务器，在“Internet信息服务(IIS)”对话框中应该把“文件传输协议(FTP)服务”的复选框也选中。
 
 
在IIS中创建Web网站
 
打开“Internet信息服务管理器”，在目录树的“网站”上单击右键，在右键菜单中选择“新建→网站”，弹出“网站创建向导”：
 

 
 
网站描述就是网站的名字，它会显示在IIS窗口的目录树中，方便管理员识别各个站点。本例中起名为“枝叶的网站”。
 
 
网站IP地址：如果选择“全部未分配”，则服务器会将本机所有IP地址绑定在该网站上，这个选项适合于服务器中只有这一个网站的情况。也可以从下拉式列表框中选择一个IP地址（下拉式列表框中列出的是本机已配置的IP地址，如果没有，应该先为本机配置IP地址，再选择。）
 
TCP端口：一般使用默认的端口号80，如果改为其它值，则用户在访问该站点时必须在地址中加入端口号。
 
主机头：如果该站点已经有域名，可以在主机头中输入域名。
 
 
主目录路径是网站根目录的位置，可以用“浏览”按钮选择一个文件夹作为网站的主目录。
 
 
网站访问权限是限定用户访问网站时的权限，“读取”是必需的，“运行脚本”可以让站点支持ASP，其它权限可根据需要设置。
 
单击“下一步”，弹出“完成向导”对话框，就完成了新网站的创建过程，在IIS中可以看到新建的网站。把做好的网页和相关文件复制到主目录中，通常就可以访问这个网站了。
 
 
访问网站的方法是：如果在本机上访问，可以在浏览器的地址栏中输入“http://localhost/”；如果在网络中其它计算机上访问，可以在浏览器的地址栏中输入“http://网站IP地址”。
 
说明：如果网站的TCP端口不是80，在地址中还需加上端口号。假设TCP端口设置为8080，则访问地址应写为“http://localhost:8080/”或“http://网站IP地址:8080”。
 
网站的基本配置
 
如果需要修改网站的参数，可以在“网站名字”上单击右键，在右键菜单中选择“属性”，可以打开“网站属性”对话框。
 
1、“网站”标签
 
 
“网站标识”：可以设置网站名字、IP地址、端口号。单击“高级”按钮可以设置主机头名。
 
2、“主目录”标签
 
 
在本地路径中可以设置主目录的路径名和访问权限。
 
3、“文档”标签
 
 
默认文档是指访问一个网站时想要打开的默认网页，这个网页通常是该网站的主页。如果没有启用默认文档或网站的主页文件名不在默认文档列表中，则访问这个网站时需要在地址中指明文件名。
 
默认文档列表中最初只有4个文件名：Default.htm、Default.asp、index.htm和Default.aspx。我用“添加”按钮加入了一个index.asp，并用“上移”按钮把它移到了顶部。这主要是因为我的网站的主页名为“index.asp”，所以应该把它加入列表，至于是否位于列表顶部倒是无关紧要的。
 
经过以上配置，一个Web网站就可以使用了。把制作好的网页复制到网站的主目录中，网站主页的文件名应该包含在默认文档中。打开浏览器，在地址栏中输入“http://本机IP地址”，就可以打开网站的主页。其它页面可以用网页中的超链接打开。
 
虚拟目录
 
虚拟目录可以使一个网站不必把所有内容都放置在主目录内。虚拟目录从用户的角度来看仍在主目录之内，但实际位置可以在计算机的其它位置，而且虚拟目录的名字也可以与真实目录不同。如：
 
 
图中用户看到的一个位于主目录下的文件夹“pic”，它的真实位置在服务器的“D:myimage”处，而主目录位于“C:mywww”处。假设该网站的域名是“www.abc.com”，则用户访问“http://www.abc.com/pic/文件1”时，访问的实际位置是服务器的“D:myimage文件1”，所以虚拟目录的真实名字和位置对用户是不可知的。
 
创建虚拟目录的方法：
 
打开Internet信息服务窗口，在想要创建虚拟目录的Web站点上单击右键，选择“新建”→“虚拟目录”。弹出虚拟目录创建向导：
 
 
别名是映射后的名字，即客户访问时的名字；
 
 
路径：服务器上的真实路径名，即虚拟目录的实际位置；
 
 
访问权限：指客户对该目录的访问权限。
 
单击“下一步”按钮，弹出完成对话框，虚拟目录就建立成功了。把相关文件复制到虚拟目录中，用户就可以按照虚拟的树形结构访问到指定文件了。
 
通常虚拟目录的访问权限、默认文档等都继承自主目录，如果需要修改，可在“Internet信息服务管理器”中的虚拟目录上单击右键，选择“属性”，就可以修改虚拟目录的参数设置了。
 
常见问题
 
1、如何在一台Web服务器上建立多个网站？
 
在IIS管理器的“网站”上单击右键，选择“新建Web网站”，然后用“网站创建向导”可以创建新网站，每运行一次就能创建一个网站。
 
多网站的关键是如何区分各个网站，区分的依据是IP地址、TCP端口号、主机头，只要这三个参数中有任何一个不同都可以。
 
①用IP地址区分各网站：首先为服务器配置多个IP地址，然后在网站属性的IP地址栏目中为每个网站设置一个IP地址。
 
②用TCP端口区分各网站：这时各网站可以使用相同的IP地址，但把TCP端口设置的不同（应该使用1024~65535之间的值），这样也可以区分各网站。但这种方法要求用户在访问网站时，必须在地址中加入端口号，显得不太方便，一般不用。
 
③用主机头区分各网站：主机头是一个符合DNS命名规则的符号串，一般就用网站的域名作为主机头。设置主机头可以在网站属性的“网站”标签中单击“高级”按钮进行设置。如图：
 
 
利用这个“高级”设置，还可以为一个网站配置多个IP地址，或使用不同的TCP端口。
 
2、网站配置完成后，为何打不开？
 
最常见的情况是没有把网站主页的文件名添加到默认文档列表中，IIS6中网站的默认文档只有4个：Default.htm、Default.asp、index.htm和Default.aspx，如果你的网站主页名字不是这4个中的一个，就应该把它添加进去。如果不添加，就应该用带文件名的地址访问这个页面。
 
3、为什么我的ASP页面不能执行？
 
在IIS6中，ASP文件必须在启用“ActiveServerPages”时才能执行，如果安装IIS时，没有选中“ActiveServerPages”，则服务器默认不启用“ActiveServerPages”，也就不能执行ASP文件。
 
启用“ActiveServerPages”的方法是：打开“Internet信息服务管理器”，选中其中的“Web服务扩展”，然后启用里面的“ActiveServerPages”。如图：
 

<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 有两重意思
 
有时候 server 表示硬件，也就是一台机器。它还有另一个名字：「主机」。
更多时候，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);
});
 
你不用看懂这段程序，你只需要知道两件事情：
 
这段程序监听了当前机器的 8080 端口。
一旦外部访问当前机器的 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。
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Web 服务器
 
当我们在浏览器输入URL后，浏览器会先请求DNS服务器，获得请求站点的 IP 地址。然后发送一个HTTP Request（请求）给拥有该 IP 的主机，接着就会接收到服务器给我们的 HTTP Response（响应），浏览器经过渲染后，以一种较好的效果呈现给我们。这个过程中，正是Web服务器在幕后默默做贡献。
 
简单来说，Web服务器是在运行在物理服务器上的一个程序，它永久地等待客户端（主要是浏览器，比如Chrome，Firefox等）发送请求。当收到请求之后，它会生成相应的响应并将其返回至客户端。Web服务器通过HTTP协议与客户端通信，因此也被称为HTTP服务器。
 

 Web服务器的工作原理并不复杂，一般可分成如下4个步骤：建立连接、请求过程、应答过程以及关闭连接
 
建立连接：客户机通过TCP/IP协议建立到服务器的TCP连接。
请求过程：客户端向服务器发送HTTP协议请求包，请求服务器里的资源文档。
应答过程：服务器向客户机发送HTTP协议应答包，如果请求的资源包含有动态语言的内容，那么服务器会调用动态语言的解释引擎负责处理“动态内容”，并将处理得到的数据返回给客户端。由客户端解释HTML文档，在客户端屏幕上渲染图形结果。
关闭连接：客户机与服务器断开。
 
 
虽然说web服务器的主要工作是根据request返回response，但是实际中的 Web 服务器远远比上面示例的复杂的多，因为要考虑的因素实在是太多了，比如：
 
缓存机制：讲一些经常被访问的页面缓存起来，提高响应速度；
安全：防止黑客的各种攻击，比如 SYN Flood 攻击；
并发处理：如何响应不同客户端同时发起的请求；
日志：记录访问日至，方便做一些分析。
 
目前在UNIX和LINUX平台下使用最广泛的免费 Web 服务器有Apache和Nginx。
 
 
Web 应用程序
 
Web 服务器接受 Http Request，返回 Response，很多时候 Response 并不是静态文件，因此需要有一个应用程序根据 Request 生成相应的 Response。这里的应用程序主要用来处理相关业务逻辑，读取或者更新数据库，根据不同 Request 返回相应的 Response。注意这里并不是 Web 服务器本身来做这件事，它只负责 Http 协议层面和一些诸如并发处理，安全，日志等相关的事情。
 
应用程序可以用各种语言编写（Java, PHP, Python, Ruby等），这个应用程序会从Web服务器接收客户端的请求，处理完成后，再返回响应给Web服务器，最后由Web服务器返回给客户端。整个架构如下：
 

 以 Python 为例，使用Python开发Web，最原始和直接的办法是使用CGI标准，在1998年这种方式很流行。首先确保 Web 服务器支持CGI及已经配置了CGI的处理程序，然后设置好CGI目录，在目录里面添加相应的 python 文件，每一个 python 文件处理相应输入，生成一个 html 文件即可，如下例：
 
#!/usr/bin/python
# -*- coding: UTF-8 -*-

print "Content-type:text/html"
print         # 空行，告诉服务器结束头部
print '<html>'
print '<head>'
print '<meta charset="utf-8">'
print '</head>'
print '<body>'
print '<h2>Hello Word! 我是一个CGI程序</h2>'
print '</body>'
print '</html>'
 
这样在浏览器访问该文件就可以得到一个简单的 Hello World 网页内容。直接通过 CGI 写 Web 应用程序看起来很简单，每一个文件处理输入，生成html。但是实际开发中，可能会遇到许多不方便的地方。比如：
 
每个独立的CGI脚本可能会重复写数据库连接，关闭的代码；
后端开发者会看到一堆 Content-Type 等和自己无关的 html 页面元素；
 
 

 
Web 框架
 
早期开发站点确做了许多重复性劳动，后来为了减少重复，避免写出庞杂，混乱的代码，人们将 Web 开发的关键性过程提取出来，开发出了各种 Web 框架。有了框架，就可以专注于编写清晰、易维护的代码，无需关心数据库连接之类的重复性工作。
 
其中一种比较经典的Web框架采用了MVC架构，如下图所示：
 
 用户输入 URL，客户端发送请求，控制器（Controller）首先会拿到请求，然后用模型（Models）从数据库取出所有需要的数据，进行必要的处理，将处理后的结果发送给视图（View），视图利用获取到的数据，进行渲染生成 Html Response返回给客户端。
 
以 python web 框架 flask 为例，框架本身并不限定我们用哪种架构来组织我们的应用，不过 flask 可以很好地支持以 MVC 方式组织应用。
 
控制器：flask 可以用装饰器来添加路由项，如下：
 
@app.route('/')
def main_page():
    pass
 
模型：主要用来取出需要的数据，如下面函数中操作：
 
@app.route('/')
def main_page():
    """Searches the database for entries, then displays them."""
    db = get_db()
    cur = db.execute('select * from entries order by id desc')
    entries = cur.fetchall()
    return render_template('index.html', entries=entries)
 
视图：flask 利用 jinja2 来渲染页面，下面的模版文件指定了页面的样式：
 
{% for entry in entries %}
<li>
  <h2>{{ entry.title }}</h2>
  <div>{{ entry.text|safe }}</div>
</li>
{% else %}
<li><em>No entries yet. Add some!</em></li>
{% endfor %}
 
 

 
Web 服务器网关接口
 
我们知道Python有着许多的 Web 框架，而同时又有着许多的 Web 服务器（Apache, Nginx, Gunicorn等），框架和Web服务器之间需要进行通信，如果在设计时它们之间不可以相互匹配的，那么选择了一个框架就会限制对 Web 服务器的选择，这显然是不合理的。
 
那么，怎样确保可以在不修改Web服务器代码或网络框架代码的前提下，使用自己选择的服务器，并且匹配多个不同的网络框架呢？答案是接口，设计一套双方都遵守的接口就可以了。对python来说，就是WSGI（Web Server Gateway Interface，Web服务器网关接口）。其他编程语言也拥有类似的接口：例如Java的Servlet API和Ruby的Rack。
 
Python WSGI的出现，让开发者可以将 Web 框架与 Web 服务器的选择分隔开来，不再相互限制。现在，你可以真正地将不同的 Web 服务器与Web框架进行混合搭配，选择满足自己需求的组合。例如，可以使用 Gunicorn 或Nginx/uWSGI来运行Django、Flask或web.py应用。
 
 
原文链接：从零开始搭建论坛（一）：Web服务器与Web框架

http协议解析–绪篇
 
在做开发的过程中，总是能感觉到自己对http相关的各种概念模糊不清。
 
什么是web服务器，什么是应用服务器？
 
浏览器的编译原理是什么？
 
http的头文件为何要这样配置？
 
Nginx，Apache等为何要这样操作？
 
不同的服务器软件有什么作用？
 
而网上关于http的实战讲解一般都是以操作为主，涉及到原理的部分大多模糊不清，自己又很少花时间去系统的学习http协议相关的内容，大多数时候都是照着配一配就行了，所以明明写了挺多代码了，对于http还是知之甚少。所以，决定写一个专题，留作笔记也以此来督促自己深入的看看http，后续有什么地方说错了，也欢迎大家指出。
 
 
 
热点问题
 
 
 
在之前的学习中，曾经困扰我许久的问题便是：web服务器，http服务器，服务器软件，网站后台，应用服务器这些都有什么区别，与Apache，Nginx究竟是什么关系，Tomcat又是什么？
 
 
在绪篇中首先便先讲一下这些容易混淆的概念性问题。
 
web服务器
 
一般我们把发出http请求的一方称作请求分，比如浏览器就是http的请求方，那么应答方就是我们常说的web服务器（web Server）。
 
应该说web服务器在某些时候是一种很广泛的概念，比如在web代表一项应用软件是，web服务器有时候会被理解为软化的后台，也正是因为这样，很多人会混淆这个概念。
 
在硬件层面上，web服务器可以简单的理解为另一台性能更好的主机。不过在现实生活中，不仅仅只是一台主机，而是利用反向代理、负载均衡等等技术组成的一大群机房。
 
在软件层面上指的是提供web服务的应用程序。我的理解就是响应http请求，返回超文本文件等数据，或者把请求转发给后面的Tomcat、node.js等应用服务器。因此，web服务器是静态服务器。
 
常见的web服务器有Apache，Nginx，Tomcat等，其实Tomcat更多的做为应用服务器使用，一般不会直接用Tomcat做web服务器。
 
 

 当然目前Nginx等也经常用来做反向代理服务器和负载均衡等
 
http服务器
 
http服务器就是指使用http协议传输资源提供服务，由于应用层通讯协议主要就是http协议，所以在普遍情况下，web服务器==http服务器
 
网站后台
 
可以提供数据接口等服务的应用层软件。常说的就是应用的后端，进行数据和逻辑处理。
 
应用服务器
 
 
 
应用程序服务器通过各种协议把商业逻辑暴露给客户端应用程序。能实现动态网页技术，也称之为应用容器，web容器等
 
 
应用服务器不等于网站后台，但是在应用服务器上可以部署网站后台。通常，Web服务器会有插件来支持脚本语言，比如PHP、ASP等，也可以生成动态的HTTP内容。那为什么要使用应用服务器呢？
 
应用服务器可以更好的相应超大用户量的访问，并杜绝sql注入等安全问题，提供动态功能的支持。
 
常见的应用服务器有，Tomcat、Jetty、Undertow等。应用服务器也包含http服务
 
 
但是一般不会做为http服务器也就是web服务器使用，经常是搭配使用
 
浏览器>>>>>>web服务器>>>>>应用服务器>>>>>>数据库
 
 
总结
 
服务器分静态服务器和动态服务器，web服务器是静态服务器，应用服务器是动态服务器
应用服务器也可以处理静态需求，但是由于没有web服务器那么专业，所以一般搭配使用，常见如（Nginx+Tomcat）
Apache，Nginx等是静态服务器，是web服务器，也是web服务器软件
tomcat是动态服务器，也可以称之为web容器、应用容器等
网站后台不是web服务器，但是当web做为一种应用来表达的时候，web服务器可能在口头上会被理解为后台。
 
下一篇将正式开始进入http协议的学习