受朋友之托，小编挖出这篇出自该领域权威的文章，来给读者做个介绍：web服务器和application服务器的差别在哪里。
（一）Web服务器
Web服务器专门处理HTTP协议。当收到HTTP请求时，Web服务器会返回一个HTTP响应，例如，返回一个HTML页面。Web服务器会通过返回静态HTML页面、图片、跳转或者授权其他应用程序，如CGI scripts、JSPs, servlets,ASPs，服务端JavaScripts等服务器端技术来处理用户请求。无论请求的目的是什么，这类服务器端程序都会生成一个响应，大部分以HTML的形式，来给Web浏览器展示。
Web服务器的委派机制相当简单。当一个请求进入Web服务器之后，它仅仅简单地把这个请求转发给能处理这个请求的程序。Web服务器除了给程序提供一个执行环境之外，它没有其他额外功能。至于事务处理，连接数据库和消息处理，都是由服务器端程序提供的。
虽然不支持事务处理以及数据库连接池，Web服务器却会想办法增加一些容错性和可扩展性的功能，例如，负载均衡，缓冲池和集群。这些功能很多时候被认为是application服务器的专属。
（二）Application服务器
至于Application服务器，按照我们的定义，是一个通过各种协议给潜在客户端提供业务逻辑的服务器。这些协议就包含HTTP。与Web服务器专门处理和响应HTTP请求不同的是，Applicaiton服务器直接给客户端提供业务逻辑的使用入口。怎么理解呢？应用程序可以像调用一个对象的方法一样来使用这些业务逻辑。Application服务器不关心调用者是如何使用它的。
Application服务器的客户端，包括PC上运行的GUI，一个Web服务器，甚至其他的Application服务器。Applicatin服务器与它的客户端们来回交互的信息，不再仅仅是一些指导浏览器如何生成HTML页面的指令，而是程序逻辑。这些逻辑即可以是数据，也可以是方法调用，而且不局限于HTML协议。这样一来，客户端就可以自行决定怎样展示业务逻辑了。
大部分情况下，应用服务器通过component API的形式曝露自己的业务逻辑，比如J2EE服务器上的EJB。另外，Application服务器还能提供资源的自我管理。比如，安全性方面的把关，事务处理，资源共享池以及消息处理。和Web服务器一样，一个Application服务器同样提供容错性和可扩展性。
（三）例子
举例来说，一个在线商店，它提供实时报价和商品是否在售信息。这个网站处理一个询价请求然后返回一个嵌在HTML页面的价格。我们有无数种实现这样的网站的方式。这里，我给你讲解两个例子，一种通过Web服务器实现，一种通过Applcation服务器实现。
场景一：Web服务器实现
在第一个场景里，一个单Web服务器提供在线商店的功能。该服务器拿到你的请求，然后递给服务器端的程序来处理。该服务器端程序到数据库查找或者文本文件中去查找对应的商品价格。等拿到数据，该程序就用这些数据来生成HTML响应，然后由Web服务器发回给Web浏览器。
综上所述，一个Web服务器仅仅只处理HTTP请求，然后返回一个HTML页面。
场景二：带Web服务器的Application服务器实现
场景二把场景一的过程重新组合一下。Web服务器照样把生成响应的任务交给一个脚本。但是，你现在可以把到数据库询价的业务逻辑放到Application服务器上。通过这个小小的更改，那个脚本就不需要知道怎样去拿到价格，它只要简单的调用Application服务器的询价服务就行了。之后，该脚本只需要把价格嵌到HTML页面中就可以了。
在这个场景里面，Applicaiton服务器提供询价服务。它不关心客户端如何展示和使用它的价格数据。它与客户端仅仅交互数据。当客户端调用Application服务器的询价服务时，该服务仅仅返回价格信息本身。
通过将询价逻辑和生成HTML响应的代码分开，该询价逻辑就能在应用之间重用了。另外一个客户端，比如收银，也会调用同样的询价服务来给客户结账。与之相对应，场景一中的询价服务就不能重用，因为它是嵌在HTML页面中的。总之，场景二中，Web服务器处理HTTP请求并返回一个HTML页面，询价服务则由application服务器来实现。
注意：
最近XML Web Service等若客户端技术的出现，使两者的边界变得模糊。Web服务也可以专心处理业务逻辑，而不用管页面如何展示了。
另外，多数Application服务器会包含一个Web服务器。