web概述-前端学习系统化总结

为了更系统地、有的放矢地学习前端,总结前端知识如下:

基础

  • html语义化(尽量使用p、section等,而非纯粹div,方便理解)
  • 数据交互,如ajax
  • websocket
  • 网页的生命周期(预加载 渲染 以及加载后回调)
  • 浏览器兼容 (webkit内核、ie等)
  • 存储:cookie、localstorage、sessionStorage、websql、indexdb、application cache

工具

  • postman
  • devtools/微信开发者工具
  • wireshark、Charles
  • ngrok

安全角度

  • ssl
  • sql注入
  • 跨域
  • js注入

维护性

  • gulp、webpack构建工具
  • scss、less
  • es6

体验性

  • 压缩
  • 避免重定向(耗时过久)

统计分析

  • 性能统计
  • 运营数据统计分析(留存、保活、拉新)

来自:https://www.jianshu.com/p/dc0912de2ad0

web概述-http发展简史

一、HTTP的历史

由于目前的网络发展进度,http1.1  基本还是主流,http2.0 只是对 http1.1 进行了帧封装,里面的请求报文格式 都没有变化。

早在HTTP建立之初,主要就是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。也是说对于前端来说,我们所写的HTML页面将要放在我们的web服务器上,用户端通过浏览器访问url地址来获取网页的显示内容,但是到了WEB2.0以来,我们的页面变得复杂,不仅仅单纯的是一些简单的文字和图片,同时我们的HTML页面有了CSS,Javascript,来丰富我们的页面展示,当ajax的出现,我们又多了一种向服务器端获取数据的方法,这些其实都是基于HTTP协议的。同样到了移动互联网时代,我们页面可以跑在手机端浏览器里面,但是和PC相比,手机端的网络情况更加复杂,这使得我们开始了不得不对HTTP进行深入理解并不断优化过程中。

 

二、HTTP的基本优化

影响一个HTTP网络请求的因素主要有两个:带宽和延迟。

  • 带宽:如果说我们还停留在拨号上网的阶段,带宽可能会成为一个比较严重影响请求的问题,但是现在网络基础建设已经使得带宽得到极大的提升,我们不再会担心由带宽而影响网速,那么就只剩下延迟了。
  • 延迟:
  • 浏览器阻塞(HOL blocking):浏览器会因为一些原因阻塞请求。浏览器对于同一个域名,同时只能有 4 个连接(这个根据浏览器内核不同可能会有所差异),超过浏览器最大连接数限制,后续请求就会被阻塞。
  • DNS 查询(DNS Lookup):浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。
  • 建立连接(Initial connection):HTTP 是基于 TCP 协议的,浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文,达到真正的建立连接,但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显,慢启动则对文件类大请求影响较大。

三、HTTP1.0

支持长连接(但默认还是使用短连接),参看web概述-http发展简史简明版

HTTP 协议老的标准是HTTP/1.0,为了提高系统的效率,HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。但是,这也造成了一些性能上的缺陷,例如,一个包含有许多图像的网页文件中并没有包含真正的图像数据内容,而只是指明了这些图像的URL地址,当WEB浏览器访问这个网页文件时,浏览器首先要发出针对该网页文件的请求,当浏览器解析WEB服务器返回的该网页文档中的HTML内容时,发现其中的图像标签后,浏览器将根据标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求。显 然,访问一个包含有许多图像的网页文件的整个过程包含了多次请求和响应,每次请求和响应都需要建立一个单独的连接,每次连接只是传输一个文档和图像,上一次和下一次请求完全分离。即使图像文件都很小,但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程,并且会严重影响客户机和服务器的性能。当一个网页文件中包含JavaScript文件,CSS文件等内容时,也会出现类似上述的情况。

同时,带宽和延迟也是影响一个网络请求的重要因素。在网络基础建设已经使得带宽得到极大的提升的当下,大部分时候都是延迟在于响应速度。基于此会发现,http1.0被抱怨最多的就是连接无法复用,和head of line blocking这两个问题。理解这两个问题有一个十分重要的前提:客户端是依据域名来向服务器建立连接,一般PC端浏览器会针对单个域名的server同时建立6~8个连接,手机端的连接数则一般控制在4~6个。显然连接数并不是越多越好,资源开销和整体延迟都会随之增大。连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显,慢启动则对文件类大请求影响较大。head of line blocking会导致带宽无法被充分利用,以及后续健康请求被阻塞。

head of line blocking(holb)会导致健康的请求会被不健康的请求影响,而且这种体验的损耗受网络环境影响,出现随机且难以监控。为了解决holb带来的延迟,协议设计者设计了一种新的pipelining机制。pipelining只能适用于http1.1,而且由于使用苛刻,很多浏览器厂商并不支持。

四、HTTP1.1

为了克服HTTP 1.0的这个缺陷,HTTP 1.1支持持久连接(HTTP/1.1的默认模式使用带流水线的持久连接),在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输,但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间。

在http1.1,request和reponse头中都有可能出现一个connection的头,此header的含义是当client和server通信时对于长链接如何进行处理。
在http1.1中,client和server都是默认对方支持长链接的, 如果client使用http1.1协议,但又不希望使用长链接,则需要在header中指明connection的值为close;如果server方也不想支持长链接,则在response中也需要明确说明connection的值为close。不论request还是response的header中包含了值为close的connection,都表明当前正在使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。

HTTP 1.1在继承了HTTP 1.0优点的基础上,也克服了HTTP 1.0的性能问题。HTTP 1.1通过增加更多的请求头和响应头来改进和扩充HTTP 1.0的功能。如,HTTP 1.0不支持Host请求头字段,WEB浏览器无法使用主机头名来明确表示要访问服务器上的哪个WEB站点,这样就无法使用WEB服务器在同一个IP地址和端口号上配置多个虚拟WEB站点。在HTTP 1.1中增加Host请求头字段后,WEB浏览器可以使用主机头名来明确表示要访问服务器上的哪个WEB站点,这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。HTTP 1.1的持续连接,也需要增加新的请求头来帮助实现,例如,Connection请求头的值为Keep-Alive时,客户端通知服务器返回本次请求结果后保持连接;Connection请求头的值为close时,客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。HTTP/1.0不支持文件断点续传,<code>RANGE:bytes</code>是HTTP/1.1新增内容,HTTP/1.0每次传送文件都是从文件头开始,即0字节处开始。<code>RANGE:bytes=XXXX</code>表示要求服务器从文件XXXX字节处开始传送,这就是我们平时所说的断点续传!

五、HTTP/1.1和 HTTP/1.0 的区别:

HTTP1.0最早在网页中使用是在1996年,那个时候只是使用一些较为简单的网页上和网络请求上,而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中,同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在:

  1. ** 缓存处理**,在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略例如Entity tag,If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  2. 带宽优化及网络连接的使用,HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1则在请求头引入了range头域,它允许只请求资源的某个部分,即返回码是206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  3. 错误通知的管理,在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
  4. Host头处理,在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。
  5. 长连接,HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟,一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输,但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间。在HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

Pipelining介绍:(来自维基百科)

(整体上还是先进先出,如果第一个响应没有出现,就一直等了)

Schema of non-pipelined vs. pipelined connection.

HTTP管线化英语:HTTP pipelining)是将多个HTTP请求(request)整批提交的技术,而在发送过程中不需先等待服务端的回应。

请求结果管线化使得 HTML 网页加载时间动态提升,特别是在具体有高延迟的连接环境下,如卫星上网。在宽带连接中,加速不是那么显著的,因为需要服务器端应用 HTTP/1.1 协议:服务器端必须按照客户端的请求顺序恢复请求,这样整个连接还是先进先出的,队头阻塞(HOL blocking)可能会发生,造成延迟。未来的 HTTP/2.0 或者SPDY中的异步操作将会解决这个问题。因为它可能将多个 HTTP 请求填充在一个TCP数据包内,HTTP 管线化需要在网络上传输较少的 TCP 数据包,减少了网络负载。

管线化机制须通过永久连接(persistent connection)完成,并且只有 GET 和 HEAD 等要求可以进行管线化,非幂等的方法,例如POST将不会被管线化。连续的 GET 和 HEAD 请求总可以管线化的。一个连续的幂等请求,如 GET,HEAD,PUT,DELETE,是否可以被管线化取决于一连串请求是否依赖于其他的。此外,初次创建连接时也不应启动管线机制,因为对方(服务器)不一定支持 HTTP/1.1 版本的协议。

HTTP 管线化同时依赖于客户端和服务器的支持。遵守 HTTP/1.1 的服务器支持管线化。这并不是意味着服务器需要提供管线化的回复,而只是要求在收到管线化的请求时候不会失败。

六、SPDY:HTTP1.x的优化

2012年google如一声惊雷提出了SPDY的方案,优化了HTTP1.X的请求延迟,解决了HTTP1.X的安全性,具体如下:

  1. 降低延迟,针对HTTP高延迟的问题,SPDY优雅的采取了多路复用(multiplexing)。多路复用通过多个请求stream共享一个tcp连接的方式,解决了HOL blocking的问题,降低了延迟同时提高了带宽的利用率。
  2. 请求优先级(request prioritization)。多路复用带来一个新的问题是,在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级,这样重要的请求就会优先得到响应。比如浏览器加载首页,首页的html内容应该优先展示,之后才是各种静态资源文件,脚本文件等加载,这样可以保证用户能第一时间看到网页内容。
  3. header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
  4. 基于HTTPS的加密协议传输,大大提高了传输数据的可靠性。
  5. 服务端推送(server push),采用了SPDY的网页,例如我的网页有一个sytle.css的请求,在客户端收到sytle.css数据的同时,服务端会将sytle.js的文件推送给客户端,当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到,不用再发请求了。SPDY构成图:

    SPDY位于HTTP之下,TCP和SSL之上,这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式),同时可以使用已有的SSL功能。

七、HTTP2.0性能惊人

HTTP/2: the Future of the Internet 是 Akamai 公司建立的一个官方的演示,用以说明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同时请求 379 张图片,从Load time 的对比可以看出 HTTP/2 在速度上的优势。

八、HTTP2.0:SPDY的升级版

HTTP2.0可以说是SPDY的升级版(其实原本也是基于SPDY设计的),但是,HTTP2.0 跟 SPDY 仍有不同的地方,如下:
HTTP2.0和SPDY的区别:

  1. HTTP2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS
  2. HTTP2.0 消息头的压缩算法采用 HPACK,而非 SPDY 采用的 DEFLATE

九、HTTP2.0和HTTP1.X相比的新特性

多路复用 (Multiplexing)

多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。在 HTTP/1.1 协议中浏览器客户端在同一时间,针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一,拿 Twitter 为例,http://twimg.com,目的就是变相的解决浏览器针对同一域名的请求限制阻塞问题。而 HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接,HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧,这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。

二进制分帧

HTTP/2在 应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。在不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段的情况下, 解决了HTTP1.1 的性能限制,改进传输性能,实现低延迟和高吞吐量。在二进制分帧层中, HTTP/2 会将所有传输的信息分割为更小的消息和帧(frame),并对它们采用二进制格式的编码 ,其中 HTTP1.x 的首部信息会被封装到 HEADER frame,而相应的 Request Body 则封装到 DATA frame 里面。

HTTP/2 通信都在一个连接上完成,这个连接可以承载任意数量的双向数据流。在过去, HTTP 性能优化的关键并不在于高带宽,而是低延迟。TCP 连接会随着时间进行自我调谐,起初会限制连接的最大速度,如果数据成功传输,会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因,让原本就具有突发性和短时性的 HTTP 连接变的十分低效。HTTP/2 通过让所有数据流共用同一个连接,可以更有效地使用 TCP 连接,让高带宽也能真正的服务于 HTTP 的性能提升。

这种单连接多资源的方式,减少服务端的链接压力,内存占用更少,连接吞吐量更大;而且由于 TCP 连接的减少而使网络拥塞状况得以改善,同时慢启动时间的减少,使拥塞和丢包恢复速度更快。

首部压缩(Header Compression)

HTTP/1.1并不支持 HTTP 首部压缩,为此 SPDY 和 HTTP/2 应运而生, SPDY 使用的是通用的DEFLATE 算法,而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。

服务端推送(Server Push)

服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中,服务器可以对客户端的一个请求发送多个响应。Server Push 让 HTTP1.x 时代使用内嵌资源的优化手段变得没有意义;如果一个请求是由你的主页发起的,服务器很可能会响应主页内容、logo 以及样式表,因为它知道客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源,不过与之相比,服务器推送还有一个很大的优势:可以缓存!也让在遵循同源的情况下,不同页面之间可以共享缓存资源成为可能。

十、HTTP2.0的升级改造

  1. 前文说了HTTP2.0其实可以支持非HTTPS的,但是现在主流的浏览器像chrome,firefox表示还是只支持基于 TLS 部署的HTTP2.0协议,所以要想升级成HTTP2.0还是先升级HTTPS为好。
  2. 当你的网站已经升级HTTPS之后,那么升级HTTP2.0就简单很多,如果你使用NGINX,只要在配置文件中启动相应的协议就可以了,可以参考NGINX白皮书NGINX配置HTTP2.0官方指南
  3. 使用了HTTP2.0那么,原本的HTTP1.x怎么办,这个问题其实不用担心,HTTP2.0完全兼容HTTP1.x的语义,对于不支持HTTP2.0的浏览器,NGINX会自动向下兼容的。

参考:

https://www.jianshu.com/p/be29d679cbff   (文章中的HTTP pipelining 介绍有误)
https://www.jianshu.com/p/52d86558ca57
https://blog.csdn.net/elifefly/article/details/3964766

web概述-web1.0 web2.0 web3.0 的区别

Here we would like to talk about the major differences among Web 1.0, Web 2.0 and Web 3.0. To help you better understand, please watch this Youtube video, “Evolution Web 1.0, Web 2.0 to Web 3.0”.

Web 1.0
It is the “readable” phrase of the World Wide Web with flat data. In Web 1.0, there is only limited interaction between sites and web users. Web 1.0 is simply an information portal where users passively receive information without being given the opportunity to post reviews, comments, and feedback.

Web 2.0
It is the “writable” phrase of the World Wide Web with interactive data. Unlike Web 1.0, Web 2.0 facilitates interaction between web users and sites, so it allows users to interact more freely with each other. Web 2.0 encourages participation, collaboration, and information sharing. Examples of Web 2.0 applications are Youtube, Wiki, Flickr, Facebook, and so on.

Web 3.0
It is the “executable” phrase of Word Wide Web with dynamic applications, interactive services, and “machine-to-machine” interaction. Web 3.0 is a semantic web which refers to the future. In Web 3.0, computers can interpret information like humans and intelligently generate and distribute useful content tailored to the needs of users. One example of Web 3.0 is Tivo, a digital video recorder. Its recording program can search the web and read what it finds to you based on your preferences.


在这里我们想谈谈Web 1.0,Web 2.0和Web 3.0的主要区别。为了帮助您更好地理解,请观看此Youtube视频“Evolution Web 1.0,Web 2.0 to Web 3.0”

Web 1.0
它是万维网上带有平面数据的“可读”短语。在Web 1.0中,站点和Web用户之间的交互有限。Web 1.0只是一个信息门户,用户被动地接收信息而没有机会发布评论,评论和反馈。

Web 2.0
它是交互式数据的万维网的“可写”短语。与Web 1.0不同,Web 2.0促进了网络用户和网站之间的交互,因此它允许用户彼此更加自由地交互。Web 2.0鼓励参与,协作和信息共享。Web 2.0应用程序的例子是Youtube,Wiki,Flickr,Facebook等。

Web 3.0
它是动态应用程序,交互式服务和“机器对机器”交互的“万维网”的“可执行”短语。Web 3.0是一个涉及未来的语义网络。在Web 3.0中,计算机可以像人类一样解读信息,并智能地生成和分发适合用户需求的有用内容。Web 3.0的一个例子是Tivo,一种数字视频录像机。它的录制程序可以搜索网络,并根据您的喜好阅读它找到的内容。

j2ee标准-servlet3.0引入的新特性

来自:http://www.blogjava.net/freeman1984/archive/2012/11/16/391444.html

Servlet3.0规范的新特性主要是为了3个目的:
1.简化开发
2.便于布署
3.支持Web2.0原则
为了简化开发流程,Servlet3.0引入了注解(annotation),这使得web布署描述符web.xml不在是必须的选择。
Pluggability可插入性
当使用任何第三方的框架,如Struts,JSF或Spring,我们都需要在web.xml中添加对应的Servlet的入口。这使得web描述符笨重而难以维护。Servlet3.0的新的可插入特性使得web应用程序模块化而易于维护。通过web fragment实现的可插入性减轻了开发人员的负担,不需要再在web.xml中配置很多的Servlet入口。
Asynchronous Processing 异步处理
另外一个显著的改变就是Servlet3.0支持异步处理,这对AJAX应用程序非常有用。当一个Servlet创建一个线程来创建某些请求的时候,如查询数据库或消息连接,这个线程要等待直到获得所需要的资源才能够执行其他的操作。异步处理通过运行线程执行其他的操作来避免了这种阻塞。
Apart from the features mentioned here, several other enhancements have been made to the existing API. The sections towards the end of the article will explore these features one by one in detail.
除了这些新特性之外, Servlet3.0对已有的API也做了一些改进,在本文的最后我们会做介绍。
Annotations in Servlet Servlet中使用注解
Servlet3.0的一个主要的改变就是支持注解。使用注解来定义Servlet和filter使得我们不用在web.xml中定义相应的入口。
@WebServlet
@WebServlet用来定义web应用程序中的一个Servlet。这个注解可以应用于继承了HttpServlet。这个注解有多个属性,例如name,urlPattern, initParams,我们可以使用者的属性来定义Servlet的行为。urlPattern属性是必须指定的。
例如我们可以象下面的例子这样定义:

1. @WebServlet(name = “GetQuoteServlet”,  urlPatterns = {“/getquote”} )

2. public class GetQuoteServlet extends HttpServlet {

3.     @Override

4.     protected void doGet(HttpServletRequest request, HttpServletResponse response)

5.             throws ServletException, IOException {

6.         PrintWriter out = response.getWriter();

7.         try {

8.             String symbol = request.getParameter(“symbol”);

9.             out.println(“<h1>Stock Price is</h1>” + StockQuoteBean.getPrice(symbol);

10.         } finally {

11.             out.close();

12.         }

13.     }

14. }

15.

16. public class StockQuoteBean {

17. private StockQuoteServiceEntity serviceEntity = new StockQuoteServiceEntity();

18.     public double getPrice(String symbol) {

19.         if(symbol !=null )  {

20. return serviceEntity.getPrice(symbol);

21.          } else {

22.             return 0.0;

23.         }

24.     }

25. }

复制代码

在上面的例子中,一个Servlet只对应了一个urlPattern。实际上一个Servlet可以对应多个urlPattern,我们可以这样定义:

1. @WebServlet(name = “GetQuoteServlet”,  urlPatterns = {“/getquote”,  “/stockquote”} )

2. public class GetQuoteServlet extends HttpServlet {

3.     @Override

4.     protected void doGet(HttpServletRequest request, HttpServletResponse response)

5.             throws ServletException, IOException {

6.         PrintWriter out = response.getWriter();

7.         try {

8.             String symbol = request.getParameter(“symbol”);

9.             out.println(“<h1>Stock Price is</h1>” + StockQuoteBean.getPrice(symbol);

10.         } finally {

11.             out.close();

12.         }

13.     }

14. }

复制代码

@WebFilter
我们可以使用@WebFilter注解来定义filter。这个注解可以被应用在实现了javax.servlet.Filter接口的类上。同样的,urlPattern属性是必须指定的。下面就是一个例子。

1. @WebFilter(filterName = “AuthenticateFilter”, urlPatterns = {“/stock.jsp”, “/getquote”})

2. public class AuthenticateFilter implements Filter {

3.

4.     public void doFilter(ServletRequest request, ServletResponse response,

5.             FilterChain chain)     throws IOException, ServletException {

6.         String username = ((HttpServletRequest) request).getParameter(“uname”);

7.         String password = ((HttpServletRequest) request).getParameter(“password”);

8.           if (username == null || password == null) {

9.                  ((HttpServletResponse) response).sendRedirect(“index.jsp”);            }

10. if (username.equals(“admin”) && password.equals(“admin”)) {

11.                 chain.doFilter(request, response);      }

12. else {

13.                 ((HttpServletResponse) response).sendRedirect(“index.jsp”);         }

14.          }

15.

16.     public void destroy() {

17.     }

18.     public void init(FilterConfig filterConfig) {

19.     }

20. }

复制代码

@WebInitParam
可以使用@WebInitParam注解来制定Servlet或filter的初始参数。当然我们也可以使用@WebServlet或@WebFileter的initParam属性来指定初始参数。下面是使用@WebInitParam的例子:

1. @WebServlet(name = “GetQuoteServlet”, urlPatterns = {“/getquote”})

2. @WebInitParam(name = “default_market”, value = “NASDAQ”)

3. public class GetQuoteServlet extends HttpServlet {

4.     @Override

5.     protected void doGet(HttpServletRequest request, HttpServletResponse response)

6.             throws ServletException, IOException {

7.         response.setContentType(“text/html;charset=UTF-8”);

8.         PrintWriter out = response.getWriter();

9.         try {

10.             String market = getInitParameter(“default_market”);

11.             String symbol = request.getParameter(“symbol”);

12.             out.println(“<h1>Stock Price in ” + market + ” is</h1>” + StockQuoteBean.getPrice(symbol, market));

13.         } finally {

14.             out.close();

15.         }

16.     }

17. }

复制代码

下面是使用initParam属性的例子:

1. @WebServlet(name = “GetQuoteServlet”,

2.             urlPatterns = {“/getquote”},

3.             initParams={@WebInitParam(name=”default_market”,  value=”NASDAQ”)}

4.            )

5. public class GetQuoteServlet extends HttpServlet {

6.     @Override

7.     protected void doGet(HttpServletRequest request, HttpServletResponse response)

8.             throws ServletException, IOException {

9.         response.setContentType(“text/html;charset=UTF-8”);

10.         PrintWriter out = response.getWriter();

11.         try {

12.             String market = getInitParameter(“default_market”);

13.             String symbol = request.getParameter(“symbol”);

14.             out.println(“<h1>Stock Price in ” + market + ” is</h1>” + StockQuoteBean.getPrice(symbol, market));

15.         } finally {

16.             out.close();

17.         }

18.     }

19. }

复制代码

@WebListener
@WebListener注解被应用在作为listener监听web应用程序事件的类上,所以@WebListener能够被应用在实现了ServletContextListener,ServletContextAttributeListener,ServletRequestListener,ServletRequestAttributeListener,HttpSessionListener和HttpSessionAttributeListener接口的类上。在下面的例子中,该类实现了ServletContextListener接口。

1. @WebListener

2. public class QuoteServletContextListener implements ServletContextListener {

3.    public void contextInitialized(ServletContextEvent sce) {

4.    ServletContext context = sce.getServletContext();

5. context.setInitParameter(“default_market”, “NASDAQ”);

6. }

7. public void contextDestroyed(ServletContextEvent sce) {

8. }

9. }

复制代码

@MultipartConfig
使用@MultipartConfig注解来指定Servlet要求的multipart MIME类型。这种类型的MIME附件将从request对象中读取。
The Metadata and Common Annotations元数据与通用的注解
除了以上的Servlet特定的注解之外,Servlet3.0还支持JSR175(Java元数据规范)和JSR250(Java平台通用注解)所规定的注解,包括:
* 安全相关的注解,如 @DeclareRoles 和 @RolesAllowed
* 使用EJB的注解,如 @EJB 和 @EJBs
* 资源注入相关的注解,如 @Resource 和 @Resources
* 使用JPA的注解,如 @PersistenceContext, @PersistenceContexts, @PersistenceUnit, 和 @PersistenceUnits
* 生命周期的注解,如 @PostConstruct和 @PreDestroy
* 提供WebService引用的注解,如 @WebServiceRef and @WebServiceRefs
注解和web.xml哪个会生效
注解的引入使得web.xml变成可选的了。但是,我们还是可以使用web.xml。容器会根据web.xml中的metadata-complete元素的值来决定使用web.xml还是使用注解。如果该元素的值是true,那么容器不处理注解,web.xml是所有信息的来源。如果该元素不存在或者其值不为true,容器才会处理注解。
Web框架的可插入性
我们前面说过了Servlet3.0的改进之一就是使得我们能够将框架和库插入到web应用程序中。这种可插入性减少了配置,并且提高了web应用程序的模块化。Servlet3.0是通过web模块布署描述片段(简称web片段)来实现插入性的。
一个web片段就是web.xml文件的一部分,被包含在框架特定的Jar包的META-INF目录中。Web片段使得该框架组件逻辑上就是web应用程序的一部分,不需要编辑web布署描述文件。
Web片段中使用的元素和布署文件中使用的元素基本相同,除了根元素不一样。Web片段的根元素是<web-fragment>,而且文件名必须叫做web-fragment.xml。容器只会在放在WEB-INF\lib目录下的Jar包中查找web-fragment.xml文件。如果这些Jar包含有web-fragment.xml文件,容器就会装载需要的类来处理他们。
在web.xml中,我们要求Servlet的name必须唯一。同样的,在web.xml和所有的web片段中,Servlet的name也必须唯一。
下面就是一个web-fragment的例子:
web-fragment.xml

1. <web-fragment>

2. <servlet>

3. <servlet-name>ControllerServlet</servlet-name>

4. <servlet-class>com.app.control.ControllerServlet</servlet-class>

5. </servlet>

6. <listener>

7. <listener-class>com.listener.AppServletContextListener</listener-class>

8. </listener>

9. </web-fragment>

复制代码

框架的Jar包是放在WEB-INF\lib目录下的,但是Servlet3.0提供两种方法指定多个web片段之间的顺序:
1. 绝对顺序
2. 相对顺序
我们通过web.xml文件中的<absolute-ordering>元素来指定绝对顺序。这个元素有之元素name,name的值是各个web片段的name元素的值。这样就指定了web片段的顺序。如果多个web片段有相同的名字,容器会忽略后出现的web片段。下面是一个指定绝对顺序的例子:
web.xml

1. <web-app>

2. <name>DemoApp</name>

3. <absolute-ordering>

4. <name>WebFragment1</name>

5. <name>WebFragment2</name>

6. </absolute-ordering>

7. …

8. </web-app>

复制代码

相对顺序通过web-fragment.xml中的<ordering>元素来确定。Web片段的顺序由<ordering>的子元素<before>,<after>和<others>来决定。当前的web片段会放在所有的<before>元素中的片段之前。同样的,会放在所有的<after>元素中的片段之后。<others>用来代替所有的其他片段。注意只有当web.xml中没有<absolute-ordering>时,容器才会使用web片段中定义的相对顺序。
下面是一个帮助理解相对顺序的例子:
web-fragment.xml

1. <web-fragment>

2. <name>WebFragment1</name>

3. <ordering><after>WebFragment2</after></ordering>

4. …

5. </web-fragment>

复制代码

web-fragment.xml

1. <web-fragment>

2. <name>WebFragment2</name>

3. ..

4. </web-fragment>

复制代码

web-fragment.xml

1. <web-fragment>

2. <name>WebFragment3</name>

3. <ordering><before><others/></before></ordering>

复制代码

..
</web-fragment>
这些文件将会按照下面的顺序被处理:
1. WebFragment3
2. WebFragment2
3. WebFragment1
包含WebFragment3的Jar文件被最先处理,包含WebFragment2的文件被第二个处理,包含WebFragment1的文件被最后处理。
如果既没有定义绝对顺序,也没有定义相对顺序,那么容器就认为所有的web片段间没有顺序上的依赖关系。
Servlet中的异步处理
很多时候Servlet要和其他的资源进行互动,例如访问数据库,调用web service。在和这些资源互动的时候,Servlet不得不等待数据返回,然后才能够继续执行。这使得Servlet调用这些资源的时候阻塞。Servlet3.0通过引入异步处理解决了这个问题。异步处理允许线程调用资源的时候不被阻塞,而是直接返回。AsyncContext负责管理从资源来的回应。AsyncContext决定该回应是应该被原来的线程处理还是应该分发给容器中其他的资源。AsyncContext有一些方法如start,dispatch和complete来执行异步处理。
要想使用Servlet3.0的异步处理,我们需要设置@Webservlet和@WebFilter注解的asyncSupport属性。这个属性是布尔值,缺省值是false。
Servlet3.0的异步处理可以很好的和AJAX配合。在Servlet的init方法中,我们能够访问数据库或从JMS读取消息。在doGet或doPost方法中,我们能够启动异步处理,AsyncContext会通过AsyncEvent和AsyncListener来管理线程和数据库操作/JMS操作自己的关系。
已有API的改进
除了这些新特性之外,Servlet3.0还对以往已经存在的API做了一些改进。
HttpServletRequest
To support the multipart/form-data MIME type, the following methods have been added to the HttpServletRequest interface:
为了支持multipart/form-data MIME类型,在HttpServletRequest接口中添加了项目的方法:
* Iterable<Part> getParts()
* Part getPart(String name)
Cookies
为了避免一些跨站点攻击,Servlet3.0支持HttpOnly的cookie。HttpOnly cookie不想客户端暴露script代码。Servlet3.0在Cookie类中添加了如下的方法来支持HttpOnly cookie:
* void setHttpOnly(boolean isHttpOnly)
* boolean isHttpOnly()
ServletContext
通过在ServletContext中添加下面的方法,Servlet3.0允许Servlet或filter被编程的加入到context中:
* addServlet(String servletName, String className)
* addServlet(String servletName, Servlet servlet)
* addServlet(String servletName, Class<? extends Servlet> servletClass)
* addFilter(String filterName, String className)
* addFilter(String filterName, Filter filter)
* addFilter(String filterName, Class<? extends Filter>filterClass)
* setInitParameter (String name, String Value)

Servlet3.0新功能: 异步处理

J2EE 6和Glassfish 3V正式发布了,J2EE 6正式发布了Servlet3.0, 为了能更好的对WEB2.0提供支持, 3.0添加了异步处理的机制.

 

HTTP1.1相对于HTTP1.0的影响.

 

HTTP1.1最大的一个改变就是提供了长连接,这样HTTP不再是一次请求,一次连接的协议了,只要HTTP的connection不关闭,一次HTTP连接可以支持任意多次request/reponse处理. 当WEB Client与WEB Server建立连接时,客户端可以采用长连接,也就是说Client会一直保持对WEB Server的连接(例如:Browser对一个网站保持当连接,知道Browser关闭或最终退出该网站). 旧的WEB Server会为每一个Http连接分配一个active的Thread,这样当Client的数量增大时,Server端Thread Pool的最大容量也需要相应增大,但Thread是相当耗内存的,一个不小心就会导致Server端NotEnoughMemory…

 

基于HTTP1.1,大部分支持Servlet2.X的WEB容器都采用的NIO去接收和处理请求. 当Client和Server端建立连接时,Server端并不分配一个Thread给HTTP连接.直到Server端收到Client端发送的Request时, Server才开始为该Request分配Thread(注意:这里不是为HTTP连接分配Thread).

 

这样当大量的Client建立长连接与Server进行交互时,Server无需维持一个Thread给inactive的HTTP长连接, 每个Servlet在doReceived()时其实对应的是一个active Request,而不是HTTPConnection本身. 这样Server端所需的最大Thread数大大地减少了.

 

AJAX的影响

 

1. Request的数量爆炸性增加增加

 

过去WEB Browser打开一个Web page,只需要和Web Server端建立一个HTTP连接.但AJAX技术出现以后,一个Web page上可能有多个与Web Server的连接,而且Ajax request通常是十分频繁的,Server接收到的Request数量大大增长了, 这样原先NIO的技术已经不能很好的支持基于Ajax的服务了.

 

Servlet 3.0的异步处理就能够解决上面的问题.

 

Servlet3.0的solution:

当request发送到Server端时,servlet的doReceived()将request放进一个queue里,然后doReceived结束.这个时候server并没有关闭response,Client端一直在等server端response的内容. Server端维护自己的ThreadPool,当ThreadPool里有idle的Thread,就从queue里取出一个request,分配idle的Thread给request,并进行处理.

 

Java代码 
  1.    @WebServlet(“/test” asyncSupported=true)
  2.    public class MyServlet extends HttpServlet {
  3.        ScheduledThreadPoolExecutor executor = null;
  4.         public void init(ServletConfig arg0) throws ServletException {
  5.                    executor = new ThreadPoolExecutor(10);//独立的线程池处理请求
  6.         }
  7.         public void doGet(HttpServletRequest req, HttpServletResponse res) {
  8.             …
  9.             AsyncContext aCtx = request.startAsync(req, res);
  10.             executor.execute(new AsyncWebService(aCtx));//异步处理
  11.         }
  12.    }
  13.    public class AsyncWebService implements Runnable {
  14.         AsyncContext ctx;
  15.         public AsyncWebService(AsyncContext ctx) {
  16.             this.ctx = ctx;
  17.         }
  18.         public void run() {//处理请求
  19.             //Do something here …
  20.             // Dispatch the request to render the result to a JSP.
  21.             ctx.dispatch(“/render.jsp”);
  22.    }
  23. }
   @WebServlet("/test" asyncSupported=true)   public class MyServlet extends HttpServlet {       ScheduledThreadPoolExecutor executor = null;        public void init(ServletConfig arg0) throws ServletException {                   executor = new ThreadPoolExecutor(10);//独立的线程池处理请求        }        public void doGet(HttpServletRequest req, HttpServletResponse res) {            ...            AsyncContext aCtx = request.startAsync(req, res);            executor.execute(new AsyncWebService(aCtx));//异步处理        }   }   public class AsyncWebService implements Runnable {        AsyncContext ctx;        public AsyncWebService(AsyncContext ctx) {            this.ctx = ctx;        }        public void run() {//处理请求            //Do something here ...            // Dispatch the request to render the result to a JSP.            ctx.dispatch("/render.jsp");   }}

以上的例子可以用于处理对Ajax的请求,因为通常Ajax的请求多,但对响应速度的要求并不太高. 对于正常的页面请求,要求一定的响应速度,可以沿用以前Servlet同步的实现.

 

2. Server端推送信息

在Web2.0的应用中, Ajax可用通过不断的发送Request来获取Server端某种信息的变化,但这种实现会产生大量的Client请求. 当前推荐的方法是,让Server端自己推送信息变化给Client.

 

因为Servlet3.0提供了异步处理的方式, Request提交给Server以后, Server可以为Request注册一个Listener,由Listener去monitor信息的变化,当信息发生变化时,由Listener负责把信息变化发送给Cient(Listener关闭HTTP response).

j2ee标准-web.xml中的web-app标签分析

当用eclipse创建 dynamic web project 时,创建过程中  需要选择一个 dynamic web module version 。当前可选择的取值有 2.2    2.3   2.4   2.5   3.0   3.1  取值完毕时  ,项目中的   web.xml  里面的   web-app 版本 就是   dynamic web module version 值。  这个值 其实 就是 servlet 版本值。(servlet 版本升级,都会带来一些新的功能)

每个tomcat版本对应的标准servlet版本,如下:

The XSD version is preferred since JSP 2.0 / Servlets 2.4 (eg: Tomcat 5.5). Note that the XML encoding can be specified as ISO-8859-1, UTF-8, or any other valid encoding in either version, and should match the actual encoding of your text file.

注意 servlet 2.4、3.1之后xsi的变化。

Servlet 3.1 deployment descriptor

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
		 http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
</web-app>

XSD example for JSP 2.2 / Servlets 3.0 (Tomcat 7.0):

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
      version="3.0">

</web-app>

XSD example for JSP 2.1 / Servlets 2.5 (Tomcat 6.0):

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
     version="2.5">

</web-app>

XSD example for JSP 2.0 / Servlets 2.4 (Tomcat 5.5):

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
     version="2.4">

</web-app>

DTD example for JSP 1.2 / Servlets 2.3 (Tomcat 5):

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE web-app
   PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
   "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

</web-app>&nbsp;

官方参考可见http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html。

对于spring,对应关系如下:
  • 4.0 最低要求JDK 6,支持websocket, Servlet 3.0+
  • 3.0 最低要求JDK 1.5,基于注解的配置,servlet 2.4,完全支持REST,包从spring.jar拆分为按模块进行组织
  • 2.5 最低要求JDK 1.4.2,Servlet 2.3, JSP 1.2
========================================================================
十余年金融IT行业团队管理,系统架构,数据库架构与优化经验
擅长于大规模高并发j2ee soa体系系统架构设计与实现,精通j2ee系统性能分析与优化
精通oltp&dss oracle&mysql数据库设计、性能分析与优化、HA、分库分表应用架构设计与实现
我的开源项目io.spider,mysqlawr,logpool。https://git.oschina.net/zhjh256
来自:https://www.cnblogs.com/zhjh256/p/6118158.html

 


Servlet 3十二月2009开发平台标准版6,6可插性,易于开发,异步ser vlet,安全,文件上传
Servlet 2.5九月2005开发平台标准版5,5需要平台标准版5,支持注释
Servlet 2.4十一月2003中1.4,1.3 web.xml新解
Servlet 2.1十一月1998未正式规范,添加Dispatcher,Ser vlet Cont ext
Servlet 2类1.1部分程序开发工具包2
Servlet 1六月1997定义

j2ee标准-web.xml中load-on-startup源码解析

查看tomcat 7.0 源码:

/**
 * Load and initialize all servlets marked "load on startup" in the
 * web application deployment descriptor.
 *
 * @param children Array of wrappers for all currently defined
 *                 servlets (including those not declared load on startup)
 */
/**
 * StandardContext类,代表webapps目录下的一个web应用
 * 方法会被startInternal调用(),也就是应用在启动的时候
 * @param children
 * @return
 */
public boolean loadOnStartup(Container children[]) {

    // Collect "load on startup" servlets that need to be initialized
    //用TreeMap来排序 默认为natural order,也就是按ascii码
    TreeMap<Integer, ArrayList<Wrapper>> map =
            new TreeMap<Integer, ArrayList<Wrapper>>();
    for (int i = 0; i < children.length; i++) {
        Wrapper wrapper = (Wrapper) children[i];
        //每个Wrapper对应一个Servlet,负责创建、初始化、销毁servlet,并为其提供ServletConfig
        int loadOnStartup = wrapper.getLoadOnStartup();
        if (loadOnStartup < 0) //如果loadOnStartup的配置参数小于0,则不添加到TreeMap中
            continue;
        Integer key = Integer.valueOf(loadOnStartup);
        ArrayList<Wrapper> list = map.get(key);
        if (list == null) {
            list = new ArrayList<Wrapper>();
            map.put(key, list);
        }
        list.add(wrapper);
    }

    // Load the collected "load on startup" servlets
    //按loadOnStartup 的natural order即升序,依次对servlet进行初始化
    for (ArrayList<Wrapper> list : map.values()) {
        for (Wrapper wrapper : list) {
            try {
                //此方法包含对servlet的实例化和init方法的调用
                wrapper.load();
            } catch (ServletException e) {
                getLogger().error(sm.getString("standardContext.loadOnStartup.loadException",
                        getName(), wrapper.getName()), StandardWrapper.getRootCause(e));
                // NOTE: load errors (including a servlet that throws
                // UnavailableException from the init() method) are NOT
                // fatal to application startup
                // unless failCtxIfServletStartFails="true" is specified
                if (getComputedFailCtxIfServletStartFails()) {
                    return false;
                }
            }
        }
    }
    return true;

}

代码和清晰

总结:如果web.xml中的servlet没有配置 <load-on-startup> 标签或者其值小于0,那么在容器启动时不会对其初始化;否则按照数字升序排列串行对其初始化(这也证实了 正数的值越小,启动该servlet的优先级越高 这句话)。

来自:https://blog.csdn.net/joenqc/article/details/73497804


自己动手 单独测试了一下:

一、创建最新的dynamic web project
二、在WebContent目录中(即网站根目录),创建 index.jsp   如下:
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Insert title here</title>
</head>
<body>







<h3> helleo  word</h3>







</body>
</html>
三、编辑web.xml  文件 如下:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" id="WebApp_ID" version="3.1">
  <display-name>webXml</display-name>
  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
    <welcome-file>default.html</welcome-file>
    <welcome-file>default.htm</welcome-file>
    <welcome-file>default.jsp</welcome-file>
  </welcome-file-list>
  <servlet>
    <servlet-name>S1</servlet-name>
    <servlet-class>com.web.servlet.S1</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet>
    <servlet-name>S2</servlet-name>
    <servlet-class>com.web.servlet.S2</servlet-class>
    <load-on-startup>2</load-on-startup>
  </servlet>
  <servlet>
    <servlet-name>S3</servlet-name>
    <servlet-class>com.web.servlet.S3</servlet-class>
    <load-on-startup>-1</load-on-startup>
  </servlet>
  <servlet>
    <servlet-name>S4</servlet-name>
    <servlet-class>com.web.servlet.S4</servlet-class>
    <load-on-startup>4</load-on-startup>
  </servlet>
  <servlet>
    <servlet-name>S5</servlet-name>
    <servlet-class>com.web.servlet.S5</servlet-class>
    <load-on-startup>0</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>S1</servlet-name>
    <url-pattern>/s1</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>S2</servlet-name>
    <url-pattern>/s2</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>S3</servlet-name>
    <url-pattern>/s3</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>S4</servlet-name>
    <url-pattern>/s4</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>S5</servlet-name>
    <url-pattern>/s5</url-pattern>
  </servlet-mapping>
</web-app>
四、创建 servlet 文件:

在 com.web.servlet 下面创建 5个 差不多的 servlet (eclipse 右键新建 servlet 即可) ,仅在 url ,构造函数 上进行了修改
S1 代码:

package com.web.servlet;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * Servlet implementation class S1
 */
@WebServlet(name = "S001", urlPatterns = { "/001" })
public class S1 extends HttpServlet {
	private static final long serialVersionUID = 1L;
       
    /**
     * @see HttpServlet#HttpServlet()
     */
    public S1() {
        super();
        System.out.println("S1:init ready");
        // TODO Auto-generated constructor stub
    }

	/**
	 * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
	 */
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		// TODO Auto-generated method stub
		response.getWriter().append("Served at: ").append(request.getContextPath());
	}

	/**
	 * @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response)
	 */
	protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		// TODO Auto-generated method stub
		doGet(request, response);
	}

}

同理 S2代码如下:

package com.web.servlet;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * Servlet implementation class S1
 */
@WebServlet(name = "S002", urlPatterns = { "/002" })
public class S2 extends HttpServlet {
	private static final long serialVersionUID = 1L;
       
    /**
     * @see HttpServlet#HttpServlet()
     */
    public S2() {
        super();
        System.out.println("S2:init ready");
        // TODO Auto-generated constructor stub
    }

	/**
	 * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
	 */
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		// TODO Auto-generated method stub
		response.getWriter().append("Served at: ").append(request.getContextPath());
	}

	/**
	 * @see HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response)
	 */
	protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		// TODO Auto-generated method stub
		doGet(request, response);
	}

}

其他servlet代码 类似

五、测试结果总结:

1、load on startup 大于等于 0,服务器启动时,会加载servlet ,并调用servlet的init方法。当以后 用 url 再访问 servlet时,servlet 不会再创建了,直接回把之前创建好的,直接拿过来用了。

@Override
public void init() throws ServletException {
	// TODO Auto-generated method stub
	super.init();
}

如果load on startup 值小于0,那么服务器启动时不会加载,直达 调用时才会 加载。加载完成后,以后调用时,就直接拿来用了,不会再创建第二遍了。

2、servlet 3.0 加入了注解功能,我上面写的S1。。。都用了注解。url 可以用/S1访问,也可以用 /001 访问。因为 同一个 servlet 配置时取了两个名字,两个路径。服务器 启动时,会当做两个 servlet 来处理,每种 url 访问都会创建一次。

j2ee标准-web.xml文件的含义

每个javaEE工程中都有web.xml文件,那么它的作用是什么呢?它是每个web.xml工程都必须的吗?

一个web中可以没有web.xml文件,也就是说,web.xml文件并不是web工程必须的。

web.xml文件是用来初始化配置信息:比如Welcome页面、servlet、servlet-mapping、filter、listener、启动加载级别等。

当你的web工程没用到这些时,你可以不用web.xml文件来配置你的Application。

每个xml文件都有定义它书写规则的Schema文件,也就是说javaEE的定义web.xml所对应的xml Schema文件中定义了多少种标签元素,web.xml中就可以出现它所定义的标签元素,也就具备哪些特定的功能。web.xml的模式文件是由Sun 公司定义的,每个web.xml文件的根元素为<web-app>中,必须标明这个web.xml使用的是哪个模式文件。如:
<?xml version=”1.0″ encoding=”UTF-8″?>
<web-app version=”2.5″
xmlns=”http://java.sun.com/xml/ns/javaee”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd”>
</web-app>

web.xml的模式文件中定义的标签并不是定死的,模式文件也是可以改变的,一般来说,随着web.mxl模式文件的版本升级,里面定义的功能会越来越复杂,标签元素的种类肯定也会越来越多,但有些不是很常用的,我们只需记住一些常用的并知道怎么配置就可以了。

下面列出web.xml我们常用的一些标签元素及其功能:

1、指定欢迎页面,例如:
<welcome-file-list>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index1.jsp</welcome-file>
</welcome-file-list>
PS:指定了2个欢迎页面,显示时按顺序从第一个找起,如果第一个存在,就显示第一个,后面的不起作用。如果第一个不存在,就找第二个,以此类推。

关于欢迎页面:

访问一个网站时,默认看到的第一个页面就叫欢迎页,一般情况下是由首页来充当欢迎页的。一般情况下,我们会在web.xml中指定欢迎页。但 web.xml并不是一个Web的必要文件,没有web.xml,网站仍然是可以正常工作的。只不过网站的功能复杂起来后,web.xml的确有非常大用处,所以,默认创建的动态web工程在WEB-INF文件夹下面都有一个web.xml文件。

2、命名与定制URL。我们可以为Servlet和JSP文件命名并定制URL,其中定制URL是依赖命名的,命名必须在定制URL前。下面拿serlet来举例:
(1)、为Servlet命名:
<servlet>
<servlet-name>servlet1</servlet-name>
<servlet-class>org.whatisjava.TestServlet</servlet-class>
</servlet>

(2)、为Servlet定制URL、
<servlet-mapping>
<servlet-name>servlet1</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>

3、定制初始化参数:可以定制servlet、JSP、Context的初始化参数,然后可以再servlet、JSP、Context中获取这些参数值。

下面用servlet来举例:
<servlet>
<servlet-name>servlet1</servlet-name>
<servlet-class>org.whatisjava.TestServlet</servlet-class>
<init-param>
<param-name>userName</param-name>
<param-value>Daniel</param-value>
</init-param>
<init-param>
<param-name>E-mail</param-name>
<param-value>[email protected]</param-value>
</init-param>
</servlet>
经过上面的配置,在servlet中能够调用getServletConfig().getInitParameter(“param1”)获得参数名对应的值。

4、指定错误处理页面,可以通过“异常类型”或“错误码”来指定错误处理页面。
<error-page>
<error-code>404</error-code>
<location>/error404.jsp</location>
</error-page>
—————————–
<error-page>
<exception-type>java.lang.Exception<exception-type>
<location>/exception.jsp<location>
</error-page>

5、设置过滤器:比如设置一个编码过滤器,过滤所有资源
<filter>
<filter-name>XXXCharaSetFilter</filter-name>
<filter-class>net.test.CharSetFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>XXXCharaSetFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

6、设置监听器:
<listener>
<listener-class>net.test.XXXLisenet</listener-class>
</listener>

7、设置会话(Session)过期时间,其中时间以分钟为单位,假如设置60分钟超时:
<session-config>
<session-timeout>60</session-timeout>
</session-config>

除了这些标签元素之外,还可以往web.xml中添加很多标签元素,由于不常用省略。

来自:https://www.cnblogs.com/yqskj/articles/2233061.html

j2ee标准-web-inf文件夹的意义

写这篇文章的原因是看到了Tomcat下面的Webapps下面的,就想看一下。

总结一下这篇文章的内容:

WEB-INF下面的内容都是只能由服务器级别才能访问,客户端并不能访问。什么是客户端级别?什么是服务器级别呢?

转发就是服务器级别,浏览器的地址不会变,因为,客户端发送一个请求,服务器受理之后,发现要请求内容还要再去别的请求,那么转发就是服务器自己去处理完成。不麻烦客户端(浏览器)了,所以客户端上面的地址栏不会改变。

重定向:就是客户端级别的。服务器收到请求后,发现还要去请求别的内容,但是服务器自己不想处理,那么就告诉客户端,你自己去处理吧,那么客户端就去请求那个别的内容了。所以客户端(浏览器)地址栏就会改变了。


在web项目中,为了安全,可能需要把jsp文件放在WEB-INF目录下,这样如果我们的页面中出现超链接a标签或者js的location.href去直接转向到WEB-INF下的某一个jsp页面,那么就会引用不到,因为这样的请求方式是客户端的请求,而WEB-INF页面只对服务端开放,对客户端是不可见的。这时候我们可以使用action,来进行转向,我们先去请求一个action,然后由这个action分发到这个WEB-INF下的页面就可以了。我们可以自己定义一个类似struts1的DispatcherAction的一个action来分发页面。

由于WEB-INF下对客户端是不可见的,所以相关的资源文件,如css,javascript和图片等资源文件不能放在WEB-INF下,那么如何从WEB-INF下引用非WEB-INF下的文件,以及js,html的frame的框架如何去访问WEB-INF下的jsp呢?

下面对WEB-INF目录的一些问题进行详细说明:

以一个项目为例:

如下这样一个代码目录:我们把除index.jsp外其他的jsp文件放在WEB-INF下,把css,javascript,图片放在了webRoot(WebContent)目录下,然后main.jsp是一个frame的html框架,包含了main1.jsp和main2.jsp两个文件。

1、index.jsp页面访问css,js,图片等文件的时候,自然不用说,因为它不在WEB-INF下,正常的访问即可:

<link href="css/login_css.css" rel="stylesheet" type="text/css">

<script type="text/javascript" src="js/login_js.js"></script>

<img alt="" src="image/1.jpg">

2、register.jsp页面去访问css,js和图片的时候,也是不需要添加WEB-INF目录的,也就是忽略WEB-INF目录,访问的时候和index.jsp页面所在的路径访问资源文件是一样的:

<link href="css/register_css.css" rel="stylesheet" type="text/css">

<script type="text/javascript" src="js/register_js.js"></script>

<img alt="" src="image/2.jpg">

3、register.jsp页面去转向index.jsp页面,即注册页面有一个链接,转向到登录界面,由于index.jsp页面没有在WEB-INF下,所以可以直接访问index.jsp页面的路径,

 register.jsp:

<tr>

    <td></td>

    <td colspan="2" style="float: left; ">

        <button type="button" >注册</button>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

        <button type="button"  onclick="goLogin()">去登录</button>

    </td>

</tr>

在register.jsp页面中定义了一个botton,然后响应一个onclick事件,

我们在register_js.js中定义这个goRegister ()的js事件:

regitster_js.js:

function goLogin(){

    location.href="index.jsp";

}

这样就可以访问到WebContent目录中的index.jsp页面了。

 

4、index.jsp(登录页面)有一个链接,指向register页面,如果点击链接,就跳转到register.jsp中进行注册,因为register.jsp在WEB-INF下,所以不可以直接使用a标签去访问WEB-INF路径下的文件:

<a href="WEB-INF/register/register.jsp">去注册</a>

或者js的location.href去访问:

function goRegister(){  

    location.href="WEB-INF/register/register.jsp";

}

这样两种方式都是直接请求了WEB-INF路径,都是无法跳转的。

我们可以建立一个action,struts的action中没有DispatcherAction,但是我们可以通过通配符来让一个action的不同方法返回不同的页面,然后我们去请求这个action中的相应方法即可由这个action从服务器端请求到WEB-INF下的页面了:

下面详细说明如果进行自定义的分发action来进行页面的分发:

DispatcherAction.java:

package com.yun.test.webinf.action;

import com.opensymphony.xwork2.ActionSupport;
publicclass DispatcherAction extends ActionSupport{
    public String goRegister(){

        return"goRegister";

    }
}

这个action中,我们定义了一个goRegister的方法,这个方法没有任何逻辑代码,只是返回一个字符串,然后在struts.xml中我们让这个字符串指向我们要访问的WEB-INF下的register.jsp页面:

struts.xml:

<action name ="dispatcher" class="com.yun.test.webinf.action.DispatcherAction" >

    <result name ="goRegister">WEB-INF/register/register.jsp</result >

    <result name ="input">/index.jsp</result >

</action >

然后我们可以在页面中进行请求DispatcherAction的goRegister方法,然后这个action的goRegister方法就会把页面转向到WEB-INF下的register.jsp页面了:

我们在index.jsp中定义了一个botton,然后给这个botton注册一个点击事件:

index.jsp:

<tr>

    <td></td>

    <td colspan="2" style="float: left; ">

        <button onclick="checkValues()">登录</button>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

        <button type="button" id="button1" onclick="goRegister()">去注册</button>

    </td>

</tr>

在index_js.js中定义这个点击事件为location.href到定义的action的goRegister.action方法中:

login_js.js:

function goRegister(){

    location.href="dispatcher!goRegister.action";

}

当然,也可以直接在页面中使用a标签来请求这个action的goRegister方法:

    <a href="dispatcher!goRegister.action">去注册</a>

这样我们就可以通过action的转发,成功的请求道WEB-INF下的jsp文件了。

注意请求action的方式,dispatcher!goRegister.action  这个!是一个分发字符,!之前的部分是action的名字,!之后的部分是这个action的某个我们要请求的方法的名字。然后这个action中必须要定义一个同名的方法,就不需要使用execute方法了。然后这个同名方法,返回的是一个String字符串,这个字符串在struts.xml中指向为我们想要跳转的路径。这就是一个请求分发的action。

我们还可以自己定义分发的分隔符,可以是下划线等,分发action详见Struts2实现分发的action一节

5、jsp页面中的frame框架中想把多个WEB-INF下的页面设置为框架的内容的时候,即使main.jsp和main1.jsp,main2.jsp同在WEB-INF目录下,也不可以直接去指定WEB-INF路径,如:

<frameset cols="30%,70%">

    <frame src="main/main1.jsp">

    <frame src="main/main1.jsp">

</frameset>

这样还是不能访问,也必须使用服务端的action分发的方式进行指定jsp文件的路径。

代码如下:

main.jsp:

<%@ page language="java" contentType="text/html; charset=UTF-8"

    pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>main</title>
</head>
<frameset cols="30%,70%">

    <frame src="dispatcher!goMain1.action">

    <frame src="dispatcher!goMain2.action">

</frameset>
</html>

struts.xml:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE struts PUBLIC

    "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"

    "http://struts.apache.org/dtds/struts-2.0.dtd">

    

<struts >

    <package name ="test" extends ="struts-default" >

        <action name ="dispatcher" class ="com.yun.test.webinf.action.DispatcherAction" >

            <result name ="goRegister">WEB-INF/register/register.jsp</result >

            <result name ="goMain1">WEB-INF/main/main1.jsp</result >

            <result name ="goMain2">WEB-INF/main/main2.jsp</result >

            <result name ="input">/index.jsp</result >

        </action >

        <action name ="login" class ="com.yun.test.webinf.action.LoginAction" >

            <result name ="success">WEB-INF/main.jsp</result >

            <result name ="input">/index.jsp</result >

        </action >

        <action name ="register" class ="com.yun.test.webinf.action.RegisterAction" >

            <result name ="success">WEB-INF/main.jsp</result >

            <result name ="input">WEB-INF/register/register.jsp</result >

        </action >
  </package>
<!-- 定义struts标签为无默认样式 -->

    <constant name="struts.ui.theme" value="simple" />

</struts>

DispatcherAction.java:

package com.yun.test.webinf.action;

import com.opensymphony.xwork2.ActionSupport;

publicclass DispatcherAction extends ActionSupport{
    public String goRegister(){
        return"goRegister";

    }

    public String goMain1(){
        return"goMain1";
    }

    public String goMain2(){

        return"goMain2";

    }
}

这样,这个main页面就可以通过action分发使用frame框架了。

 

6、同在WEB-INF目录下的register.jsp和main.jsp中怎么跳转呢?我们会在register.jsp中提交表单,然后在action中进行处理,如果注册成功,会跳转到main页面,这时的跳转也会涉及到WEB-INF目录,因为目标路径main.jsp也在WEB-INF下,所以我们在跳转的时候也必须写上WEB-INF的目录路径才可以,而且必须是请求分发,而不能是redirct的方式。

如代码:

register.jsp:

<%@ page language="java" contentType="text/html; charset=UTF-8"

    pageEncoding="UTF-8"%>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<title>register</title>

<link href="css/register_css.css" rel="stylesheet" type="text/css">

<script type="text/javascript" src="js/register_js.js"></script>

</head>

<body>
    <div id="content" >

    <form action="register.action" id="registerForm"  method="post">
        <table>

            <tr>

                <td width="150px;" style="text-align:center; ">注册名</td>

                <td width="80px;" style="text-align: left;"><input type="text" name="user.username"  id="username" ></td>

                <td width="400px;" style="text-align: left;"><font color="red">* 请输入用户名</font></td>

            </tr>

            <tr>

                <td width="100px;" style="text-align:center; ">注册密码</td>

                <td width="80px;" style="text-align: left;"><input type="password" name="user.password" size="22" id="password"></td>

                <td width="400px;" style="text-align: left;"><font color="red">* 请输入密码</font></td>

            </tr>

            <tr>

                <td></td>

                <td colspan="2" style="float: left; ">

                    <button type="button"  onclick="checkValues()">注册</button>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

                    <button type="button"  onclick="goLogin()">去登录</button>

                </td>

            </tr>

        </table>

 

     </form>

    </div>

    <img alt="" src="image/2.jpg">

</body>

</html>

struts.xml:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE struts PUBLIC

    "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"

    "http://struts.apache.org/dtds/struts-2.0.dtd">
<struts >

    <package name ="test" extends ="struts-default" >

        <action name ="dispatcher" class ="com.yun.test.webinf.action.DispatcherAction" >

            <result name ="goRegister">WEB-INF/register/register.jsp</result >

            <result name ="goMain1">WEB-INF/main/main1.jsp</result >

            <result name ="goMain2">WEB-INF/main/main2.jsp</result >

            <result name ="input">/index.jsp</result >

        </action >

        <action name ="login" class ="com.yun.test.webinf.action.LoginAction" >

            <result name ="success">WEB-INF/main.jsp</result >

            <result name ="input">/index.jsp</result >

        </action >

        <action name ="register" class ="com.yun.test.webinf.action.RegisterAction" >

            <result name ="success">WEB-INF/main.jsp</result >

           <result name ="input">WEB-INF/register/register.jsp</result >

        </action >

 

    </package>

 

    <!-- 定义struts标签为无默认样式 -->

    <constant name="struts.ui.theme" value="simple" />

</struts>

RegisterAction.java:

package com.yun.test.webinf.action;

import com.opensymphony.xwork2.ActionSupport;

import com.yun.test.webinf.entity.User;
public class RegisterAction extends ActionSupport{
         private User user;
         public void setUser(User user) {
                   this.user = user;

         }

         public User getUser() {
                   return user;

         }

         @Override

         public String execute() throws Exception {

                   if("lisi".equals(user.getUsername())&&"lisi".equals(user.getPassword())){

                            return SUCCESS;

                   }

                   return INPUT;

         }

         

}

 

接下来对WEB-INF页面中的注意事项进行说明:

1、把页面资源文件只能放在WebContent目录内,,如CSS,JS,image等.不能放在WEB-INF下,因为WEB-INF是对客户端隐藏的,所以放在WEB-INF下会造成页面的布局等文件引用不到的情况。
2、页面文件一般放在WEB-INF目录下面,这样可以限制访问,提高安全性.如JSP,html文件,放在WEB-INF目录下就可以避免客户端直接在地址栏上输入路径进行访问了。基于不同的功能,把JSP 放置在WEB-INF下的不同的目录中。
3、只能用转向方式来访问WEB-INF目录下的JSP,不用采用重定向的方式请求该目录里面的任何资源。
4、转向方式:

4.1、请求转发:

如struts.xml文件中配置

<result name ="goMain2">WEB-INF/main/main2.jsp</result >

或在Action中写

request.getRequestDispatcher(“/WEB-INF/main/main2.jsp”).forward(request, response);

的方式都是服务器读取了该页面内容,并发送到客户端的,客户端的地址不变,然后内容跳转了。这样的方式是可以访问到WEB-INF目录下的jsp文件的。

4.2、重定向方式:

如struts.xml文件中配置

<result name ="goMain2" type="redirect">WEB-INF/main/main2.jsp</result >

 或在action中

response.sendRedirect(“WEB-INF/main/main2.jsp “);

都属于重定向的方式,重定向的含义就是服务器把地址发给客户端,让客户端去访问,这样还是在客户端访问的WEB-INF目录,所以是无法访问到WEB-INF目录下的jsp文件的。

5、有一些标签,也是可以访问到WEB-INF目录中的文件的,如果符合要求的情况下也可以使用,如:

<jsp:forward page = "/WEB-INF/jsp/test/test.jsp" />

<a href="javascript:<jsp:forward page='WEB-INF/xxxx.jsp'/>"></a>

<jsp:include page="WEB-INF/xxx.jsp">

都是可以访问WEB-INF下的jsp文件的。但是局限性很大,还是建议使用action分发的方式。

来自:https://www.cnblogs.com/shenxiaoquan/p/5819359.html

j2ee标准-j2ee简介

人们平常说的Java一般指JavaSE,也就是Java Standard Edition,Java的标准版,一般用来开发桌面应用程序,但是在开发桌面应用程序上相对VB,Delphi,VC++并没有什么优势。

而JavaWeb则到了JavaEE(J2EE)领域了,也就是Java Enterprise Edition,Java的企业版,看那个web就应该想到是与Internet有关的,其实开发JavaWeb应用程序,初级的一般是用JSP(Java Server Pages)+servlet+Javabean来开发的,对大型的网站一般是使用框架来开发的,例如struts,hibernate,spring,例如校内,你在登陆的时候会在地址栏看见Login.do,登陆以后会看见Home.do这样的请求,典型的struts框架结构。

J2EE核心是一组技术规范与指南,其中所包含的各类组件、服务架构及技术层次,均有共同的标准及规格,让各种依循J2EE架构的不同平台之间,存在良好的兼容性,解决过去企业后端使用的信息产品彼此之间无法兼容,企业内部或外部难以互通的窘境。

Java还有一个版本是JavaME,Java Micro Edition,Java的微型版,诺基亚手机上运行的Java程序就是指用这个版本开发的程序。

 

 

浏览器兼容-浏览器兼容性待整理(三)

序章

  • 谈谈“浏览器兼容性”的问题?
    • 很多前端的面试或笔试中,都有比较笼统的“说说你所知道的各浏览器存在的兼容问题”,个人感觉这个问题问的太“大”了些,从样式到脚本,都会有很多不一样的地方(特别是IE8-对比主流浏览器)。实际回答的时候就会晕乎乎的不清楚如何抓住重点地来阐述。到底怎样回答这个问题,才能较为全面又不失重点,并让面试官感到满意呢?
  • 首先明确一个概念,“谈谈浏览器兼容性”的问题和“说说你所知道的各浏览器存在的兼容问题”是两个完全不同的问题。
  • 前者,鬼知道他想要问什么,得追问。
    比如得问“您说的是哪个浏览器的哪类问题?还是常用浏览的(前端)API差异?渲 染差异?等等。还是要谈谈浏览器为什么存在兼容问题?兼容存在的历史原因?历史必然性等等”。
    后者,基本上是个有着较明确边界范围的开放问题。
    基本上可以知道,他是想了解你常用的常见到的常解决到的,或者近期刚刚解决过的一些浏览器兼容问题。从而判断你这部分知识面、解决问题的思路等等方面内容,而且不像前者一样慢无边界的。
    起码,这么问的是不太闲,不想陪你唠嗑的。
  • 如果面试官纠结于你没回答出某个兼容性问题,即使要了你也不要去。 特别是那种还在炫耀IE6+ 1px技能的老先生。 现在还谈IE6+兼容性的面试官,真的挺掉公司的价的。
  • 下面我们由浅到深,由简到易的回答这个笼统的“浏览器兼容性”问题!

CSS篇

1. 一些常见问题汇总

  • 浏览器兼容问题一:不同浏览器的标签默认的外补丁和内补丁不同
    问题症状:随便写几个标签,不加样式控制的情况下,各自的margin 和padding差异较大。
    碰到频率:100%
    解决方案:CSS里 *{margin:0;padding:0;}
    备注:这个是最常见的也是最易解决的一个浏览器兼容性问题,几乎所有的CSS文件开头都会用通配符*来设置各个标签的内外补丁是0。
  • 浏览器兼容问题二:块属性标签float后,又有横行的margin情况下,在IE6显示 margin比设置的大
    问题症状:常见症状是IE6中后面的一块被顶到下一行
    碰到频率:90%(稍微复杂点的页面都会碰到,float布局最常见的浏览器兼容问题)
    解决方案:在float的标签样式控制中加入 display:inline;将其转化为行内属性
    备注:我们最常用的就是div+CSS布局了,而div就是一个典型的块属性标签,横向布局的时候我们通常都是用div float实现的,横向的间距设置如果用margin实现,这就是一个必然会碰到的兼容性问题。
  • 浏览器兼容问题三:设置较小高度标签(一般小于10px),在IE6,IE7,遨游中高度超出自己设置高度
    问题症状:IE6、7和遨游里这个标签的高度不受控制,超出自己设置的高度
    碰到频率:60%
    解决方案:给超出高度的标签设置overflow:hidden;或者设置行高line-height 小于你设置的高度。
    备注:这种情况一般出现在我们设置小圆角背景的标签里。出现这个问题的原因是IE8之前的浏览器都会给标签一个最小默认的行高的高度。即使你的标签是空的,这个标签的高度还是会达到默认的行高。
  • 浏览器兼容问题四:行内属性标签,设置display:block后采用float布局,又有横行的margin的情况,IE6间距bug
    问题症状:IE6里的间距比超过设置的间距
    碰到几率:20%
    解决方案:在display:block;后面加入display:inline;display:table;
    备注:行内属性标签,为了设置宽高,我们需要设置display:block;(除了input标签比较特殊)。在用float布局并有横向的margin后,在IE6下,他就具有了块属性float后的横向margin的bug。不过因为它本身就是行内属性标签,所以我们再加上display:inline的话,它的高宽就不可设了。这时候我们还需要在display:inline后面加入display:talbe。
  • 浏览器兼容问题五:图片默认有间距
    问题症状:几个img标签放在一起的时候,有些浏览器会有默认的间距,加了问题一中提到的通配符也不起作用。
    碰到几率:20%
    解决方案:使用float属性为img布局
    备注:因为img标签是行内属性标签,所以只要不超出容器宽度,img标签都会排在一行里,但是部分浏览器的img标签之间会有个间距。去掉这个间距使用float是正道。(我的一个学生使用负margin,虽然能解决,但负margin本身就是容易引起浏览器兼容问题的用法,所以我禁止他们使用)
  • 浏览器兼容问题六:标签最低高度设置min-height不兼容
    问题症状:因为min-height本身就是一个不兼容的CSS属性,所以设置min-height时不能很好的被各个浏览器兼容
    碰到几率:5%
    解决方案:如果我们要设置一个标签的最小高度200px,需要进行的设置为:{min-height:200px; height:auto !important; height:200px; overflow:visible;}
    备注:在B/S系统前端开时,有很多情况下我们又这种需求。当内容小于一个值(如300px)时。容器的高度为300px;当内容高度大于这个值时,容器高度被撑高,而不是出现滚动条。这时候我们就会面临这个兼容性问题。

2. CSS hack

  • 请谨慎使用 css hack
  • In modern computing terminology, a kludge (or often a “hack“) is a solution to a problem, doing a task, or fixing a system that is inefficient, inelegant, or even unfathomable, but which nevertheless (more or less) works.
    (from wiki: Kludge)
    也就是说,hack 是不优雅的、不是最有效的,甚至是不能理解的,但是能搞定问题的解决办法。
    那么 CSS hack 呢?CSS hack 就是利用浏览器一些不标准的,或者可以称之为 bug 的特性,达到特定的目的。最常见的各种 hack 是关于 ie 的,尤其是旧版本 ie。这种 hack 比较无奈,但是相对安全,因为旧版本 ie 不再更新了,不会发生变化了。
    但是,如果用一些当前浏览器的 bug 来 hack,就是有危险的了。这种 hack 建立在不稳定的浏览器特性上,没有标准可依。当浏览器厂商修复/标准化了这个特性的时候,hack 就可能失效。这样就解释了问题的这句话。
  • 说实话,笔者到现在为止还没有用到过CSS hack。个人认为原因有三:1. 笔者太菜,遇到的场景不够丰富,运气好没有踩到过坑;2.一些浏览器bug已经随着浏览器的版本更新被修复掉;3.遇到要使用CSS hack的情况了却没有意识到,换了种方式去实现了。最最最最究极原因,笔者所在的公司不需要支持 IE9 一下的老古董,甚至在某些项目里可以直接舍弃掉IE,是不是很羡慕?

JS篇

1. 集合类对象的()与[]的问题
IE下,可以使用()或[]获取集合类对象;Firefox下,只能使用[]获取集合类对象。
Js代码
document.write(document.forms(“formName”).src);
//该写法在IE下能访问到Form对象的src属性
解决办法:将document.forms(“formName”)改为 document.forms[“formName”]。统一使用[]获取集合类对象。

2. 对浏览器Native组件调用属性、方法大小写问题
IE:不区分大小写
FF、Chrome:区分大小写
如:Ajax返回的response对象,IE支持response.responseXml和responseXML;FF等浏览器支持response.responseXML,解决办法只有在编写程序时尽量避免不兼容的写法

3. new Date().getYear()
分析原因:在IE中得到的日期是2011,在FF和Safari中看到的日期是111,原因是在FF和safari返回的是当前年份-1900的值。
兼容处理:
Js代码:

//方式一  
var year= new Date().getYear();  
year = (year<1900?(1900+year):year);  
document.write(year);  


//方式二  
var year = new Date().getFullYear();  
document.write(year);

4. innerText的使用
分析原因:FF不支持innerText,它支持textContent来实现innerText,不过textContent没有像innerText一样考虑元素的display方式,所以不完全与IE兼容。如果不用textContent,字符串里面不包含HTML代码也可以用innerHTML代替。
兼容处理
通过判断不同浏览器做不同的处理
Js代码 javascript

if(document.all){  
   document.getElementById('element').innerText = "mytext";  
} else{  
   document.getElementById('element').textContent = "mytext";  
}

注:Safari和Chrome对innerText和textContent都支持。

5. Frame的引用
【分析原因】
IE可以通过id或者name访问这个frame对应的window对象;而FF只可以通过name来访问这个frame对应的window对象。

【应用场景】
在一个页面嵌套了一个iframe页面(下面简称父页面和子页面)。父页面取子页面的值。
Js代码

<iframe id="frame_id" src="frametest.jsp" width="100%" height="100%" title="你好世界">

此时如果父页面想获取子页面例如div中的显示值,IE下可以这样写:

 var obj = window.top.frame_id.document.getElementById(div_id);
 alert(obj.innerText);

但是在FF中却无法取子页面中的值,原因就是FF只支持window.top.frameName来访问子页面中的window对象。所以在IE、safari中是支持通过frameName或是frameId来访问子页面window对象的。
解决方法:
1、尽量都是用frameName去访问子页面window对象。
2、在FF、IE、Safari中都支持window.document.getElementById(frameId)来获得子页面window对象。

HTML 篇

  1. 如有以下这样一段代码:
    <div id="test">
    <p>文字</p>
    <p>文字</p>
    <p>文字</p>
    </div>

单从HTML结构表象来看,ID test 一共有3个P元素子节点。其实,在IE下,这种表象就是实质,而在非IE下,表象的外衣将顷刻被撕开。
为了看出这种区别,我们可以遍历test的子节点,并将其节点个数及节点类型都打印出来:

<script type="text/javascript">
var x = document.getElementById("test");
var xc = x.childNodes;
var xcl = xc.length;
for(var i=0;i<xcl;i++){
document.write("nodeName = " + xc[i].nodeName + "; nodeType = " + xc[i].nodeType + "<br />");
</script>

IE的打印结果为:

nodeName = P; nodeType = 1
nodeName = P; nodeType = 1
nodeName = P; nodeType = 1

非IE的打印结果为:

nodeName = #text; nodeType = 3
nodeName = P; nodeType = 1
nodeName = #text; nodeType = 3
nodeName = P; nodeType = 1
nodeName = #text; nodeType = 3
nodeName = P; nodeType = 1
nodeName = #text; nodeType = 3

显而易见,IE的打印结果和我们所说的表象一样:有3个子节点,并且都为P元素;而非IE则表现出极大的差异:居然打印出了7个子节点,当然也包括3个P元素子节点在内,除此之外还多了4个nodeType=3的子节点,我们都知道节点类型为3的节点属于文本节点,但从那段HTML中可以看P与 P之间并无其它的内容出现,那这4个文本节点是怎样凭空出现的呢?
在这种情况下,唯一有可能的原因就是在HTML的书写上,因为这段HTML并不是连续的书写,而是每个节点间都用回车换行了,并且正好出现了4次换行,也许非IE把换行也当成了一个节点。
为了测试,我们可以将那段HTML改写为:

<div id="test"><p>文字</p><p>文字</p><p>文字</p></div>

IE的打印结果为:

nodeName = P; nodeType = 1
nodeName = P; nodeType = 1
nodeName = P; nodeType = 1

非IE的打印结果为:

nodeName = P; nodeType = 1
nodeName = P; nodeType = 1
nodeName = P; nodeType = 1

预想中的情况出现了,这回不论什么浏览器打印出来的都只是3个P子节点。

一些很基础却很不起眼的冷知识

  • DOCTYPE
    1. 作用:声明文档的解析类型(document.compatMode),避免浏览器的怪异模式。
    document.compatMode: BackCompat:怪异模式,浏览器使用自己的怪异模式解析渲染页面。 CSS1Compat:标准模式,浏览器使用W3C的标准解析渲染页面。
    这个属性会被浏览器识别并使用,但是如果你的页面没有DOCTYPE的声明,那么compatMode默认就是BackCompat,
    这也就是恶魔的开始 — 浏览器按照自己的方式解析渲染页面,那么,在不同的浏览器就会显示不同的样式。
    如果你的页面添加了<!DOCTYPE html>那么,那么就等同于开启了标准模式,那么浏览器就得老老实实的按照W3C的标准解析渲染页面,这样一来,你的页面在所有的浏览器里显示的就都是一个样子了。
    这就是<!DOCTYPE html>的作用。
    2. 常用的 DOCTYPE 声明:
    HTML 5

    <!DOCTYPE html>

HTML 4.01 Strict
该 DTD 包含所有 HTML 元素和属性,但不包括展示性的和弃用的元素(比如 font)。不允许框架集(Framesets)。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

HTML 4.01 Transitional
该 DTD 包含所有 HTML 元素和属性,包括展示性的和弃用的元素(比如 font)。不允许框架集(Framesets)。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML4.01Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">

HTML 4.01 Frameset
该 DTD 等同于 HTML 4.01 Transitional,但允许框架集内容。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0 Strict
该 DTD 包含所有 HTML 元素和属性,但不包括展示性的和弃用的元素(比如 font)。不允许框架集(Framesets)。必须以格式正确的 XML 来编写标记。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Transitional
该 DTD 包含所有 HTML 元素和属性,包括展示性的和弃用的元素(比如 font)。不允许框架集(Framesets)。必须以格式正确的 XML 来编写标记。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.0 Frameset
该 DTD 等同于 XHTML 1.0 Transitional,但允许框架集内容。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.1
该 DTD 等同于 XHTML 1.0 Strict,但允许添加模型(例如提供对东亚语系的 ruby 支持)。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

废话太多了,你只需要记住每个页面头部都写这么一句话就ok了!

<!DOCTYPE html>
  • 浏览器渲染原理
    Web页面运行在各种各样的浏览器当中,浏览器载入、渲染页面的速度直接影响着用户体验简单地说,页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。先来大致了解一下浏览器都是怎么干活的:
    1. 用户输入网址(假设是个html页面,并且是第一次访问),浏览器向服务器发出请求,服务器返回html文件;
    2. 浏览器开始载入html代码,发现<head>标签内有一个<link>标签引用外部CSS文件;
    3. 浏览器又发出CSS文件的请求,服务器返回这个CSS文件;
    4. 浏览器继续载入html中<body>部分的代码,并且CSS文件已经拿到手了,可以开始渲染页面了;
    5. 浏览器在代码中发现一个img标签引用了一张图片,向服务器发出请求。此时浏览器不会等到图片下载完,而是继续渲染后面的代码;
    6. 服务器返回图片文件,由于图片占用了一定面积,影响了后面段落的排布,因此浏览器需要回过头来重新渲染这部分代码;
    7. 浏览器发现了一个包含一行Javascript代码的<script>标签,赶快运行它;
    8. Javascript脚本执行了这条语句,它命令浏览器隐藏掉代码中的某个
    (style.display=”none”)。杯具啊,突然就少了这么一个元素,浏览器不得不重新渲染这部分代码;
    9. 终于等到了</html>的到来,浏览器泪流满面……
    10. 等等,还没完,用户点了一下界面中的“换肤”按钮,Javascript让浏览器换了一下<link>标签的CSS路径;
    11. 浏览器召集了在座的各位span ul li 们,“大伙儿收拾收拾行李,咱得重新来过……”,浏览器向服务器请求了新的CSS文件,重新渲染页面。
    浏览器每天就这么来来回回跑着,要知道不同的人写出来的html和css代码质量参差不齐,说不定哪天跑着跑着就挂掉了。好在这个世界还有这么一群人——页面重构工程师,平时挺不起眼,也就帮视觉设计师们切切图啊改改字,其实背地里还是干了不少实事的。
    说到页面为什么会慢?那是因为浏览器要花时间、花精力去渲染,尤其是当它发现某个部分发生了点变化影响了布局,需要倒回去重新渲染,内行称这个回退的过程叫reflow。

reflow几乎是无法避免的。现在界面上流行的一些效果,比如树状目录的折叠、展开(实质上是元素的显示与隐藏)等,都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化,都会引起它内部、周围甚至整个页面的重新渲染。通常我们都无法预估浏览器到底会reflow哪一部分的代码,它们都彼此相互影响着。

reflow问题是可以优化的,我们可以尽量减少不必要的reflow。比如开头的例子中的 img 图片载入问题,这其实就是一个可以避免的reflow——给图片设置宽度和高度就可以了。这样浏览器就知道了图片的占位面积,在载入图片前就预留好了位置。
另外,有个和reflow看上去差不多的术语:repaint,中文叫重绘。 如果只是改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性,将只会引起浏览器repaint。repaint的速度明显快于 reflow(在IE下需要换一下说法,reflow要比repaint 更缓慢)。

  • 从浏览器的渲染原理讲CSS性能

平时我们几乎每天都在和浏览器打交道,写出来的页面很有可能在不同的浏览器下显示的不一样。苦逼的前端攻城师们为了兼容各个浏览器而不断地去测试和调试,还在脑子中记下各种遇到的BUG及解决方案,而我们好像并没有去主动地关注和了解下浏览器的工作原理。如果我们对此做一点了解,我想在项目过程中就可以根据它有效的避免一些问题以及对页面性能做出相应的改进。今天我们主要根据浏览器的渲染原理对CSS的书写性能做一点改进,下面让我们一起来揭开浏览器的渲染原理这一神秘的面纱吧:
最终决定浏览器表现出来的页面效果的差异是:渲染引擎 Rendering Engine(也叫做排版引擎),也就是我们通常所说的“浏览器内核”,负责解析网页语法(如HTML、JavaScript)并渲染、展示网页。相同的代码在不同的浏览器呈现出来的效果不一样,那么就很有可能是不同的浏览器内核导致的。
我们来看一下加载页面时浏览器的具体工作流程:

1、解析HTML以重建DOM树(Parsing HTML to construct the DOM tree ):渲染引擎开始解析HTML文档,转换树中的标签到DOM节点,它被称为“内容树”。
2、构建渲染树(Render tree construction):解析CSS(包括外部CSS文件和样式元素),根据CSS选择器计算出节点的样式,创建另一个树 —- 渲染树。
3、布局渲染树(Layout of the render tree): 从根节点递归调用,计算每一个元素的大小、位置等,给每个节点所应该出现在屏幕上的精确坐标。
4、绘制渲染树(Painting the render tree) : 遍历渲染树,每个节点将使用UI后端层来绘制。
主要的流程就是:构建一个dom树,页面要显示的各元素都会创建到这个dom树当中,每当一个新元素加入到这个dom树当中,浏览器便会通过css引擎查遍css样式表,找到符合该元素的样式规则应用到这个元素上。
注意了:css引擎查找样式表,对每条规则都按从右到左的顺序去匹配。 看如下规则:

#nav  li {}

看起来很快,实际上很慢,尽管这让人有点费解。我们中的大多数人,尤其是那些从左到右阅读的人,可能猜想浏览器也是执行从左到右匹配规则的,因此会推测这条规则的开销并不高。在脑海中,我们想象浏览器会像这样工作:找到唯一的ID为nav的元素,然后把这个样式应用到直系子元素的li元素上。我们知道有一个ID为nav的元素,并且它只有几个Li子元素,所以这个CSS选择符应该相当高效。
事实上,CSS选择符是从右到左进行匹配的。了解这方面的知识后,我们知道这个之前看似高效地规则实际开销相当高,浏览器必须遍历页面上每个li元素并确定其父元素的id是否为nav。

*{}

额,这种方法我刚写CSS的也写过,殊不知这种效率是差到极点的做法,因为*通配符将匹配所有元素,所以浏览器必须去遍历每一个元素,这样的计算次数可能是上万次!

ul#nav{} ul.nav{}

在页面中一个指定的ID只能对应一个元素,所以没有必要添加额外的限定符,而且这会使它更低效。同时也不要用具体的标签限定类选择符,而是要根据实际的情况对类名进行扩展。例如把ul.nav改成.main_nav更好。

ul li li li .nav_item{}

对于这样的选择器,之前也写过,最后自己也数不过来有多少后代选择器了,何不用一个类来关联最后的标签元素,如.extra_navitem,这样只需要匹配class为extra_navitem的元素,效率明显提升了
对此,在CSS书写过程中,总结出如下性能提升的方案:
1.避免使用通配规则 如 *{} 计算次数惊人!只对需要用到的元素进行选择
2.尽量少的去对标签进行选择,而是用class 如:#nav li{},可以为li加上nav_item的类名,如下选择.nav_item{}
3.不要去用标签限定ID或者类选择符 如:ul#nav,应该简化为#nav
4.尽量少的去使用后代选择器,降低选择器的权重值 后代选择器的开销是最高的,尽量将选择器的深度降到最低,最高不要超过三层,更多的使用类来关联每一个标签元素
5.考虑继承 了解哪些属性是可以通过继承而来的,然后避免对这些属性重复指定规则
选用高效的选择符,可以减少页面的渲染时间,从而有效的提升用户体验(页面越快,用户当然越喜欢_),你可以看一下CSS selectors Test,这个实验的重点是评估复杂选择符和简单选择符的开销。也许当你想让渲染速度最高效时,你可能会给每个独立的标签配置一个ID,然后用这些ID写样式。那的确会超级快,也超级荒唐!这样的结果是语义极差,后期的维护难到了极点。
但说到底,CSS性能这东西对于小的项目来讲可能真的是微乎其微的东西,提升可能也不是很明显,但对于大型的项目肯定是有帮助的。而且一个好的CSS书写习惯和方式能够帮助我们更加严谨的要求自己。

结语

能看到这里,你才是赚到了。上面BB了那么多,想必客官一定看得头晕雾绕了。大家心里一定有个疑问,浏览器兼容性有这么恶心人吗?有没有一个好的解决方案呢?答案是一定的,那就是框架,各种各样的框架。
啥是框架?
框架从本质上来说,就是帮你干活,让你少操心,什么兼容性了、底层的东西了统统交给我。你只需要告诉我你要干嘛,我全帮你搞定了。当然了,帮你搞定兼容性也是有代价的,那就是牺牲性能换兼容性。不过在这个硬件过剩的时代,使用框架所消耗掉的那点性能绝对是可以接受的,反正我相信大家肯定不愿意天天被测试追着问 “xxx,IE下又白屏了,IE下又没居中了,IE下样式又乱掉了….”。嗯,笔者对 IE 绝对没(shen)有(wu)成(tong)见(jue).
关于框架怎么用?且听下回分解~