[TOC]
概述
描述:Web服务器/Web应用程序容器/Web应用程序服务器/反向代理有点像四胞胎,在网络上经常一起出现下面我们将对其进行区别;
1.Web服务器概念与基本原理
1.1 Web服务器的历史
1989年,互联网之父Berners-Lee向其雇主CERN提出了一个新项目,目的是通过使用超文本系统来缓解科学家之间的信息交流。Berners-Lee在1990年编写了两个方案:
- 一个名为WorldWideWeb的浏览器。
- 世界上第一个网络服务器后来被称为CERN httpd,它运行在NeXTSTEP上,在1994年前用于通过万维网冲浪和交换数据的早期技术的简单性和有效性有助于将其移植到许多不同的操作系统 1994年,Berners-Lee决定组建万维网联盟(W3C),通过标准化过程来管理涉及的许多技术(HTTP,HTML等)的进一步发展。
Web服务器功能
描述: Web服务器的主要功能是存储,处理和传递网页给客户
。
- 客户端和服务器之间的通信使用超文本传输协议(HTTP)或者https进行。
- 交付的页面最常见的是HTML文档,除了文本内容之外,还可能包含图像,样式表和脚本。
- 虽然主要功能是提供内容,但HTTP的完整实现还包括从客户端接收内容的方式,此功能用于提交Web表单,包括上传文件
- 还可以在服务端设置支持脚本语言
用户代理通常是web浏览器或web爬虫,通过发起一个HTTP请求以获取服务器资源,服务器根据请求返回该资源或由于某种原因响应错误消息。
WeiyiGeek.
许多通用Web服务器还支持使用Active Server Pages(ASP),PHP或其他脚本语言的服务器端脚本。 意味着Web服务器的行为可以在单独的文件中脚本化,而实际的服务器软件保持不变。通常此函数用于动态生成HTML文档(“即时”),而不是返回静态文档。前者主要用于从数据库检索或修改信息。后者通常快得多并且更容易被缓存,但不能提供动态内容。
Web服务器应用 Web服务器不仅用于为万维网服务,它们也可以被嵌入到诸如打印机,路由器,网络摄像机等设备中,并且仅服务于本地网络。然后web服务器可以用作用于监视或管理所讨论的设备的系统的一部分。这通常意味着客户端计算机上不需要安装其他软件,因为只需要一个网络浏览器(现在大多数操作系统都包含在内)。
1.2 Web服务器工作原理
HTTP协议基于TCP协议
上是一个应用层协议
,用于用户代理和Web服务器进行通信。
Web服务器通常采用一问一答的方式进行工作:
- 1、在用户代理上用户发起资源请求,请求内容包括但不限于:指定资源的唯一标识IRI,指明动作类型(GET/POST/DELETE/PUT…)
- 2、用户代理解析用户输入IRI并从中获取目标域名,交由DNS服务器解析。如果IRI中指定某IP地址,这无需这步。
- 3、如果与服务器的会话还没建立,此时先建立TCP连接,并完成HTTP协商(确定双方均可接受的处理方式,包括协议版本,是否加密,内容格式等等)。
- 4、用户代理把请求内容封装成HTTP数据包向服务器发送。
- 5、服务器接收到资源请求并以之前协商好的方式解包并处理。
- 6、服务器请求的资源封装成HTTP数据包并返回给用户代理。
服务器端的工作原理:
WeiyiGeek.
原理关键词介绍:
- 1)TCP监听模块
- 服务器监听某个端口(一般默认是8080端口,用户可以设置其他端口),以建立和用户代理之间的连接。一旦建立连接,用户代理的后续HTTP请求将不用再进入监听模块。
- 2)预处理
- 1.从TCP报文中获取HTTP请求报文。
- 2.根据和用户代理的协商进行
解密与解压
,安全处理等等。 - 3.根据服务器自身的配置进行安全处理,建立会话状态等等。
- 3)URL路由
- 解析URL字符串和动作以确定用户代理请求的资源,根据匹配规则(通常根据正则表达式 后缀)路由到静态资源处理模块或动态资源处理模块。
- 4)静态资源处理模块
- 负责找到静态资源比如HTML/Javascript/CSS文件/图片/图像,
- 确定内容是字符流或者字节流或对应MIME,比如HTML生成MIME为text/html的字符流,mpeg视频文件生成MIME为video/mpeg的字节流。
- 4)动态资源处理模块
- 运行业务逻辑处理,动态决定返回的资源内容和类型,内容和类型的处理原则同上。
- 5)后处理
- 根据和用户协商的协议进行加密,压缩,安全处理等等。
- 6)资源输出模块
- 把处理好的内容和类型封装成HTTP报文,往TCP连接另一头的用户代理发送TCP报文(内容是HTTP报文)。
主流Web服务器:
- Apache (前三者使用较多)
- IIS
- Nginx
- Tomcat
- Jetty
- WebSphere
- WebLogic
- Kerstrel
2.Web应用程序容器概念与基本原理
2.1 Web应用程序容器的由来
Web服务器的出现的标志着WWW时代的带来,世界变得更加平面化,后续开发者为了能在web服务器中进行动态脚本的解析,出现了CGI脚本来动态获取资源。再后来网络发展方向也是朝着增强Web服务器动态获取资源的能力前进。
以下是代表性的动态技术: 技术名词 |特点 —|— CGI(Common Gateway Interface,公用网关接口)| 以独立进程运行,可以用多种语言开发,比如C,C ,VB,Perl,灵活但效率低,维护复杂 PHP | 服务器端嵌入HTML脚本,开源,功能强大,扩展性较差 JSP | 服务器端嵌入HTML脚本,跨平台,部署前需编译,主要缺点是编写JSP比较复杂,需熟悉JAVA及相关技术 ASP |服务器端嵌入HTML脚本,开发简单,功能强大,只能在windows下运行
随后Web服务器朝着企业级应用方向发展,快速的业务变化迫使Web开发人员面对新的挑战;
如何快速写出鲁棒,可靠,符合业务需求的程序并顺利部署?
解决这个挑战的一个有效的办法是,创造一个Web程序开发框架(含运行环境,比如解释执行JSP,Web API
),这个框架解决鲁棒性,可靠性问题,提供快速开发接口
。换言之开发人员只需要专注于实现业务本身,如有更高的需求还可以对框架进行定制和扩展;框架的另外一个名字是Web应用程序容器
;
2.2 Web应用程序容器的基本工作原理
注:浅蓝色的模块是实现业务程序的主要使用模块。
WeiyiGeek.Web容器
相对于Web服务器,该容器新增或强化了以下模块:、
- 分配线程池资源
- 容器为每个请求分配一个线程进行处理,通常采取线程池的方式高效理由CPU算资源。
- 封装Request上下文
- 一个请求对应一个Request上下文,它主要封装了用户请求的主要构成:URL,HTTP请求头,以及基于请求头构建的Session,Cookie等对象,方便编程使用。
- 封装Response上下文
- 一个请求对应一个Response上下文,主要用于向用户代理返回资源。可以在其中写入输出流,或者重定向,或者返回错误码等等。
- URL路由
- 在容器里,运行开发人员设置不同的路由匹配规则,比如让.HTM返回.HTML,也可以自定义.xyz返回.HTML资源。更加灵活的配置可以参考JAVA MVC或者ASP.NET MVC的配置方案。
- 动态资源处理模块
- 通常在这里具体的容器和开发语言都有自己的高效开发模型,比如JAVA的Servlet,ASP.NET的Web Form,MVC。
- 回收资源
- 这里会回收刚才的线程资源,为了线程复用,除非服务器空闲一般会将线程返回线程池。
值得一说的是Web容器本身具备了做为一个Web服务器的功能,事实上通常实现Web容器功能的服务器就是一个Web服务器
主流Web容器:
- Tomcat
- IIS
- Jetty
- WebSphere
- WebLogic
3.Web应用程序服务器概念及基本原理
3.1 发展历史
应用程序服务器(The Application Server): 在Web服务器发展的同一个时期,应用服务器已经存在并发展很长一段时间了。一些公司为Unix开发了Tuxedo(面向事务的中间件)、TopEnd、Encina等产品,这些产品都是从类似IMS和CICS的主机应用管理和监控环境衍生而来的。 大部分的这些产品都指定了“封闭的”产品专用通信协议来互连胖客户机(“fat” client)和服务器。在90年代这些传统的应用服务器产品开始嵌入HTTP通信功能,刚开始要利用网关来实现,不久后它们之间的界线开始变得模糊了。
同时web服务器越来越成熟,可以处理更高的负载、更多的并发和拥有更好的特性
;应用服务器开始添加越来越多的基于HTTP的通信功能导致了web服务器 与 应用服务器 的界线变得更窄了
。但是人们还把这两个术语区分开来作为强调使用两种区别如下:
- web服务器:以HTTP为核心、web UI为向导的应用
- 应用服务器:高负载、企业级特性、事务和队列、多通道通信(HTTP和更多的协议)
3.2 应用程序服务器原理
Web应用服务器的结构图:
WeiyiGeek.
Web应用服务器包括了Web容器,同时内置了支撑企业应用的事务,安全,集成,通信,高可用等等功能
,极大了减少了重复开发量,保障了业务系统快速开发和部署,而它本身也是一个Web服务器。
主流的的应用程序服务器:
- WebLogic
- WebSphere
- Tomcat/jetty(Web容器)加上第三方的框架(spring,hibernate等)来构建自己的Application Server
- .NET Core平台下可以选择IIS, Apache,Nginx 与 ASP.NET Core构建。
4.反向代理概念与基本原理
4.1 反向代理基本概念
描述:反向代理是代理服务器的一种,它根据客户端的请求从后端的服务器(如Web服务器)上获取资源,然后再将这些资源返回给客户端。
与前向代理不同,前向代理作为一个媒介将互联网上获取的资源返回给相关联的客户端
,而反向代理是在服务器端(如Web服务器)作为代理使用,而不是客户端
。
客户端通过前向代理可以访问很多不同的资源,而反向代理是很多客户端都通过它访问不同后端服务器上的资源,而不需要知道这些后端服务器的存在,而以为所有资源都来自于这个反向代理服务器。
WeiyiGeek.
互联网中的请求发送给反向代理,反向代理把请求转发到内网中的服务器,反向代理的主要作用为:
- 加密和SSL加速
- 负载均衡
- 缓存静态内容
- 压缩
- 减速上传
- 安全防火墙
- 外网发布
- 突破互联网封锁
- 解决跨域问题
4.2 反向代理基本工作原理
一个反向代理服务器的构成和处理过程如下图: 左边淡黄色功能模块对外网报文进行处理,右边灰色功能模块针对内网报文进行处理
WeiyiGeek.
- 1)TCP监听模块 监听TCP请求,这里的请求是指报文内容是某应用层协议(比如HTTP,FTP,EMAIL等应用层协议)的请求。至于这里是否会单独产生一个线程来开始处理,这个由服务器自己决定,目前最流行的是先入消息队列然后异步处理,这样能极大提高代理的吞吐量和稳定性。
- 2)匹配被代理服务器 代理服务器根据一个表(存放外网url和内网服务器的对应关系,通常需人工进行设置),如果匹配到则继续处理,否则依据外网协议返回错误信息,比如HTTP协议这返回404。
- 3)应用负载均衡策略
如果比较大型的互联网应用,为了
整体系统稳定性解决单点问题
,需要根据自定义策略合理的转发报文给被代理服务器。简单的策略是哈希分发或者随机分发,一般可以由用户进行配置和选择。 - 4)预处理 这里依据协商好的外网应用协议进行解密,安全,会话,解压等处理。
- 5)新生成网络报文 这里依据协商好的内网应用协议生成网络报文,这里可能会进行加密,安全,会话,压缩等处理。
- 6)转发给被代理服务器 把新生成的网络报文发送给内网服务器(可能是否Web服务器,Ftp服务器,邮件服务器)。
- 7)接受网络报文 接受内网服务器反馈的网络报文。
- 8)预处理 这里依据协商好的外网应用协议进行加密,安全,会话,压缩等处理。
- 9)资源输出模块 这时生成满足外网应用协议要求的报文,并发送到外网连接的另一端(用户代理)。
常用的反向代理服务器:(它们的名字您一定记得)
- Ngnix (使用最多)
- IIS
- Apache
5.各类应用
1) Web服务器Apache
世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上,尤其对Linux的支持相当完美。它和Linux一样都是源代码放的自由软件,所以不断有人来为它开发新的功能、新的特性、修改原来的缺陷。 到目前为止Apache仍然是世界上使用最多的Web服务器,市场占有率达60%左右。
Apache的特点是简单、速度快、性能稳定、移植性高,并可作为代理服务器来使用。
世界上很多著名的网站都是Apache的产物,它的成功主要有两个原因: 一、是它的源代码开放,有一支开放的开发队伍; 二、是支持跨平台的应用,可以运行在几乎所有的UNIX、Linux、Windows等系统平台上,它具有超强的可移植性,所以Apache是作为Web服务器的最佳选择。
它对HTML页面具有强大的解释能力,但是不能解释嵌入页面内的服务器端脚本代码(JSP/Servlet) Apache:在Web服务器中,Apache是纯粹的Web服务器,经常与Tomcat配对使用。
2) 轻量级应用服务器 Tomcat
早期Tomcat是一个嵌入Apache内的JSP/Servlet解释引擎Apache Tomcat就相当于IIS ASP,后来的Tomcat已不再嵌入Apache内,Tomcat进程独立于Apache进程运行。 现在Tomcat已经是一个独立的Servlet和JSP容器,业务逻辑层代码和界面交互层代码可以分离了,因此有人把Tomcat叫做轻量级应用服务器。
对于处于中间位置的Tomcat,它可以配合纯Web服务器Apache一起使用,也可以作为应用服务器的辅助与应用服务器一起部署:
3) 轻量级应用服务器 IIS
微软(Microsoft)早期的IIS,就是一个纯粹的Web服务器。后来它嵌入了ASP引擎,可以解释VBScript和JScript服务器端代码了,这时它就可以兼作应用服务器。当然它与J2EE应用服务器根本无法相比,但是,从功能/原理上说,它勉强可以称之为应用服务器,确切地说,它是兼有一点应用服务器功能的Web服务器。
综上:Apache是纯粹的web服务器,而Tomcat和IIS因为具有了解释执行服务器端代码的能力,可以称作为轻量级应用服务器或带有服务器功能的Web服务器。
WEB服务器、应用程序服务器的更详细区别?
- 1.Web服务器(Web Server)
- Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request),会返回一个HTTP响应 (response),例如送回一个HTML页面。为了处理一个请求(request),Web服务器可以响应(response)一个静态页面或图片,进行页面跳转(redirect),或者把动态响应(dynamicresponse)的产生委托(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),例如负载平衡(loadbalancing),缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。
- 2.应用程序服务器(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)技术。
服务器容器区别讲解 1)Tomcat 应用服务器 Web服务器
- (1) 到目前为止,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结合起来使用。虽然整合会带来相关的问题,但是这种方式是最为有效的
- (2)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实现负载平衡。
举个例子 例如,设想一个在线商店(网站)提供实时定价(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)等等),而且给最佳产品的选取留有余地。
总结
1.四种服务器概念 从概念上讲:HTTP服务器=WEB服务器、应用程序服务器、应用容器、有何区别?
- Web服务器是提供WWW服务的程序;
- Web容器是提供给开发者的框架;
- Web应用程序服务器内容丰富得多,既可用各厂商通常遵循一定的工业标准并自定义扩展功能而成,也可以利用开源组件轻量级拼装打造;
- 反向代理服务器在企业级应用中表现突出,具有解决集中式安全,负载均衡等等优点。
- 中间件是为应用程序提供容器和服务;
如今这四个概念的边界越来模糊,看看这个表就知道了: 软件名词| 是否Web服务器| 是否Web容器| 是否Web应用服务器| 是否能反向代理 | 公司 —|—|—|—|—|— IIS |是 |是| |是 | 微软公司 Nginx |是 | | |是 | Apache |是 | | |是 | Sun公司 Http.sys|是 | | |是 | Tomcat |是 |是| | | Apache开源软件组织 Jetty |是 |是| | | WebSphere|是|是|是| | IBM公司 WebLogic |是|是|是| | BEA公司 JBossAS |是|是|是| | 红帽公司 Kerstrel |是|是?
补充知识点 关于Kerstrel是否web容器,有两种观点:
- 1.由于Kerstrel不提供编写应用的框架,所以它不是容器;asp.net core才是容器,因为它提供了开发应用的框架并提供web应用(MVC,Web API)运行环境。
- 2.Kerstrel提供了运行环境。
主流WEB搭配与对比 平台框架名称| 平台| WEB服务器 | 数据库| 开发语言 —|—|—|—|—|— LAMP |Linux |Apache|Mysql |php ASP.NET|Windows|IIS |Mssql|ASP、c# JAVAEE| Unix |Tomcat |Oracle |Jsp